Re: Choosing a header compression algorithm

Roberto Peon <grmocg@gmail.com> Sat, 23 March 2013 00:26 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 02DFE21F8F31 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Mar 2013 17:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.483
X-Spam-Level:
X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 2ZdGgQixjcJu for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Mar 2013 17:26:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53C21F8F2E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 22 Mar 2013 17:26:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UJCGy-0000fg-5C for ietf-http-wg-dist@listhub.w3.org; Sat, 23 Mar 2013 00:25:24 +0000
Resent-Date: Sat, 23 Mar 2013 00:25:24 +0000
Resent-Message-Id: <E1UJCGy-0000fg-5C@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UJCGm-0000en-OQ for ietf-http-wg@listhub.w3.org; Sat, 23 Mar 2013 00:25:12 +0000
Received: from mail-ob0-f182.google.com ([209.85.214.182]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UJCGh-000816-62 for ietf-http-wg@w3.org; Sat, 23 Mar 2013 00:25:10 +0000
Received: by mail-ob0-f182.google.com with SMTP id ef5so1929587obb.13 for <ietf-http-wg@w3.org>; Fri, 22 Mar 2013 17:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/GbxFzaJnvAH3HwUIrS4rJ9qzPnbGY6Krw/grZaGLUQ=; b=R6yHHkifL3yg62TKePzIS/oho1+AAgAFLo53Lw3N5icKqyFgT5I/+oVULamty5wEQx 3v+HcVANiNEoK0L7PuLVuUDShswQOeXGaMhBTkYvO+ci8S/UiNAsxESBTvkM2uidBQbI QYhzn/fpyDfxWbvo9GD6QFYYjm+naLYf/M9FOXOjEsgAT64JMFqt+FHZp+9klxmWGZkd EeTX0fdYWPq48pjW+Isq54ircMz27bNie1bWqAu3DWtVatCOn3khy8PO10Ly7EQdKhfi k8Fo4lO02V7elvvQ2pE3Y39j6gxpSYtVsZZR9mFMIuFVZAbpgKiPuXYARJWOJ9zzs8l1 f91A==
MIME-Version: 1.0
X-Received: by 10.60.172.84 with SMTP id ba20mr3771007oec.10.1363998281158; Fri, 22 Mar 2013 17:24:41 -0700 (PDT)
Received: by 10.76.109.72 with HTTP; Fri, 22 Mar 2013 17:24:40 -0700 (PDT)
Received: by 10.76.109.72 with HTTP; Fri, 22 Mar 2013 17:24:40 -0700 (PDT)
In-Reply-To: <CABkgnnWKBvNnzE7JTfX=x7oYJsWBp7zsB6S9Ubnv8e6o8t2ZpA@mail.gmail.com>
References: <254AABEE-22B9-418E-81B0-2729902C4413@mnot.net> <A14105FB-ED1A-4B70-8840-9648847BCC3A@mnot.net> <6C71876BDCCD01488E70A2399529D5E5163F3C67@ADELE.crf.canon.fr> <CAP+FsNfFohSwrX2DxthNcnn+wDj6T5W7xpcg4yA56Gvt_nP3_Q@mail.gmail.com> <CABkgnnWKBvNnzE7JTfX=x7oYJsWBp7zsB6S9Ubnv8e6o8t2ZpA@mail.gmail.com>
Date: Fri, 22 Mar 2013 20:24:40 -0400
Message-ID: <CAP+FsNd9KFSs78Kapoj_wBMggnM-MTrapo1S=ZTc-0yh0Vh2jQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Content-Type: multipart/alternative; boundary="bcaec55408ac05d7c304d88c998c"
Received-SPF: pass client-ip=209.85.214.182; envelope-from=grmocg@gmail.com; helo=mail-ob0-f182.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.731, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UJCGh-000816-62 4141f90f177b20358132e9380550795d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Choosing a header compression algorithm
Archived-At: <http://www.w3.org/mid/CAP+FsNd9KFSs78Kapoj_wBMggnM-MTrapo1S=ZTc-0yh0Vh2jQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17124
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>

Ya, connection management and compression are linked.

Sharing of connections when both the cert and the DNS resolution match is
something that is done today for SPDY and which does reduce latency
(generally by at least 2 RTT but often effectively more due to slow start,
etc. ) as well as reducing connection counts, server load, etc.

In SPDY4, we'll be experimenting with policy w.r.t. connection sharing, as
what exists today is both too much or too little, depending on what one
wants, but the latency (etc.) savings are likely to be compelling.

The proxy case is another where this matters, as you point out, but that
isn't where the biggest win has been so far since there has been
significant experience with that mode of operation yet (unless Amazon
speaks up!). It is an interesting case though.

-=R
On Mar 22, 2013 1:12 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 22 March 2013 10:45, Roberto Peon <grmocg@gmail.com> wrote:
> > Correct, delta2 uses a header group per host, however, the real benefits
> of
> > this don't show up with the current streamifier, which removes the
> > intermingling of requests to different hosts (which is a bit unrealistic,
> > but does makes the graphs easier to parse visually).
> > This can end up really mattering to the compression in the cases where
> there
> > is some ping-ponging between different host headers.
>
> Isn't this only a concern/advantage for the hop between a client and a
> client-side proxy?  Requests toward different hosts are going to be on
> their own connections in all other situations.  Origin servers are
> unlikely to see any benefits from improved compression between hosts.
>
> The question of reuse of a connection for different authorities is
> still unresolved.  I know that  this is on some people's minds, but we
> haven't seen any proposals, nor do I think we're ready to go there
> just yet.
>