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

Mike Fisk 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 
> capacity.
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 
control.

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.

-- 
Mike Fisk
Technical Director
Advanced Computing Solutions Program



More information about the end2end-interest mailing list