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

[Ted Faber]

On 05/21/14 20:15, Noel Chiappa wrote:
>     > 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?

I don't want to go too far on this list, because I'm not really talking
about the history of the thinking.

That said :-), there are two problems here: what does a network element
know that an endpoint would benefit from knowing, and how does the
element communicate that info if it knows any.

I don't think there's a compelling case to use a separate packet a la SQ
for doing the communication.  The info would have to be both extremely
important and the benefit of sending it immediately rather than
piggybacking extremely high to justify sending a separate packet. That
packet's at best a hint so unless the info is unbelievably valuable just
send it along in due course.
> 
>     > 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! :-)

There's a lot in there, IMHO, but I think the XCP model of congestion is
fairly conventional - too many packets for the store and forward engine
to keep up with.

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

My 2 cents: the congestion/corruption distinction sounds very
interesting to explore, but the urge to prematurely optimize is almost
pathological.  The corruption/congestion line can be blurry depending on
the technology - load can make corruption more likely or not - and a
good architecture should consider those possibilities.  A lot of people
seem to come at it bottom up with the attendant preconceptions from
their technology and shut the door to interactions that seem obvious to
people from other backgrounds.

-- 
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/20140522/83188ad0/attachment.asc>