Re: [tcpm] Increasing the Initial Window - Notes

[John Heffner <[e-mail]>]

On Thu, Nov 11, 2010 at 5:56 PM, Jerry Chu <[e-mail]> wrote:
> On Thu, Nov 11, 2010 at 2:58 AM, Michael Welzl <[e-mail]> wrote:
>>
>> On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote:
>>
>>>
>>>
>>>>> I certainly won't object to this, if that's all it takes for
>>>>> standardization. Unfortunately the
>>>>> point for the non-convinced is they don't want ANY flows to use IW10
>>>>> for fear of hurting
>>>>> the performance of their flows.
>>>>
>>>> ... but here, your "browsers open tens of flows" argument totally holds.
>>>> How is a web flow with IW10 worse than a browser opening tens of flows? If
>>>> people only use it for the web, like Google has been successfully doing,
>>>> this seems to be quite safe, based on experience.
>>>>
>>>> I'm curious what the opposition says to this  :)
>>>
>>> If today a brower opens 10 flows with a server using IW=1 you gets 10
>>> packets equivalent IW.
>>> Increasing the IW to 10 leads to an equivalent IW of 100 packets. At that
>>> point, you DSL modem will definitively start dropping most of them...
>>
>> ... which is a good reason to open fewer connections. So that's a matter
>> of bringing of bringing out an update of a web client with a different
>> behavior for the case that a web server uses a larger IW. But how does the
>> web browser know what the web server is doing? I guess they could exchange
>> this information with HTTP. Hm. Are we getting somewhere here, or is this a
>> dead end?
>
> One solution to safely migrate to IW10 for browsers opening multiple
> connections is to mandate browsers that open X connections, when X is, e.g.,
>> 4 to set the initial receive window to 3 (assuming OSes allow initrwnd to
> be set on a per connection basis). But I don't know how this can be
> enforced...
> Jerry


I'm not a Googler, so you probably have better insight into this than
I do, but my impression is that one big reason (if not the *primary*
reason) browsers open multiple connections is being able to submit
requests in parallel.  HTTP pipelining can help some, but (a) most
browsers disable this because of some buggy and widely deployed
servers, and (b) it is still susceptible to head-of-line blocking on
responses.  Might limiting the number of simultaneous connections
based on IW hurt more than it helps?

The solution would seem to be shared congestion state on the server.
Like the "congestion manager" (http://nms.lcs.mit.edu/cm/), or using
multiple channels in SCTP.  Of course, this may not be practical with
a lot of load-balancing systems.

Thanks,
  -John