Re: [quicwg/base-drafts] Mandate allowing peer to create enough unidirectional streams for HTTP and QPACK (#2762)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -912,10 +912,20 @@ Endpoints that set low values for the QUIC transport parameters
 chance that the remote peer reaches the limit early and becomes blocked. In
 particular, the value chosen for `initial_max_uni_streams` should consider that
 remote peers may wish to exercise reserved stream behaviour ({{stream-grease}}).
-To reduce the likelihood of blocking, both clients and servers SHOULD send a
-value of three or greater for the QUIC transport parameter
-`initial_max_uni_streams`, and a value of 1,024 or greater for the QUIC
-transport parameter `initial_max_stream_data_uni`.
+To reduce the likelihood of blocking, both clients and servers MUST allow
+the peer to create one unidirectional stream for the HTTP control stream plus

Maybe it would be better to state "create _at least_", to avoid the confusion that the endpoints are expected to allow creation *exactly* three streams.

> @@ -912,10 +912,20 @@ Endpoints that set low values for the QUIC transport parameters
 chance that the remote peer reaches the limit early and becomes blocked. In
 particular, the value chosen for `initial_max_uni_streams` should consider that
 remote peers may wish to exercise reserved stream behaviour ({{stream-grease}}).
-To reduce the likelihood of blocking, both clients and servers SHOULD send a
-value of three or greater for the QUIC transport parameter
-`initial_max_uni_streams`, and a value of 1,024 or greater for the QUIC
-transport parameter `initial_max_stream_data_uni`.
+To reduce the likelihood of blocking, both clients and servers MUST allow

Maybe replacing "To reduce the likelihood of blocking" with "To avoid blocking" might make sense.

This is because there is in practice no chance of seeing the connection being blocked now that the text mandates endpoints allow the necessary number of streams to be open-able. The only case where blocking might still happen is when the peer might grease a unidirectional stream before creating the mandatory streams. But that causing blocking is unrelated to the provision of this paragraph.

-- 
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/pull/2762#pullrequestreview-244684013