Subject: #40 - HTTP2 default value for client supported max_concurrent_streams

From: Osama Mazahir <[email-masked]>
Date: Fri, 22 Feb 2013 05:04:56 +0000

Hi,

Issue #40 [1] tracks: What is the default number of concurrent pushed streams that a client must be able to support?

The suggestion is that the default value be 0.  That is, the communication defaults to no-push.  If the client is capable and willing to handle pushed streams, it can emit a non-zero value in its initial SETTINGS frame.

Thanks,
--Osama.

[1] https://github.com/http2/http2-spec/issues/40

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:29:23 -0800

What is the motivation for that?
While I have a hard time imagining how a server would do a push before the
client has made a request, I also believe that market forces would deal
appropriately with any server which doesn't serve a client's needs.
Additionally, as currently spec'd, pushing a stream that isn't in reply to
another stream means bits go into the waste bucket at best...

-=R

On Thu, Feb 21, 2013 at 9:04 PM, Osama Mazahir <[email-masked]> wrote:

> Hi,
>
> Issue #40 [1] tracks: What is the default number of concurrent pushed
> streams that a client must be able to support?
>
> The suggestion is that the default value be 0.  That is, the communication
> defaults to no-push.  If the client is capable and willing to handle pushed
> streams, it can emit a non-zero value in its initial SETTINGS frame.
>
> Thanks,
> --Osama.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Feb 2013 08:19:47 -0800

> What is the motivation for that?

I'm not suggesting that this is Osama's motivation, but look at the
Upgrade scenario: the server is the first to send on the HTTP/2.0
session with a response.  There's an obvious opportunity there to push
prior to the client SETTINGS frame arriving.  The TLS scenario is less
interesting - the client sends SETTINGS prior to any request, making
defaults non-interesting.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 08:23:59 -0800

Yup, I understand that part. :)
I'm doing a poor job of pointing out that any harm done by doing something
like this is borne by the party doing it.
... so why mandate it-- if there turns out to be a positive benefit of
doing such a push in the future, fine.
I guess I'm attempting to argue that, unless we can figure out how this
causes harm/is likely to be done accidentally and cause issues, then it is
better to not say anything about it. Saying something about it creates a
spec with is more fragile.

-=R

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 22 Feb 2013 21:02:42 +0000

There is harm borne by the unwilling client receiver: battery and data allowance are not free.

From: Roberto Peon [mailto:[email-masked]]
Sent: Friday, 22 February, 2013 08:24
To: Martin Thomson
Cc: Osama Mazahir; [email-masked] Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

Yup, I understand that part. :)
I'm doing a poor job of pointing out that any harm done by doing something like this is borne by the party doing it.
... so why mandate it-- if there turns out to be a positive benefit of doing such a push in the future, fine.
I guess I'm attempting to argue that, unless we can figure out how this causes harm/is likely to be done accidentally and cause issues, then it is better to not say anything about it. Saying something about it creates a spec with is more fragile.

-=R

On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 22 Feb 2013 13:29:12 -0800

Let's be careful about this issue, because as we've noted many times
before, if the server can't leverage HTTP/2 to push streams, it is likely
to just inline resources directly, which is definitely worse.
Fundamentally, when the client issues a request, the server can send
anything it wants in the response. Defaulting to 0 would most likely
incentivize servers to to just inline resources, which is probably worse
than sending push streams to clients which don't want it (I assert that in
the open web, this should be a minority. If not, then HTTP/2 stream pushing
will have failed and people will just inline resources).

