Re: QUIC stream limits exposure to application mapping

[Ian Swett <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
>> 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.
>>
>