Summary

  • RFC 1016 proposed SQuID, Source Quench Introduced Delay: the source IP module would keep a delay D for recently contacted destinations and wait D between datagrams sent to each affected destination.
  • Its example parameters started D at at least 75 ms after a warning, added 20 ms for a later warning event, coalesced warnings within two seconds, and reduced D by 1 ms after each qualifying second with data to send. The authors tested the idea in a C simulation, not in a reported live deployment.

A source-quench message was the network's version of a raised eyebrow. A gateway whose output queue was running short of room could drop a datagram and ask the sending host to slow traffic toward that destination. A destination could also send the warning. But “slow down” left an awkward question: by how much? In July 1987, W. Prue and Jon Postel answered with a small clock at the source. Their RFC 1016 called the scheme SQuID, a name with enough mischief to match the memo's own description of itself as a crazy idea paper.

The pressure was real even in simple arithmetic. The RFC observed that the last datagram behind one megabyte of data queued for a 56 kb/s line would wait more than two minutes. A fast local network could feed a slow wide-area line much faster than that line could drain. By the time a gateway complained, packets might already have been discarded. The warning identified a destination whose flow needed restraint; it did not arrive carrying a neatly calculated waiting time for the source.

SQuID put that calculation in the source host's IP module. For a given destination, D was the introduced pause between sending datagrams. Normally D was zero. A host stored entries only when a destination had a nonzero delay, keeping a small cache for recently contacted hosts. A packet for an unaffected destination could leave while another destination waited. The proposal therefore made the warning specific to the path that had attracted it, instead of forcing every outgoing packet into the same queue of penance.

The example algorithm gave D a quick upward move and a slow way home. On a source-quench event, D became the greater of its old value plus 20 milliseconds or a 75-millisecond floor. One or several warnings inside a two-second event period counted as one increase. That mattered because a gateway might report many dropped packets in a burst; treating every warning as an independent order could make the host overreact. After a qualifying second with data to send, D could fall by one millisecond, never below zero. A quiet destination did not automatically earn a fresh start just because a clock ticked while no packets were waiting.

The paper chose those numbers for its experiment. They show the design's tempo. The source slowed sharply when the network signaled trouble, then tested its way back toward immediate sending. A 75-millisecond pause sounds tiny in ordinary life. Placed between every datagram to one destination, it changes how quickly a burst can reach a narrow link. The host had turned a complaint into a repeatable action.

The authors also gave the gateway a more nuanced script. At an illustrative 70% queue level, SQ Keep, it could warn the source while still forwarding the triggering datagram. At a 95% SQ Toss level, it could discard data as pressure became critical. Warnings would continue until the queue fell below a 50% low-water mark. These thresholds were part of a proposed design and test model. The important division of work was clear: the gateway observed its queue and sent a pressure signal; the host's IP module translated that signal into spacing.

Prue and Postel wrote a C simulation to see what happened when that arrangement met TCP traffic. Their example path placed a 56 kb/s wide-area link between two 10 Mb/s local networks. The model used packet queues, 512-byte datagrams and fixed routing; it left out fragmentation and TTL behavior. In their tests, all algorithms oscillated. Increasing D too timidly and decreasing it too quickly kept the source driving the network into drops. An increase of roughly 20 milliseconds per warning event and a decrease of one millisecond per active second looked more promising in that model.

A flood of warnings, in turn, needed the two-second coalescing window.

One of the model's clearest scenes involved a 20-datagram TCP burst racing from a fast LAN toward the slow link. The RFC's calculation put those packets into the gateway's neighborhood in 81 milliseconds, while only one could cross the next segment in roughly 73 milliseconds. The last four packets of the burst were lost under the chosen queue settings. The issue was not that the sending application lacked enthusiasm. It had more enthusiasm than the queue had room. Spacing packets upstream was a way to make the fast side respect the slow side's calendar.

This was an experiment in who should respond to a network warning. The memo noted that many TCP implementations did not receive a well-defined source-quench notification from IP and ICMP. By placing delay in source IP, SQuID could pace traffic before it joined the outgoing path, while letting other destinations continue. The model suggested that early warnings, before discarding, could improve effective throughput. The authors also admitted the model's limits through its fixed routes and simplified traffic. The stopwatch remained an implementable proposal being argued in public.

What makes the 1987 design memorable is the mismatch between a blunt message and a precise response. “Slow down” came from a queue under pressure. “Wait this long, then try again” belonged to the sender. SQuID wrote that handoff in milliseconds, one destination at a time. The gateway could raise its voice. The host still had to decide how long to hold its breath.