[quicwg/base-drafts] HTTP/3 has less concurrency than HTTP/2 (#2787)

[Kazuho Oku <[e-mail]>]

At the moment, we state that "It is RECOMMENDED that initial_max_bidi_streams be no smaller than 100, so as to not unnecessarily limit parallelism."

This means that there is a reduction in parallelism compared to HTTP/2 that allows 100 concurrent requests, due to the following reasons:
1. unlike HTTP/2, a QUIC server is likely to consider a stream to be existing until receiving an ACK for the stream-level FIN that it has sent
2. even after the stream state is discarded (when receiving an ACK for FIN), a server might not immediately send a MAX_STREAMS frame to indicate the client can open new streams

IIUC, one of the primary reasons we want parallelism is to fulfill the bandwidth of a high latency connection even when the size of the HTTP responses are small<sup>2</sup>.

The differences pointed out above means that in such a scenario (where the responses are small, e.g. 304), the concurrency could go down from 100 requests per RTT to 50, because the minimal latency of retiring a stream state changes from 1 RTT to 2 RTT (see point 1 above).

I think we should provide some better guidance, assuming that we consider "100" that we have in HTTP/2 as a good advice.

One way would be to change the recommended minimum of initial_max_bidi_streams to 200. The other way would be to recommend servers providing clients "window to issue 100 requests in parallel," without giving them concrete suggestion on how, because the way the QUIC servers retain stream-level states and how they send MAX_STREAMS can be different.

2: The other reason is to provide sufficient amount of window for prioritization.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2787