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

[Noel Chiappa]

    > From: Jack Haverty <jack at 3kitty.org>

    > So a gateway (router) that had to discard a packet because no buffers
    > were available

Ah, no. I don't know about other routers, but the one I did discarded a
packet _when the output queue on a particular network got too long_. My
router in fact worked very hard never to run out of buffers, and in fact
would start tossing packets _before_ it used up the last buffer.

Basically it tried to prevent one backed-up interface from interfering with
the the operation of the other interfaces, so once an interface used up more
than its 'fair share' of buffers, the code started keeping a rein on it. (I
will pass over the details of its algorithm for the moment, I'm not sure it's
relevant.)

    > sent a SQ to the Host that had sent that packet. That's the
    > best it could do ... that SQ could have gone to some Host that really
    > had nothing to do with the excessive traffic that was causing the
    > problem. 

But that's pretty much what congestion drop is (at least, in the early days;
now we know about the evils of tail-drop, and we have RED and all that
stuff). You took some random packet, which might or might not be from a
problem source, and shot it.

And even those new target selection mechanims are still probabilistic - you
take some packet and shoot it, and _hope_ you got someone who's _a_ cause of
the problem, and not some innocent by-stander, but there's no guarantee -
it's just that these new algorithms are _more likely_ to zap a packet from a
problem source.

    > 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.

I'm tempted to say something really snarky, but I will refrain. :-)

    > 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

You're talking about a mostly orthogonal problem (identification of actual
congestion sources) - see above. That's a non-trivial problem, and there has
been a lot of work on it, but I do think it's separable from what I'm
focusing on here.

Assume for the sake of this discussion that we have a perfect crystal ball
procedure that will identify the 'bad packets'. Now, does SQ work if it is
used 'correctly' (i.e. as an input to a working congestion control mechanism
on the source host, an input that says 'congestion is happening')?

	Noel