Re: QPACK and the Static Table

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 24 May 2018 06:18 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124F912D950 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 23:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GAVUrkdMceaY for <quic@ietfa.amsl.com>; Wed, 23 May 2018 23:18:15 -0700 (PDT)
Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6861200E5 for <quic@ietf.org>; Wed, 23 May 2018 23:18:15 -0700 (PDT)
Received: by mail-pl0-x241.google.com with SMTP id m24-v6so390885pls.11 for <quic@ietf.org>; Wed, 23 May 2018 23:18:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=GCbhHGAy+J+muwjSBaWurkVNjUee1oGTZue8JVvGgmI=; b=LwBFbla7VXo3s5ey25dr/g18tGqpH7u8n8DK7f4NDDYXnd3taMwElqXIZgtyQZm3Uo bdAQ8EgZqE9jIVKOJXUC/IKO7tmbecuppbS9xTxRCc2+0xo3DFKt0SjcWVaiBuIscSMP d4kwgidFRYNmoKFSNSGHdtx0wdSKbGFZYaudRLPWmveYQVn5gAH6qpwk2HjIbAy9yv0N QrJOBcLMb7LpUU04oc68XRzMtMqNxzY78f2CfoOrRF0CADAbTQ7UQwf1M0VBvsmMEnmC DZQwp0S7u3+RJuXavhhwZzICyvV+7YP1Cx5Q2yXJaOHJaYU1OZhCN078mawzNK45/Pr2 +0JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=GCbhHGAy+J+muwjSBaWurkVNjUee1oGTZue8JVvGgmI=; b=OiogNz0m+U8hoXJdXFcK5ZLMoZdg6LfO7s/t5KARWkK3PnxA2EPyHWpSy5/xggCNI7 8YibxYwkOVmWyF33PSkm/BB1oo1x2LWvR/sEUL5ZCmrvUV3dVEeaKeZ1BEtNgM7SlCs0 i7BjZ+Uq6vkhaKC7VCPPIrVu3VzZDmrLC0vk/Mz3GNiGv2xTM/AHL67StkUbGekkF7wZ UMROqzEkFUiI3J1Sn44yBp7SxNFCtIUYuonKrFYVNGdh5wCH/6fT8LX0ht1PAJPgJppr QMHPSNNm47RwIVM6xYxAFTooqmHPp+bkDf5kZE0OOHNwamzT90lToIRsplt9f/bnBDTI a06w==
X-Gm-Message-State: ALKqPwfLo05n5n0Nm4lYb8VTrVWnIymygBFN7EH4204VkfMBh+5xKMfP SXLMMquyIF1ZHko25lQU7ns511GEKus=
X-Google-Smtp-Source: AB8JxZpvisFZjz9zoaHx7TwPrJTWl/GT8EBZEA8msYiCPY4luPQ3MJO8iAAOxOTZrhQ2S7RQsHRaiw==
X-Received: by 2002:a17:902:5a03:: with SMTP id q3-v6mr5015242pli.300.1527142694397; Wed, 23 May 2018 23:18:14 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id k2-v6sm40038424pfg.82.2018.05.23.23.18.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 May 2018 23:18:13 -0700 (PDT)
From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= <mikkelfj@gmail.com>
To: Willy Tarreau <w@1wt.eu>, Mike Bishop <mbishop@evequefou.be>
CC: "quic@ietf.org" <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: QPACK and the Static Table
Thread-Topic: QPACK and the Static Table
Thread-Index: ATA3MUExtIGgs/i5yafQYsNfY1TP4jVBNDAwxc3h1f4=
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Thu, 24 May 2018 06:18:10 +0000
Message-ID: <DB6PR10MB1766FB99352EA99B31384A1CAC6A0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <SN1PR08MB1854395A2875541C4DC0673DDA6B0@SN1PR08MB1854.namprd08.prod.outlook.com>, <20180524044146.GA5215@1wt.eu>
In-Reply-To: <20180524044146.GA5215@1wt.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766FB99352EA99B31384A1CAC6A0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tGNQPuMOX1Xfmpv8zA2S3TUBVUo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 06:18:18 -0000

