Re: [tcpm] TCP tuning

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

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

Of course, one would not use this mechanism if there is any sign of lost
packets. But, obviously, any heuristic can fail. BTW, another problem is
a highly congested link resulting in a large RTT. In this case, the
algorithm would send additional data to a congested link - but this
would also happen if the initial window would be increased. There is no
free lunch.

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

If the RTT is larger than 100ms (or whatever threshold is used), you
would still get a benefit compared to RFC 3390. Maybe that would be just
good enough?

Michael