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

[Jerry Chu <[e-mail]>]

On Tue, Jul 14, 2009 at 1:00 PM, Joe Touch<[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...
>>>> >> What would be the pros and cons of using the cached rtt measurements
>>>> >> from previous connections for the SYN
>>> >
>>> > You can use more than cached RTT; the technique and some other cacheable
>>> > items are described in RFC2140.
>>
>> Yes we are very aware of your proposal. I think the most effective one to speed
>> up short connections is the snd_cwnd reuse, but unfortunately it's also the most
>> dicey due to cwnd's highly temporal nature. Is this why snd_cwnd reuse was not
>> implemented per rfc2140? Any insight and suggestion will be much appreciated.
>
> We didn't distribute our implementations; the Linux code was developed
> separately. We did do some tests using predictive SND_CWND learning.
> There are two parts; one is "how fast would a connection speed up if
> guessing were perfect", and the other is "how close to that perfect goal
> can be achieved using basic prediction".
>
> Granted, our web server didn't have your traffic, but we found that the
> impact of SND_CWND was small, and limited to only a small subset of
> connections. Connections too short don't benefit from a large window.
> Connections too long have little benefit from increasing startup behavior.

Hmm, your conclusion seems a bit counter-intuitive - for a typical web object
of 5-8 pkts in size, starting with an initcwnd of 6, e.g., from the cache will
require only half of the round trips to complete the http transaction compared
to initcwnd = 3.

>
> (see the tech report at http://www.isi.edu/aln)
>
>>> > The pro is more rapid convergence to an accurate RTT; the con is that
>>> > you're using a potentially invalid RTT, but then that's what you do when
>>> > you start without knowing the RTT at all anyway.
>>> >
>>> > It has also been implemented in Linux; see RFC4614.
>>
>> Yes Linux stack maintains a "destination cache" of ssthresh and RTT on
>> a per dest IP address basis. It doesn't currently use snd_cwnd, probably
>> out of the same concerned mentioned above?
>
> Lack of benefit is also an issue.

See above. I thought this should be the one that will give the largest beneift
(in terms of latency reduction) for the web traffic, if done (i.e.,
predicted) correctly.

>
>> Also it is very conservative
>> hence won't use the cached RTT value unless the timestamp option is
>> on.
>>
>> Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK
>> the initRTO is still set to 3secs (don't know why).
>
> If you spin the initRTO down too far, you end up resending the SYN
> needlessly, no?

Correct so there is a fine line to walk. But if > 98% of all TCP connections
experience RTT << 1 sec, it just seems too conservative to have a global
initRTO == 3secs just to avoid spurious retransmission in the < 2% category.

Jerry

>
> Joe
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpc49AACgkQE5f5cImnZruF5QCfc5BRj9np2yjizDIqOa+i09bT
> LsQAoMBPrr2dYErruJc0ED7s2hfCQztE
> =uouq
> -----END PGP SIGNATURE-----
>