Draft: draft-ietf-quic-qpack

Commentary: Fixes issue . This PR fixes the race condition and clarifies that both endpoints must keep track of the Known Received Count . Also remove " If a header block was potentially blocking " phrase from Known Received Count section , because it is redundant with the clear instructions on whether to increase the Known Received Count in the next sentence . Also remove " for example because the encoder or the decoder have chosen not to risk blocked streams " and defer to new - table - entries instead , so that all guidance on emitting Insert Count Increment instructions is in one place . Note that the decoder has no way to know if the encoder chose not to risk blocked streams , so I find this phrase confusing to start with . 
 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 ,   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 , " 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 4 ) or an Insert Count Increment instruction . " In the first case , one insertion ( C ) was processed since the last   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 . 
 Ah , it needs to explicitly reference the Required Insert Count from the header block that was acked , rather than " since the last time " . I think this is editorial , since that 's the intent of the text . 
 I agree that it 's editorial . In I 'm already proposing to mandate both the encoder and the decoder to keep track of the Known Received Count . Then Insert Count Increment could simply increase Known Received Count , without any references to previously acked header blocks if any etc . 
 Fixed by
Paragraph (version A):
The Known Received Count is the total number of dynamic table
insertions and duplications acknowledged by the decoder.  The encoder
tracks the Known Received Count in order to identify which dynamic
table entries can be referenced without potentially blocking a
stream.  The decoder tracks the Known Received Count in order to be
able to send Insert Count Increment instructions (see insert-count-
increment).
Paragraph (version A):
If a header block was potentially blocking, the encoder infers from
receiving a Header Acknowledgement instruction (header-
acknowledgement) that the decoder has received all dynamic table
state necessary to process that header block.  If the Required Insert
Count of the acknowledged header block is greater than the current
Known Received Count, the encoder updates the Known Received Count to
the value of the Required Insert Count of the acknowledged header
block.
Paragraph (version A):
To acknowledge dynamic table entries which are not referenced by
header blocks, for example because the encoder or the decoder have
chosen not to risk blocked streams, the decoder sends an Insert Count
Increment instruction (see insert-count-increment).
Paragraph (version B):
The Known Received Count is the total number of dynamic table
insertions and duplications acknowledged by the decoder.  The encoder
tracks the Known Received Count in order to identify which dynamic
table entries can be referenced without potentially blocking a
stream.  The decoder tracks the Known Received Count in order to be
able to send Insert Count Increment instructions.
Paragraph (version B):
A Header Acknowledgement instruction (header-acknowledgement) implies
that the decoder has received all dynamic table state necessary to
process corresponding the header block.  If the Required Insert Count
of the acknowledged header block is greater than the current Known
Received Count, Known Received Count is updated to the value of the
Required Insert Count.
Paragraph (version B):
An Insert Count Increment instruction insert-count-increment
increases the Known Received Count by its Increment parameter.  See
new-table-entries for guidance.
Paragraph (version B):
The Header Acknowledgement instruction might increase the Known
Received Count, see known-received-count.
Paragraph (version A):
The Insert Count Increment instruction begins with the '00' two-bit
pattern, followed by the Increment encoded as a 6-bit prefix integer.
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 known-received-count) or an Insert Count
Increment instruction.  The encoder uses this value to update the
Known Received Count, as described in state-synchronization.
Paragraph (version B):
The Insert Count Increment instruction begins with the '00' two-bit
pattern, followed by the Increment encoded as a 6-bit prefix integer.
This instruction increases the Known Received Count (see known-
received-count) by the value of the Increment parameter.  The decoder
should send an Increment value that increases the Known Received
Count to the total number of dynamic table insertions and
duplications processed so far.