Re: Extensible Priorities and Reprioritization

Patrick Meenan <patmeenan@gmail.com> Tue, 09 June 2020 15:27 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 7CDA13A0936 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 08:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.738
X-Spam-Level:
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: 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 VX09mRllzu3Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 08:27:30 -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 AE89B3A0900 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jun 2020 08:27:30 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jig9l-0005SS-Mu for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jun 2020 15:27:17 +0000
Resent-Date: Tue, 09 Jun 2020 15:27:17 +0000
Resent-Message-Id: <E1jig9l-0005SS-Mu@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <patmeenan@gmail.com>) id 1jig9k-0005Rh-Pa for ietf-http-wg@listhub.w3.org; Tue, 09 Jun 2020 15:27:16 +0000
Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <patmeenan@gmail.com>) id 1jig9i-0005Qe-7s for ietf-http-wg@w3.org; Tue, 09 Jun 2020 15:27:16 +0000
Received: by mail-io1-xd32.google.com with SMTP id o5so23140541iow.8 for <ietf-http-wg@w3.org>; Tue, 09 Jun 2020 08:27:13 -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=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; d=1e100.net; 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: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com> <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com> <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com>
In-Reply-To: <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com>
From: Patrick Meenan <patmeenan@gmail.com>
Date: Tue, 09 Jun 2020 11:26:51 -0400
Message-ID: <CAJV+MGy2CytgPVEwEO3nDfpZ6h9+CCL-bODk=65cXexvS3N7Lw@mail.gmail.com>
To: Bence Béky <bnc@chromium.org>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Eric Kinnear <ekinnear@apple.com>, Yoav Weiss <yoav@yoav.ws>, Patrick Meenan <pmeenan@webpagetest.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000faf38805a7a85bfd"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d32; envelope-from=patmeenan@gmail.com; helo=mail-io1-xd32.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: mimas.w3.org 1jig9i-0005Qe-7s 4bc743bae08d524d45e1dd2c6d62bcbb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CAJV+MGy2CytgPVEwEO3nDfpZ6h9+CCL-bODk=65cXexvS3N7Lw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37739
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>

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

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
non-incremental)
- 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 <bnc@chromium.org> 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 <kazuhooku@gmail.com> 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 <ekinnear@apple.com>:
>>
>>> 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
>>
>