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