Re: [tcpm] TCP tuning

["SCHARF, Michael" <[e-mail]>]

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.

Michael