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

[Andrew Yourtchenko <[e-mail]>]

Hi Joe,

On Thu, 18 Nov 2010, Joe Touch wrote:

> Hi, Andrew,
>
> On 11/18/2010 4:47 PM, Andrew Yourtchenko wrote:
>> 
>> 
>> On Thu, 18 Nov 2010, Joe Touch 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 think this is a very viable idea.
>> 
>> However, I think there is a catch due to which it would need tweaking -
>> there should be a signaling mechanism whereby a node on the
>> "conservative" side of the connection would be able to signal the node
>> on the "eager" side of the connection not to be too aggressive, in case
>> the data flow is mostly from from "eager" to "conservative" side.
>
> I think the rest of your argument boils down to how the client decides to 
> aggregate it's idea of the best IW. That's up to the client to decide what it 
> is willing to support - coarse or fine-grained.

No. IW of the client does not really matter - it sends the short GET request. 
The server side is the one that may generate congestion by having large IW.
So it needs either to remember all the clients somehow, or take a hint.

"Average temperature in the hospital" approach (aggregating on the server) will 
not be useful.

>
> An IW=10 as a static proposal is the coarsest possible; anything else we 
> could do can't be any worse.
>
> ...
>> If the above logic is right, then the peers during the 3whs should
>> communicate their memorized values and pick up the minimum of theirs and
>> the communicated by the peer.
>
> Congestion isn't often bidirectional, so it's unlikely IMO that a peer would 
> know what to suggest to its counterpart (if I understand your proposal).

If I connect to http://foo.example/ which sends me an IW=10 and I lose 5 packets 
out of that, and I connect to http://bar.example/ which sends me an IW=10 and I 
lose 5 packets out of that, my assumption that if I connect to 
http://baz.example, most chances are that I will also be able to get up to 5 
packets - so I better give it a hint based on my previous knowledge.


> However, your suggestion is that there could be additional input if someone - 
> anyone - knew 'better' what to do. That's fine - that's just an out-of-band 
> hint to the algorithm.

well, I've added the proposal you had about adjusting only one side, added an 
extra parameter to the code, and am attaching it.

To save you a compile, just three runs:

1) Static IW=10, access capacity 5..8, backbone capacity 8..15

./a.out 10 0 1000 5 8 8 15 1 | grep round

Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000
Results from the round: loss: 436, headroom: 0, avg IW size: 10.000000
Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000
Results from the round: loss: 426, headroom: 0, avg IW size: 10.000000

2) One-side-adjustment (what I understand is your proposal):

./a.out 10 1 1000 5 8 8 15 1 | grep round

Results from the round: loss: 66, headroom: 10, avg IW size: 6.380000
Results from the round: loss: 52, headroom: 14, avg IW size: 6.180000
Results from the round: loss: 62, headroom: 10, avg IW size: 6.350000
Results from the round: loss: 63, headroom: 9, avg IW size: 6.210000

3) With the hint:

./a.out 10 1 1000 5 8 8 15 0 | grep round

Results from the round: loss: 1, headroom: 32, avg IW size: 5.420000
Results from the round: loss: 0, headroom: 37, avg IW size: 5.350000
Results from the round: loss: 1, headroom: 29, avg IW size: 5.350000
Results from the round: loss: 1, headroom: 41, avg IW size: 5.350000
Results from the round: loss: 0, headroom: 50, avg IW size: 5.290000

So, the "hint" has roughly the same effect on the new proposal as the new 
proposal on the original proposal - of course at the expense of being a bit more 
conservative.

Whether this effect is significant enough and whether the simulation is a good 
enough approximation - I'd be very curious to hear.

cheers,
andrew

>
> Joe
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>