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

[John Heffner]

On Sat, Jun 28, 2008 at 12:13 AM, Xiaoliang David Wei <weixl at caltech.edu> wrote:
> 1. rwnd is not critical for the correctness of TCP. So, yes, we can remove
> rwnd without breaking TCP's correctness.

This is only mostly true -- TCP can maintain a zero window
indefinitely, but the receiver is dropping segments, the sender cannot
distinguish between the network's and the receiver's drops, and will
eventually time out and reset the connection.


> 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

In all modern operating systems, receiver buffer isn't really
"allocated" when the window is announced.  A TCP receiver will
allocate memory only as segments arrive and must be buffered.  The
announced window is used to indicate how much memory TCP might be
willing to commit to buffering data should it suddenly need to.  The
only real reason for not announcing more window is if you know that
typical behavior such as a single loss in the network or a brief
application pause will cause you to drop lots of segments because you
are unwilling or unable to commit the memory.


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

For what it's worth, this is the idea that receive autotuning uses,
though it has never been appropriately documented (mea culpa).  It
measures the amount of data consumed by the application in an RTT, and
uses the maximum as the app's processing capacity.  (Past behavior is
not always a good indication of future behavior, but it's the best
thing we've got.)

  -John