Re: [quicwg/base-drafts] Use "Insert Count" rather than "Largest Reference" (#2111)

[afrind <[e-mail]>]

afrind commented on this pull request.

I'm not really sure that Largest Reference was so unclear or that this provides substantially more clarity.  Interested to hear what other think as well.

> @@ -249,18 +250,19 @@ Because QUIC does not guarantee order between data on different streams, a
 header block might reference an entry in the dynamic table that has not yet been
 received.
 
-Each header block contains a Largest Reference ({{header-prefix}}) which
-identifies the table state necessary for decoding. If the greatest absolute
-index in the dynamic table is less than the value of the Largest Reference, the
-stream is considered "blocked."  While blocked, header field data SHOULD remain
-in the blocked stream's flow control window.  When the Largest Reference is
-zero, the frame contains no references to the dynamic table and can always be
-processed immediately. A stream becomes unblocked when the greatest absolute
-index in the dynamic table becomes greater than or equal to the Largest
-Reference for all header blocks the decoder has started reading from the stream.
-If the decoder encounters a header block where the actual largest reference is
-not equal to the Largest Reference declared in the prefix, it MAY treat this as
-a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED.
+Each header block contains the total number of entries added to the dynamic
+table - the Insert Count - which identifies the table state necessary for
+decoding (see {{header-prefix}}). If the Insert Count is greater than the number

I think this will be somewhat confusing, because the state of the table at the encoder at the time of encoding (insert count) can be different than the table state (insert count) required to decode a particular block.  Maybe if you called it 'Required Insert Count' in the header prefix that would make it clear that an encoder shouldn't just blindly use the actual Insert Count?

>  
 n = count of entries inserted
 d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Control Stream"}
 
 Because frames from request streams can be delivered out of order with
-instructions on the encoder stream, relative indices are relative to the Base
-Index at the beginning of the header block (see {{header-prefix}}). The Base
-Index is an absolute index. When interpreting the rest of the frame, the entry
-identified by Base Index has a relative index of zero.  The relative indices of
-entries do not change while interpreting headers on a request or push stream.
+instructions on the encoder stream, relative indices are relative to the Base at
+the beginning of the header block (see {{header-prefix}}). The Base is encoded
+as a value relative to the Insert Count, so it can be expressed as the number of
+entries inserted. The dynamic table entries up to the Base can be referenced.

What about post-base?

>  
 n = count of entries inserted
 d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Control Stream"}
 
 Because frames from request streams can be delivered out of order with
-instructions on the encoder stream, relative indices are relative to the Base
-Index at the beginning of the header block (see {{header-prefix}}). The Base
-Index is an absolute index. When interpreting the rest of the frame, the entry
-identified by Base Index has a relative index of zero.  The relative indices of
-entries do not change while interpreting headers on a request or push stream.
+instructions on the encoder stream, relative indices are relative to the Base at
+the beginning of the header block (see {{header-prefix}}). The Base is encoded
+as a value relative to the Insert Count, so it can be expressed as the number of
+entries inserted. The dynamic table entries up to the Base can be referenced.

> The Base is encoded as a value relative to the Insert Count, so it can be expressed as the number entries inserted

I'm having a hard time understanding why you are trying to say here.  That Base in the number of entries inserted?  Or the encoding of Base is the number of entries inserted?

>  
 n = count of entries inserted
 d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Control Stream"}
 
 Because frames from request streams can be delivered out of order with
-instructions on the encoder stream, relative indices are relative to the Base
-Index at the beginning of the header block (see {{header-prefix}}). The Base
-Index is an absolute index. When interpreting the rest of the frame, the entry
-identified by Base Index has a relative index of zero.  The relative indices of
-entries do not change while interpreting headers on a request or push stream.
+instructions on the encoder stream, relative indices are relative to the Base at
+the beginning of the header block (see {{header-prefix}}). The Base is encoded
+as a value relative to the Insert Count, so it can be expressed as the number of
+entries inserted. The dynamic table entries up to the Base can be referenced.
+The most recently inserted entry within the limit set by the Base has a relative
+index of 0.
+
+Though new entries could be added while processing a header block, the relative
+indices of entries do not change.

How are new entries added while processing a header block?  Do you mean on the encoder side?  Maybe encoding would be better than processing then?

>  
 In order to identify which dynamic table entries can be safely used
 without a stream becoming blocked, the encoder tracks the absolute index of the
-decoder's Largest Known Received entry.
+decoder's Known Received Count entry.

What is the decoder's Known Received Count entry?  That doesn't really make sense to me, maybe just this sentence needs rewording.

What the encoder is tracking is the state of the decoder.  The state of either the encoder or the decoder can be uniquely identified by the number of inserts that it has performed on its dynamic table.  

Would it be helpful to call the a table's 'State' or 'Version'?  Or maybe change it from "Known Received Count" to "Decoder's Known Insert Count"?

>  
 n = count of entries inserted
 d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Control Stream"}
 
 Because frames from request streams can be delivered out of order with
-instructions on the encoder stream, relative indices are relative to the Base
-Index at the beginning of the header block (see {{header-prefix}}). The Base
-Index is an absolute index. When interpreting the rest of the frame, the entry
-identified by Base Index has a relative index of zero.  The relative indices of
-entries do not change while interpreting headers on a request or push stream.
+instructions on the encoder stream, relative indices are relative to the Base at
+the beginning of the header block (see {{header-prefix}}). The Base is encoded
+as a value relative to the Insert Count, so it can be expressed as the number of
+entries inserted. The dynamic table entries up to the Base can be referenced.
+The most recently inserted entry within the limit set by the Base has a relative

> The most recently inserted entry with the limit set by the Base

I think this is where calling it Base rather than Base Index becomes awkward.  Base Index tells you which entry in the table is relative index 0.

-- 
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/2111#pullrequestreview-186287017