Re: [quicwg/base-drafts] Length-prefixes and flow control (#1432)

[Dmitri Tikhonov <[e-mail]>]

I'd like to make another comment related to the EOS symbol.  The QPACK encoding process produces two outputs: the encoder stream instructions and the header block.  Now that the encoder framing has been removed, the encoder instructions can be written directly to the stream, while the associated header block must be buffered because we don't know its length [1,2].

We can avoid buffering of the header block by introducing an _End of the Header Block_ instruction at the cost of one byte.  The header block has just a few instructions and can easily accommodate another one.  This would also force our hand with regard to the Base Index: we'd have to pick it immediately.  On the other hand, it can make the design simpler: just set it to the same value as the Largest Reference.  This will offset the cost of the new EOS instructions, as Base Reference no longer has to be transmitted.

For this to work, we'd have to bring back _CONTINUATION_ frames, which seem to have had been designed exactly with this use case in mind.  Without them, we still have to buffer to calculate the size of the _HEADERS_ frame.  For background, see issue #76 and the [httpbis PR #548](https://github.com/http2/http2-spec/pull/548).  Needless to say, I do not agree with the rationale behind removing CONTINUATION frames from QUIC.

Footnotes:

1. I am aware of the deadlock hazard brought on by writing the header block and the encoder stream concurrently.  The assumption is that an implementation that writes to packets directly has the logic to do this right.
1. One alternative is to pre-calculate the encoded length of the header block.  This is unworkable because it a) essentially doubles the work; and b) causes buffering of unencoded header fields.

-- 
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/1432#issuecomment-410717845