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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Erik Nordmark wrote:
> Jerry Chu wrote:
> 
>> From our own measurement of world wide RTT distribution to Google servers
>> we believe 3secs is too conservative, and like to propose it to be
>> reduced
>> to 1sec.
>>
>> Why does it matter?
>>
>> We have seen SYN-ACK retransmission rates upto a few percentage points to
>> some of our servers. We also have indirect data showing the SYN (client
>> side) retransmission to be non-negligible (~1.42% worldwide). At a rate >
>> 1% a large RTO value can have a significant negative impact on the
>> average
>> end2end latency, hence the user experience. This is especially true for
>> short connections, including much of the web traffic.
> 
> For short web traffic I'd assume many of the connections go to a server
> with which the client has recently had a tcp connection.
> 
> 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.

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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpckwkACgkQE5f5cImnZruYrQCgkCe/wm7W4F78Iy9K5gEcMtj5
xekAoMbbvAXZA230zsKCxsdy3toZA+1N
=o0dt
-----END PGP SIGNATURE-----