Re: [tcpm] TCP tuning

[Kacheong Poon <kacheong.poon at sun.com>]

On 02/ 4/10 09:35 PM, SCHARF, Michael wrote:

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


For a server, it may just have 1 sample of RTT (the ACK for its 
SYN/ACK).  Is this enough to determine much?  Suppose the ACK
for the SYN/ACK is lost, and the server gets a request (data +
ACK for the SYN/ACK) instead, can it distinguish this case from
the case when a client can bundle data in third leg of 3-way
handshake?

And it seems to defeat much of the benefits of increasing the
initial cwnd if the server needs to wait 100ms before sending
more.


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



--

						K. Poon.
						kacheong.poon at sun.com