Re: QUIC stream limits exposure to application mapping

[Lucas Pardue <[e-mail]>]

Thanks for the replies so far.

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

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.

On Tue, May 19, 2020 at 7:24 PM Ian Swett <[e-mail]> wrote:

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