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

[Noel Chiappa]

    > From: Ted Faber <faber at ISI.EDU>

    > that inference and reaction is required. Not reacting to congestion
    > results in congestion 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 

Good point.

So I'm not sure SQ really solves Brian's problem (how to sort out congestion
drops from packets lost because of errors). If you _do_ get an SQ, you _can_
be sure it was congestion - but otherwise... who knows?

    > Furthermore several good systems for piggybacking significant
    > congestion information on existing packets exist (from DECBit to XCP

Right, but do they solve Brian's problem? I don't remember enough about
XCP - I keep re-reading it and then promptly forgetting it again! :-)

Whatever the solution is, it _has_ to be something that involves the
routers in the middle - because only they know whether, when a packet
is tossed in the middle, if it's due to congestion or error.


    > From: Wesley Eddy <wes at mti-systems.com>

    > A decent summary of rationale is in RFC 6633 

Ah, there's no answer there to my question about 'does SQ work if it is used
correctly'. It basically seems to say 'we stopped using this aeons ago, this
is the formal death notice'. It sent me to RFC-1812, but that also didn't say
directly; _it_ sent me off to two other papers, one which seems not to be
online, and the other is only available behind a paywall.

It does mention some good reasons not to use SQ (e.g. it might be an attack
vector), but again, this doesn't answer the fundamental question (above) -
and if it was really useful, there might be away around the DoS etc issues.

	Noel