RE: Header compression: header set diff

RUELLAN Herve <Herve.Ruellan@crf.canon.fr> Fri, 22 March 2013 13:35 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B3621F8B7E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Mar 2013 06:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.074
X-Spam-Level:
X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2hjwwveE0zA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Mar 2013 06:35:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F276721F8B84 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 22 Mar 2013 06:35:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UJ26Z-00009R-Da for ietf-http-wg-dist@listhub.w3.org; Fri, 22 Mar 2013 13:33:59 +0000
Resent-Date: Fri, 22 Mar 2013 13:33:59 +0000
Resent-Message-Id: <E1UJ26Z-00009R-Da@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UJ26M-00006E-Lc for ietf-http-wg@listhub.w3.org; Fri, 22 Mar 2013 13:33:46 +0000
Received: from inari-msr.crf.canon.fr ([194.2.158.67]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UJ26H-00047m-2d for ietf-http-wg@w3.org; Fri, 22 Mar 2013 13:33:46 +0000
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r2MDXB3e031358; Fri, 22 Mar 2013 14:33:11 +0100
Received: from ADELE.crf.canon.fr (adele.fesl2.crf.canon.fr [172.19.70.17]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r2MDXBj1013460; Fri, 22 Mar 2013 14:33:11 +0100
Received: from ADELE.crf.canon.fr ([::1]) by ADELE.crf.canon.fr ([::1]) with mapi id 14.02.0342.003; Fri, 22 Mar 2013 14:33:11 +0100
From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
To: Roberto Peon <grmocg@gmail.com>, James M Snell <jasnell@gmail.com>
CC: Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Header compression: header set diff
Thread-Index: Ac4mL1LuwGxSnbYUSfCTl+emPK1Flv///DKAgABv1ACAAA8SAIAABluA//7czIA=
Date: Fri, 22 Mar 2013 13:33:10 +0000
Message-ID: <6C71876BDCCD01488E70A2399529D5E5163F3CA8@ADELE.crf.canon.fr>
References: <6C71876BDCCD01488E70A2399529D5E5163F39CB@ADELE.crf.canon.fr> <CAOdDvNq8K52L1rOF8GR7pi4VDx+fOshO=Co7O+0YQTGUL9XMZw@mail.gmail.com> <CABP7RbfCyK8EFHt7g2s+uFhQHHPs3tv=2eunJ8rYDYgz2p=wmw@mail.gmail.com> <CAP+FsNcHTJRsuZ9ZAH6FdQnQjBSpJ08brYnbNhnSM0e5_ZjLAA@mail.gmail.com> <CAP+FsNdvWxMuxMvw3zqfRG_gWf8tMUhahejp_nGkqB-VOvjboA@mail.gmail.com>
In-Reply-To: <CAP+FsNdvWxMuxMvw3zqfRG_gWf8tMUhahejp_nGkqB-VOvjboA@mail.gmail.com>
Accept-Language: en-US, fr-FR
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.7.30]
Content-Type: multipart/alternative; boundary="_000_6C71876BDCCD01488E70A2399529D5E5163F3CA8ADELEcrfcanonfr_"
MIME-Version: 1.0
Received-SPF: none client-ip=194.2.158.67; envelope-from=Herve.Ruellan@crf.canon.fr; helo=inari-msr.crf.canon.fr
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: AWL=-1.165, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.497
X-W3C-Scan-Sig: lisa.w3.org 1UJ26H-00047m-2d b0157d859c82c45ffc0c1115a06d2236
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Header compression: header set diff
Archived-At: <http://www.w3.org/mid/6C71876BDCCD01488E70A2399529D5E5163F3CA8@ADELE.crf.canon.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17116
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.