Re: Extensible Priorities and Reprioritization

Kazuho Oku <kazuhooku@gmail.com> Tue, 09 June 2020 04:07 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 0F06F3A0867 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jun 2020 21:07:53 -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 Y1fJcnxbGJL2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jun 2020 21:07:50 -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 2C78A3A07F6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 8 Jun 2020 21:07:50 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jiVUz-0006No-2M for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jun 2020 04:04:29 +0000
Resent-Date: Tue, 09 Jun 2020 04:04:29 +0000
Resent-Message-Id: <E1jiVUz-0006No-2M@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 <kazuhooku@gmail.com>) id 1jiVUx-0006KO-9Z for ietf-http-wg@listhub.w3.org; Tue, 09 Jun 2020 04:04:27 +0000
Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <kazuhooku@gmail.com>) id 1jiVUu-0008IG-QZ for ietf-http-wg@w3.org; Tue, 09 Jun 2020 04:04:26 +0000
Received: by mail-ed1-x532.google.com with SMTP id e12so15183264eds.2 for <ietf-http-wg@w3.org>; Mon, 08 Jun 2020 21:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o235pvGy4TbGdlOCUMOHkqAXxO/XQZpusI57SC3pmps=; b=f2LALsK2/HipYJ+4UaIALKAGwZTIUyPy2QpKAZlrV2TU38hPnJGa3kwZXoZN9QEuPp dZVjaVS6MsI/r1RkqUr21s49Zc9pS6/dW5pq7sunaJV/ZW8zytvcjQF3mnsOH6+0Q8Fw wEmQiDPrJ1TRUsjjmqtrXvlEn6nffbpruHPf4ftNm6+7hvjQoujY/baeeIEmX6Dq9AbC ZjJ9qrOabpmj6raDj5CrLrQtJZTAc0mjFareK6hXRSZLpeJMXzbC3/myB02QWoAsrW9r mZpzsKruNV08sYoKeWMxBwv7igH5oAhpg5AeDk7kU2yNuKsqECGsZXxXRhfZCF4x+sgX h4sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o235pvGy4TbGdlOCUMOHkqAXxO/XQZpusI57SC3pmps=; b=GVwmdkTI2ftmMqSmlTWu6ihIwXkgpPvia9BWK0Q5lMcE9w8NveIC7REnsHQO3ZMfe9 /fVkOcsZlV1NZhlU3E0kJUqrMJYVLTtV4PFbz2G/bG631K2wxWHaGBXkDZd3rEYpBiLl MrwjERssyCxOPWtL+KzP9OliUMiyY+r5x4zrMIQODRZigrhNmcFS8aASqc5IU7LQv/1D T1Gk5teKdMN3aeoKhPLXnm8kOCVSyoChWfD/ri6qdEM+mLROnNt3ejNOAVAb8Jp/StWz XeYqsc1bSrLbne5+CWtlwX8nC9iGgzASIvoNPtp11JS6NLa3VMgFLi3/09F1A5l7jI3s fakg==
X-Gm-Message-State: AOAM531wqYO/8WPZbo4zMUW9KlcpWDpOI13zfPEQpQ56vhjrwwocRGHu q39GDSQnzXFszJSY+hciYlSnkbKTtRmR8iBvahQ=
X-Google-Smtp-Source: ABdhPJy3KEtf7UpMw+WIfO9hXuF3Q3nb14Myl/4w8btXEJe0bzCefXWMATrd9UjpFuai63TVfMGuNMr85AKcItLmY8U=
X-Received: by 2002:a50:8307:: with SMTP id 7mr25489508edh.283.1591675453155; Mon, 08 Jun 2020 21:04:13 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com>
In-Reply-To: <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 9 Jun 2020 13:04:02 +0900
Message-ID: <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com>
To: Eric Kinnear <ekinnear@apple.com>, Yoav Weiss <yoav@yoav.ws>, Patrick Meenan <pmeenan@webpagetest.org>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000fbb13805a79ed1a8"
Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=kazuhooku@gmail.com; helo=mail-ed1-x532.google.com
X-W3C-Hub-Spam-Status: No, score=-1.4
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_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_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jiVUu-0008IG-QZ 7ca4ad0a5528f8270145add93533508b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37733
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 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 <ekinnear@apple.com>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 <lucaspardue.24.7@gmail.com>
> 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] - https://github.com/httpwg/http-extensions/issues/1021
> [2] -
> https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities
>
>
>

-- 
Kazuho Oku