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

[Ted Faber]

On 05/21/14 17:06, Noel Chiappa wrote:
>     > From: Bob Braden <braden at ISI.EDU>
> 
>     > Source Quench was a perfect example of our pre-VJ cluelesssness. Wwhat
>     > seemed a plausible congestion control mechanism was in fact completely
>     > broken.
> 
> Here is the 'SQ is wrong' meme again. But was it really broken, or did we
> just not know how to use it?

The SQ ICMP packet is a signal from the network to the endpoint that
congestion exists.  That's what the endpoint wants to know (in the world
of congestion control), of course, so sending the message seems a
straightforward plan.  The explicit message can have all kinds of
additional data in it that the endpoint can use to change plans.

So far, the fault's in us.  Consider, however the case where the path
that the SQ will take back to the endpoint is congested itself.  People
have waved their hands about considerably about how likely that is, but
it certainly happens.  If the path is congested, the endpoint needs
machinery to infer congestion exists and react to it in the absence of
quench packets.

IMHO, that inference and reaction is required.  Not reacting to
congestion results in congestion collapse. In a system that relies on
explicit congestion signals, attackers may even preferentially corrupt
SQ's to cause collapse.

Implementing SQ, or any explicit congestion signal, is at best a hint.
It doesn't save any code or thinking in the endpoints, because the
congestion control system has to work when all SQs get lost or (dun,
dun, dun: murdered!).  Furthermore several good systems for piggybacking
significant congestion information on existing packets exist (from
DECBit to XCP with a couple interesting points between).

The upshot is that I find SQ pedagogically useful, but practically
subsumed by other systems.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP:
http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See
http://www.isi.edu/~faber/FAQ.html#SIG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140521/f9c76370/attachment.asc>