[e2e] Why do we need TCP flow control (rwnd)?
mfisk at lanl.gov
Tue Jul 1 14:55:15 PDT 2008
Detlef Bosau wrote:
> 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
In their Auto-Tuning paper, Mathis, et al essentially disable
flow-control. In our Dynamic Right-Sizing papers, I made the argument
that the receiver would probably like to have more information so that
it can manage its buffers and not let an arbitrarily slow receiving app
consume an arbitrarily large amount of memory. That implies that there
is still a need for flow control.
In our work for large delay-bandwidth connections, we set the receive
window capacity at twice the observed delay-throughput product
(throughput being congestion controlled, used bandwidth, not channel
capacity bandwidth). We added code to estimate the round-trip time
based on ACK-pacing and measure the throughput during that rtt
directly. This is in stock Linux kernels now.
If the bottleneck is the receiving app, then it will fail to drain the
receive buffer and the receive window will fill up, resulting in flow
If the bottleneck is the sending app or congestion, that will affect the
delay-throughput product and therefore result in smaller receive buffers.
Linux doesn't statically pre-allocate receive buffers, so there is a
(perverse) opportunity for a bunch of open connections to over-commit
total receive windows larger than the memory capacity of the machine.
There is no logic to specifically prevent this situation, but I believe
packet loss and retransmissions would be the only penalty in such a case.
Advanced Computing Solutions Program
More information about the end2end-interest