[e2e] Why was hop by hop flow control eventually abandonded?
detlef.bosau at web.de
Wed Jul 17 11:25:29 PDT 2013
Am 17.07.2013 14:50, schrieb dpreed at reed.com:
> The end-to-end argument (which I developed and Jerry decided to write down) is quite specific: if you can't do the function entirely in the network, focus on how to do it at the end-to-end level.
"The network" sounds a bit confusing to me: "The network" sounds like a
more or less closed "block".
And particularly VJCC has a typical "black box approach" to the network.
> And the *congestion control* function is one that cannot achieve entirely in the network. The reason is simple: congestion management requires the endpoints to change their behavior in one or more ways.
Absolutely. Particularly the reason for congestion is offering more load
to the network than the network can carry. And this misbehaviour is to
When I take a white box view on networks, I may understand congestion
control as a sequence, or mesh, of concatenated flow controls. (To me,
flow control makes sure that not more data is sent than the receiver can
accept, congestion control makes sure that no more data is sent than
links and nodes along the path can store.)
Perhaps, Jon is a bit on the white box side here?
> By conflating "flow control" (which has to do with orderly sequencing and local error management) and congestion control (which has to do with *resource allocation* among unanticipatable bursty exogenous demand) you don't further understanding of the problem.
> Air traffic control involves both congestion and flow control. Congestion control is a negotiation solely between endpoints of "trips", while flow control is about keeping airplanes separated in the air so they don't collide or get forced to land.
> The original separation of these concepts was the design choice in TCP that made the system scalable and robust with respect to topology and dynamics of the underlying network.
I'm not quite sure whether flow and congestion control are intentionally
separated in TCP. To me, VJCC appears as a (actually quite reasonable)
kludge to solve the problem with an extreme black box view of the network.
Today, however, we see the limits of this network view on the one hand -
and have the technical possibilities for a white box view on the other.
> To do congestion control, one needs to have inputs.
> Perhaps the controversial thing in TCP you might want to focus on is not the falsely confused congestion and flow control functions, but the idea that packet drops are integral to providing input to the distributed negotiation among endpoints.
They are an important means for this purpose. However, others exist.
(I was thinking about IP over Avian Carriers quite some time yesterday.
And I had a first glance at the XCP work as well. And my impression was
that VJCC is neither a good idea for congestion control in carrier
pigeons nor in LFN networks. It works quite reasonable for a number of
technologies and a black box approach, however, for particular
technologies there may be smarter approaches.)
> It need not have been so - a simple alternative would have been to record in each packet how much excess queueing delay it encountered during its end-to-end path, and develop a distributed control algorithm that min-maxed a figure of merit consisting of global end-to-end queuing delay "excess".
Sounds like some kind of banker's algorithm ;-)
> Strategies such as source routing (for path selection), dynamic route-table optimization (for traffic engineering dynamically), codec changes (to change the underlying needed bitrate, or to take advantage of FEC to recover lost packets), low-rate or rateless erasure coding, and even "network coding" all need *end-to-end* congestion control.
And why shouldn't these strategies take advantage from local information
on intermediate network nodes?
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest