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

[[e-mail]]

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
>