RE: Header compression: header set diff

Roberto,

I haven't checked in these changes, and I have many changes to check in already :-(
I'll try to do it anyway.

Hervé.

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

To clarify-- when we do server push, often many resources with extremely similar headers are being pushed.

Herve-- have you checked in the changes to HeaderDiff for this so I can reproduce?
-=R

On Thu, Mar 21, 2013 at 4:47 PM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
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.

Received on Friday, 22 March 2013 13:33:46 UTC