Re: Priority signals in HTTP/2
Greg Wilkins <gregw@webtide.com> Sat, 19 December 2020 15:04 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 BF8033A08E7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 07:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Level:
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=webtide-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 NQGTGB2tL0jC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 07:04:31 -0800 (PST)
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 53C083A08D3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 19 Dec 2020 07:04:30 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kqdjb-00048T-6w for ietf-http-wg-dist@listhub.w3.org; Sat, 19 Dec 2020 15:01:27 +0000
Resent-Date: Sat, 19 Dec 2020 15:01:27 +0000
Resent-Message-Id: <E1kqdjb-00048T-6w@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 <gregw@webtide.com>) id 1kqdjY-00047i-RS for ietf-http-wg@listhub.w3.org; Sat, 19 Dec 2020 15:01:24 +0000
Received: from mail-oi1-x229.google.com ([2607:f8b0:4864:20::229]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <gregw@webtide.com>) id 1kqdjV-0003Uj-VM for ietf-http-wg@w3.org; Sat, 19 Dec 2020 15:01:24 +0000
Received: by mail-oi1-x229.google.com with SMTP id 15so6328384oix.8 for <ietf-http-wg@w3.org>; Sat, 19 Dec 2020 07:01:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webtide-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fJwpgKop4zb1aVNd2cETL2nLKui59Jo0SO0Msg4yhYM=; b=tJlXBNKAp+iUFRPjUA3Qb7crTWHjmi6tKbiu81fD0W7dLnMZ8lcKIbsshNkPm/UBn+ q/4qSNdxJTvjoZgEd92tU2CVW+QEjWNTaC47x9cPjjXzQuFsXlE/4zl744GIKtSS7BJ8 U4NJzmBIBHjYvS5PdlHDNdYru1MgRVmJfqqT3cvrytR5HkdnKT0e2ik+vE4MQ0MTHR39 LdHqP43IwGrlIau6yWRwWYzn63Zz4iwlDA6U04HVQ/JZZnhSCwwAhJK/VnvqpsFa1Qh2 yVaKiV5yhAego5r5U4OXjvOMClGQqpebTnyURGjvOt/4rdCDD3lzDlsyVxs8c5MCefXP Vb9w==
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=fJwpgKop4zb1aVNd2cETL2nLKui59Jo0SO0Msg4yhYM=; b=fjm1ljewxlWyhfIQiozEOAUka9I/CQzy0Bi6OiztDBIEiRqXGlDtXGiNXOz8DEZam0 vxxYBwRqzxZ2fDMDbI7inJok5RQBBAN4Wu4gJ4UuRn8xcKxRm0ccfMqQMV86+r+h9ZFh lTzLiuu3pbeDSZsbyiJof9SyL0OgUO6sA9DUr1vY2HcZug11txWH/4meQXZ+eiJlMNLR 33tpOXStNJmyfAgXA/03sDmpLd/o2tubGOHVnVOqOdkyFlQj+EPnRIepXr1mHCMZwk2o D7ckHvyOF0PAwcpnj/Y/sk1UfCbVXEbnw+xf0J2Pn8oxLvltkpj3d09J9UHfbYfS4HmI IfDQ==
X-Gm-Message-State: AOAM533ZxMqO/W9/g9sjo2fn9S4zVx8HhBQNma5mPeifbdvlR6J52iaX sY5F8Iyz747TMSePp9s8OOpSD1jmgzH8t0jw9c0xPSKMj1RIFLQord4=
X-Google-Smtp-Source: ABdhPJy+ujkDb3ONmwGi6Pv95UD6RdjrvZ0fjk+uZeLcQh9N9JHcrAZNVLHYdmDN2JmyaBmn20gnVRGC9pa8C12fPJM=
X-Received: by 2002:aca:4fd0:: with SMTP id d199mr5996547oib.33.1608390070803; Sat, 19 Dec 2020 07:01:10 -0800 (PST)
MIME-Version: 1.0
References: <32bc8d5e-23c9-412e-84a5-5f153e827c33@www.fastmail.com>
In-Reply-To: <32bc8d5e-23c9-412e-84a5-5f153e827c33@www.fastmail.com>
From: Greg Wilkins <gregw@webtide.com>
Date: Sat, 19 Dec 2020 16:00:59 +0100
Message-ID: <CAAPGdfENarbmwHyYFO1oLOyhC__o=ZW_KZBs+XCJYSN_DHU+Vw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000d4b3e205b6d27efd"
Received-SPF: pass client-ip=2607:f8b0:4864:20::229; envelope-from=gregw@webtide.com; helo=mail-oi1-x229.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kqdjV-0003Uj-VM d67710317223dda9dff332fe3fc64692
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Priority signals in HTTP/2
Archived-At: <https://www.w3.org/mid/CAAPGdfENarbmwHyYFO1oLOyhC__o=ZW_KZBs+XCJYSN_DHU+Vw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38326
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>
On Fri, 18 Dec 2020 at 03:26, Martin Thomson <mt@lowentropy.net> wrote: > Now that we're official, I'd like to get started on some of the more > difficult pieces: priority. > I wrote up a proposed plan for dealing with the priority signaling in RFC > 7540 here: > https://github.com/httpwg/http2-spec/issues/773#issuecomment-725285414 > What do people think about this general approach (quoting): > > 1. Cut the section with the detailed explanation and replace it with > some explanatory text OK > about the importance of having prioritization in a multiplexed transport > (though not necessarily signaling thereof). > Lost me here! I'm just not sure that it is universally true that priorities are needed in a multiplexed transport. I'm sure there are some circumstances that need them, but I am far from convinced that they are generally required nor that the complexity of implementation is justified in many of the cases that they might be conceptually useful. > 2. Explain that this document used to define a priority signaling > scheme, but that the one that was defined was unsuccessful. > 3. In that section recommend against using the priority signaling > scheme from RFC 7540, but explain that other endpoints that you talk to > might send these frames. > OK - I'm back onboard with 2. and 3. 4. Point to the new signaling system if that is mature enough (and > probably even if it is not). > I don't think that any new priority signalling system should be linked or recommended unless it has been proven to be of general benefit. However, I'd not be opposed to defining a general signalling system that would allow consenting endpoints to exchange arbitrary signals. Such a system could be used as the basis for a priority conversation if/when something is agreed, but would be ignorable by non consenting/participating endpoints. It would also better allow for experimenting with alternate solutions and optimizations (eg perhaps some extension to flow control would be better than priorities). > 5. Suggest, but not recommend, that servers pay attention to priority > signals using these old mechanisms in the absence of other signals. This > might take a little careful wording, but it's probably enough to caution > that ignoring signals might degrade performance and some signals might be > better than none. Point to RFC 7540 for the details of how the old scheme > works. > As a server implementor (jetty), we have thought long and hard about any way we can realistically implement priorities in a way that would not hurt our general overall performance for non prioritized handling. It may be true that ignoring priorities MIGHT degrade performance, but I think it is equally true that implementing priorities MAY itself degrade performance. We've deployed HTTP/2 in some very large scale high performance situations and our lack of priorities has not been an issue. So the careful wording should say that the RFC7540 priorities may help performance in some circumstances, but that it may also be valid to ignore them. Ie it should say "your mileage may vary"! > 6. Leave the definition of the frame type intact, but cut the > definitions right down to just the necessary pieces sizes, names, and any > mandatory processing (error handling, sizes, ranges, the hard stuff). This > should ensure that people are able to do things like generate the right > error codes and skip over the HEADERS frame pieces properly. > 7. Leave text about when PRIORITY can be sent in the state machine. > This is important for interoperating with endpoints that generate the frame. > Definitely need to keep this for interoperability. Some endpoints will send PRIORITY frames for the foreseeable future, so we can't pretend they don't exist, even if we ultimately ignore them. -- Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
- Priority signals in HTTP/2 Martin Thomson
- Re: Priority signals in HTTP/2 Cory Benfield
- Re: Priority signals in HTTP/2 Robin MARX
- Re: Priority signals in HTTP/2 Lucas Pardue
- Re: Priority signals in HTTP/2 Greg Wilkins
- Re: Priority signals in HTTP/2 Willy Tarreau
- Re: Priority signals in HTTP/2 Martin Thomson
- Re: Priority signals in HTTP/2 Martin Thomson