[e2e] Why was hop by hop flow control eventually abandonded?

[Ted Faber]

On 07/16/2013 08:14, Noel Chiappa wrote:
>     > From: Detlef Bosau <detlef.bosau at web.de>
> 
>     > the decision to abandon hop by hop flow control
>     > ...
>     > Does anyone happen to know, whether this was decision for a concrete
>     > reason and the rational behind it? Or did this "simply happen"?
> 
> Probably the internet-history list is a better place to ask this?
> 
> I don't know for sure, but having arrived on the scene shortly thereafter,
> and knowing intimately what packet switches were like then, my _guess_
> is that it had to do with state.
> 
> It seems to me that to be able to do hop-by-hop flow control, you have to
> have some state in the switches, yes? (I can't see a way to do it without.)

One of the many interesting ideas in Dina Katabi's XCP work is that she
distributes the per-flow/per-switch data into the packets of the flow.
It's not an obvious idea (in my dumb opinion) and reading about XCP with
that in mind is worthwhile.

I think at its core congestion control is an end-to-end problem, not so
much because of state in elements (though that does matter) but
diversity of elements.  End-to-end congestion control makes TCP over
avian carriers possible.

There are many elements in a network path that can become a flow's
bottleneck. There's no way to guarantee that the thing that's
bottlenecked is also smart enough (or honest enough) to participate in
hop-by-hop congestion control.  An end-to-end system can assess the path
and make decisions without cooperation of internal elements (though an
end-to-end system can make use of cooperation that it can get).  No
matter what's slowing your pigeons down, an end-to-end congestion
control will react to it.  Eventually. :-)


-- 
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: 261 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130716/2963a6af/signature.bin