Subject: #529: Working around concurrency limits

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jul 2014 15:16:59 +1000

<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/

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Wed, 2 Jul 2014 09:20:39 +0000

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."

That leaves the door wide open for large downloads, proxies and all the other "atypical" cases.

Richard

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: 02 July 2014 06:17
To: HTTP Working Group
Subject: #529: Working around concurrency limits

Regards,

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 02 Jul 2014 21:21:50 +1200

On 2014-07-02 17:16, Mark Nottingham wrote:
> 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).
> 

IMHO, close. The SHOULD has sufficient emphasis against doing it 
casually, while allowing for proxies and others if/when actually 
necessary.

Amos

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 2 Jul 2014 12:26:28 -0700

+peter

On Wed, Jul 2, 2014 at 2:20 AM, Richard Wheeldon (rwheeldo) <
[email-masked]> 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.

> 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).
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jul 2014 10:06:24 +1000

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 (陈智昌) <[email-masked]> wrote:

> +peter
> 
> On Wed, Jul 2, 2014 at 2:20 AM, Richard Wheeldon (rwheeldo) <[email-masked]> wrote:
> 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.
>  
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Roberto Peon <[email-masked]>
Date: Wed, 2 Jul 2014 17:23:32 -0700

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 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 <[email-masked]> 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.
>
> > 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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 3 Jul 2014 01:26:52 +0000

During our SPDY development in IE, we actually hit that limit with a single connection.  ☺

From: Roberto Peon [mailto:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> 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.

On 3 Jul 2014, at 5:26 am, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

> +peter
>
> On Wed, Jul 2, 2014 at 2:20 AM, Richard Wheeldon (rwheeldo) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Mark Nottingham [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: 02 July 2014 06:17
> To: HTTP Working Group

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 03 Jul 2014 14:59:06 +1200

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:
> 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
> <[email-masked]<mailto:[email-masked]>> 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.
> 
> On 3 Jul 2014, at 5:26 am, William Chan (陈智昌)
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
>> +peter
>> 
>> On Wed, Jul 2, 2014 at 2:20 AM, Richard Wheeldon (rwheeldo) 
>> <[email-masked]<mailto:[email-masked]>> 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."
>> 
>> 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.
>> 
>>

---

From: Peter L <[email-masked]>
Date: Wed, 9 Jul 2014 07:14:28 -0400

+1.

As per the other thread, more than one connection will often result in better page load time so I agree with removing the SHOULD.

Thanks,

Peter

> On Jul 2, 2014, at 8:06 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Peter L <[email-masked]>
Date: Wed, 9 Jul 2014 07:42:49 -0400

"HTTP/2 eliminates delays due to queuing in the browser so opening more than one connection will not result in the large performance gains seen in HTTP/1.1. It will still however mitigate the impact of slow start over high bandwidth links and so will improve performance in some cases."

Something like the above?

> On Jul 9, 2014, at 7:14 AM, Peter L <[email-masked]> wrote:
> 
> +1.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jul 2014 15:03:55 +1000

There was some subsequent pushback on diluting the SHOULD. 

I don't think this is worth a lot of time going back and forth on -- people have the SHOULD if they need more than one connection, and our charter is focused on mitigating the misuse of the transport protocol at any rate.

Closing with no action.

Regards,