[ih] internet-history Digest, Vol 84, Issue 10

[Jack Haverty]

On Wed, May 21, 2014 at 5:06 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>wrote:

> Here is the 'SQ is wrong' meme again. But was it really broken, or did we
> just not know how to use it?
>

Personally, I always thought SQ was broken, and said so when we first put
it in.

The problem was that SQs were to be sent when a packet was discarded
somewhere in transit.  So a gateway (router) that had to discard a packet
because no buffers were available sent a SQ to the Host that had sent that
packet. That's the best it could do since it didn't remember any kind of
state information or flows etc.   SQ was more accurately an "I dropped your
packet, sorry about that" report that was just called Source Quench,
launched at some possibly irrelevant user process.

Since the gateways had no state information about connections, that SQ
could have gone to some Host that really had nothing to do with the
excessive traffic that was causing the problem.   It could also have gone
to some process with a TCP connection that had nothing to do with the
congestion.   It made little sense for a TCP connection that had just
opened, or that was already sending only a little data (a User Telnet) to
be told to slow down.

Dave Mills figured out that an appropriate response to receiving an SQ was
to immediately retransmit, since you knew that your packet had been
dropped.  This was especially appropriate if your system was hung out on
the end of a low speed dialup line, and thus very very unlikely to be
sending enough traffic to be causing congestion.  This of course did
nothing to reduce traffic at all.

The problem was that an SQ could easily go to a user process that had
nothing to do with the congestion being experienced, and could do nothing
useful to alleviate that congestion.  SQs of course could also create more
congestion themselves.

I think it would have been possible to make smarter gateways that
remembered a lot about recent traffic flows, and could thereby deduce which
ones were causing the problem, directing an SQ to a source that would
actually be appropriate to slow down.  But that would start to look a lot
like a virtual circuit net, where the internal mechanisms knew about flows
and connections, rather than a datagram one.  We already had the ARPANET
with such internal mechanisms.  IP was supposed to be different, lean and
mean with very simple very fast switches and a mix of TCP and UDP traffic.

So, yes we didn't know how to use it, but I think it was also inappropriate
for a "datagram network".

/Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140521/c71c472e/attachment.htm>