QUIC stream limits exposure to application mapping

[Lucas Pardue <[e-mail]>]

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.