Re: 0-RTT Design for HTTP/2

[Ian Swett <[e-mail]>]

On Sun, Dec 20, 2020 at 5:46 PM Martin Thomson <[e-mail]> wrote:

> On Sun, Dec 20, 2020, at 06:36, Ian Swett wrote:
> > If I only had to send the SETTING client to server, I think that might
> > be deployable in the near future, though Chrome would have to run more
> > widespread tests.  I'm actually more concerned about the fact that the
> > server has to send the SETTING(which makes complete sense, given what
> > you're trying to accomplish).  It's impractical to wait for receipt of
> > the client SETTING before sending the server one, and the client
> > ecosystem is much slower to upgrade, unfortunately.
>
> My original write-up only had the server send the setting.  It certainly
> works that way.  You get most of the functionality.
>
> If the client says nothing, the server can't condition its treatment on an
> indication of support from the client.  The consequence being that the
> server can't rely on the client respecting lower limits.  That's not a big
> loss though; even fairly low limits would be hard to exceed in the limited
> space available, either due to max_early_data or CWND limits.
>
> > Given this, ALPS looks better from a deployability perspective.  To my
> > knowledge, there are no known issues deploying new TLS 1.3 extensions.
> > Given the lack of interest in a new h2 ALPN, I'm suggesting ALPS
> > include a GREASE recommendation, so if one deploys ALPS, it's also an
> > indication it's a fully compliant h2 implementation.
>
> I suspect that that is not going to be an easy stipulation.  As others
> have observed, people update their TLS stacks independent of their h2
> implementation.
>

Yes, but ALPS has to be actively enabled by the application(h2 in this
case), so if the application is actively enabling it, it should be possible
to require a compliant h2 implementation.