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

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 19:42:39 -0700

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Jun 2019 23:17:58 -0700

I can in fact see a use case with much more than 200 concurrent requests, but then you would know that you need it, and a ramp up time might not be a big deal so the initial value is of less importance.

-- 
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#issuecomment-501564585

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 23:25:17 -0700

Admittedly, I did not argue how appropriate it is to use initial value as a way of describing the expected parallelism. If we are to address that too, the suggestion would be more like the latter (i.e. "provide clients window to issue 100 requests in parallel").

-- 
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#issuecomment-501566377

---

From: Mike Bishop <[email-masked]>
Date: Mon, 17 Jun 2019 14:36:02 -0700

I'm more inclined toward that as well.  I agree that the recommendation is to allow ~100 concurrent requests, and transport implementations could decide to consider it safe to re-issue the stream at different points in the request lifecycle.

-- 
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#issuecomment-502860138

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 17 Jun 2019 14:42:04 -0700

I think its important to keep this recommended level of effective parallelism - deployment with HTTP/2 (and DoH) has seen these recommendations easily hit.

-- 
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#issuecomment-502861908