Re: QPACK Design Input Needed

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Thu, 29 March 2018 04:04 UTC

Return-Path: <dtikhonov@litespeedtech.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 8462C12D72F for <quic@ietfa.amsl.com>; Wed, 28 Mar 2018 21:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=litespeedtech-com.20150623.gappssmtp.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 kfI5TQ8beGuc for <quic@ietfa.amsl.com>; Wed, 28 Mar 2018 21:04:13 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 A9DA512778D for <quic@ietf.org>; Wed, 28 Mar 2018 21:04:13 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id y16so1721624pgv.1 for <quic@ietf.org>; Wed, 28 Mar 2018 21:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=iOR1HZZOwARr7gM6nZ2zV08ioSVngU6N7cTjjOJ/hJs=; b=0tW45tYAuEu4tiPyVt8WvD7liQOcWIZiXNbAAvSVknAJRlkKkfj/p3YepzvENB7wI5 EKFomR+DPUWFhs1CGEZlZTza1iL1HV5SwJya5QhnHOwfoDtahqHytzuRnc8RarFH8vE1 wfY4NNjMwz7M9MGWkzTVDiEbRz7Yv+v/mRKhIKhp1RLBPtMnXQCGw5yHLEKUL4zaLs/y 2QMzzmJPL296UnyMM/BJeAb7HDHj4V5787Y+F2bRc2D1lmjk83XTcnKYm9e9X+8Mg0kO 906Yms4awSrPa5/+DF3YcqjCMS91fm75IwRPJRcpk/0AdzKdxKcG60m2QliuuELGQ8sB SbRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=iOR1HZZOwARr7gM6nZ2zV08ioSVngU6N7cTjjOJ/hJs=; b=YX5Eqrngnhzt3nDH1CIlMh/kEf/9IiR6lIP4td5F20ByMAJ4S2b98Ykn1qvg1RnVUB V2snitvG+/wdn8yG5haCgcvij6uSwjJd/ac8MuBJjQ2KDOPQOHt+u4mrOmUiF06DLIV1 M5AS1JwYaZg9fsXiiMmuQYzhY8QEWl+DnMGyhdqffXysx80EOy4Ffi8PcBqsZWZPMHrB k6qw5AIZvd89H8rNVNABupxI3I2o+TMYG9Mw8f9arlV4YZehAGlIRm/lopdGKvxJxcZg z9d8Wl07wv1Q6zHAj6AbWqgKQmxTQrkr3+FAgXko6PH3RNJ+DfAf1O4c0ZT6CobMrP2f Qm7Q==
X-Gm-Message-State: AElRT7FN3a5+nwvs9tgOE7iYFZ7/7O7tRZPIzAWZXkywoU1UyiaDEtrh sN3RT6fI/1vE/DBaiMvU+ylseNSic6Y=
X-Google-Smtp-Source: AIpwx49mDzyh9OwcZ88DQt7016+QDNESUF+F7GzTEDhPXNrHSUD7eGL0mNlV/aBAK/mbB+Uyb9XoBA==
X-Received: by 10.167.130.71 with SMTP id e7mr5061006pfn.22.1522296253191; Wed, 28 Mar 2018 21:04:13 -0700 (PDT)
Received: from BY2PR0101MB0567.prod.exchangelabs.com ([132.245.82.84]) by smtp.gmail.com with ESMTPSA id u22sm8008957pgv.77.2018.03.28.21.04.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Mar 2018 21:04:12 -0700 (PDT)
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Alan Frindell <afrind@fb.com>, QUIC WG <quic@ietf.org>
Subject: Re: QPACK Design Input Needed
Thread-Topic: QPACK Design Input Needed
Thread-Index: ATYwQTRDbNkalxb82MraCwYuf0zH2rsto5IS
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Thu, 29 Mar 2018 04:04:10 +0000
Message-ID: <BY2PR0101MB0567D37A24F82E7E2BCFFBDDADA20@BY2PR0101MB0567.prod.exchangelabs.com>
References: <C971130C-64E4-4D77-9FAB-B49905F167A6@fb.com>
In-Reply-To: <C971130C-64E4-4D77-9FAB-B49905F167A6@fb.com>
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_BY2PR0101MB0567D37A24F82E7E2BCFFBDDADA20BY2PR0101MB0567_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hRd4tR27hqrJDLZ5Fxm1pX076QY>
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, 29 Mar 2018 04:04:15 -0000

I vote “not important.”

 - Dmitri.

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Alan Frindell <afrind@fb.com>
Sent: Wednesday, March 28, 2018 7:59:47 PM
To: QUIC WG
Subject: QPACK Design Input Needed

We need input from the working group about the importance of HPACK compatibility versus cleanliness of QPACK.  Mike’s PR (#1141), previously mentioned on list, reorganizes the instruction space, and makes a couple other compatibility-breaking changes.

The new instructions are cleaner[1] than re-using the HPACK instructions, and would allow us (now, or in the future), to increase the size of the static table without any negative compression impacts[2].

Re-using the HPACK instructions makes it easier to share code between an HPACK and QPACK implementation.  It would allow using an HPACK library directly in HTTP over QUIC with a zero byte dynamic table[3].

Which do you prefer?

Thanks

-Alan


[1] QPACK has two contexts for instructions, and all HPACK instructions are only valid in one of the contexts.  QPACK makes more efficient use of the instruction space and removes any notion of an “invalid” instruction.  My one-pass encoding PR (#1239) is kind of a hack, re-using some otherwise invalid instructions when a single instruction with a flag would be a cleaner design.

[2] In HPACK all dynamic indexes are serialized on the wire offset by the static table size.  If we increased the static table size, it would cost approximately one byte per dynamic indexed header field.  Mike’s PR replaces offsetting the index with a static bit.

[3] This is not a good idea for compression in general, as it only saves about 30% of header bytes on the wire, but it is nice for anyone trying to get an HTTP over QUIC implementation off the ground.