incrementally indexed headers should be inserted in index '0' instead of len(table)+1 #233
Comments
|
Does this also imply that eviction should occur from the "bottom" of the table? |
|
eviction from the bottom == oldest entry dies first when all one is using is incremental indexing. With substitution indexing, that isn't true. I'm happy with either one, but I imagine that Herve might prefer one over the other. |
|
And I'm fine with either, because I intend to only do incremental indexing, since my research as shown it to be as good or better than substitution (at least so far), and because I know that incremental indexing is suitable to use in a world where we have something like TCP-minion or SCTP doing out-of-order-delivery without HOL blocking at the compressor (with a couple of small modifications). |
|
Does the small modification require you to expose the sequence number? |
|
Precisely! |
|
An argument to drop substitution indexing from the spec? |
|
Thusfar, we're assuming TCP transport, and I can imagine that substitution has the capacity to help out there, but not on substrates like TCP-Minion, SCTP, etc. On those transports substitution indexing probably hurts more than it helps. |
|
Interesting discussion. Please continue on-list :) |
|
Discussed in Seattle: we will make this change. |
Change the location of inserting and removal of headers into the header table.
…ing/adding new entries. Removed more references to substitution indexing Changed 'initial headers' to 'static headers', as per issue #258 Merged 'request' and 'response' static headers, as per issue #259 Changed text to indicate that new headers are added at index 0 and expire from the largest index, as per issue #233 Further clarifications to how eviction works #238
xml2rfc is overly pedantic about non-ASCII text. The result in this case was that Hervé's name was being mangled to include a literal `&httpwg#233;`, even in a text format (where HTML character references make no sense). To avoid that, this is what is necessary. Of course, this makes the rendering of the document with the RFC Editor stylesheet look awful. I've decided not to concern myself with that part though; the stylesheet we use is fine.
Currently, index 0 is the 'top' of the table, and when a new header is added using incremental indexing, it is added at the 'bottom' (i.e. the highest number index).
This is potentially problematic from a compression-efficacy standpoint-- data analysis shows that newly added items are the most likely to be reused or removed from the reference set, and thus most likely to be referred to again.
This implies that we should change the spec to insert headers inserted via incremental indexing into position '0' (i.e. the top)
The text was updated successfully, but these errors were encountered: