Header compression: buffer management

[RUELLAN Herve <[e-mail]>]

In HeaderDiff we chose to let the encoder decide how the buffer is managed (regarding additions and removals). These decisions are encoded on the wire and applied by the decoder on its own buffer. We think this choice has several advantages.

First, this allows to have a very simple and lightweight decoder: it only needs to decode the decisions made by the encoder and apply them. It has no need to effectively implements a LRU mechanism for its buffer. This is especially important for small devices with limited CPU.
In addition, we think it could be of interest for an intermediary, that could keep a partial buffer containing only the entries it is interested with, ignoring the other entries.

Second, this allows to adapt the buffer management to the context. While LRU is a good algorithm in the general case for deciding which entry to remove from the buffer, it may not be the best one for every specific case. More complex algorithms can probably be devised to improve the compaction (for example taking also into account the frequency of occurrence of headers), or simpler algorithms could be used to reduce the CPU cost to the detriment of compaction (this is important for small devices).
Adaptability is also important for the future of HTTP/2.0. If we do our job correctly, HTTP/2.0 will still be used in 10 or 20 years, but we have no idea how it will be used at that time. Making HTTP/2.0 adaptable to new usages is crucial to give it a long life expectancy.


For these reasons, we prefer to keep all the buffer management on the encoder side, allowing an implementer to choose its preferred approach.

Hervé.