Re: [tcpm] TCP tuning

[Andrew Yourtchenko <[e-mail]>]

On Thu, 4 Feb 2010, SCHARF, Michael 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.

And a possible tweak to this: if we increased the initial window beyond 
RFC3390, measure the number of retransmits that have to be done for those 
segments. If the stack had to retransmit, then subsequent connection 
attempts from the host would need to reduce this "increased" window.

I think this could help to take care of the concern about the short queue 
limits on the access-layer equipment.


cheers,
andrew

>
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>