On Fri, Feb 22, 2013 at 1:02 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  There is harm borne by the unwilling client receiver: battery and data
> allowance are not free.****
>
> ** **
>
> *From:* Roberto Peon [mailto:[email-masked]]
> *Sent:* Friday, 22 February, 2013 08:24
> *To:* Martin Thomson
> *Cc:* Osama Mazahir; [email-masked] Group
> *Subject:* Re: #40 - HTTP2 default value for client supported
> max_concurrent_streams****
>
> ** **
>
> Yup, I understand that part. :)****
>
> like this is borne by the party doing it.****
>
> doing such a push in the future, fine.****
>
> spec with is more fragile.****
>
> ** **
>
> -=R****
>
> ** **
>
> On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson <[email-masked]>
> wrote:****
>
> > What is the motivation for that?****
>
> defaults non-interesting.****
>
>  ** **
>

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 24 Feb 2013 00:03:37 +1300

On 23/02/2013 10:29 a.m., William Chan (陈智昌) wrote:
> before, if the server can't leverage HTTP/2 to push streams, it is 
> likely to just inline resources directly, which is definitely worse. 
> incentivize servers to to just inline resources, which is probably 
> worse than sending push streams to clients which don't want it (I 
> assert that in the open web, this should be a minority. If not, then 
> HTTP/2 stream pushing will have failed and people will just inline 
> resources).

Sorry I just parsed that as a re-wording of "if it turns out the 
majority of clients disable push we can consider it failed and servers 
will just do it via inlining anyway."

