Subject: Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)

From: Alessandro Ghedini <[email-masked]>
Date: Tue, 02 Apr 2019 21:36:14 +0000 (UTC)

I clarified the "An endpoint MAY avoid creating its own encoder stream" part to be more permissive (which was the intention from the beginning, it was just worded wrong).

Things that might need chaning from the above discussions:
1. Should we be explicit about decoder stream creation delay as suggested by @kazuho? I don't think there's anything preventing that right now though.
2. Regarding the "An endpoint MUST allow its peer to create both encoder and decoder streams", the HTTP draft currently says that "Both clients and servers SHOULD send a value of three or greater for the QUIC transport parameter initial_max_uni_streams" but it doesn't talk about `MAX_STREAMS`, so I guess this would be adding a new restriction. I seem to remember that was the consensus for the discussion in Tokyo, but I may be remembering wrong. Thoughts?

-- 
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/2529#issuecomment-479213967

---

From: Mike Bishop <[email-masked]>
Date: Tue, 30 Apr 2019 18:41:38 +0000 (UTC)

MikeBishop commented on this pull request.

>  HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint MUST
-initiate a single encoder stream and decoder stream. Receipt of a second
-instance of either stream type be MUST treated as a connection error of type
+initiate at most one encoder stream and one decoder stream. Receipt of a second

> Maybe swap the order to "one decoder stream and at most one encoder stream" to make it less likely to be misread as "at most one encoder stream and at most one decoder stream".

Perhaps this manifests a difference of opinion, but that's exactly how I read this text, and what I think it should say.  An implementation could defer creating both the decoder stream (because the peer hasn't yet sent anything that needs acknowledgement) and the encoder stream (because it doesn't intend to send anything on the dynamic table).

>  HTTP_WRONG_STREAM_COUNT. These streams MUST NOT be closed. Closure of either
 unidirectional stream type MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MAY avoid creating its own encoder stream if the maximum size of
+the dynamic table permitted by the peer is zero.
+
+An endpoint MAY avoid creating its own decoder stream if the maximum size of
+its own dynamic table is zero.
+
+An endpoint MUST allow its peer to create both encoder and decoder streams

> I think most implementations will take closed streams into account to know when to issue more uni stream credit. In the case of servers, there's never a need to increase it in vanilla HTTP/3. Clients need only increase it when they want more pushes (or grease, or extensions, etc).

Once the three basic streams are opened, servers never need to increase the number of streams, true.  However, the server still needs to keep giving credit as streams close until those three are opened at least.

-- 
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/2529#discussion_r279883054

---

From: Bence Béky <[email-masked]>
Date: Tue, 30 Apr 2019 11:53:38 -0700

bencebeky commented on this pull request.

In that case, I propose the wording "at most one encoder stream and at most one decoder stream".  The current text is ambigous, as evidenced by Mike and I parsing it differently.

-- 
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/2529#discussion_r279889531