Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

On Thu, Nov 18, 2010 at 1:16 PM, Joe Touch <[e-mail]> wrote:
> Maybe it should have been for IW=3 too, but it didn't occur to me at the
> time.
>
> The benefit is that had we used this mechanism then, we wouldn't be asking
> for a new IW now, though.

The problem is that had we used this mechanism we would've quickly found out
it just doesn't work well. It's always easy to hand wave and point to something
never well tested and claim that would've worked better.

Linux has a "dst cache" feature on a per destination IP basis for years.
The problem is that the effectiveness of the dst cache is determined by the
cache hit rate, which is highly dependent on client-server access pattern.
An ftp server serving RFC documents to a handful of clients (e.g., TCP
researchers) may enjoy high cache hit ratio. But consider > 1B users
accessing millions of servers, what kind of cache hit ratio would you expect?

Frustrated by very low cache hits from Linux's dst cache, we went on to
modify dst cache from per dst IP to per dst /24 subnet basis, but it only
showed limited improvement.

Then we discovered out of the small % of cache hits many still suffered
low cached cwnd. We quickly realized simple cwnd cache is not sufficient
- the prior connection must also have sufficient data to grow its cwnd for
the later connection to enjoy a larger IW.

Adding on top of all the above were transient congestions on well
provisioned users causing cwnd to be clamped down, and later connections
to suffer a small IW even though the congestions were long gone (presumably).

BTW,  we've covered this topic in our 1st presentation (see
http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf) and list
discussions
many times. I really hope we don't have to repeat the same topic over
and over again.

Best,

Jerry

>
> Joe
>
> On 11/18/2010 1:11 PM, John Heffner wrote:
>>
>> Why is this mechanism required for IW=10 but not for IW=3?
>>
>>   -John
>>
>>
>> On Thu, Nov 18, 2010 at 4:08 PM, Joe Touch<[e-mail]>  wrote:
>>>
>>> That's basically what I'm suggesting; it can easily be per subnet, per
>>> interface, or per the entire machine as desired.
>>>
>>> The ultimate point is:
>>>
>>>        - put something in the end node that notices if/when
>>>        it fails objectively, and fixes it
>>>
>>>        - that same thing can allow the IW to increase
>>>        over time if there are no problems
>>>
>>> I'll be glad to write this up if people need a more concrete proposal.
>>>
>>> Joe
>>>
>>> On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote:
>>>>
>>>> Why can't you do something like this :
>>>>
>>>> - If any one of the TCP connections egressing out of that interface
>>>> (this can determined in TCP layer) is in the TCP retransmit state (or
>>>> has experienced congestion in the past xxx secs/mins), then go back to a
>>>> lower IW for new TCP connections which are using the same output
>>>> interface..
>>>>
>>>> - When you want to start a connection, use the connection history (Joe's
>>>> RFC)
>>>>
>>>> Well, there may be some gotchas of this scheme, but you can become
>>>> conservative when there is some concrete information.
>>>>
>>>> Thanks,
>>>> -Anantha
>>>>>
>>>>> To be more clear, here's the case:
>>>>>
>>>>>        start 1000 connections in a row.
>>>>>
>>>>>        during the first connection, lose some packets and do
>>>>>        normal TCP backoff
>>>>>
>>>>>        so what do the other 999 connections start with?
>>>>>        ans: 10 packets
>>>>>
>>>>> The point is that subsequent connections don't do anything different.
>>>>> If
>>>>> you have 1000 connections, you're sending a certain amount of data
>>>>
>>>> into
>>>>>
>>>>> the network without reacting. We're tripling that.
>>>>>
>>>>> That can easily cause congestion. At which point the *existing*
>>>>> connections will backoff, but new connections keep making problems.
>>>>>
>>>>> Joe
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>