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

[Runa Barik <[e-mail]>]

Hi J. Touch,

Comments inline.
________________________________________
From: Joe Touch <[e-mail]>
Sent: Thursday, October 23, 2014 4:38 PM
To: Runa Barik
Cc: Hagen Paul Pfeifer; Michael Welzl; [e-mail]
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

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.

> 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".

RB -

     I agree with the above  points. But consider the scenarios,
   (1) All flows start with say IW10; (2) The large flows start with
  IW as per rfc 3390, and small flows with IW10. Scenario (2) shows better
  performance than scenario (1) in various network conditions. In scenario (1),
  we observed large flows are affecting small flows more. However, in scenario (2), this negative
  effect on small flow is reduced . This motivates IW as a function. I agree with rfc 2140 
 that a past experience will help predicting a better value.

RB -

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.

RB -
    Consider a grass field and animals: goat and cow. If same amount of grass will
   be given to both cow and goat, then cow will remain hungry later and goat will
  waste the grass. However, if cow and goat will get the amount they need, probably
  no wastage, and no hungriness. That is my point, different applications may need
  different values of IW for their best service requirements.

RB -


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.

Joe

Regards,
- Runa