[quicwg/base-drafts] Insert Count Increment instruction description has race condition (#3082)

[Bence Béky <[e-mail]>]

Assume a decoder receives the following data:

A: the first dynamic table insertion,
B: the second dynamic table insertion,
C: the third dynamic table insertion,
X: a header block with required insert count of one.

A, B, and C are guaranteed to be received in this order, because they are all on
the encoder stream.  X arrives on a request stream, so its order relative to the
insertions is not guaranteed.

Consider the orders A, B, X, C, and A, X, B, C.  Suppose the decoder sends a
Header Acknowledgement of the header block as soon as it is received (all
necessary entries are available by that time).  This Header Acknowledgement
instruction increases the encoder's Known Received Count by one.  Suppose that
after receiving C, the decoder decides to send an Insert Count Increment
instruction.

According to
https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#insert-count-increment,
"The value of the Increment is the total number of dynamic table insertions and
duplications processed by the decoder since the last time it sent a Header
Acknowledgement instruction that increased the Known Received Count (see Section
2.1.4) or an Insert Count Increment instruction."

In the first case, one insertion (C) was processed since the last Header
Acknowledgment instruction that increased the Known Received Count was sent.  In
the second case, two insertions (B and C).

I'm ready to address this issue with a PR but waiting for review of issue 2942 which would conflict.

-- 
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/3082