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

[Alfredo]

Hi All,

In my opinion, in this discussion about flow control we should also consider
that the speed of the receiver is not the only issue that determines the
need for flow control.

If you have a very large number of outstanding segments (high BDP) and a
segment gets lost in the network, the next segments that will be received by
the receiver will be buffered till the lost segment is received (we need to
wait the retransmitted version of the lost segment). This is mandatory to
ensure in sequence data delivery. In this case, regardless of the speed of
the receiver, you need flow control.

Best Regards

Alfredo

 

-----Messaggio originale-----
Da: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] Per conto di Michael Scharf
Inviato: Saturday, June 28, 2008 11:00 AM
A: Xiaoliang David Wei
Cc: end2end-interest at postel.org
Oggetto: Re: [e2e] Why do we need TCP flow control (rwnd)?

On Fri, 27 Jun 2008 at 21:13:02, Xiaoliang David Wei wrote:
>     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.

Maybe we can detect the cases "A" and "B" by some heuristic?

To come up with something simple: What about if a sender considered rwnd
only when it is small:
  
  if (rwnd<=thresh) /* flow control enabled */
    wnd = min(cwnd,rwnd)
  else /* flow control disabled */
    wnd = cwnd;

The parameter "thresh" could be e. g. 64 KB. Or, more disruptive, "thresh"
could be set to the initial window (typically, 3 MSS). The rational behind
the latter would be that any host should be able to buffer at least an
initial window of data, and if this is not the case, it is definitively
running out of buffer space.

Such a scheme should reduce the risk of buffer overflows in slow (e. g.
embedded) devices, while faster endpoints wouldn't have to care much about
the precise value of the advertized window unless they run out of (shared)
buffer space as well.

Michael

Internal Virus Database is out-of-date.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.1/1512 - Release Date: 6/21/2008
9:27 AM
 

Internal Virus Database is out-of-date.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.1/1512 - Release Date: 6/21/2008
9:27 AM