RE: Header compression: header set diff

There are two sides on that coin.

First, for the compression ratio, in the general context of the web (i.e.: downloading webpages...), I agree that compressing request headers will have more impact on the user perceived latency than compressing response headers.
However, compressing response headers is also important in many contexts. For example, for the web, being able to MUX many 304 in the cwnd could have an impact. As Roberto pointed, it is also important for server push: the smaller the size of the push promises, the faster the data for the requested page will be sent.
In addition, from the results obtained by both Delta and HeaderDiff, I'm not so sure on the variability of response headers. I would think that their variability for one server is roughly of the same level as the variability of the request headers. In addition, server/site developers could take advantage of HTTP/2.0 in the future and reduce the variability of the response headers.

The other side of the coin is the complexity of this feature. I don't think we must only think compression ratio, but also complexity. From the data I have, this feature allows improving compaction of about 1 point for requests, while losing .25 point for responses. From my point of view, it's not worth the trouble implementing it. But I'm willing to reconsider it in view of new data.

Hervé.


From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: jeudi 21 mars 2013 21:47
To: James M Snell
Cc: Patrick McManus; HTTP Working Group; RUELLAN Herve
Subject: Re: Header compression: header set diff

Unless, of course, you ever intend to do server push :)
-=R

On Thu, Mar 21, 2013 at 3:53 PM, James M Snell <jasnell@gmail.com<mailto:jasnell@gmail.com>> wrote:

+1.. In addition to this,  response headers tend to be significantly more variable than request headers...  Which,  of course means much lower compression ratios anyway if we're talking about delta based mechanisms.  It makes very little sense to optimize for the response side.
On Mar 21, 2013 6:14 AM, "Patrick McManus" <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:
On Thu, Mar 21, 2013 at 8:50 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr<mailto:Herve.Ruellan@crf.canon.fr>> wrote:

> To better understand the impact of this choice of persisting the header set, we tested it inside HeaderDiff and saw a slight improvement of compaction for requests but also a slight(er) decrease of compaction for responses.

All else being equal (which is of course never true), compression
ratio of requests is more important than responses because the MUX
allows multiple requests to fit inside the cwnd (and thus avoid
scaling by rtt). The better the ratio, the greater the number of
transactions in 1-flight-mux. On the response side the headers are
mixed in with data frames which in many (but not all) scenarios
overhwelm the headers on a byte count basis - so the effect of header
compression is less likely to impact congestion control.