Re: Call for Adoption: HTTP/2 Bis

Hi,

I also support adoption of this document.

As Willy mentioned, doing GREASE with Chrome has somewhat promising
results.  I'm not aware of any sites that have problems with reserved
setting identifiers.  There are a number of sites that have issues with
reserved frame types, most notably https://slack.com.  However, all three
server bugs I'm aware of causing GREASE intolerance have been fixed, so
moving the ecosystem forward is a matter of upgrading (which I acknowledge
can be quite complex).  Also, it is a lucky coincidence that the particular
issue affecting slack.com only affects frame types above 0x20, and
PRIORITY_UPDATE frame type is 0x10, so that should not be an issue for the
time being.

There is also a GREASE intolerant middlebox product out there, and while
that bug has been fixed in recent releases, some older branches are still
supported.  In fact no available upgrade includes the fix for certain
hardware platforms.  See https://crbug.com/1127569#c9 for specifics.  I do
not know if this bug is triggered by frame type 0x10, or only larger values.

I guess these server bugs will be around for a little while, but not
forever.

I'm planning to implement PRIORITY_UPDATE in Chrome by the next release,
and based on what we've seen from GREASE, we might indeed run into issues
with sending the new frame and the SETTINGS_DEPRECATE_HTTP2_PRIORITIES
identifier, as Ian mentioned above.  The experiments so far happened only
on Chrome Dev and Canary channels, and an issue with a site as popular as
https://netflix.com has only been reported after two months, so it is still
possible that there is a bug with a website that is not popular enough that
I would have learned about it yet, but popular enough that it will block
PRIORITY_UPDATE launch.

Then there is the situation from the server's perspective.  An old version
of an HTTP/2 client library is intolerant to unknown setting identifiers:
it simply closes the connection if it receives any.  This causes
difficulties for WebSockets over HTTP/2 and also PRIORITY_UPDATE.  Also, I
am not aware of any GREASE experiments from the server side, so I do not
know what the situation is with reserved frame types.  I believe that
creating a new ALPN identifier would solve this particular issue: if these
two setting identifiers were sent by popular servers every time the new
protocol is negotiated, then clients would be forced not to close the
connection upon receiving them.  At the same time, I understand the
argument that a new ALPN identifier has huge costs.  We are currently
exploring other workarounds.

Cheers,

Bence

On Thu, Dec 10, 2020 at 11:41 PM Willy Tarreau <w@1wt.eu> wrote:

> Hi Mike,
>
> On Thu, Dec 10, 2020 at 10:05:22PM +0000, Mike Bishop wrote:
> > And to me, that's the real question over a new ALPN.  If we can keep the
> > token "h2" and add GREASE successfully, let's do that.  If we can't add
> > GREASE without changing the ALPN token, we should consider changing the
> ALPN
> > token.
>
> But why would GREASE require a new ALPN ? Bence is already doing some
> greasing and managed to find bugs in several of our implementations. I'd
> rather push stronger in this direction after some code points can be
> reserved for various purposes.
>
> >  Of course, that means we're effectively minting "h2.1" or
> > "h2-nobugs", at which point we need not necessarily be limited to
> > non-breaking changes.
>
> What I hate with changing ALPN is that it's a user-visible change. Asking
> users to change their ALPN string from "h2,http/1.1" to "h2.1,h2,http/1.1"
> just because a working group decided to slightly change the protocol for
> the sake of better interoperability is hard to justify, especially after
> it was claimed that the protocol is called "HTTP/2" because it will not
> have a sub-version.
>
> If we'd change the ALPN we should then think about all the on-wire changes
> that were discussed in the past, like the poor hpack encoding, changing
> initial settings etc. It doesn't seem worth doing with H3 knocking at the
> door in my opinion.
>
> Cheers,
> Willy
>