Re: Extensible Priorities and Reprioritization

Patrick Meenan <> Tue, 09 June 2020 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CDA13A0936 for <>; Tue, 9 Jun 2020 08:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.738
X-Spam-Status: No, score=-7.738 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_DNSWL_HI=-5, 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 VX09mRllzu3Y for <>; Tue, 9 Jun 2020 08:27: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 AE89B3A0900 for <>; Tue, 9 Jun 2020 08:27:30 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jig9l-0005SS-Mu for; Tue, 09 Jun 2020 15:27:17 +0000
Resent-Date: Tue, 09 Jun 2020 15:27:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jig9k-0005Rh-Pa for; Tue, 09 Jun 2020 15:27:16 +0000
Received: from ([2607:f8b0:4864:20::d32]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jig9i-0005Qe-7s for; Tue, 09 Jun 2020 15:27:16 +0000
Received: by with SMTP id o5so23140541iow.8 for <>; Tue, 09 Jun 2020 08:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5MdRfOHPnarJFaw2yNdNxUexA1jZBvPwnx0OngX6hec=; b=YbSCE/XkQEo4TR0DdHW8asi0n9/IADvGY7bte9QaFJ0hIEJ0yJ6EfkIAI5uO+eqPQk QZqw0VPBN9lAHk/uscFowVTBbceFtY4JydI3RmXAkkOA4Kz0eKJtBMs+j+gfZvZhAYbt cfeInaNDcOItSJEbpx8gIFvrvtsnhMV/Y0Odh+nLG8lp0rBnfUOqRahv6cqu0IhmsGns WPnlBX1V7oMPws/rbXwW0ofcew5s6plXzi7XMxZU3bwe+OdnQaKeHoSRDL1j+J0/9TH3 EKZi2widWjVjZdSRzaAYRWX/08Y87DBRkQMucjHnC4IG/RiV+nuWukolSfD1zyQBRg1T i9pg==
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=5MdRfOHPnarJFaw2yNdNxUexA1jZBvPwnx0OngX6hec=; b=erGA25fCu0KV8RipLH1YbLR3cO6Lto/9qQB1OHXDr+Qn1A89tWcwYbRXCGrc7T7IMu 8pmqzEOuEknZ+zITGTnBCisr98hIJMo6QYYrryeL82+yFwEsLBJ/ZgoRd/5T9jD0xd0r n+gDjZ2y7JeXT4lpLDvqMKAmtqCiLoWI+pZen730uvysnUFhHIzUJuJP2Kb5N+Sod1DU u+sQ30DFM1CRRVI+KpWLaswIsZlcT3gq+cdDzXDUrlzh5hOdy9D8yak3UYILcMt+q0Kv 2TyVbVAHZ3r7qK/VSZJSO7YDLwASSg7Ztf2PqsvyM+HKEE7xLqC5uAVI3AmkLnkDlH1B yz4Q==
X-Gm-Message-State: AOAM532Iiy9iymxpJFm9Zk05vNS+SF0XSH9R9qSoiwxApZZvyDv6c91h cOu4HaO05zqaXJ0UPfIPUz4bvB1j/IqiQ9dh+tI=
X-Google-Smtp-Source: ABdhPJxrvqwdpnpkCJ91GODiRjvxpKky8K91lKYvwIXX2ntUIgYpjtjFIaT16p7uOqysRHnpJZE2i+O0ylCgaZ+MrMY=
X-Received: by 2002:a02:2c6:: with SMTP id 189mr28041983jau.115.1591716423068; Tue, 09 Jun 2020 08:27:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Patrick Meenan <>
Date: Tue, 9 Jun 2020 11:26:51 -0400
Message-ID: <>
To: =?UTF-8?Q?Bence_B=C3=A9ky?= <>
Cc: Kazuho Oku <>, Eric Kinnear <>, Yoav Weiss <>, Patrick Meenan <>, Lucas Pardue <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000faf38805a7a85bfd"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d32;;
X-W3C-Hub-Spam-Status: No, score=-1.4
X-W3C-Scan-Sig: 1jig9i-0005Qe-7s 4bc743bae08d524d45e1dd2c6d62bcbb
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37739
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Eric's download example is a great one for exposing the risks that would
come for an implementation that supported prioritization but not

Take the trivial example of an anchor link that links to a download (say, a
200MB installer of some kind):
- When the user clicks on the link, the browser assumes it is doing a
navigation and issues the request with the "HTML" priority (relatively
high, possibly non-incremental
- When the response starts coming back, it has the content-disposition to
download to a file.
- At this point, the 200MB download will block every other lower-priority
request on the same connection (or possibly navigation if it is
- The user clicks on another page on the same site and gets nothing or a
broken experience until the 200MB download completes

Without reprioritization the browser will effectively have to burn the
existing QUIC connection and issue any requests on a new connection (and
repeat for each new download).

Implementing prioritization without reprioritization in this case is worse
than having no prioritization support at all.

On Tue, Jun 9, 2020 at 8:16 AM Bence Béky <> 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.
> Since Chrome renderer has already been sending reprioritization signals to
> the network stack when an image goes in or out of the current view, now
> PRIORITY_UPDATE frames should be sent upon these events when using HTTP/3.
> Since we had reprioritization in place in the renderer for the HTTP/2 case,
> this essentially came for free for HTTP/3 with the network stack change.
> Cheers,
> Bence
> On Tue, Jun 9, 2020 at 12:08 AM Kazuho Oku <> wrote:
>> Hello all,
>> Thank you for all the discussion.
>> To me it seems that there's sentiment that reprioritization would be
>> useful, even if it is hard to immediately prove that it is. I share that
>> sentiment.
>> At the same time, as others (mostly recently Lucas in this thread) have
>> pointed out, reprioritization is more complex to implement than compared to
>> just having initial priorities. That is because the servers need to take
>> care of frames arriving out-of-order across multiple streams.
>> That brings my mind back to the question that Lucas posted: even if we
>> think that reprioritization would be useful, should that be an
>> indispensable part of Extensible Priorities?
>> We know that the prioritization signals sent by clients are merely
>> advices; servers might or might not honor them. What we've learned from
>> HTTP/2 is that we cannot assume that the servers do the "correct" thing, if
>> the scheme being defined is complex.
>> Based on these points, my preference is starting to lean towards *not*
>> having reprioritization as an indispensable feature of Extensible
>> Priorities.
>> I am totally fine (and supportive) of having reprioritization as an
>> optional feature. I do not have a strong opinion regarding if it should be
>> kept as an optional feature of the current draft, or if it should be a
>> different draft.
>> What do you think? Would the user experience deteriorate if the server
>> only supports initial priorities? Would that deterioration be significant
>> to the extent that it would be a blocker for us to proceed?
>> 2020年6月9日(火) 9:46 Eric Kinnear <>om>:
>>> Hi all,
>>> As another datapoint, Safari (and URLSession for general HTTP use
>>> outside the browser) use reprioritization to update the incremental flag.
>>> One place where we do that update is during a download in Safari: since
>>> some responses are displayed and some responses are downloaded, we don’t
>>> know upfront if we’re going to be rendering the content onscreen or putting
>>> it in the downloads list. More generally, we support the concept of “fetch
>>> the response for this request” as well “download this resource to some path
>>> on disk for me to deal with later”, and switching between them causes us to
>>> signal whether we are [no longer] interested in incremental delivery of the
>>> resource.
>>> Unfortunately, we don’t currently have any numbers to share about
>>> efficacy here, but it does seem as though the ability to update the value
>>> that we sent is key in supporting an API that allows both directions of
>>> update:
>>> - Clients can defer updates to a resource, knowing that they can
>>> “re-request” such incremental updates should their user navigate back to
>>> some particular UI that would benefit from displaying the results of
>>> incremental delivery.
>>> - Clients can always request incremental updates and know that they can
>>> defer those incremental updates once they are able to identify that the
>>> response will not be rendered onscreen.
>>> Anecdotally, we do know that offering the ability to adjust how the
>>> on-client-device data delivery behaves can significantly impact throughput
>>> itself and also power cost (mostly due to changes in batching during
>>> delivery).
>>> Thanks,
>>> Eric
>>> On Jun 4, 2020, at 4:33 PM, Lucas Pardue <>
>>> wrote:
>>> 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.
>>> Cheers
>>> Kazuho and Lucas
>>> Extensible Priorities Editors
>>> [1] -
>>> [2] -
>> --
>> Kazuho Oku