Re: Extensible Priorities and Reprioritization

Eric Kinnear <> Tue, 09 June 2020 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 084BC3A084A for <>; Mon, 8 Jun 2020 17:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.74
X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, T_KAM_HTML_FONT_INVALID=0.01] 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 LQYmPhIQxYvm for <>; Mon, 8 Jun 2020 17:49:12 -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 8FE2E3A0847 for <>; Mon, 8 Jun 2020 17:49:12 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jiSPB-0006BI-2k for; Tue, 09 Jun 2020 00:46:17 +0000
Resent-Date: Tue, 09 Jun 2020 00:46: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 1jiSP9-0006AS-5s for; Tue, 09 Jun 2020 00:46:15 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jiSP7-0003IU-94 for; Tue, 09 Jun 2020 00:46:15 +0000
Received: from pps.filterd ( []) by ( with SMTP id 0590g91W046785; Mon, 8 Jun 2020 17:46:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=GTQc6G9Kukt555NLwlgJpR3JNQcP5PDnatzXq1uWrIA=; b=b4mFViYZGAidMhFTwtZ6JSuzYtjP8drNsQvUd9neg745OFeatqfcM0VNu2Uc+jbBAQp9 6WzabSGibglvLZi4njj6SV3YXu+/lqp6TSC8v+UY+gLF82kr5pHoh4bSbxO4QU2tjwQ2 nwxb45KDHiYCbT/X+SgVP6Cceo7Yz4V+luiGoj96OBqw/Ry7bqDKEt2LbWFVKHjngzGj ajZtXgI7Njiv0X2s4hvS9ZiegAykDYHH9dynIQM1MC+sK8SADplKzFG19bNhw/nmDoJo HMA+Z5cWf318iWIMZCgFHDenoqXSyLPXl8BCOZ+3+ZRRa5pVzBsuXx2nUPjLVB4pEkwL 2Q==
Received: from ( []) by with ESMTP id 31ga4u6042-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Jun 2020 17:46:01 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Mon, 08 Jun 2020 17:46:01 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Mon, 08 Jun 2020 17:46:01 -0700 (PDT)
X-Va-T-CD: 1d306975629049ed2d0a273297550cbe
X-Va-E-CD: 4c236cf10ae00be095cee18b19eeba57
X-Va-R-CD: 7f82eb3bc1e3bed6084fc063e7dfecba
X-Va-CD: 0
X-Va-ID: b1ff0286-4a51-49ea-9235-f54e0e9c1bfb
X-V-T-CD: 1d306975629049ed2d0a273297550cbe
X-V-E-CD: 4c236cf10ae00be095cee18b19eeba57
X-V-R-CD: 7f82eb3bc1e3bed6084fc063e7dfecba
X-V-CD: 0
X-V-ID: d1985b87-da1e-499e-b0ed-d5548bbd1656
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-08_18:2020-06-08,2020-06-08 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Mon, 08 Jun 2020 17:46:01 -0700 (PDT)
From: Eric Kinnear <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_53771FBA-BBC7-4017-A4FD-5CC0257B22A9"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 08 Jun 2020 17:46:00 -0700
In-reply-to: <>
Cc: HTTP Working Group <>, Kazuho Oku <>
To: Lucas Pardue <>
References: <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-08_18:2020-06-08,2020-06-08 signatures=0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.4
X-W3C-Scan-Sig: 1jiSP7-0003IU-94 f80984bb409e7a5913157e263875145e
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37732
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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).


> 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] - <>