[tcpm] Tuning TCP parameters for the 21st century

[Jerry Chu <hkchu at google.com>]

Sorry I don't have the I-D ready for submission yet (and the deadline
has passed anyway) so I'll try to describe what we are up to below.
I'll have more data to present in Stockholm.

At Google we have embarked on a mission to make the web faster, not
just for services provided by Google, but for every web user. We started
with TCP because TCP performance has always been a key component of
the end2end web performance. There are a number of default TCP parameter
settings, that, although conservative, have served us well over the
years. We believe the time has come to tune some of the parameters to
get more speed out of a much faster Internet than 10-20 years ago. The
current list includes:

Lowering initRTO
Increasing initcwnd
Lowering minRTO
Lowering delayed ack timer value

I'll start with Lowering initRTO.

RFC1122 contains the following paragraph:

The following values SHOULD be used to initialize the
estimation parameters for a new connection:

(a)  RTT = 0 seconds.

(b)  RTO = 3 seconds.  (The smoothed variance is to be
initialized to the value that will result in this RTO).

The "3secs SHOULD" is reaffirmed in RFC2988.

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.

What's the downside?

For those users behind a slow (e.g., dialup, wireless) link, the RTT may
still go up to > 1 sec. We believe a small amount of supriously
retransmitted SYN/SYN-ACK packets should not be a cause for concern (e.g.,
inducing more congestion,...) In some rare case the TCP performance may be
negatively affected by false congestion backoff, resulted from dupacks
caused by multiple spuriously retransmitted SYN/SYN-ACK packets. We believe
there are techniques to detect and mitigate these cases.

I'd like to hear feedback from this list on the feasibility of reducing
initRTO. For some other items (e.g., increasing IW/RW...) unfortunately I
don't have data ready to share yet but if you have an opinion on them I'd
love to hear it too.

Thanks,

Jerry

On Mon, Jul 13, 2009 at 6:54 AM, Eddy, Wesley M. (GRC-MS00)[Verizon]
<wesley.m.eddy at nasa.gov> wrote:
>
> I've uploaded a draft TCPM agenda for IETF 75 at:
> http://www.ietf.org/proceedings/09jul/agenda/tcpm.txt
>
> I don't recall seeing an I-D or mail list thread for
> the topic Jerry Chu wants to discuss (lowering the
> initial RTO), so if he can give the mail list a bit
> of a description of his proposal that would be
> helpful.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>