Re: [tcpm] TCP tuning

[Jerry Chu <hkchu at google.com>]

On Thu, Feb 4, 2010 at 6:05 AM, Andrew Yourtchenko <ayourtch at cisco.com> wrote:
>
>
> 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.

Yes we have tried something very similar (dubbed "negative cache"), but
discovered its effectiveness depends heavily on a high cache hit, which is
difficult in a large server farm behind a stateless load balancer.

A small tweak included in the upcoming I-D is to back down to rfc3390 on
RW if any burst size (during IW or RW) > 4KB incurs pkt loss. Admittedly
this is a smaller and less effective tweak but it doesn't need to maintain
any history across different connections.

Jerry

>
> 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
>> tcpm at ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>