Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 09 June 2020 14:18 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22213A00D4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 07:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 HrBQzhkyTltY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 07:18:50 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8FA3A00B3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jun 2020 07:18:50 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jif2y-0004BO-Ju for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jun 2020 14:16:12 +0000
Resent-Date: Tue, 09 Jun 2020 14:16:12 +0000
Resent-Message-Id: <E1jif2y-0004BO-Ju@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1jif2w-0004Ac-6M for ietf-http-wg@listhub.w3.org; Tue, 09 Jun 2020 14:16:10 +0000
Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1jif2u-0002F3-0N for ietf-http-wg@w3.org; Tue, 09 Jun 2020 14:16:10 +0000
Received: by mail-wr1-x433.google.com with SMTP id p5so21489990wrw.9 for <ietf-http-wg@w3.org>; Tue, 09 Jun 2020 07:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0rgRKwspjXbiiMTnTnmqEY7g2CvMpLdM0ML1GmdXuy4=; b=amnrv05tP3xfpbew+0Cl/2DGbMn3/6JZYPQPJ/BVCrwWFIYfs8+MJkR44DHJvAwdt6 RLkJ9mVRCR4SsSI8jCx3lnP+oxPANYvXI18iCzjUgP7cQFbcDYf8SE9bhQXtGXkSskxx LTGcGPX0vPNQ1rjdn3qtz1lTnHYgtobmr1h4TA7BxUaiY94L1IkyXB9BDXAa0vte3K7l NoW3RUXP8CbQYXwUdWqKNqwd/lfn05PUFgDBZxpeBh3+QW5jEHNzFfOG8HcWDUhgcKxM NXKoJW6RfgptC2oVwj4lOwN+bhhHnklaSSsEh2IU6ywAsBG8PwN4eClrYWuDwWOkyvFq YUWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0rgRKwspjXbiiMTnTnmqEY7g2CvMpLdM0ML1GmdXuy4=; b=tfKmWpC0tIKf382RDbutZTkyNyS74teaFnuUpwHSDKrSJlmYemDoSrqnDtTEhCtA+F c/Wt8PS2L9biBmnvmVJyk4okwOy5n3pulGNFwdtRW/5yGLygOIy1BgmJx73WmumrseRn /gnxBU4FaGbJKI9i5L2OJXbHjsuOocY4fF1UNkzwAVN4yg9KGVnVzrTUy2DMnvnjCmp3 9tGl2VKjH6NwPTcnaaL7AxOISkvYkdk1vuHGC/mzK6yy9pcKrX+X9ta1JKwy5LTNOlep m9Ebkaw63kekvMX0kmuS9ZRR2nvvdTmm6m53VLFgr64OB7m38Q5jMKH3OzgJMyp/gDnY KvOw==
X-Gm-Message-State: AOAM533xkARpXfRERZl76S4Hw3G61RnNo4NiqOOMBJaRIm/nScYC6Cnh ITxxpKUlVYOfl0/xTLdlZffVy2Ui5sm+YlC0KYjsJX0h
X-Google-Smtp-Source: ABdhPJze2KzIE4WuekONbStuUAX1kVQbNrZgqQMEd++cBIbEUjFdDB8cpVTlAkHYiIsLJP6/N/4OGc+OG+REfRnmZk8=
X-Received: by 2002:adf:b60b:: with SMTP id f11mr4696554wre.7.1591712156306; Tue, 09 Jun 2020 07:15:56 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com> <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com> <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com>
In-Reply-To: <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 9 Jun 2020 15:15:44 +0100
Message-ID: <CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a9500505a7a75d21"
Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-wr1-x433.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jif2u-0002F3-0N 8b87cbea0b9f2c1c7a65d349069c907b
X-Original-To: ietf-http-wg@w3.org
Subject: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)
Archived-At: <https://www.w3.org/mid/CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37736
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Spinning off a thread of discussion focused toward implementation
complexity.

Thanks, for sharing your implementation insight Bence.

On Tue, Jun 9, 2020 at 1:11 PM Bence Béky <bnc@chromium.org> wrote:

> Hi all,
>
> I find the statement that the client often learns information that
> influences priority after the request is sent conceivable.  To me this
> implies that the additional benefit of reprioritization is comparable to
> the benefit of prioritization in the first place.  Unfortunately, however,
> I do not have any data on the effect of reprioritization on the users' page
> load experience, neither for HTTP/2 or HTTP/3.
>
> However, I can speak to the complexity part.  I have implemented the
> PRIORITY_UPDATE frame for HTTP/3 both in the client and in the server
> network stack.  I consider the complexity of server-side buffering and
> resource usage limiting minimal.  Because of this, I oppose removing
> reprioritization from the Extensible Prioritization Scheme for HTTP draft.
>

Speaking as an individual:

HTTP/3 offers a pretty rational base profile of functionality,it provides
multiplexed request/response without HoL blocking. Much of the
implementation complexity needed for this is now handled by the QUIC layer.

QUIC handles a lot of complex bits now. The remaining mandatory complexity
in HTTP/3 comes from QPACK static table and huffman coding. Victor recently
asked the QUIC WG about the possibility of further simplifying things by
allowing these opt-in [1]. Negotiating these features has some gnarly race
conditions that could be hard to fix with the protocol toolkit we have
today. Group consensus was that the design strikes a fair balance between
broad optimization and complexity; future work might let us fix the
gnarlies, so the issue was punted to a future version.

Endpoints can opt-in to two additional, more-specialized, performance
optimization features, at the cost of additional complexity: QPACK dynamic
compression and server push. The spec spells out some of the constraints
and trade offs an implementation needs to think about but the instantiation
of these features is specific to an endpoint applying some decisions to the
connection properties. Importantly, these two features can interact with
the progressively-stateful QPACK compression context and getting that wrong
(desync) can lead to security problems. So it is important to know that the
receiving peer is happy to receive QPACK or server push signals before you
send them. The spec spends quite a few words to describe these features,
even though endpoints are under no obligation to implement them or use them
on any connection where they are enabled.

I can hypothesize that an implementation with QPACK dynamic support has
already crossed the threshold of complexity that means implementing
reprioritization is not burdensome. I'd like to hear from other
implementers if they agree or disagree with this.

I tend to think of reprioritization as a more-specialized optimization of
priorities. In this sense, it is similar to QPACK and server push. The
important difference though is that extensible priorities purposefully
minimizes the need for progressive state. Ignoring a priority signal is
going to be safe. It may have a non-neglibile effect on performance, but it
is time bound and recoverable within a connection. In contrast, desync of
the old tree-based priorities could lead to strange state with no way to
recover, which means there was a stronger mandate to either a) process
PRIORITY frames even if the endpoint just wanted to implement something
minimally complex, or b) just ignore most things to be safe.

For the above reasons, IMO extensible priorities on the whole is pretty
lightweight and dispensable. I think there is a valid argument to document
reprioritization alongside the core scheme, this is in-keeping with QPACK
and server push.

Cheers,
Lucas

[1] - https://github.com/quicwg/base-drafts/issues/3622