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

[David P. Reed]

I'm extremely confused as to why this is so exciting an idea.

The whole point of TCP is to be a simple, robust standard way to do 
something across a wide variety of cases.

Without fantasizing about possible imaginary justifications for which 
there is no evidence, what real problem exists?

Michael Scharf wrote:
> 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
>
>