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

[Detlef Bosau]

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

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?

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de