Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

[Joe Touch <[e-mail]>]

+1


> On Oct 24, 2014, at 1:18 AM, [e-mail] wrote:
> 
> I think this IW is not an appropriate parameter to present to the API,
> because the choice of value has a very significant impact on the
> robustness of the TCP service.
> 
> An app can anyway decide to  send less (defer sending a large volume of
> data straight away) - it is not in a place to decide the network path is
> safe to send more. Although if this were to be used as a part of  the  TCB
> sharing method (i.e. using cached network path state), that may be of
> value.
> 
> Gorry
> 
>> Hi Joe,
>> 
>> In line:
>> 
>> 
>>> On 23. okt. 2014, at 16:38, Joe Touch wrote:
>>> 
>>> 
>>> 
>>>> On 10/22/2014 1:46 AM, runabk wrote:
>>>> Hi all,
>>>> 
>>>> On 2014-10-22 01:59, Joe Touch wrote:
>>> ...
>>>>> - IW cannot be determined at the time of the connection per se
>>>>> The only way to do so would be to send IW segments into the net and
>>>>> see
>>>>> if they get there, which isn't so much a probe as just using that
>>>>> value
>>>>> as the initial window anyway.
>>>>> 
>>>>> I continue to believe that IW can be adapted over loooong periods of
>>>>> time using information on past connections as network behavior evolves
>>>>> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is
>>>>> definitely needed.
>>>> 
>>>> In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the
>>>> connections at a particular instance start with nearly same IW value
>>>> --- a single constant window for all flows.
>>> 
>>> I had been assuming 2140-style grouping of information based on network
>>> interface, destination IP address, destination subnet, etc.
>> 
>> ...which I'm not sure would be a good idea here, see my previous response
>> to Hagen and also further below.
>> 
>> 
>>>> My point is, why not to take a look on flow characteristics. I played
>>>> with a lot of simulations and experiments.
>>>> In my simulations in ns2, I considered a combination of flow types
>>>> based
>>>> on sizes --- large flows from Pareto Distribution, and small flows from
>>>> Exponential Distribution. And we observed, large flows having a small
>>>> IW, and even randomly choosing a large IW for small flows gives better
>>>> performance than all the flows with IW10;
>>> 
>>> Large flows are not as affected by IW effects because IW applies only
>>> during transients that are presumably rare (startup, restart after idle,
>>> etc.)
>>> 
>>> The problem with your observation is that it fails to consider the
>>> "tragedy of the commons". Capacity is a common network resource, and
>>> your increase of IW for short flows causes them to consume that resource
>>> before feedback corrects it in ways that are not generally considered
>>> "fair".
>> 
>> So you're arguing that this work creates an incentive for applications to
>> make their flows shorter? Interesting. An application cheating the system
>> by splitting a large flow into small ones would have to weigh the benefits
>> of being able to use a larger IW against the cost of the handshakes for
>> closing and re-opening a connection, at least. Depending on the IW
>> calculation function in use, there can be corner cases where such cheating
>> might work, I think this should be addressed in the draft.
>> 
>> 
>>> I.e., it's been known for a long time that making IW large helps short
>>> flows and has no real impact on long flows. It's also been known that
>>> this is not necessarily how we want the network to behave.
>>> 
>>> There's a balance between trying to complete a short flow quickly and
>>> having flows that are basically non-responsive to network congestion. We
>>> only recently increased IW to 10 based on the assumption that "a problem
>>> we haven't seen doesn't exist".
>>> 
>>> ...
>>>> A constant IW may not be suitable.
>>> 
>>> If you have 2140 in place, you might have the information useful to set
>>> an appropriate IW on a per-connection basis. However, setting that value
>>> solely based on the length of the connection is (IMO) inappropriate.
>> 
>> So, I think it's the most appropriate thing that can be done, and RFC 2140
>> can end up being less appropriate:
>> 1) if you reduce IW on later connections to a host you're already talking
>> to (ensemble sharing) or have talked to before (temporal sharing), ECMP
>> may put you on a different path and you may end up being too conservative.
>> 2) if you ONLY apply 2140-style IW reduction, you may not be conservative
>> enough because all these first connections to various IP addresses start
>> with IW10  (which may not seem to matter if we think about it from the
>> perspective of a single web server, but certain web pages open many
>> *first* connections from many different IP addresses to my browser, so
>> then it's my access link that suffers).
>> 
>> At the same time, using IW10 on large transfers is just useless. So I
>> think incorporating the flow length in the decision to only use a large
>> window when it can make sense is the best we can currently do.
>> 
>> Cheers,
>> Michael
>> 
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>