Mentioning CDN there are also the cross origin headers. Also needed for 1 page apps secondary api calls. (No one seems to understand them but they are there).

charset utf-8 is probably a very good idea to support.

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Willy Tarreau <w@1wt.eu>
Sent: Thursday, May 24, 2018 6:41:46 AM
To: Mike Bishop
Cc: quic@ietf.org; HTTP Working Group
Subject: Re: QPACK and the Static Table

Hi Mike,

On Wed, May 23, 2018 at 11:16:18PM +0000, Mike Bishop wrote:
> Rather than indexing the tables together and having the static table at 1-61,
> QPACK uses a bit to indicate static vs. dynamic.  Since the field is seven
> bits long, the performance is comparable for the dynamic table (you can
> access 63 entries in one byte, 190 in two), but you can increase the size of
> the static table without hurting the dynamic table.

It will make the code look less "magic"!

> As a result, we're
> building a fresh static
> table<https://github.com/quicwg/base-drafts/pull/1355> based on queries
> against HTTPArchive data.
>
> The key question that has come up in a couple venues:  What real-world
> headers do we want to artificially remove from what the data shows, and what
> headers not seen by HTTP Archive do we want to force in anyway?

I agree with Mark that request really is what matters the most.

>   *   Reordered to put headers you're likely to name-reference at the front,
>   especially if you're unlikely to add them to the dynamic table

Well, some of us have been really bothered by the lack of ordering
in the HPACK headers table, making it painful to perform efficient
lookups. I'd suggest that they are sorted by (name,value) to make
it possible to perform efficient dichotomic lookups.

> The question is whether we should also backfill headers which HTTP Archive
> wouldn't see, delete headers we wish people wouldn't use, and/or insert the
> ones we hope they eventually will.  Some candidates:

That's indeed a good point.

>   *   Add Alt-Svc entry for HTTP/QUIC with QUIC v1
>   *   Add X-Forwarded-For
>   *   Don't add X-Forwarded-For, but do add Forwarded

In practice, we can take both or none. After all, most QUIC requests going
through proxies will be encrypted already thus the proxy will not be able
to add these fields. For clear-text requests, the header field name is
roughly as long as the value, so there's not *that* much to save by encoding
them. And it will not change in most consecutive requests, so the dynamic
compression will be more efficient than the static one. Thus I suggest that
we only add them *if* we have enough unused slots at the end that we care
to cover a very broad set.

>   *   Remove Expires to incent the use of Cache-Control

Expires is for responses only anyway, thus it matters much less. Cache-control
can be used in both directions. I think that the technical focus on request
may make Expires disappear from the table ;-)

>   *   Collapse the "Content-Type: <thingey>" and "Content-Type: <thingey>; charset=utf-8" entries together
>      *   ...but which one to keep?

Probably just focus on the most reported ones and not try to collapse. I
suspect that we see a lot of en-us alone, and utf-8 added to some other
languages, but I could be wrong.

>   *   Add Content-Encoding and/or Accept-Encoding entries for zstd

Probably too early yet, and will not make a big difference overall (almost
only response, 4 characters value).

> There's an endless parade of bikesheds here.  As Martin has pointed out, this
> will never be perfect, so the goal is "good enough and keep going."  Any
> strong feelings about any of these before we merge it?

No real strong feeling here except about the ability to perform fast lookups.

> Also, there's been some discussion of a mechanism for selecting one of
> several static tables at the start of a connection.  In that case, the spec
> would probably define three tables (client headers, server headers [for
> servers that don't push], combined [for servers that push]) and enable future
> RFCs to define others for targeted scenarios (proxies, video playback, IoT,
> etc.).  How much does that interest folks?

I think it could be a good solution. We could also think about APIs and
various datacenter-oriented use cases (eg: webservice etc) where very fast
response and network efficiency matters. It could be a way to encourage
QUIC adoption inside the DC. The risk however is that tables defined too
late are never deployed due to interoperability concerns (unless there's
a way to know that it will be supported before encoding). Thus if some
participants are interested in optimizing for certain use cases, they should
probably provide their own tables to be merged into the standard from day 1.

Cheers,
Willy