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