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

[Amos Jeffries <[e-mail]>]

On 28/02/2013 9:18 a.m., William Chan (陈智昌) wrote:
> 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."
>

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 
> <[e-mail] 
> <mailto:[e-mail]>> 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.
>
>     *From:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] *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
>     <[e-mail]
>     <mailto:[e-mail]>> 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.
>
>         *From:*[e-mail] <mailto:[e-mail]>
>         [mailto:[e-mail] <mailto:[e-mail]>] *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
>         <[e-mail]
>         <mailto:[e-mail]>> 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:*[e-mail] <mailto:[e-mail]>
>             [mailto:[e-mail] <mailto:[e-mail]>]
>             *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
>             <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>                     <mailto:[e-mail]>
>                     <mailto:[e-mail]
>                     <mailto:[e-mail]>>> wrote:
>
>                         There is harm borne by the unwilling client
>                     receiver: battery and
>                         data allowance are not free.
>
>                     *From:*Roberto Peon [mailto:[e-mail]
>                     <mailto:[e-mail]>
>                     <mailto:[e-mail] <mailto:[e-mail]>>]
>                         *Sent:* Friday, 22 February, 2013 08:24
>                         *To:* Martin Thomson
>                         *Cc:* Osama Mazahir; [e-mail]
>                     <mailto:[e-mail]>
>                     <mailto:[e-mail]
>                     <mailto:[e-mail]>> 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
>
>                       <[e-mail]
>                     <mailto:[e-mail]>
>                     <mailto:[e-mail]
>                     <mailto:[e-mail]>>> wrote:
>
>                             On 22 February 2013 05:29, Roberto Peon
>                     <[e-mail] <mailto:[e-mail]>
>
>                             <mailto:[e-mail]
>                     <mailto:[e-mail]>>> 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.
>
>