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

Michael Scharf michael.scharf at ikr.uni-stuttgart.de
Sat Jun 28 02:00:16 PDT 2008


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


More information about the end2end-interest mailing list