If that is the case, why are sites not already inlining _all_ of their 
page content and pushing it on first contact from any client. The answer 
should be obvious that it is a waste of resources for both client and 
server to do this at all on any large scale. Although, that said I'm 
still fielding questions about how to pre-cache entire sites like 
facebook and google :-( there will always be idiots whatever gets specified.

Amos

>
> On Fri, Feb 22, 2013 at 1:02 PM, Gabriel Montenegro 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     *From:*Roberto Peon [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Osama Mazahir; [email-masked]
>     <mailto:[email-masked]> Group
>     max_concurrent_streams
>     I'm doing a poor job of pointing out that any harm done by doing
>     something like this is borne by the party doing it.
>
>     ... so why mandate it-- if there turns out to be a positive
>     benefit of doing such a push in the future, fine.
>
>     I guess I'm attempting to argue that, unless we can figure out how
>     this causes harm/is likely to be done accidentally and cause
>     issues, then it is better to not say anything about it. Saying
>     something about it creates a spec with is more fragile.
>
>     -=R
>
>     On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson
>     <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 23 Feb 2013 07:09:11 -0800

Sorry, I did not explicitly state a conditional that I thought was
implicitly understood.

*In situations where the server wants to push resources*, if the majority
of clients disable HTTP/2 stream push, then servers will simply inline
resources instead.

You're right that push can always be abused. But in situations that it
makes sense to push, it's better to use HTTP/2's push facility than to
inline resources. And we should ensure that the push mechanism remains
viable, otherwise servers will just inline in those situations.

On Sat, Feb 23, 2013 at 3:03 AM, Amos Jeffries <[email-masked]> wrote:

> Sorry I just parsed that as a re-wording of "if it turns out the majority
> of clients disable push we can consider it failed and servers will just do
> it via inlining anyway."
>
> server to do this at all on any large scale. Although, that said I'm still
> fielding questions about how to pre-cache entire sites like facebook and
> google :-( there will always be idiots whatever gets specified.
>
> Amos
>
>
>> Gabriel.Montenegro@microsoft.**com <[email-masked]><mailto:
>> Gabriel.Montenegro@**microsoft.com <[email-masked]>>>
>> wrote:
>>
>>     <[email-masked] <mailto:martin.thomson@gmail.**com<[email-masked]>>>
>> wrote:
>>

---

From: Gabriel Montenegro <[email-masked]>
Date: Sun, 24 Feb 2013 01:23:04 +0000

“where the server wants”

There’s two parties in this dance, and it takes both to want to do it. If a client wants at some point to not be fired upon strictly more than it requests for (perhaps because it is low on batteries or is very close to its monthly data allowance or because it just plain doesn’t feel like it), than a server inlining a bunch of stuff is like it shooting at the client. From the point of view of the client, getting fired at hurts. The client can very well decide never again to use such servers.

If the server does not inline but instead uses the new fancy push capability, it might be friendlier fire, but getting fired at even if it’s “friendly” fire hurts just the same.

Catering to the server’s wishes is fine and dandy, but that is only one part of the equation. I guess I’m a bit more optimistic in that I hope it will become possible for clients not to be fired at, instead of just changing from one type of fire to another.

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Chan (???)
Sent: Saturday, 23 February, 2013 07:09
To: Amos Jeffries
Cc: HTTP Working Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

Sorry, I did not explicitly state a conditional that I thought was implicitly understood.

*In situations where the server wants to push resources*, if the majority of clients disable HTTP/2 stream push, then servers will simply inline resources instead.

You're right that push can always be abused. But in situations that it makes sense to push, it's better to use HTTP/2's push facility than to inline resources. And we should ensure that the push mechanism remains viable, otherwise servers will just inline in those situations.

On Sat, Feb 23, 2013 at 3:03 AM, Amos Jeffries <[email-masked]<mailto:[email-masked]>> wrote:
On 23/02/2013 10:29 a.m., William Chan (陈智昌) wrote:
Let's be careful about this issue, because as we've noted many times before, if the server can't leverage HTTP/2 to push streams, it is likely to just inline resources directly, which is definitely worse. Fundamentally, when the client issues a request, the server can send anything it wants in the response. Defaulting to 0 would most likely incentivize servers to to just inline resources, which is probably worse than sending push streams to clients which don't want it (I assert that in the open web, this should be a minority. If not, then HTTP/2 stream pushing will have failed and people will just inline resources).

Sorry I just parsed that as a re-wording of "if it turns out the majority of clients disable push we can consider it failed and servers will just do it via inlining anyway."

If that is the case, why are sites not already inlining _all_ of their page content and pushing it on first contact from any client. The answer should be obvious that it is a waste of resources for both client and server to do this at all on any large scale. Although, that said I'm still fielding questions about how to pre-cache entire sites like facebook and google :-( there will always be idiots whatever gets specified.

Amos

On Fri, Feb 22, 2013 at 1:02 PM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    There is harm borne by the unwilling client receiver: battery and
    data allowance are not free.
    *From:*Roberto Peon [mailto:[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>]
    *Sent:* Friday, 22 February, 2013 08:24
    *To:* Martin Thomson
    *Cc:* Osama Mazahir; [email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>> Group
    *Subject:* Re: #40 - HTTP2 default value for client supported

    max_concurrent_streams

    -=R

    On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson
    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        > What is the motivation for that?

        I'm not suggesting that this is Osama's motivation, but look
        at the
        Upgrade scenario: the server is the first to send on the HTTP/2.0
        session with a response. There's an obvious opportunity there
        to push
        prior to the client SETTINGS frame arriving. The TLS scenario
        is less
        interesting - the client sends SETTINGS prior to any request,
        making
        defaults non-interesting.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 23 Feb 2013 18:23:49 -0800

I think we agree that, in certain cases, such as mobile clients worried
about data usage, pushing content is bad. I think we also agree that the
current reality is that many servers push content anyways. And you're right
that the users may very well decide not to use those servers if the servers
abuse push mechanisms. Creating better user feedback mechanisms to let them
know when servers are hurting them would be a good thing.

I think what we disagree on is your optimism that the push mechanism in
HTTP/2 will make it possible for the client to prevent the server from
unduly pushing content by having a low default max streams limit. If the
default is low/zero, and there's no explicit signal from the client that it
doesn't want extra content, then the server will try to make the best
choice, as it already does today, on whether or not to push and how.

I think what you want is a method for the client to signal to the server
that it doesn't want to be pushed content, regardless of the mechanism
(HTTP/2 push or resource inlining). I assert that having a low/zero
*default* max streams limit won't help here, since defaults do *not* signal
intent. Create an actual signal, don't take away the HTTP/2 push mechanism
(a low/zero default is effectively equivalent to taking it away, since it
requires a roundtrip to re-enable push, which defeats the purpose of push -
saving roundtrips), since servers will just inline instead.

On Sat, Feb 23, 2013 at 5:23 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  “where the server wants”****
>
> ** **
>
> There’s two parties in this dance, and it takes both to want to do it. If
> a client wants at some point to not be fired upon strictly more than it
> requests for (perhaps because it is low on batteries or is very close to
> its monthly data allowance or because it just plain doesn’t feel like it),
> than a server inlining a bunch of stuff is like it shooting at the client.
> From the point of view of the client, getting fired at hurts. The client
> can very well decide never again to use such servers.****
>
> ** **
>
> If the server does not inline but instead uses the new fancy push
> capability, it might be friendlier fire, but getting fired at even if it’s
> “friendly” fire hurts just the same. ****
>
> ** **
>
> Catering to the server’s wishes is fine and dandy, but that is only one
> part of the equation. I guess I’m a bit more optimistic in that I hope it
> will become possible for clients not to be fired at, instead of just
> changing from one type of fire to another.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *William
> Chan (???)
> *Sent:* Saturday, 23 February, 2013 07:09
> *To:* Amos Jeffries
> *Cc:* HTTP Working Group
> implicitly understood.****
>
> ** **
>
> resources instead.****
> viable, otherwise servers will just inline in those situations.****
>
> ** **
>
> On Sat, Feb 23, 2013 at 3:03 AM, Amos Jeffries <[email-masked]>
> wrote:****
>
>  On 23/02/2013 10:29 a.m., William Chan (陈智昌) wrote:****
>
> will have failed and people will just inline resources).****
>
> ** **
>
> Amos****
> [email-masked] <mailto:[email-masked]>>
> wrote:
>
>     data allowance are not free.****
>
>     *Subject:* Re: #40 - HTTP2 default value for client supported****
>
>
>     max_concurrent_streams
>
>     On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson****
>
>         On 22 February 2013 05:29, Roberto Peon <[email-masked]****
>
>         <mailto:[email-masked]>> wrote:
> ****

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 26 Feb 2013 19:54:42 +0000

I don’t agree with this: “I think we also agree that the current reality is that many servers push content anyways.” I thought I had said that already: I think clients’ abandoning such servers and going elsewhere is a signal, but agree that an explicit one would be much better.

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Chan (???)
Sent: Saturday, 23 February, 2013 18:24
To: Gabriel Montenegro
Cc: Amos Jeffries; HTTP Working Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

I think we agree that, in certain cases, such as mobile clients worried about data usage, pushing content is bad. I think we also agree that the current reality is that many servers push content anyways. And you're right that the users may very well decide not to use those servers if the servers abuse push mechanisms. Creating better user feedback mechanisms to let them know when servers are hurting them would be a good thing.

I think what we disagree on is your optimism that the push mechanism in HTTP/2 will make it possible for the client to prevent the server from unduly pushing content by having a low default max streams limit. If the default is low/zero, and there's no explicit signal from the client that it doesn't want extra content, then the server will try to make the best choice, as it already does today, on whether or not to push and how.

I think what you want is a method for the client to signal to the server that it doesn't want to be pushed content, regardless of the mechanism (HTTP/2 push or resource inlining). I assert that having a low/zero *default* max streams limit won't help here, since defaults do *not* signal intent. Create an actual signal, don't take away the HTTP/2 push mechanism (a low/zero default is effectively equivalent to taking it away, since it requires a roundtrip to re-enable push, which defeats the purpose of push - saving roundtrips), since servers will just inline instead.

On Sat, Feb 23, 2013 at 5:23 PM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
“where the server wants”

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of William Chan (???)
Sent: Saturday, 23 February, 2013 07:09
To: Amos Jeffries
Cc: HTTP Working Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

Amos

    max_concurrent_streams

    -=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 18:51:36 -0800

Sorry, can you clarify your disagreement here? Are you disagreeing that
servers push content anyways today? Or are you saying that users already
stop browsing such websites?

My assertion was that it's simply a fact of life today that servers push
content. I'll go even further, websites push content and users still seem
to use those websites anyway. My evidence: bing.com uses data URIs. Check
out view-source:http://www.bing.com/search?q=flowers and search for
'data:image'.

On Tue, Feb 26, 2013 at 11:54 AM, Gabriel Montenegro <
[email-masked]> wrote:

>  I don’t agree with this: “I think we also agree that the current reality
> is that many servers push content anyways.” I thought I had said that
> already: I think clients’ abandoning such servers and going elsewhere is a
> signal, but agree that an explicit one would be much better.****
>
> ** **
>
> *Sent:* Saturday, 23 February, 2013 18:24
> *To:* Gabriel Montenegro
> *Cc:* Amos Jeffries; HTTP Working Group
>
> know when servers are hurting them would be a good thing.****
>
> ** **
>
> choice, as it already does today, on whether or not to push and how.****
>
> ** **
>
> saving roundtrips), since servers will just inline instead.****
>
> ** **
>
> [email-masked]> wrote:****
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 27 Feb 2013 19:59:45 +0000

No disagreement on the present. However, in what I quoted from you, the verb is in the future tense. I interpreted this as a prediction of the future. Furthermore, I interpreted what I quoted as your saying that it is a non-signal when clients prefer better behaved servers that don’t fire upon sight of the client. I think it is a signal, admittedly not a very explicit nor particularly good one.

I agree with your assessment that it would be much better to have a clear signal that would allow a client to not be fed more by the server, than the client explicitly requests for.

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Chan (???)
Sent: Tuesday, 26 February, 2013 18:52
To: Gabriel Montenegro
Cc: Amos Jeffries; HTTP Working Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

Sorry, can you clarify your disagreement here? Are you disagreeing that servers push content anyways today? Or are you saying that users already stop browsing such websites?

My assertion was that it's simply a fact of life today that servers push content. I'll go even further, websites push content and users still seem to use those websites anyway. My evidence: bing.com<http://bing.com> uses data URIs. Check out view-source:http://www.bing.com/search?q=flowers and search for 'data:image'.

On Tue, Feb 26, 2013 at 11:54 AM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
I don’t agree with this: “I think we also agree that the current reality is that many servers push content anyways.” I thought I had said that already: I think clients’ abandoning such servers and going elsewhere is a signal, but agree that an explicit one would be much better.

Amos

    max_concurrent_streams

    -=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 27 Feb 2013 12:18:48 -0800

Great to hear we're agreed on the current state of things.

As for users changing behavior based on websites, I totally agree that's a
signal and agree it's neither explicit, nor very good.

To be clear, the part that I said was not a signal was a protocol default: "I
assert that having a low/zero *default* max streams limit won't help here,
since defaults do *not* signal intent."

On Wed, Feb 27, 2013 at 11:59 AM, Gabriel Montenegro <
[email-masked]> wrote:

>  No disagreement on the present. However, in what I quoted from you, the
> verb is in the future tense. I interpreted this as a prediction of the
> future. Furthermore, I interpreted what I quoted as your saying that it is
> a non-signal when clients prefer better behaved servers that don’t fire
> upon sight of the client. I think it is a signal, admittedly not a very
> explicit nor particularly good one.****
>
> ** **
>
> I agree with your assessment that it would be much better to have a clear
> signal that would allow a client to not be fed more by the server, than the
> client explicitly requests for.****
>
> ** **
>
> *Sent:* Tuesday, 26 February, 2013 18:52
>
> *To:* Gabriel Montenegro
> stop browsing such websites?****
>
> ** **
>
> 'data:image'.****
> *Cc:* Amos Jeffries; HTTP Working Group****
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Feb 2013 16:15:57 +1300

On 28/02/2013 9:18 a.m., William Chan (陈智昌) wrote:
> As for users changing behavior based on websites, I totally agree 
> that's a signal and agree it's neither explicit, nor very good.
>
> To be clear, the part that I said was not a signal was a protocol 
> default: "I assert that having a low/zero *default* max streams limit 
> won't help here, since defaults do *not* signal intent."
>

Indeed. Defaults signal the most liberal usage which is guarantee to 
work everywhere.

As such I am against the proposals for 100+ defaults in view that the 
*few* websites which need this for high performance are far outweighed 
by the majority of other sites and services which only use or need a 
handful (or 1!) stream for the first RTT. Forcing every miniature 
embeded server or chip hardware implementation to cope with 100+ streams 
minimum just to cater for the way a few popular sites are implemented 
today seems like arrogance. Those big players will work just as well (if 
slowly) with a few streams - they needs a high _upper_ capacity with 
fast way to signal the need, not a high _default_.

The big players of today will probably be replaced by flavour of next 
year anyway - who will be implemented differently for sure. Look to the 
10+ year goalpost.

Amos

>
> On Wed, Feb 27, 2013 at 11:59 AM, Gabriel Montenegro 
>     No disagreement on the present. However, in what I quoted from
>     you, the verb is in the future tense. I interpreted this as a
>     prediction of the future. Furthermore, I interpreted what I quoted
>     as your saying that it is a non-signal when clients prefer better
>     behaved servers that don’t fire upon sight of the client. I think
>     it is a signal, admittedly not a very explicit nor particularly
>     good one.
>
>     I agree with your assessment that it would be much better to have
>     a clear signal that would allow a client to not be fed more by the
>     server, than the client explicitly requests for.
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *William Chan (???)
>     Sorry, can you clarify your disagreement here? Are you disagreeing
>     that servers push content anyways today? Or are you saying that
>     users already stop browsing such websites?
>
>     My assertion was that it's simply a fact of life today that
>     servers push content. I'll go even further, websites push content
>     and users still seem to use those websites anyway. My evidence:
>     bing.com <http://bing.com> uses data URIs. Check
>     out view-source:http://www.bing.com/search?q=flowers and search
>     for 'data:image'.
>
>     On Tue, Feb 26, 2013 at 11:54 AM, Gabriel Montenegro
>         I don’t agree with this: “I think we also agree that the
>         current reality is that many servers push content anyways.” I
>         thought I had said that already: I think clients’ abandoning
>         such servers and going elsewhere is a signal, but agree that
>         an explicit one would be much better.
>
>         *From:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>] *On
>         Behalf Of *William Chan (???)
>         I think we agree that, in certain cases, such as mobile
>         clients worried about data usage, pushing content is bad. I
>         think we also agree that the current reality is that many
>         servers push content anyways. And you're right that the users
>         may very well decide not to use those servers if the servers
>         abuse push mechanisms. Creating better user feedback
>         mechanisms to let them know when servers are hurting them
>         would be a good thing.
>
>         I think what we disagree on is your optimism that the push
>         mechanism in HTTP/2 will make it possible for the client to
>         prevent the server from unduly pushing content by having a low
>         default max streams limit. If the default is low/zero, and
>         there's no explicit signal from the client that it doesn't
>         want extra content, then the server will try to make the best
>         I think what you want is a method for the client to signal to
>         the server that it doesn't want to be pushed content,
>         regardless of the mechanism (HTTP/2 push or resource
>         inlining). I assert that having a low/zero *default* max
>         streams limit won't help here, since defaults do *not* signal
>         intent. Create an actual signal, don't take away the HTTP/2
>         push mechanism (a low/zero default is effectively equivalent
>         to taking it away, since it requires a roundtrip to re-enable
>         push, which defeats the purpose of push - saving roundtrips),
>         since servers will just inline instead.
>
>         On Sat, Feb 23, 2013 at 5:23 PM, Gabriel Montenegro
>             There’s two parties in this dance, and it takes both to
>             want to do it. If a client wants at some point to not be
>             fired upon strictly more than it requests for (perhaps
>             because it is low on batteries or is very close to its
>             monthly data allowance or because it just plain doesn’t
>             feel like it), than a server inlining a bunch of stuff is
>             like it shooting at the client. From the point of view of
>             the client, getting fired at hurts. The client can very
>             well decide never again to use such servers.
>
>             If the server does not inline but instead uses the new
>             fancy push capability, it might be friendlier fire, but
>             getting fired at even if it’s “friendly” fire hurts just
>             the same.
>
>             Catering to the server’s wishes is fine and dandy, but
>             that is only one part of the equation. I guess I’m a bit
>             more optimistic in that I hope it will become possible for
>             clients not to be fired at, instead of just changing from
>             one type of fire to another.
>
>             *From:[email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked] <mailto:[email-masked]>]
>             *On Behalf Of *William Chan (???)
>             *Subject:* Re: #40 - HTTP2 default value for client
>             supported max_concurrent_streams
>
>             *In situations where the server wants to push resources*,
>             if the majority of clients disable HTTP/2 stream push,
>             then servers will simply inline resources instead.
>
>             You're right that push can always be abused. But in
>             situations that it makes sense to push, it's better to use
>             HTTP/2's push facility than to inline resources. And we
>             should ensure that the push mechanism remains viable,
>             otherwise servers will just inline in those situations.
>
>             On Sat, Feb 23, 2013 at 3:03 AM, Amos Jeffries
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Let's be careful about this issue, because as
>                     we've noted many times before, if the server can't
>                     leverage HTTP/2 to push streams, it is likely to
>                     just inline resources directly, which is
>                     definitely worse. Fundamentally, when the client
>                     issues a request, the server can send anything it
>                     wants in the response. Defaulting to 0 would most
>                     likely incentivize servers to to just inline
>                     resources, which is probably worse than sending
>                     push streams to clients which don't want it (I
>                     assert that in the open web, this should be a
>                     minority. If not, then HTTP/2 stream pushing will
>                     have failed and people will just inline resources).
>
>                 Sorry I just parsed that as a re-wording of "if it
>                 turns out the majority of clients disable push we can
>                 consider it failed and servers will just do it via
>                 inlining anyway."
>
>                 If that is the case, why are sites not already
>                 inlining _all_ of their page content and pushing it on
>                 first contact from any client. The answer should be
>                 obvious that it is a waste of resources for both
>                 client and server to do this at all on any large
>                 scale. Although, that said I'm still fielding
>                 questions about how to pre-cache entire sites like
>                     On Fri, Feb 22, 2013 at 1:02 PM, Gabriel
>                     Montenegro <[email-masked]
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                     <mailto:[email-masked]>>> wrote:
>
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>>]
>                     <mailto:[email-masked]>
>                       <[email-masked]
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                     <mailto:[email-masked]>>> wrote:
>
>                             On 22 February 2013 05:29, Roberto Peon
>                     <[email-masked] <mailto:[email-masked]>
>
>                             <mailto:[email-masked]

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 20:37:56 -0800

That seems like it might be backwards? The *average* number of requests for
a page is ~70 in 2011 and close to 90 today. This isn't just about a few
instances of demanding pages with many resources. Those pages probably use
in excess of 100 (and Patrick would like to see a larger default than that,
something which the trends support...).

The cheap chip can handle the case where the clients makes too many
requests by rejecting all but one stream, and causing the browser to retry.
In such cases, latency must not matter, else the device would have enough
memory to handle more than one request at once. In any case, given that
mostly we access these minimal devices on the LAN, latency will be minimal
anyway regardless of what happens in the first exchange.

The sweet spot here for defaults is such that it allows for a latency
decrease on high RTT  links as compared to HTTP/1, and such that we we
don't mask malicious behavior.
 If you set the default too low you end up providing a latency bias to
larger sites, which seems unfair to me, and also undermines reasons for
adoption.

-=R