[quicwg/base-drafts] Replace HPACK integer encoding (#1148)

krasic <notifications@github.com> Thu, 01 March 2018 22:11 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345F512FACE for <quic-issues@ietfa.amsl.com>; Thu, 1 Mar 2018 14:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 eizJg1khsV7G for <quic-issues@ietfa.amsl.com>; Thu, 1 Mar 2018 14:11:57 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8022312FAC6 for <quic-issues@ietf.org>; Thu, 1 Mar 2018 14:11:57 -0800 (PST)
Date: Thu, 01 Mar 2018 14:11:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1519942310; bh=welz9W6d8wuBsSiPJ3xV3mTJbMeVNMEP19cu6zWj18o=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=U81d/+xc+v8r1zqwRO7SkbmkjiC/Zvm7cbchkhQRAqR/zg82HxAfjLRtcJbtgaVGi lvYtS/pCKnta8qTaqOqdaK2y6fJRzNGx+IqjMEstmlBB42bus0VRiQIySKHkc3gp2b 25dMZBBSA2N1EIiJ1cxyJ8J66x6brvktCE51Xybg=
From: krasic <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3fbee744216ccf974f501bbb584e9fbd4cfcb83892cf0000000116b03ca692a169ce11f9bab9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1148@github.com>
Subject: [quicwg/base-drafts] Replace HPACK integer encoding (#1148)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a987aa6bd4fc_12392af42e11cec845521"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: krasic
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/rth262vTV3a6ZkDwvGDIdJ_AbV4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 22:11:59 -0000

Using the same data as an in [earlier thread](https://www.ietf.org/mail-archive/web/quic/current/msg03004.html), I noticed that a decent percent of bytes go to indexed representations, about 10% the example I looked at.    In this particular example, every indexed representation encoded in a single byte.    

If instead of byte-aligning every instruction as HPACK requires, only the entire header block were byte aligned, I could imagine saving two or more bits per indexed instruction (minus some bits of padding per header block),  an average of two bits reduced would be around 2.5% overall savings.    I happen to think this will be a bigger compression win than a lot of the other optimizations in flight*.

Part of my premise here is that for many connections the number of active dynamic table entries is relatively small, on the order of 64 or less.   I haven't sought out the best varint scheme.   A simple starting point for thought, one might construct a static huffman table, where probability is index value, i.e. smallest indices encode with fewest bits.  ( Byte alignment of the whole block might use a few extra bits of padding )

* As in the PR for separate instruction sets in [1141](https://github.com/quicwg/base-drafts/pull/1141).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1148