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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [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 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 ([128.30.52.76]) 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, 05 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-Hub-Spam-Report: BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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_IRA=-1, W3C_IRR=-3, W3C_WL=-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. Cheers Kazuho and Lucas Extensible Priorities Editors [1] - https://github.com/httpwg/http-extensions/issues/1021 [2] - https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities
- Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Eric Kinnear
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Martin Thomson
- Re: Extensible Priorities and Reprioritization Bence Béky
- Priority implementation complexity (was: Re: Exte… Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Roy T. Fielding
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Martin Thomson
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Reprioritization - implementation intent Mark Nottingham
- Re: Reprioritization - implementation intent Eric Kinnear
- Nice to have guidance (was: Re: Reprioritization … Lucas Pardue
- Re: Nice to have guidance (was: Re: Reprioritizat… Eric Kinnear
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss