[e2e] Just as an idea. Why can't we use hop by hop flow control for TCP?

[Detlef Bosau]

Am 06.03.2014 13:56, schrieb Roland Bless:
> Hi,
>
> On 02.03.2014 14:52, Detlef Bosau wrote:
>> I'm curious why I did not yet see a hop by hop flow control flavour for
>> TCP. Do I miss something? For ATM Networks, such approaches have been
>> conducted. I think of a classical window based flow control for TCP.
> Because TCP is only running at the edges and you better avoid
> per flow state in the network.

I would like to add a question mark here.

TCP is no way "only running at the end points" - of course, links and
switching nodes along the path are involved and affected.

Vice versa, these nodes affect a TCP flow.

(I talked too much about wireless networks, btw., what wireless networks
are concerned, there is a general wisdom: You cannot make a silk purse
from a sows ear.  And we cannot solve technological problems by
protocols, neither do protocols overcome technological limitations.
Nevertheless, we must ensure, that things are not worsened by protocols.
But we should be extremely careful, not to run into category errors here.)


>> This would be an alternative to the end to end "congestion control".
> Flow control and congestion control have different objectives:
> flow control tries to prevent overloading the receiver, whereas
> congestion control tries to prevent overloading the network.
> So you better consider them separately.

The more I think about it, this appears artificial to me.

I wrote this sometimes before: When you think so, your model is:

Sender -------------------------Line---------------------- Receiver.

In that scenario, end to end flow control makes sense.

However, my concern is that this model is, though appealing,
oversimplified. Just one example: In the sketch above, I don't see any
cross traffic.
The only active elements in the sketch are "Sender" and "Receiver". And
they have to care for anything. No matter what this will be. Traffic
bursts, varying throughtput on a link, link outages, varying offered
network load, whatever.

>From a historical perspective, this model intuitive and justified. In
the days of the ARPAnet and the early Internet, the "Line" was one
"black box".

Where, of course, quite some
- recovery,
- flow control,
- resource management
was done under the hood - and still is.

However, we prefer the bird's eye view, and so TCP flows appear a bit
like tin can telephone.

I further think that this is a misinterpretation of Salzer's paper.

Following Salzer, we should solve local problems locally and global
problems globally. Actually, we solve problems at the end points. (If at
all.)
No matter whether they are local problems or global problems.



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