Re: Header compression: header set diff

On Mar 21, 2013 2:09 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
>
> To clarify-- when we do server push, often many resources with extremely
similar headers are being pushed.
>

True, but to see any benefit with delta each of those streams would need to
share compression state forcing us to synchronize encoding for all pushed
streams in the same group...  Which would obviously be detrimental to
throughput depending on our optimization strategy overall.

Also, truth be told,  other than in truly exceptional cases, I imagine many
servers are not going to want to hold on to response compression state for
any length of time - - opting instead to dump that state as quickly as
possible after sending the response so it can free up resources for the
next request.

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