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 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
>
>