Re: [quicwg/base-drafts] 3+ and 4+ in the QPACK wire format are complex and inefficient (#3561)

Mike Bishop <> Tue, 31 March 2020 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 538903A2608 for <>; Tue, 31 Mar 2020 11:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[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_28=0.726, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 MxG8nK2XW-_R for <>; Tue, 31 Mar 2020 11:02:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D577F3A2605 for <>; Tue, 31 Mar 2020 11:02:35 -0700 (PDT)
Date: Tue, 31 Mar 2020 11:02:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585677754; bh=tHmXhFyw5ekxdrKrvAp8zA6d7S/TAT6JXZ62sMNLxGI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ifT6QtUELXI0j5T1AhUuPVObupuc0zjw2H6ip/mwV7RoxU1974pb71yrS/xA7LZEC wAt9GaiCGzapdvdr6HIPc1LEJHbmAGRQoeC9E36Gd2Yu2lGfU2RVb3fYEimV7LBuvF 1ceq4yMuw879cIxWgHSAVZkdvVFRl0eVg9N5ECFI=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3561/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] 3+ and 4+ in the QPACK wire format are complex and inefficient (#3561)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e8385bab1251_7dce3fe6ebccd96091982"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Tue, 31 Mar 2020 18:02:37 -0000

Let's look at the 3+ and 4+ cases:

- Literal with Post-Base Name Reference.  A 3+ can reference up to 6 values before spilling into a second byte, and the expectation is that there will usually be very few post-base entries to reference.  I would expect this to be single-byte much of the time.
- Literal without Name Reference.  I agree that there are very few names that won't require a second byte, so this doesn't come out any better most of the time.  There are also very few names that will require a third byte, so it's also no worse.
- Indexed with Post-Base Index.  A 4+ can reference up to 14 values in a single byte.  Here again, we expect there to be few Post-Base entries, so I would expect this to be single-byte most of the time.
- Literal with Name Reference.  We designed the static table's order to fill the first 14 slots with names of fields that you often won't to add to the dynamic table.  (That's why so many of the first 14 entries have an empty value.)  My expectation, which could be proven wrong by more data, is that this fits in a single byte often enough to have some benefit.

As to the complexity, I don't see it.  As soon as you have to write an encoder/decoder function that takes the prefix length as an argument, no prefix length is more complex than any other.

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