Subject: QUIC stream limits exposure to application mapping

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 May 2020 18:17:24 +0100

Hello folks,

During the HTTP interim meeting today [1] we came to talk a bit about QUIC
stream ID limits and how implementations might or might not expose this
property of the transport layer to an application mapping layer.

To abstract the technical discussion: we have an application-mapping
message that can be sent on a stream and it contains a reference to a
different stream by ID. In order to bound resource usage there is the
requirement "if the *other* stream ID exceeds the stream ID limit, receiver
MUST close the connection".

To implement the above requires the application mapping to have access to
the transport's maximum stream ID. This makes assumption about how
implementations do things and rightfully has been questioned.

HTTP/3 describes some resource usage considerations but makes it clear that
QUIC is responsible for managing a connection's concurrency. There is an
expectation that HTTP/3 can ask the transport to manage a concurrency limit
on it's behalf, but that otherwise it need no further input or feedback.

I'd like to understand what implementations actually do in practice, and
solicit the arguments against exposing the stream ID limits. I think this
could be useful for other application mapping documents that need to work
with transport primitives.

Cheers
Lucas

[1] Specifically, we were talking about HTTP/3 priorities and the
PRIORITY_UPDATE frame whic is sent on a Control stream and references
Request streams by ID.

---

From: Martin Duke <[email-masked]>
Date: Tue, 19 May 2020 10:52:25 -0700

We (F5) expose the max_stream_id for each type to the application. We also
have a stop_allowing_streams() API to enable things like GOAWAY.

IMO that's superior to buffering stream requests QUIC can't immediately
fulfill, or making the application poll again and again until QUIC accepts
a new stream request.

On Tue, May 19, 2020 at 10:17 AM Lucas Pardue <[email-masked]>
wrote:

> HTTP/3 describes some resource usage considerations but makes it clear
> that QUIC is responsible for managing a connection's concurrency. There is
> an expectation that HTTP/3 can ask the transport to manage a concurrency
> limit on it's behalf, but that otherwise it need no further input or
> feedback.
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 19 May 2020 14:24:41 -0400

Chrome exposes the maximum number of uni or bidi streams we've allowed the
peer to open so far(as indicated by MAX_STREAMS, code
<https://source.chromium.org/chromium/chromium/src/+/master:net/third_party/quiche/src/quic/core/quic_session.cc;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4;bpv=1;bpt=1;l=1698?originalUrl=https:%2F%2Fcs.chromium.org%2F>),
so we do some conversion to determine the largest stream ID.

This question is somewhat similar to the question of whether HTTP/3
GOAWAY should reference a transport stream ID, and in that case we decided
it was ok(#3273 <https://github.com/quicwg/base-drafts/issues/3273>)

On Tue, May 19, 2020 at 1:52 PM Martin Duke <[email-masked]> wrote:

>> During the HTTP interim meeting today [1] we came to talk a bit about
>> QUIC stream ID limits and how implementations might or might not expose
>> this property of the transport layer to an application mapping layer.
>>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 May 2020 20:33:11 +0100

Thanks for the replies so far.

> have a stop_allowing_streams() API to enable things like GOAWAY.

Interesting. Since QUIC manages stream concurrency I hadn't before
considered the benefits of asking the transport layer to stop sending
MAX_STREAMS when the application want to scheduled closure.

> it was ok(#3273 <https://github.com/quicwg/base-drafts/issues/3273>)
Thanks for reminding me of that discussion. After the HTTP meeting I
remembered the similarities to GOAWAY. However, there are is no upper bound
on the the GOAWAY stream ID because it doesn't have the same type of
processing requirements.

Another consideration here is that an application mapping might not know
the explicit maximum stream ID but it probably knows the stream concurrency
value and the number of streams in-flight. From that it can make a pretty
well-informed guess at the limit. There's practical issues such as
receiving FIN acks etc, that affect the precision but rough approximation
is possibly close enough to protect resource usage.

Cheers
Lucas