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, 09 Jun 2020 15:15:44 +0100
Message-ID: <CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Bence Béky <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
- Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Eric Kinnear
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Martin Thomson
- Re: Extensible Priorities and Reprioritization Bence Béky
- Priority implementation complexity (was: Re: Exte… Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Roy T. Fielding
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Martin Thomson
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Reprioritization - implementation intent Mark Nottingham
- Re: Reprioritization - implementation intent Eric Kinnear
- Nice to have guidance (was: Re: Reprioritization … Lucas Pardue
- Re: Nice to have guidance (was: Re: Reprioritizat… Eric Kinnear
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss