Re: #131: Connection limits (proposal)

Adrien de Croy wrote:
> as discussed previously, I'm not convinced that concurrent connections 
> is the (only?) thing that should be limited, or that this should be the 
> responsibility of the client (rather than the server or an intermediary).
> 
> Server resources are becoming cheaper every day (memory / disk / CPU).  
> So I believe the best place to restrict usage is at the server, where 
> the operator then has a choice about how much service will be provided.  
> Putting a responsibility on the client takes away this choice from the 
> server operator.
> 
> If you made cellphones, and decided to restrict the number of calls it 
> would make in any 1 day, do you think you'd find a telco that would sell it?

This analogy is badly flawed.

More connections does not result in higher performance.

And such a client can cause congestion, as TCP's congestion control does 
not detect multiple connections from the same client, degrading not only 
the user's client, but others as well.

It is much as if someone opened 50 cell phones all at once and dialed at 
the same time: you can be sure that your service (and others) were 
degraded badly).
                     - Jim

> 
> Furthermore, putting restrictions into the protocol makes it independent 
> of application.  For instance an in-house client server system using 
> HTTP may have no need or desire for any sort of limit.
> 
> I think therefore the best we can do is encourage implementors to act 
> responsibly, and consider other users of the network (where there are any).
> 
> So, what about something like:
> 
> "Implementors of client applications SHOULD give consideration to 
> effects that a client's use of resources may have on the network (both 
> local and non-local), and design clients to act responsibly within any 
> network they participate in.  Some intermediaries and servers are known 
> to limit the number of concurrent connections, or rate of requests.  An 
> excessive number of connections has also been known to cause issues on 
> congested shared networks.  In the past HTTP has recommended a maximum 
> number of concurrent connections a client should make, however this 
> limit has also caused problems in some applications.  It is also 
> believed that any recommendation on number of concurrent connections 
> made now will not apply properly to all applications, and will become 
> obsolete with advances in technology."
> 
> this then potentially covers any resource that should be managed, e.g. 
> not just connections, but perhaps also bandwidth, cache space on an 
> intermediary etc etc etc
> 
> Regards
> 
> Adrien.
> 
> 
> William A. Rowe, Jr. wrote:
>> Mark Nottingham wrote:
>>   
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>
>>>
>>> NEW:
>>>
>>> """
>>> 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.
>>>
>>> In particular, while using multiple connections avoids the "head-of-line
>>> blocking" problem (whereby a request that takes significant server-side
>>> processing and/or has a large payload can block subsequent requests on
>>> the same connection), each connection used consumes server resources
>>> (sometimes significantly), and furthermore using multiple connections
>>> can cause undesirable side effects in congested networks.
>>> """
>>>     
>>
>> Is it worthwhile to add the caveat;
>>
>> """
>> Clients attempting to establish simultaneous connections SHOULD anticipate
>> the server to reject excessive attempts to establish additional connections,
>> and gracefully degrade to passing all requests through the successfully
>> established connection(s), rather than retrying.
>> """
>>
>>   
> 
> -- 
> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>

Received on Monday, 19 October 2009 11:23:34 UTC