Re: Extensible Priorities and Reprioritization

Yoav Weiss <> Fri, 05 June 2020 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FF363A13C8 for <>; Fri, 5 Jun 2020 01:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.638
X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HeyCCXp1RlrC for <>; Fri, 5 Jun 2020 01:17:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 391BA3A1333 for <>; Fri, 5 Jun 2020 01:17:29 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jh7Ur-0000mj-CR for; Fri, 05 Jun 2020 08:14:37 +0000
Resent-Date: Fri, 05 Jun 2020 08:14:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jh7Uq-0000lt-0Y for; Fri, 05 Jun 2020 08:14:36 +0000
Received: from ([2a00:1450:4864:20::232]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jh7Un-0006CU-DD for; Fri, 05 Jun 2020 08:14:35 +0000
Received: by with SMTP id 9so1001928ljv.5 for <>; Fri, 05 Jun 2020 01:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tIl3luXW7/83eLKDKLrpk8T/lG+AL9+urBMJ6FVpSAQ=; b=eFabJhe3pPIM1yOkn1fBw7D9f7/qv9dyuEnvBgcoeH6xrbfn114piIp6tpxN3CZJ1W uN43/S7svDPdmlL6sCsxCF4F5fDiUtUULDZx7crYIKk4uqaRTCuwmyDi3NLfaFoWmCXa uWTu3KMKXy+EYi1Apvd6kRgzSvlbXkcdxjIFAOHZ/8m/XELKdUZfSHeigyPxAEzhFAqT hJgeuOD1lGV99kRB3S3wG7VOdu7t1ila/hwzOT0Im18W/bLINDzEaNRvmKFJntAxKF5r D7HPu2lmE6eXXe3WaIbHydyqdke+IMIpvQ2K5/kRYw18W11p5YQt3wp5VjXzHStmlcMY 6UnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tIl3luXW7/83eLKDKLrpk8T/lG+AL9+urBMJ6FVpSAQ=; b=dtecysbNJrLrW0cNyLK+R29q1+1P5Wob3j3ap03KARKjWbtDfhc+axsGcLIAvxN9Nu uDaDVSnFwGnba4MRmmLGm/u1NPPgfMAwMJgJFQLhAmcJGrG70nByGDDrXurQWn9ZkhL1 yy9+mGsrou6b7GDThkOGQW4NrzelY+ENpuCj3MJeMDmvC6c9jgCfkZ4YiDWqAyvxfclZ YLVXUiPztt0yA7wmdtabJ5JfRO5U/iF4zSpFbnkwqVXa/oPNbnovqltqEcOMgS8l5WQU 73riGFugG9Ez62JsXccHzmTCY2uERtNN0Oe+D1L0fWNefw/2JRv9DaLo445ptP5diY5S T62w==
X-Gm-Message-State: AOAM531bwgNjqDruoq7xlcAMADPiDFC4/2wxOpb5humjldZKGGQp6wu6 VB9/PT1ot2GLM4+shgpzo2+DCCk/h401wTrSdybklQ==
X-Google-Smtp-Source: ABdhPJzRAxG6HDQiHwLL1Rq6xdcsk4WztW0i1icaMo0ScyrNYvVo0sz6lhOvQStA/Hq4BSB6JFErh58ZPV4+V/SOXQY=
X-Received: by 2002:a2e:5c45:: with SMTP id q66mr4124450ljb.147.1591344860775; Fri, 05 Jun 2020 01:14:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yoav Weiss <>
Date: Fri, 5 Jun 2020 10:14:04 +0200
Message-ID: <>
To: Lucas Pardue <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Tarun Bansal <>
Cc: HTTP Working Group <>, Kazuho Oku <>
Content-Type: multipart/alternative; boundary="000000000000245aa905a751d919"
Received-SPF: pass client-ip=2a00:1450:4864:20::232;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_50=0.8, 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, T_KAM_HTML_FONT_INVALID=0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jh7Un-0006CU-DD 165ce3189604ecdcf731ab51cf5b99b4
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37722
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Jun 5, 2020 at 1:36 AM Lucas Pardue <>

> Hello folks,
> The Extensible Priorities draft has an open issue on the topic of
> reprioritization [1] and the May 2020 HTTP Interim session [2] pivoted
> towards it. The discussion highlighted that reprioritization is something
> we need to get to the bottom of in order to unblock progressing this draft.
> Our definition of the reprioritization feature is purposefully narrow, but
> the frame-related mechanics cause complications for implementations. One
> option on the table is to take reprioritization out of the critical path of
> draft-ietf-httpbis-priority by extracting the text to leave a simpler
> definition of just the scheme and the Priority header signal. The extracted
> text could be put in a separate I-D, reworked, replaced, or dropped
> altogether. The choice of action is ultimately up to the WG, so that is why
> we’re sending this email.
> Removing reprioritization from draft-ietf-httpbis-priority sounds pretty
> drastic but in all the work that’s got us here, we’ve struggled to find
> data that backs up its efficacy.
> Reducing Extensible Priorities to its core, clients issue priority signals
> (U and I) based on the expectation that the server, if possible, will
> transmit responses in the order of their urgency and request order
> (inferred by stream ID). Reprioritization is a client sending a subsequent
> signal (U’ and I’) that modifies the priority of in-flight responses.
> Reprioritization is not:
>    -
>    Sending a batch of requests and signalling the desire for later
>    requests to be sent before earlier ones. By design, that is supported using
>    urgency.
>    -
>    Purposeful ordering of requests to meet a priority objective. This a
>    client implementation choice.
>    -
>    Aborting requests or responses that are in flight. By design, that is
>    a function provided by HTTP/2 or QUIC streams that is actioned by
>    implementation choice.
>    -
>    Manipulating a dependency tree through the lifetime of a connection.
>    By design, that is not required.
>    -
>    Any other mechanisms to adjust the server’s scheduling of response
>    data. That is out of scope.
> We’d be very interested to hear from people who support keeping
> reprioritization and can provide data, directly or indirectly, that the way
> it is applied in the extensible priority scheme provides tangible benefits.
> Data to the opposite effect is also of interest.

Chromium is re-prioritizing image requests. Images are sent with low
priority and in-viewport images are later re-prioritized (once
layout happens and the browser knows they are actually in the viewport).
IIRC +Bence Béky <> implemented that re-prioritization for
H2, and may have data regarding its impact from the launch. Also CCing +Tarun
Bansal <>om>, as he may be aware of data to its efficacy.

Note that any such data regarding H2 would be biased by current H2
implementations and their challenges
with buffer bloat. So I'd tend to trust test cases/examples from known
good-actors more than internet-wide data that's more likely to be watered
down with other issues.

What's the timeline for us to provide supporting data and/or tests cases in
order to keep re-prioritization in?

> Cheers
> Kazuho and Lucas
> Extensible Priorities Editors
> [1] -
> [2] -