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

[Michael Welzl <[e-mail]>]

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