Re: [tcpm] Tuning TCP parameters for the 21st century

[Jerry Chu <[e-mail]>]

On Wed, Jul 15, 2009 at 2:15 AM, Michael
Scharf<[e-mail]> wrote:
> On Tue, 14 Jul 2009 at 16:02:39, Joe Touch wrote:
>> Larger messages benefit as you open the window to burst the whole thing
>> out. Here's a back of the envelope:
>>
>> # packets     was RTTs:       is RTTs:        benefit
>>       4       2               2               0%
>>       10      3               2               33%
>>       19      4               2               50%
>>       32      5               2               60%
>>       52      6               2               67%
>>       82      7               2               71%
>>
>> Note though that at some point your SND_CWND will be opened only as far
>> as the path allows, at which point sending more packets just takes more
>> RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which
>> means we only saw benefits in the 20-30% range (i.e., the first two rows
>> above). Sure, if you see CWNDs much larger, you might benefit from
>> reusing old values...
>
> A large initial SND_CWND might not result in such a large benefit if
> the receiver still announces a small receive window (e. g., the Linux
> stack initially announces a receive window of about 6K only). This
> issue is documented in an (expired) ID:
>
>  http://tools.ietf.org/html/draft-scharf-tcpm-flow-control-quick-start-00

Yes I remember Linux stack also "slow starts" the receive window.
The good news is that for us the receiver is on the client side dominated by
the Windows stack, which is probably not sophisticated enough to do this.
(Need double check.)

>
> An example for a limitation by the receive window can also be seen on
> slide 19 of
>
>  http://www.ietf.org/proceedings/08nov/slides/iccrg-2.pdf
>
> Note that, at least in case of Linux, it is possible to mitigate this
> limitation by an ugly hack: The sender could ignore the announced
> receive window during the first RTT of the Slow-Start and
> optimistically send more data. As the receiver exponentially opens the
> receive window, the received packets are always within the current
> receive window - if the receiver does not run out of memory. But of
> course this hack violates RFC 793.
>
> BTW: My experiments with different fast startup schemes (with and
> without rate pacing) also show that the absolute benefit of a faster
> startup is small for many typical Internet workloads. Yet,
> applications that frequently transfer mid-sized amounts of data can
> indeed benefit. And since only few applications actually use a large
> initial SND_CWND, the risk of a moderate increase of the initial
> window appears to be rather small. As also mentioned in my ICCRG
> presentation, the "Jump-Start" idea of M. Allman et al. seems to have
> a quite reasonable performance in many scenarios.

Thanks for the pointers! This seems very relevant to our on-going struggle
with TCP slow start :-).

>
> Unfortunately, I cannot back these statements by large-scale
> experimental data so far. But if someone wanted to perform some
> experiments, e. g., with the "Jump-Start" scheme, I could provide
> corresponding Linux kernel patches.

We're planning for some experiement in this area too. Will let you know
how it goes.

Jerry

>
> Michael
>