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

[afrind <[e-mail]>]

afrind commented on this pull request.



>  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).

> Thinking about this a little more, its a nice feature of HPACK that it can chose when to start using dynamic compression, with little overhead.

I suppose that's a feature of HPACK, but is it really all that useful?  I think of it the other way - HPACK was simpler to setup (didn't require any extra streams) but that's because the underlying transport provides the strong ordering guarantee.  If you want QPACK dynamic table then you have to open some streams.  Just do it at the beginning of the connection when you know you have credit, or risk not being able to use it later, if you consume the credit with some other 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/2529#discussion_r267926845