Re: HTTP/2 GREASE, Results, and Implications

If only some servers accepted SETTINGS, that would further constrain the
negotiation process to only allowing the server to send the SETTING after
receiving the client's.  It'd be good to know if that's necessary, but
hopefully it's not.

On Thu, Oct 31, 2019 at 11:59 AM Mike Bishop <mbishop@evequefou.be> wrote:

> Bence’s experiment didn’t cover anything server-sent, that I’m aware of.
> Of course, if Cloudflare would like to do a corresponding experiment…?  😉
>
>
>
> *From:* Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Sent:* Thursday, October 31, 2019 11:46 AM
> *To:* Mike Bishop <mbishop@evequefou.be>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: HTTP/2 GREASE, Results, and Implications
>
>
>
>
>
> On Thu, Oct 31, 2019 at 3:14 PM Mike Bishop <mbishop@evequefou.be> wrote:
>
> Way back when, I presented a draft (
> https://tools.ietf.org/html/draft-bishop-httpbis-grease-00) proposing
> that we adopt as an HTTP/2 extension the same behaviors that HTTP/3 is
> specifying, permitting the greasing of settings and frame types.  The
> outcome of that discussion was that, prior to considering adoption, we’d
> want to understand the real-world impact of deploying such a behavior.
> Bence generously volunteered to add such an experiment to Chrome, which he
> has done.
>
>
>
> The results are discussed at https://crbug.com/1019410.  TL;DR:  Settings
> are fine, but too many servers blow up on unknown frame types for this to
> be viable in major client deployments.  They don’t even tell you what they
> don’t like – they just PROTOCOL_ERROR on you.
>
>
>
>
>
> Thanks for the experimentation and sharing the results Mike and Bence.
>
>
>
> Is the sense that this is symmetrically broken? Do we have data about how
> server-sent GREASE frames might break clients? (and if not would that move
> the needle at all).
>
>
>
> Frankly, this makes me quite sad.  It means that our primary extension
> mechanism for HTTP/2 has already rusted shut, and it’s now inadvisable to
> define new optional-to-understand frame types and send them without prior
> negotiation.
>
>
>
> Now that we have this data, are we interested in pursuing the draft with
> settings only, or perhaps reserving frame types but recommending caution in
> their use?
>
>
>
> This indeed has some practical implications to active work in the group. I
> can see how there might be some merit in capturing this situation, along
> with some guidance, in a draft that can be reference by people making
> HTTP/2 extensions.
>
>
>
> Based on my experience of HTTP/3 interop to date, we are doing pretty well
> with GREASE perhaps it is time to capture this in the matrix. I'd also like
> to highlight that today the Cloudflare edge exercises all HTTP/3 grease
> mechanisms* for all connections.
>
>
>
> * unidirectional stream type GREASE is sent when sufficient stream credit
> is provided by the client e.g. more than 3
>
>
>