Re: [quicwg/base-drafts] Add further guidance related to unidirectional stream TPs (#2612)

[Lucas Pardue <[e-mail]>]

LPardue commented on this pull request.



> @@ -321,8 +321,19 @@ defined in this document: control streams ({{control-streams}}) and push streams
 ({{push-streams}}).  Other stream types can be defined by extensions to HTTP/3;
 see {{extensions}} for more details.
 
-Both clients and servers SHOULD send a value of three or greater for the QUIC
-transport parameter `initial_max_uni_streams`.
+The performance of HTTP/3 connections in the early phase of their lifetime is
+sensitive to the creation and exchange of data on unidirectional streams.
+Endpoints that set low values for the QUIC transport parameters
+`initial_max_uni_streams` and `initial_max_stream_data_uni` will increase the
+chance that the remote peer reaches the limit early. In particular, the value
+chosen for `initial_max_uni_streams` should consider that remote peers may wish
+to exercise reserved stream behaviour ({{stream-grease}}). Limits can be
+increased post handshake at the cost of additional RTT, for example by
+exchanging `STREAMS_BLOCKED` and `MAX_STREAMS` QUIC frames. To reduce the

Sorry I should have been more specific, I was speaking about the number of uni streams not data. If the server gives the client initial uni streams value of 1, and the client uses up, what should the server do in the sense of upping the unidirectional stream limit? Not giving sufficient unidirectional streams will cause all sorts of annoying issues at the start of a H3 connection.

> The receiver should know when all the flow control credit is used(ie: it knows the current max and it knows the amount used in order to enforce limits), so when it gets to or close to 0, it should know the peer is unable to send.

> In practice, the current text advises providing enough window for 2RTTs I believe, which is reasonably generous.

The problem is that the flow control credit starts at 0 if not specified. So, without some sensible guidance for an initial value, if a remote peer initiates a new unidirectional stream, it then needs to wait for the the local peer to send a MAX_DATA of _some_ value. Again this is pretty naff when all you are trying to do is create a HTTP/3 Control stream.

-- 
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/2612#discussion_r274968781