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

[Joe Touch <[e-mail]>]

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

> On Tue, Jul 14, 2009 at 1:00 PM, Joe Touch<[e-mail]> wrote:
...
>> > 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.

First, you get to send 4K or 4 packets (whichever is smaller) at the
start of a connection anyway. Second, RTT is only a fraction of the
overall delays experienced by a message. Finally, connections already
eat 2 RTTs before you do anything to get a response, due to the SYN
handshake followed by the request-response of HTTP. You might be eating
a single RTT off of a 3-4 RTT exchange. Your RTTs may go down by 30-50%,
but since they're not 100% of your delay, you end up benefitting only
around 20% or so.

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...
	
>> > (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.

It would if most connections's max CWND was larger than 10, and if most
connections sent more than 20 packets, but neither was the case for us.

>>> >> 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.

It doesn't matter much if 99.99% of connections wouldn't benefit from
having the initRTO go off earlier anyway. That's the tradeoff. Don't
know if it helps your case, though.

Joe

>> > 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-----
>> >

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

iEYEARECAAYFAkpdDo4ACgkQE5f5cImnZrs3fwCfaOB3Ki+FKf1rrJP3kKfdxV2X
D68AoKxBh/3C0Bh3MVZ8AniBoen9vuX/
=X+Od
-----END PGP SIGNATURE-----