RE: #529: Working around concurrency limits

Off topic slightly, but FYI we are also starting to receive complaints 
from Squid users about hitting the gmail limits in HTTP/1.1.

Amos

On 2014-07-03 13:26, Mike Bishop wrote:
> During our SPDY development in IE, we actually hit that limit with a
> single connection.  ☺
> 
> From: Roberto Peon [mailto:grmocg@gmail.com]
> Sent: Wednesday, July 2, 2014 5:24 PM
> To: Mark Nottingham
> Cc: William Chan (陈智昌); Richard Wheeldon (rwheeldo); HTTP Working
> Group; Peter Lepeska
> Subject: Re: #529: Working around concurrency limits
> 
> SHOULD is the right thing here.
> And it is testable, though annoying to do--annoyingly, gmail already
> tests for/enforces something like this, with a substantially low
> concurrency limit.
> Opening multiple HTTP/2 connections to
> mail.google.com<http://mail.google.com> would result in users not
> being able to receive all of their attachments.
> 
> -=R
> 
> On Wed, Jul 2, 2014 at 5:06 PM, Mark Nottingham
> <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
> Given that it’s not testable, and based on the feedback so far, I
> think softening the SHOULD to prose is the right way to go.
> 
> Can everyone live with that?
> 
> 
> On 3 Jul 2014, at 5:26 am, William Chan (陈智昌)
> <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
> 
>> +peter
>> 
>> On Wed, Jul 2, 2014 at 2:20 AM, Richard Wheeldon (rwheeldo) 
>> <rwheeldo@cisco.com<mailto:rwheeldo@cisco.com>> wrote:
>> As previously discussed, it's technically close to impossible for us 
>> to implement and undesirable in many other cases. I think this 
>> position has been well understood enough that there will be no attempt 
>> to enforce or proactively encourage any limit. Hence, it's an 
>> editorial issue rather than an interop one at this point.
>> 
>> However, I'd just remove the text. It's adding controversy without 
>> value IMHO. Alternatively, if we want to say something, drop the 
>> RFC2119 language. How about: "In typical browser cases, client will 
>> achieve better throughput by restricting themselves to a single HTTP/2 
>> connections to each host and port pair, where host is derived from a 
>> URI, a selected alternative service [ALT-SVC], or a configured proxy."
>> 
>> Peter might disagree with this statement.
>> 
>> Overall, like you, I feel this is primarily an editorial issue. There 
>> are definitely reasons to open multiple connections, and clients are 
>> going to do them if they feel like they need to. But I do think it's 
>> overall good to encourage using fewer connections. I'm not going to 
>> comment any more on this because I feel like it's more bikeshedding 
>> than anything.
>> 
>> 
>> That leaves the door wide open for large downloads, proxies and all 
>> the other "atypical" cases.
>> 
>> Richard
>> 
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mnot@mnot.net<mailto:mnot@mnot.net>]
>> Sent: 02 July 2014 06:17
>> To: HTTP Working Group
>> Subject: #529: Working around concurrency limits
>> 
>> <https://github.com/http2/http2-spec/issues/529>
>> 
>> As I just mentioned in the issue, we already limit the requirement to 
>> a SHOULD here, allowing proxies to open more connections if they feel 
>> it necessary (and indeed, this isn't something we can really test 
>> for).
>> 
>> Do we need to do more than that, or can we close the issue?
>> 
>> Regards,
>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> --
> Mark Nottingham   http://www.mnot.net/

Received on Thursday, 3 July 2014 02:59:41 UTC