Re: [tcpm] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

[sorry I'm trying to catchup while on vacation]

On Mon, Nov 15, 2010 at 7:45 PM, John Heffner <[e-mail]> wrote:
> 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.

The various points you raised above have been covered in our earlier
slides and/or discussed on the list. The following is a short summary
for you:

1. Browsers requires multiple connections to schedule web object downloads
in parallel to get the best user experience, much like a multi-threaded
application requires a multi-core CPU to run well. TCP's small IW is one
important but not the only reason for simultaneous connections. Avoiding
HOLB is another.

2. The # of simultaneous connections by all popular browsers have
continued to increase in the past few years. By increasing IW we hope
to reverse this trend because with a much large IW the browser won't
need that many connections to get the best user experience.

3. The solutions you've mentioned above are well understood on paper
and not deployed for various reasons. Also they would require an even
larger IW to work well.

Best,

Jerry

>
> Thanks,
>  -John
>