[e2e] Why do we need TCP flow control (rwnd)?
detlef.bosau at web.de
Mon Jun 30 07:18:46 PDT 2008
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
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
So, basically you can omit both, flightsize and rwnd. However, this
happens to the cost of unnessecary retransmissions, drops and congestion
> 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 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
More information about the end2end-interest