W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: 0-RTT Design for HTTP/2

From: Ian Swett <ianswett@google.com>
Date: Mon, 21 Dec 2020 07:04:41 -0500
Message-ID: <CAKcm_gMF0oucBmbzy-m-2XdpXiO3wq9HroH8vJmM5H5329HnrQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Dec 20, 2020 at 5:46 PM Martin Thomson <mt@lowentropy.net> 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.
Received on Monday, 21 December 2020 12:05:05 UTC

This archive was generated by hypermail 2.4.0 : Monday, 21 December 2020 12:05:07 UTC