W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: [OT] Re: #131: Connection limits (proposal)

From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
Date: Mon, 19 Oct 2009 16:15:15 -0500
Message-ID: <4ADCD6E3.1060101@rowe-clan.net>
To: Adrien de Croy <adrien@qbik.com>, "jim gettie"
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote:
> 
> William A. Rowe, Jr. wrote:
>> Mark Nottingham wrote:
>>  
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>
>>>
>>> """
>>> Clients (including proxies) SHOULD limit the number of simultaneous
>>> connections that they maintain to a given server (including proxies).
>>>
>>> Previous revisions of HTTP gave a specific number of connections as a
>>> ceiling, but this was found to be impractical for many applications. As
>>> a result, this specification does not mandate a particular maximum
>>> number of connections, but instead encourages clients to be conservative
>>> when opening multiple connections.
>>> """
>>>     
>>
>> It really seems like this is ripe for a Connection: max=# tag
>> recommendation.
>> Wherein the application can recommend a number of parallel connections
>> that
>> 1) they support and 2) provide optimal user/application experience. 
>> But this
>> would be out of scope of 2616bis :)
>>   

Adrien de Croy replied:
>
> I think that could create problems, especially with intermediaries. 
> E.g. intermediaries and servers may have different limits.  Would you
> treat the max= as an indication of desired number of connections, or
> undesired number of connections etc.

Connection: is a hop-by-hop header.  Yes, it would be stripped by some
intermediaries, yes, it is advisory only.  But if something was adopted along
these lines, intermediaries would be able to

> I think until we can signal a client that service is being refused
> because of number of connections, we are going to have trouble dealing
> with this problem.

It is not a problem.  If you are declined 503 or disconnected, throttle back,
don't blast ahead.

Jim Gettys also replied:
>
> The problem is that congestion can occur anywhere in the path from
> client to server, and therefore any information the server can give on
> number of connections is incorrect.  So this idea doesn't work.
> [...]
> We showed in the HTTP/1.1 paper that additional parallel connections did
> not actually increase performance; fastest performance was achieved with
> a single TCP connection.  But for many bad implementations, doing so
> will, without the implementers having to actually think or restructure
> their code.

Yes, but the implication of max= was the -apparent- performance, not the net
total performance.  User agents are throttled on multiple resources, and in
many cases are not aware from the document structure which of the resources
will be bottlenecks.  Adrien explained this well in his follow-up.

What would be nice in this case, is to inform the browser of max=1 where it
is known that the resources are not dynamic, all quickly served from cache,
with no display delays.  Or max=4 to suggest that the page is very complex
and contains a number of nested, dynamic resources which take time to compute.

> Exactly what the right recommendations to implementers should be, and
> whether the spec should try to enforce such behavior is a different
> discussion.

And thus, I labeled this Off-Topic, but it's an interesting discussion to have :)
This is probably as far as the http-wg wants to see this discussion move at the
moment, until the work on 2616bis is complete.
Received on Monday, 19 October 2009 21:15:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT