Re: [tcpm] TCP tuning

[Jerry Chu <[e-mail]>]

Michael,

On Thu, Feb 4, 2010 at 5:35 AM, SCHARF, Michael
<[e-mail]> wrote:
> Jerry,
>
>> > - A significant increase to the initial window might benefit from
>> > introduction of some form of pacing, since you won't have any ack
>> > clock yet.  This might help reduce losses and delay jitter.
>>
>> Agreed. The question is, what is that threshold of
>> window/burst size beyond which pacing is required. My current
>> guess is > 10.
>
> I have the same impression, at least from what I have seen in simulations.
>
> Yet, one could think of a very simple form of pacing with a single timer that changes the Slow-Start only when it "hurts" - I think that I have mentioned this possibility on this list before:
>
> In this approach, the initial window remains at the value given by RFC 3390. But the sender is allowed to further increase the window after a certain time (say, 100ms), but only
> if the RTT is known to be larger than 100ms (as measured e. g. during handshake), if no ACK has been received until then, and if recently there have been no signs of congestion to this destination.
>
> The advantage of this approach is that TCP uses the larger initial window only if the RTT is larger than 100ms (or whatever threshold is defined). On the one hand, this reduces the performance problems that can be observed for RTTs of the order of 200ms. But, on the other hand, flows with a smaller RTT would use the existing Slow-Start, i. e., the faster startup is only used by a small number of flows and thus be much less disruptive than a general revision of RFC 3390.
>
> A simpler variant of this idea is to allow an increased initial window beyond RFC 3390 if the measured RTT is larger than a certain threshold such as 100ms.

Thanks for all the interesting ideas. We may need them in the future.

We actually spent the first few months testing a more complex
algorithm, partly based on Joe Touch's caching
idea described in RFC2140. We abandoned that approach later due to a
number of problems, low cache hit
rate due to server side load balancing being one of them. We have
since adopted a two-phase approach. The first
phase follows the KISS principle to simply pick a fixed, larger number
for initial window that has minimal negative
impact for all connections (and I can't believe it can't be bumped up
by more than a couple of MSS safely, given
the huge growth of average bandwidth and the gradual disappearing of
dialup links < 56Kbps. Our test data has
confirmed this, detailed in the upcoming paper). This enables a more
timely deployment and a faster web
experience for most people sooner while we can embark on a second
phase to investigate a more elaborate
algorithm involving pacing and other non-trivial implementation tasks
but can unleash more performance for the
regular users with 1.7Mbps, the average b/w globally reported recently
by Aktimai.

I understand and appreciate the "err on the conservative side"
principle. The robustness and ubiquity of the Internet
largely came out of it. But at some point it needs to be balanced
against the need for improvement. My fear is that
IETF might risk becoming irrelevant if it's too conservative, much
like California's highway speed limit 20 years
ago. It was at 55MPH while hardly anyone drove below that speed. (Of
course what is considered "conservative",
"risky" can be very subjective. The trick to get to some consensus here...)

Jerry

>
> Michael
>
>
>