[e2e] Why do we need TCP flow control (rwnd)?
David P. Reed
dpreed at reed.com
Sat Jun 28 13:43:50 PDT 2008
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.
More information about the end2end-interest