Re: [quicwg/base-drafts] Static table negotiation (#1343)

Martin Thomson <notifications@github.com> Wed, 09 May 2018 21:57 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 DFFD512D775 for <quic-issues@ietfa.amsl.com>; Wed, 9 May 2018 14:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 D3ErRMR64yGQ for <quic-issues@ietfa.amsl.com>; Wed, 9 May 2018 14:57:49 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D8B129C6B for <quic-issues@ietf.org>; Wed, 9 May 2018 14:57:47 -0700 (PDT)
Date: Wed, 09 May 2018 14:57:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1525903066; bh=gATtwrekXSAw2TrY3qK/g1tBn2JqypqF1IdaQve3UOM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AicyVcirt5c0v24yT8dV5C7VYKyzyUb6YpyuBOAto03f4BsbPXwNl9LfoA07U/ayC 0atAcPGE1Z0/FGRY1RF/MER0IoWl5llIpxkDhO4GJGmtm0ThH5b13EEku3f8jIkFae naMhFVNi4lpC9bXygzCwUn0DjOB9Miz07fpPEeqY=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf5b6542e12002ee2c619dcd6f79845c2224f41e992cf00000001170b30da92a169ce132ccea3@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1343/387888124@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1343@github.com>
References: <quicwg/base-drafts/issues/1343@github.com>
Subject: Re: [quicwg/base-drafts] Static table negotiation (#1343)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5af36eda48bed_470b2ac122458f5472344"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/L_Bkea4zHymusN4p3C8DYeCtqwQ>
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: Wed, 09 May 2018 21:57:51 -0000

The simplest answer - don't - seems best to me.  The HPACK table is poor, and was poor the day it was released, but that doesn't mean it is useless.  The same is likely to apply to QPACK also.  I think that updating the table based on what we know today is a good move, but a fixed table is OK.

If it were easy to do, then I'd be far more likely to be interested, but as you say it's pretty hard.  The best design is probably to preface every HEADERS frame with a table identifier.  That's close to the instruction idea, but recognizes that every HEADERS frame uses the static table and that synchronization is hard.  That leads me to question whether the extra byte on every frame could be regained by having a better table.  (Yes, the instruction could be dropped once you reached a steady state, but that's both hard to manage; besides, compression efficiency during those first round trips matters most.) 

-- 
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/1343#issuecomment-387888124