Re: Stream limits draft posted

Can you elaborate on the compatibility and configuration issues? h2.1-only
clients is a good example of why the weird implicit ALPS thing isn't ideal.
It allows a server to say "I'm willing to do fixed-h2 but not broken-h2",
but it doesn't allow a client to say this. Less of a serious concern than
the server, but it's something we give up by losing the orthogonality.

I also think this allergy towards minting ALPNs is bad for the evolvability
of our protocols. There are plenty of problems where minting a new ALPN is
the right solution. If we have systems that cannot handle it, that's a
problem and we should exercise them better and fix this. Otherwise we'll
have ossified yet another extension point.

On Mon, Nov 13, 2023 at 11:30 AM Ben Schwartz <bemasc@meta.com> wrote:

> If ALPS is in use, I think a new ALPN ID is unnecessary.  ALPS implicitly
> defines a new profile of each offered ALPN.  We can define a
> SETTINGS_USE_MAX_STREAMS setting for H2, and note that client support for
> this setting (and any other settings that we believe should be in a
> "modern" client baseline) is mandatory when offering ALPS for "h2".
>
> This does move toward ALPS influencing the server's ALPN selection.
> Perhaps that is less elegant than perfect orthogonality, but I think it's
> better than minting new ALPN IDs.  In particular, a new ALPN ID creates
> various compatibility and configuration headaches related to "h2.1-only"
> clients and servers, and HTTPS records.
>
> --Ben Schwartz
> ------------------------------
> *From:* David Benjamin <davidben@chromium.org>
> *Sent:* Sunday, November 12, 2023 6:55 PM
> *To:* Ilari Liusvaara <ilariliusvaara@welho.com>
> *Cc:* ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> *Subject:* Re: Stream limits draft posted
>
> Even over TLS 1. 3, I would expect the vast, vast majority of HTTP/2
> servers do not send SETTINGS at half-RTT. When I probed some list of top
> sites in 2020, I could not find a single one. This should not be surprising
> once you dig into it. Half-RTT
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
>
> ZjQcmQRYFpfptBannerEnd
> Even over TLS 1.3, I would expect the vast, vast majority of HTTP/2
> servers do *not* send SETTINGS at half-RTT. When I probed some list of
> top sites in 2020, I could not find a *single* one.
>
> This should not be surprising once you dig into it. Half-RTT data on a
> 1-RTT handshake is semantically weird, in a way that half-RTT on a 0-RTT
> handshake is not. It really does not fit well into TLS-over-TCP's existing
> interfaces at all.On the client side, taking a 1-RTT hit against
> practically all existing HTTP/2 servers seems clearly an unreasonable
> performance cost. Ultimately, it is a change in protocol semantics to go
> from "sending SETTINGS at 1-RTT is just fine" to "SETTINGS must be sent at
> half-RTT to avoid latency problems". On the server side, I don't believe
> it's possible to send it with OpenSSL servers. BoringSSL too, which was an
> intentional choice on our part.
>
> I wrote this a couple years ago, which discusses this and other problems
> with trying to solve this shape of problem with half-RTT:
> https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html
>
> I haven't been following this issue as closely, but skimming the draft, it
> seems to me three questions here:
> 1. How to ensure clients know to trigger the new mode early enough.
> 2. How to allow clients to open streams in the new mode without waiting
> for an RTT, in both 1-RTT and 0-RTT handshakes.
> 3. How to distinguish clients that do and don't implement the new scheme
> so that, either under load or perhaps unconditionally in the future,
> servers can avoid negotiating h2 with older clients.
>
> I suspect any solution for (2) will either look like early server->client
> communication (be it ALPS or a Rube Goldberg of half-RTT, 0-RTT session
> ticket state, and applications injecting themselves into the 0-RTT
> accept/reject decision), or, as Kazuho suggested, just some hard-coded
> initial default value. Both the ALPS and half-RTT plans will require TLS
> software changes, so I suspect the hard-coded initial value is most viable,
> provided we can find a small enough default to satisfy DoS concerns, but
> large enough to admit one RTT worth of stream creations.
>
> But then we don't solve (1) for free. For that, I think the new ALPN is
> the way to go. As this is essentially a protocol bugfix, rather than an
> optional extension, a version bump to "h2.1" seems appropriate.  ALPN
> happens early enough, and is already correctly integrated with 0-RTT, so
> the client will know, before sending data, to use the new mode. Moreover,
> the server knows whether the client will behave *before* picking the
> protocol, so we get (3) as well, which the half-RTT and ALPS options would
> not give us. (ALPS puts the client message in the second client flight so
> that it is encrypted. That means the server only knows "client supports
> ALPS" at protocol selection time. It also was designed assuming it
> *wouldn't* impact protocol selection.)
>
> The hardcoded default is a little unsatisfying compared to early
> server->client, but we could do both: if we get a server->client initial
> value in ALPS, use that. Otherwise, use the hard-coded default. (This isn't
> an option with half-RTT because the client needs to know when to stop
> waiting, when talking to a server that can't send it.)
>
> (To fully explore the problem space, a new ALPN *does* resolve the client
> performance problems of the half-RTT approach: with a new ALPN we can say
> "you *must* send SETTINGS in half-RTT in h2.1". But all the other
> problems, such as those in the link and requiring TLS library changes,
> remain. I do not think half-RTT is viable here.)
>
> On Sat, Nov 11, 2023 at 3:37 AM Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> On Sat, Nov 11, 2023 at 08:50:51AM +0100, Martin Thomson wrote:
> > On Fri, Nov 10, 2023, at 14:16, Stefan Eissing wrote:
> > > +1
> > >
> > > I think clients will not wait for the MAX_STREAMS from the server. I
> > > assume they want to send right away instead of waiting for a while.
> The
> > > server might support it or not. How long are they willing to wait for
> > > this?
> >
> > In the meeting, it was suggested that we require clients to wait for
> > SETTINGS before opening streams.  I think that is a good idea and
> > entirely possible, without significant performance penalties.
> >
> > In TLS 1.3, the server can send SETTINGS immediately, which means that
> > the client only needs to read a few more bytes before it can start
> > sending.
> >
> > The minor pain here, as David Benjamin will likely remind us, is that
> > it is a little awkward sending data from the server before seeing the
> > client Finished.  So we'd probably want to experiment here.
>
> I have written a HTTP reverse proxy, which used to send SETTINGS
> immediately in TLS 1.3[1]. Unfortunately, that caused some clients to
> break[2], manifesting as fatal unexpected_message TLS alert immediately
> after handshake completed. So I changed the code to always wait for
> finished from client[3].
>
>
> [1] If there was no client certificate request, for shortcomings of
> the interface between TLS and HTTP layers.
>
> [2] No information about what clients broke. However, mentions by
> one user might indicate that some "anti-virus" products were
> involved.
>
> [3] There might still be option to re-enable the old behavior.
>
>
>
>
> -Ilari
>
>