Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)

Christian Huitema <> Mon, 04 May 2020 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2290C3A0DE4 for <>; Mon, 4 May 2020 10:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f0XkwWsh85bU for <>; Mon, 4 May 2020 10:40:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB9DD3A0E05 for <>; Mon, 4 May 2020 10:40:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 33E65285EA2 for <>; Mon, 4 May 2020 10:40:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588614007; bh=GBrOf0+fbEHHI4L2wY/zSUmufCiabp6MmegY5Olq4NY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=USILrepSvCrng4CsC4+4a+gvKA0HNIhFHSrbKbmR5/f0Sft+mWQytNKJ7F+JZxKWJ AXlAYJWE/d0vdwmmxp5/yGMYD17T0ygYGN841P8HEGFC+e90RTRiJb9urLuHl51yfY aUfT1G13bex5kPDnrpCYyiptaclZiqqoVvspfebU=
Date: Mon, 04 May 2020 10:40:07 -0700
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3622/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb05377248c3_58263fcf3bacd95c266f6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 May 2020 17:40:14 -0000

@dtikhonov is right. The Huffman code in h3zero was not optimized for size -- I was more concerned about being able to directly copy tables from the specs, and making sure that the result was conformant. The result in 4K of table and 1K of code. As Dmitri says, this can be easily optimized for size -- a table of 256 elements could be represented as a flat tree of 256 entries, 16 bits per entry, thus 512 bytes. The decoding code might be reduced in size too. The code size could shrink to just over 1K of code and table.

That was not my priority. But if there is demand for that, I could certainly export h3zero in its own github project, and let volunteers drive down the code size. 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: