Re: Header compression: header set diff

On Fri, Mar 22, 2013 at 6:31 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

>  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.****
>
> **
>
​
I ran some numbers testing variability on the various sample datasets we
have so far. Obviously these are far from being a statistically significant
sample but they are telling... The raw output data is here:
https://github.com/jasnell/compression-test/tree/headerstats/counts

If we take a look at just one of those (for amazon) and examine the
variability of each header across requests.. we get the following (my
apologies, fairly long list...)

accept-language      0.00273224043716  Req
:version             0.00273224043716  Req/Resp
user-agent           0.00273224043716  Req
accept-encoding      0.00273224043716  Req
:scheme              0.00273224043716  Req
connection           0.00446428571429  Req
:method              0.00546448087432  Req
x-cache              0.00847457627119  Resp?
content-encoding     0.00925925925926  Req/Resp (typically Resp)
:status              0.0109289617486   Resp
:status-text         0.0109289617486   Resp
via                  0.0127118644068   Resp
accept               0.0191256830601   Req
vary                 0.0194174757282   Resp
server               0.0280112044818   Resp
transfer-encoding    0.03125           Req/Resp (typically Resp)
pragma               0.0322580645161   Req/Resp (typcailly Req: pragma:
no-cache)
content-type         0.0502645502646   Resp
x-requested-with     0.0588235294118   Resp?
accept-ranges        0.0666666666667   Req
:host                0.068306010929    Req
referer              0.0694444444444   Req
nncoection           0.0714285714286   ?
x-cache-lookup       0.125             Resp?
if-modified-since    0.142857142857    Req
p3p                  0.173076923077    Resp
expires              0.200636942675    Resp
cache-control        0.206686930091    Resp
etag                 0.21686746988     Resp
cookie               0.238095238095    Req
set-cookie           0.25              Resp
location             0.4               Resp
content-transfer-encoding 0.5          Resp (typically)
content-location     0.5               Resp
date                 0.693150684932    Resp
x-amz-request-id     0.75              Resp
x-amz-id-2           0.815789473684    Resp
x-amz-meta-md5-hash  0.833333333333    Resp
x-amz-meta-jets3t-original-file-date-iso8601 0.833333333333 Resp
x-amz-id-1           0.866666666667    Resp
content-length       0.867605633803    Resp
last-modified        0.880794701987    Resp
age                  0.958158995816    Resp
:path                0.964480874317    Req
keep-alive           1.0               Req
if-none-match        1.0               Req

These are measurements of variability between 0.0 and 1.0. With 0.0 being
"doesn't ever change" and 1.0 being "changes with every request". I've
pulled out some of the less relevant application specific X-? extension
headers from this sample and added indicators of where the header is used.
While there are a number of Response headers with low variability (:status,
:status-text, via, content-type, the overwhelming majority of headers with
high variability are Response headers.

Yes, we will see some benefit to compressing response headers, I'm not
arguing that by any means. All I am saying is that, given these results, I
do not see any significant advantage to optimizing compression for
responses. In fact, I highly doubt most servers are going to want to
maintain response compression state for any length of time longer than it
takes to completely send that response, especially since the server has
absolutely no guarantee that it will ever need to reuse that compression
context beyond responding to the immediate request.



> **
>
> 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.****
>
> **
>

​Here I definitely agree and I am struggling with this particular point. I
am currently implementing Roberto's delta compression mechanism in Java (
https://github.com/jasnell/http2) just so we can have another
implementation to play around and experiment with, particularly for interop
testing. While there are certainly many ways the mechanism can (and will)
be optimized, the mechanism adds an additional degree of complexity that
I'm not yet fully convinced is justified. For one, the additional state
storage requirements could become rather significant, even with the
restriction that the receiver gets to control the amount of stored state.
Existing infrastructure is not designed to handle those additional memory
requirements and could require a fairly significant upgrade in order to
support it. Roberto's argument to me when I've raised that point is that
infrastructure providers for whom better compression ratios are important
will be willing to invest in upgrading their existing hardware to support
it. While that's a logical argument, I remain not fully convinced. In the
worse case, infrastructure providers will simply do a software upgrade and
set the amount of stored state to zero, which kills our compression ratios.
Furthermore, for services that operate at significantly high volume,
concerns about overall throughput is likely going to trump compression
ratio. So while I do like the idea of delta in theory, and I am impressed
with the work Roberto has done on this, my fear is that delta is trying to
be "too clever". Perhaps all we really ought to be doing at this point is
finding a more efficient way of encoding the header data (i.e. the
binary-optimized header encoding draft) and hold off on delta until we have
better analytical data to work from.



>  **
>
> 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> 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> wrote:**
> **
>
> On Thu, Mar 21, 2013 at 8:50 AM, RUELLAN Herve
> <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.****
>
> ** **
>