Re: Reference set in HPACK

Roberto Peon <grmocg@gmail.com> Wed, 02 July 2014 05:42 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD41B28D1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Jul 2014 22:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.652
X-Spam-Level:
X-Spam-Status: No, score=-7.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSwPQYa6v6cD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Jul 2014 22:42:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6EC1B28D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 1 Jul 2014 22:42:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1X2DHG-0001CG-Ji for ietf-http-wg-dist@listhub.w3.org; Wed, 02 Jul 2014 05:40:18 +0000
Resent-Date: Wed, 02 Jul 2014 05:40:18 +0000
Resent-Message-Id: <E1X2DHG-0001CG-Ji@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 1X2DHD-0001BU-3J for ietf-http-wg@listhub.w3.org; Wed, 02 Jul 2014 05:40:15 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1X2DHB-0005Fd-0A for ietf-http-wg@w3.org; Wed, 02 Jul 2014 05:40:14 +0000
Received: by mail-ob0-f177.google.com with SMTP id uy5so11328889obc.36 for <ietf-http-wg@w3.org>; Tue, 01 Jul 2014 22:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDd831/Hs06RVenl5oelPwnbVVbDkz4m2/72aL9lJgM=; b=d4eJdNL7QxBmUZW0CPUpQvPGeR1/oA8vafGEfsw3gFHFNDOt2koG3wF6VwAvBQjpXO 13kNB9rJ57DMzb0/Ofm+eGm7TqNIW16ZMXch1jS2E1q82IRLJsYRaRzDMXZDKfQuC7wz fkMxKAoKmnBVfx+KqK0KtetJdh24JCyU7+13s9he+edLPym4ob60rftt2W0S6wSioSir /Zi5Lx0Z4egBqBGdoLuPDYIqk/szecwT/4jY4S4LAGIByEIF3E69luJ91GCd7FRxaP2i UvbdLElFCal02Kn1HsTQfs04u9348k+Xv7+09lA/u2ILb59dyPCkQwrhB+9pOXtokxsa f3Lg==
MIME-Version: 1.0
X-Received: by 10.182.85.228 with SMTP id k4mr53618121obz.37.1404279586962; Tue, 01 Jul 2014 22:39:46 -0700 (PDT)
Received: by 10.76.108.12 with HTTP; Tue, 1 Jul 2014 22:39:46 -0700 (PDT)
In-Reply-To: <20140702.143041.283993814131065692.kazu@iij.ad.jp>
References: <20140702.143041.283993814131065692.kazu@iij.ad.jp>
Date: Tue, 01 Jul 2014 22:39:46 -0700
Message-ID: <CAP+FsNexzVzt+YV7oBeMdGrMoajbMVj1Z90XvQfaCuNMDjYdHg@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Kazu Yamamoto <kazu@iij.ad.jp>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e0149d350f24fc304fd2f51e3"
Received-SPF: pass client-ip=209.85.214.177; envelope-from=grmocg@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.691, 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 1X2DHB-0005Fd-0A c16c2e964011427f2f6bc8079fe46589
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Reference set in HPACK
Archived-At: <http://www.w3.org/mid/CAP+FsNexzVzt+YV7oBeMdGrMoajbMVj1Z90XvQfaCuNMDjYdHg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/25026
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>

You're basing conclusions on today's data, instead of looking forward as to
what might happen when the set of headers sent adapts to the compression
method, making it significantly more likely for items in the reference set
to be emitted.

You may want to look at how many of those entries would be regularized if
HPACK was in use and servers/clients intended on sending headers that were
similar.
-=R


On Tue, Jul 1, 2014 at 10:30 PM, Kazu Yamamoto <kazu@iij.ad.jp> wrote:

> Hi,
>
> As you may remember, I implemented several HPACK *encoding* algorithms
> and calculated compression ratio. I tried it again based on HPACK
> 08. I have 8 algorithms.
>
> - Naive    -- No compression
> - Naive-H  -- Using Huffman only
> - Static   -- Using static table only
> - Static-H -- Using static table and Huffman
> - Linear   -- Using header table
> - Linear-H -- Using header table and Huffman
> - Diff     -- Using header table and reference set
> - Diff-H   -- Using header table, reference set and Huffman
>
> The implementations above pass all test cases in
> https://github.com/http2jp/hpack-test-case/.  Using this test cases as
> input, I calculated compression ratio again. The ratio is calculated
> by dividing the number of bytes after compression by that before
> compression.
>
> Here is results:
>
> Naive     1.10
> Naive-H   0.86
> Static    0.84
> Static-H  0.66
> Linear    0.39
> Linear-H  0.31
> Diff      0.39
> Diff-H    0.31
>
> Linear-H and Diff-H results in almost the same. To my calculation,
> Diff-H is only 1.6 byte shorter than Linear-H in average. This means
> that reference set does NOT much contribute to compress headers
> although it is very difficult to implement.
>
> I have NOT seen any header examples for which reference set work
> effectively so far.
>
> So, if the authors of HPACK want to retain reference set, I would like
> to see evidence that there are some cases in which reference set
> contributes the compression ratio. HPACK 08 says "Updated Huffman
> table, using data set provided by Google". So, I guess that the
> authors can calculate the compression ratio based on this data.
>
> If there is not such an evidence, I would like to strongly recommend
> to remove reference set from HPACK. This makes HPACK much simpler, so
> implementations gets bug less and inter-operability is improved. Plus,
> the order of headers is reserved always.
>
> Regards,
>
> --Kazu
>
>
>
>
>
>