IETF Logo Mail Archive

Re: Priority signals in HTTP/2

Willy Tarreau <w@1wt.eu> Sat, 19 December 2020 17:08 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 0A89F3A0D25 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 09:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 S93vCuZW7FSC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 09:08:27 -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 151173A0D10 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 19 Dec 2020 09:08:26 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kqffc-0001Ka-29 for ietf-http-wg-dist@listhub.w3.org; Sat, 19 Dec 2020 17:05:28 +0000
Resent-Date: Sat, 19 Dec 2020 17:05:28 +0000
Resent-Message-Id: <E1kqffc-0001Ka-29@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kqffM-0001JA-Aa for ietf-http-wg@listhub.w3.org; Sat, 19 Dec 2020 17:05:24 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kqffJ-0008NI-Jp for ietf-http-wg@w3.org; Sat, 19 Dec 2020 17:05:11 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 0BJH4r1n018859; Sat, 19 Dec 2020 18:04:53 +0100
Date: Sat, 19 Dec 2020 18:04:53 +0100
From: Willy Tarreau <w@1wt.eu>
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20201219170453.GA18787@1wt.eu>
References: <32bc8d5e-23c9-412e-84a5-5f153e827c33@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <32bc8d5e-23c9-412e-84a5-5f153e827c33@www.fastmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1kqffJ-0008NI-Jp 4ed71b2c192092f4e503fa5698877bf2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Priority signals in HTTP/2
Archived-At: <https://www.w3.org/mid/20201219170453.GA18787@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38327
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>

Hi Martin,

On Fri, Dec 18, 2020 at 01:22:19PM +1100, Martin Thomson 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):
(...)

I think I'm OK with this plan. I'm just thinking, do we have an exhaustive
list of the most annoying problems caused by the current scheme and do we
think that we could bring back some value if they were at least partially
addressed ? If so, maybe we could have the following recommendations by
order of preference:
  - new priority scheme (yet to be defined)
  - "fixed" version of the previous one to be used as a second option,
    expected to work better than nothing with existing implementations;
  - no priority handling at all (i.e. round robin or random)

Just my two cents,
Willy

v2.23.0 | Report a Bug | By Email