Extensible Priorities and Reprioritization

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 04 June 2020 23:36 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 1821C3A1069 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 4 Jun 2020 16:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.739
X-Spam-Status: No, score=-2.739 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jBYtdjslduu5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 4 Jun 2020 16:36:23 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org []) (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 09EE33A1066 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 4 Jun 2020 16:36:22 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jgzMV-0005jA-Bp for ietf-http-wg-dist@listhub.w3.org; Thu, 04 Jun 2020 23:33:27 +0000
Resent-Date: Thu, 04 Jun 2020 23:33:27 +0000
Resent-Message-Id: <E1jgzMV-0005jA-Bp@lyra.w3.org>
Received: from titan.w3.org ([]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1jgzMT-0005iP-Af for ietf-http-wg@listhub.w3.org; Thu, 04 Jun 2020 23:33:25 +0000
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1jgzMR-00018F-Ho for ietf-http-wg@w3.org; Thu, 04 Jun 2020 23:33:25 +0000
Received: by mail-wm1-x336.google.com with SMTP id q25so7349435wmj.0 for <ietf-http-wg@w3.org>; Thu, 04 Jun 2020 16:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=4f+uEcpIV/hO/Jw/HLjLd7H3GbdrRj7TyK00wCf086E=; b=HH/zJiaoHZHMvIZKlIBtX63P+0tFSEs2fv6Ukdk1svlII7IT/ORYWm4ntZ/bjCimGT YhL05qOUh1XNUpn7QpgBp3l1+mNYOLkHEF8+DIVZo3NyN1iXMzbSN7D6F80VeuTiqzF+ c2gFDpYDYDqtKh7o8+ikpaMKuIG9kIRUVrQrsjqQtHpOOfrackXF6/cfBV8TeUQgCkxy RPj76GMNFq6b+/JB4b4mZQPz9qpwDIRTuglcZnCcst4IeClyZ7kvVmGdu6XABPkqu5WH rQtlBs7kKvrKVDFsBi0K93qgcE5qxHULFAvt6WIwCZ5ifXmorPIu6smu3gpJXTMlv+Si nxKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=4f+uEcpIV/hO/Jw/HLjLd7H3GbdrRj7TyK00wCf086E=; b=JavW0HMB6qknGYEAw8t8D21Op1BbN6yIzvddRw9WxdbF3laW8gseg1ZYEtDG0Z7/Qe ywXMH2+Xyes3cY/xRBcDRkyLn5kusPsrVkf0G7YyyC0Rsv8qXYkpq+tyo2L+yy3arRIA Pqtz8CL6M2ETWIYBEcvxzf4IQJ9+H7LQvnkeLCBLzqIyfGF4ylQd1m4ZmT9WjZNmAqLZ 0rVWlh6/XVXXsO1ESTZ7cmNDh9P3mOkVZ4o8zaIrR9Cz0A9RKzVv0y1xT+2OlHfE6jFd R7yJQ2VBrPCp33ek2k/jfj7TESwwASHwqfDi6aEbVTd137fH5m+XvIHzGePEYcMc5A6p cSTw==
X-Gm-Message-State: AOAM531ewIYCePGFrgF59b00y8CQAlwpCI1RNdnMG8rJaaMWiQ/YdB/N Kd1XTvYTE3QDkEe0n1sN70yMNZQW92MRaV0f3RKTJ2LH
X-Google-Smtp-Source: ABdhPJxSKCygmb0+jCjqA+S7C04WHxj/vS4n030TXeELn4fjlGNPJJK+r/FmHBoT1dooaJg1rbXZzvkUbeyiBN4jyf8=
X-Received: by 2002:a05:600c:224f:: with SMTP id a15mr5981186wmm.166.1591313591622; Thu, 04 Jun 2020 16:33:11 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 5 Jun 2020 00:33:06 +0100
Message-ID: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005aed3605a74a9183"
Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-wm1-x336.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Scan-Sig: titan.w3.org 1jgzMR-00018F-Ho 91514be49bbb1b38304058ce4d8ad978
X-Original-To: ietf-http-wg@w3.org
Subject: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37721
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>

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.


Kazuho and Lucas

Extensible Priorities Editors

[1] - https://github.com/httpwg/http-extensions/issues/1021

[2] -