[e2e] Why do we need TCP flow control (rwnd)?

[Detlef Bosau]

Michael Scharf wrote:
> However, I have some difficulties to understand why the flow control
> part and receiver advertized window is actually needed.
>   

Well, the path does not know anything about a receiver's capacity - and 
vice versa the receiver does not know anything about the path's capacity.
> Instead of reducing rwnd, an overloaded receiver running out of buffer
> space could simply drop (or mark) new arriving packets, or just
>   

"Mark" is often a bad idea. Of course, you are always free to "mark" 
something. And then pray that the "mark" will reach its goal...
What makes "implicit notification", i.e. drop, particularly appealing is 
that "loss cannot get lost."
NACKs can, marks can, loss can't.
> refrain from sending acknowledgements. 
No. A receiver's buffer may well be smaller than the path's capacity. 
Either way, you must not have more unacknowledged data on the fly than 
the path and the receiver are able to carry. So, if you omit the rwnd, 
you may have much more unacknowledged data on the fly, than a receiver 
my be able to accept.

O.k., when the receiver's buffer is overrun, further packets will be 
dropped and the receiver thus will refrain from sending ACKs anyway. 
This will result in a delayed congestion action (perhaps without any 
actual network congestion) and retransmissions which could be avoided.


> As a reaction to this, the
> sender probably times out and the TCP congestion control significantly
> reduces the sending rate, which reduces the load on the receiver, too.
>   

Michael, I apologize for carrying cowls to newcastle, but there is no 
such thing as rate control or sending rate reduction in (general) TCP.
("general": Of course, I'm aware of rate controlled TCP flavours, e.g. 
Westwood. But these are experimental and not actually deployed.)

> To my understanding, a fine granular receiver advertized window is
> much more efficient if the buffer sizes are of the order of a few
> packets only. But I guess that most of today's Internet hosts have
> larger buffers, and therefore they hardly need a fine granular flow
> control.
>   

??

Of course, you _can_ leave out flow control. But, what is this good for? 
Imagine a long fat line with 100 MByte capacity and an appropriately 
large congestion window and up to 100 MByte of unacknowledged data on 
the fly. Now, you have a queue overrun at the receiver.
How long do you want to do retransmissions without sense (because even 
many of the retranmitted packets are likely to be dropped) until you 
decreased CWND appropriately? (This reminds me a bit on the flightsize 
discussion launched by Daniel Minder's question some time ago, which I 
did not understand for a long time. Perphas, these two issues point into 
a similar direction. However, the flightsize _may_ greatly exceed a 
receiver's buffer.)

So, basically you can omit both, flightsize and rwnd. However, this 
happens to the cost of unnessecary retransmissions, drops and congestion 
actions.

> Are there reasons why TCP can't just use its congestion control to
> handle slow receivers? 


To my understanding, the reason is performance.

>  Do I overlook some aspect?  Any hint or
> reference would be welcome.
>   
One "stupid" question: Do you have a concrete reason to launch this 
discussion? AFAIK TCP flow control is one of the oldest mechanisms in 
TCP, even part of RFC 793 (?). Of couse, it is always valid to put 
things in question. Some months ago, Dave Reed wrote: Science is about 
asking questions and answering them. But I'm a bit curious why we put in 
question a mechanism which is well proven for 30 years now?

Detlef


-- 
Detlef Bosau                          Mail:  detlef.bosau at web.de
Galileistrasse 30                     Web:   http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937