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

[Xiaoliang "David" Wei]

    I really enjoyed reading this thread -- lots of wisdom and history from
what all the gurus have said. :)

    I would add two cents with my experience of playing with the rwnd:

1. rwnd is not critical for the correctness of TCP. So, yes, we can remove
rwnd without breaking TCP's correctness.

    The TCP algorithm is very robust to guarantee reliability and avoid
congestion. If we remove rwnd, the receiver buffer will just be viewed as
part of (the last hop of) the network model in the congestion control
algorithm, and receiver dropping the packet (due to lack of buffer) will be
a congestion signal to the sender to slow down. This will work, though the
sender now has to "guess" the receiver's buffer with the *same* assumption
of network congestion, and the guessing function will be the same congestion
control algorithm such as AIMD or whatever loss based algorithms -- not
necessary sawtooth if your algorithm is not AIMD. So, removing rwnd control
will be OK (maybe less efficient), and works well when the receiving
application is not the bottleneck, or the receiving application has a
similar processing pattern as network processing patterns.


2. Why do we want to remove rwnd control (John's question)?  rwnd has its
own goodness and badness:

    Pro: rwnd control is very good in avoiding buffer overflow -- no loss
will happen for lack of receiving buffer (unless OS some buffer negation).

    Con: However, rwnd is not very good in using the buffer efficiently, esp
with small buffer cases. With rwnd control, we have to allocate BDP worth of
buffer at the receiver to fully utilize the network capacity. However, this
BDP worth of buffer is not always necessary at all -- Think about an extreme
case that the receiving application has a much larger processing capacity,
and each packet arrives at the receiver side can be immediately consumed by
the application: we only need to have 1 packet worth of buffer to hold that
received packet.  But with rwnd control, sender will only send a maximum of
rwnd packets each RTT, even there is no queue-up at the receiver side at
all! (As David Reed pointed out, the rwnd should indicate the receiving
app's processing capacity, but unfortunately, the current way of indication
is through available buffer size, which is not always an accurate
indication.)
    This trouble is particular obvious with the majority OS implementations
of the last generation. As many research (e.g. web100) pointed out a few
years ago, most of the TCP connections are bounded by a very small default
buffer of Windows and also Linux. While it is easy to change the server's
sending buffer, the clients' receiver buffer (usually lies in millions of
customers Windows boxes) is hard to change. So, if we can remove the rwnd
control (e.g. having the sender ignore the rwnd and only rely on congestion
control), we might improve the connection speed and don't even have extra
loss if the receivers can process all the packets quickly. I remember some
of the network enhancement units on the market actually do such a feature
(with other features to reduce the negative effect of ignoring rwnd). This
reason, however, will probably be weaken as Vista and Linux 2.6 both come
with buffer auto-tuning.

3. rwnd is very important for the responsiveness and adaptability of TCP.
So, no, please don't remove rwnd until you get a good solution for all TCP
usages.:)

    TCP are used almost universally in all reliability traffic. Bulk traffic
where network is bottle-necked usually satisfies above conditions that
receiver is not a bottleneck. However, there are also many cases that the
receiver is slow, or the receiver's processing pattern is completely
different from network router (and hence congestion control algorithm's
estimation will completely go off).

    Just give an example of networked-printer. When a networked-printer runs
out of paper, it is data processing capability quickly drops to zero and
lasts for minutes, then after feeding paper, its capacity quickly jumps back
to normal. This on-off pattern is very different from most network
congestion, and I don't see TCP congestion control algorithms can handle
such case responsively. In this case, rwnd control has its own advantage:
great responsiveness (by preventive control, explicit notification when the
buffer opens up and etc).

    Note that to achieve such great responsiveness, rwnd control is designed
to be very conservative and preventive -- sender (at this moment) can at
most send data up to whatever the receiver (half RTT ago) could receive.
This conservativeness guarantees that no packet will be dropped even
application completely shut down its processing after announcing the rwnd.
ECN and other explicit congestion control provide no such guarantee and
cannot achieve the same responsiveness to a sudden capacity shutdown.

    I think there are a lot other applications that have very different
processing patterns and it is very hard to have one algorithm to predict all
these patterns efficiently.

    So, my understanding here is that:
    A. if the receiver is very fast, we don't need rwnd control at all;
    B. if the receiver's processing pattern is similar to network congestion
and if tcp congestion does a good job, we don't need rwnd either.
    C. The two "if" in A and B might stand in some cases, but not all the
usage cases. I don't expect TCP will work as universally well as
it currently does if we don't have rwnd control.


-David


On Thu, Jun 26, 2008 at 12:38 AM, Michael Scharf <
michael.scharf at ikr.uni-stuttgart.de> wrote:

> Hi,
>
> maybe this is a stupid question: Is there really a need for the TCP
> flow control, i. e., for signaling the receiver window back to
> the sender?
>
> It is well known that TCP realizes both congestion control and flow
> control, and that a TCP sender therefore maintains two different
> windows (cwnd and rwnd). Obviously, the congestion control protects
> the path from overload, while the flow control protects the receiver
> from overload.
>
> However, I have some difficulties to understand why the flow control
> part and receiver advertized window is actually needed.
>
> Instead of reducing rwnd, an overloaded receiver running out of buffer
> space could simply drop (or mark) new arriving packets, or just
> refrain from sending acknowledgements. 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.
>
> 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.
>
> Are there reasons why TCP can't just use its congestion control to
> handle slow receivers?  Do I overlook some aspect?  Any hint or
> reference would be welcome.
>
> Michael
>
>


-- 
Xiaoliang "David" Wei
http://davidwei.org
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080627/36acaa2f/attachment-0001.html