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

Lucas Pardue <> Mon, 04 May 2020 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1D853A0DD1 for <>; Mon, 4 May 2020 10:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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_28=1.404, 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 CTIgemmvZPZU for <>; Mon, 4 May 2020 10:46:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25F2E3A0DCF for <>; Mon, 4 May 2020 10:46:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 31172669F2B for <>; Mon, 4 May 2020 10:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588614376; bh=Msx50h3rZq2qwFtJ6uOsNbbagzqNtD412oehIjWVIBI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wh9sLF+/Ilj7GGggsbL68gfj11r7UXdOTb1mR8aB9R2p5NMLCmqfCqJVRc3GUfkyY Ya3XHZfC9OFx0NKVXX/d+LsOgst8g2er0JE86r4KwD8Dz8dP2iXXRaTmUKCDejSKsy sintG+3Q9HgOQwk4I2GUOYIy08/7WpulLaElF0+4=
Date: Mon, 04 May 2020 10:46:16 -0700
From: Lucas Pardue <>
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_5eb054e821310_22a63fe96d2cd9685219"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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:46:19 -0000

> This will in fact affect the first flight of requests if the client does not receive server's SETTINGS frame fast enough. That does sound like a problem, but it will be eventually fixed when we fix #3086, so I'm not particularly concerned.

hat-off:  I would push back against introducing a performance regression in v1 that *might* possibly be fixed in v2

> I am not sure how that kind of profile would look in practice. The reason I am filing this for v1 is that in general, you can add complexity as an opt-in, but opting out of it does not really work.

CoAP has done a pretty decent job and seems to have traction.

One way is to profile things is to create a new Application Protocol e.g. "h3-lite" or whatever, that can completely profile away all the features that are deemed as too much overhead. One could then make sweeping changes such as rewriting the message exchanges to use an ASCII-HEADERS frame that just carries verbatim headers.

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