Re: [quicwg/base-drafts] Clarify QPACK eviction races (#1237)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +any eviction-prone entries, which are dynamic table entries that might be
+evicted soon.  Rather than reference an eviction-prone entry, the encoder SHOULD
+emit an Indexed-Duplicate representation (see {{indexed-duplicate}}), and
+reference the duplicate instead.
+
+To identify eviction-prone entries, the encoder can maintain a draining index,
+which is the smallest absolute index in the dynamic table that it will emit a
+reference for.  As new entries are inserted, the encoder increments the
+draining index such that the amount of free and draining space in the dyanmic
+table is larger than its target threshold.
+
+~~~~~~~~~~  drawing
+   +----------------+-----------------------+------------+
+   | Eviction-prone |     Referenceable     | Free Space |
+   |    Entries     |        Entries        |            |
+   +----------------+-----------------------+------------+

The point here is not that there might be some free space (there is almost always free space because header fields are not necessarily a neat fit for the available space), but that the encoder needs to keep its hands off those entries that are close to eviction.  Eviction-prone is misleading, because it implies that there is a probability of eviction.

I think that this map is misleading though.  There are three important classifications here:

* Entries that are near eviction, such that new insertions might be blocked by outstanding references to those entries.
* Entries that are recently added (i.e., those that are "vulnerable"), such that references to them might cause the receiver to block.
* Other entries that are acknowledged, but not near eviction.

The line between those that are "vulnerable" and acknowledged is crisp.  The point here is that the line between near-eviction and merely acknowledged is fuzzy and subject to heuristics.

I think that you also want to say that keeping the near-eviction index in the range of acknowledged entries will prevent perverse behaviour.  If the two ever cross, you can get duplication on every header block, which causes unnecessary churn.  (It's also possible to get that without the two crossing with a naive implementation, but I don't think that we need to get into that too much.)

-- 
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/1237#discussion_r184911335