Re: Extensible Priorities and Reprioritization
Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 05 June 2020 15:58 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 28FBC3A07EA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Jun 2020 08:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 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, 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 mksjRYUflWfJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Jun 2020 08:58:48 -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 217463A07BA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 5 Jun 2020 08:58:47 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jhEhH-0003vh-GN for ietf-http-wg-dist@listhub.w3.org; Fri, 05 Jun 2020 15:55:55 +0000
Resent-Date: Fri, 05 Jun 2020 15:55:55 +0000
Resent-Message-Id: <E1jhEhH-0003vh-GN@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 <lucaspardue.24.7@gmail.com>) id 1jhEhE-0003uv-Oo for ietf-http-wg@listhub.w3.org; Fri, 05 Jun 2020 15:55:52 +0000
Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1jhEhC-0003Wv-Sx for ietf-http-wg@w3.org; Fri, 05 Jun 2020 15:55:52 +0000
Received: by mail-wm1-x331.google.com with SMTP id y20so1890821wmi.2 for <ietf-http-wg@w3.org>; Fri, 05 Jun 2020 08:55:50 -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=HXgX5U98dFHIweZH+T0H63FkNSL6vmy8Q0zBy8xm3fs=; b=TOgJVI1r/8NftFkIzhF0fsTCIWZWXlUEGxbvtXtMDy20HFDKHLpaGKEABjmivI08d/ 0nRrDFL6BqZ+KlDhmQEbxpX8INCY/9DFVEiOEvp/P8KRpkjotxAH9XeLssO8IfhUwQ5S 6mqMB91+Q0D/aTQMIcz/Gsagh6Iyn1YP1KjaeC4EqLxMxGOZYstdkQ8AnIIoryrJ2nL8 2tKodSkVm8mT0R12AecaQwNFQmkTq9eoGr4qr7FyNXLn+DSBsvXdPoFjeyoisFQIfYof yDfZBZrY8XEchvobovjZD8Cktc7fFcecHYXlJ+TIony1odr5gbe7L5h0sUVLO5s7PM8t TDjw==
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=HXgX5U98dFHIweZH+T0H63FkNSL6vmy8Q0zBy8xm3fs=; b=O0uX4pCq+BRPDulrQRVKTMTIa1XPg7OJmgKSWUw8K/bmeVA7jnOJtHs/BjG/5RO4KH ajIqREKdPlXmbLJY8BLG8IiIxnjx6RwIlYOCuGTy0Aj873ZEh0ycGazuk/5Lg3enLJ1R RIaswoFBu0sijLtglI6trdaJdudvI2/B9BKT/cZoh5mixdVzTfo9SN2WIptktOOv1FBZ D6X2wVaRMw3kZU0bBGDtYV/5D8YXrU/uvYMhA/qdv/ZRwItPMSii+Xn/ibqykjaReK2a QpLo8MOLTOmR+SOy4gfCOQm0NWBU0qbT9P3qLPEiKv30f66J642wWNf4H5Wiavm7M4+k fI6w==
X-Gm-Message-State: AOAM531jd6A4H4aL5k/d1Bkg8bj8CVrHlXrfW1MUHYEb9DmgoREO8/7T lXFnL8+YGZcVSGlQT11Alqzn3Pgdo/MiII4xYEI=
X-Google-Smtp-Source: ABdhPJzx58eWKsjm/SU5+FXiKI2nLx7FpeWcWonP0dfzZBS0nCOoCUKPzWpSjY8rKqhnZuMDTaqDyS4z/lMe3WCwo5M=
X-Received: by 2002:a7b:c007:: with SMTP id c7mr1430934wmb.165.1591372539001; Fri, 05 Jun 2020 08:55:39 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <CACj=BEiOA=7ixKsnK85VEmC+6Tjkwaeb7zB78sgZEmRjeYD0kQ@mail.gmail.com> <CALGR9obohr44X1tfgWAbQ=akAiYmMsW4Yd_8NtR7jeJZwYxD8A@mail.gmail.com> <CAJV+MGyN0ijWd1zKb=XJwkFdriVCFmddoRB_qLrw5iRckJnirA@mail.gmail.com>
In-Reply-To: <CAJV+MGyN0ijWd1zKb=XJwkFdriVCFmddoRB_qLrw5iRckJnirA@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 05 Jun 2020 16:55:27 +0100
Message-ID: <CALGR9oaTsUKZYkwqPZt3Bu=2QHsea-LGjiwACabqz_iVS7ii7A@mail.gmail.com>
To: Patrick Meenan <patmeenan@gmail.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Bence Béky <bnc@chromium.org>, Tarun Bansal <tbansal@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e47d6705a7584aa1"
Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-wm1-x331.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, 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, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jhEhC-0003Wv-Sx b9873143a2b298a30bf57d218eedc0f3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CALGR9oaTsUKZYkwqPZt3Bu=2QHsea-LGjiwACabqz_iVS7ii7A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37725
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>
Hey Patrick, On Fri, Jun 5, 2020 at 3:41 PM Patrick Meenan <patmeenan@gmail.com> wrote: > If you're looking for a distilled test case, my HTTP/2 prioritization > test page > <https://github.com/pmeenan/http2priorities/tree/master/stand-alone> used > for the https://ishttp2fastyet.com prioritization support tracking. It > loads a bunch of images "below the fold" and then after they start loading > it injects 2 images (one after the other) into the viewport. > It's a good test case but I wonder how it directly translates to reprioritization frames. I think understanding specific wire behaviour in H2 and mapping that into Extensible priorities is the key to figuring out if PRIORITY_UPDATE frames are required. I suspect that in H2 and chrome, your test case triggers an implicit tree reshuffle because the new request is inserted somewhere with an explicit dependency. Or maybe it triggers a whole set of PRIORTY frames that shuffle the tree? How does the behaviour of other implementations look on the wire? That said, I think things play out differently in Extensible priorities. The "below the fold" images can be requested at an urgency of N, the injected images are requested later at a higher urgency between N-1 and 0. A server that follows the specification's recommendations will pass your test; no reprioritization frames are required to be sent. > Building a whole separate "VIEWPORT" scheme that is browser-specific feels > a bit like punting on the problem and effectively killing it, particularly > since most of the drive behind simplifying prioritization was for the > browser use case anyway. > Point taken. Although I will clarify that some of the drive toward a header was to expose more control to web developers. We might also want to consider how this scheme's reprioritization feature would or would not be exposed. That might limit it's usefulness even further. What are the difficult points around implementing the current > reprioritization plans? Is it a sequencing problem with streams and > out-of-band changes? Would it help if the priority change was actually a > stream-level message and specifically changed just the urgency of the > requested stream (with any server-side headers overriding even the changed > urgency)? > The H2 request/response exchange sequence [1] requires the final frame in the sequence to bear the END_STREAM flag, which closes the send side of the stream and prevents any more frames being sent. Furthermore, see the thread Mike Bishop started about H2's lack of grease and the impact on extension points [2], support for extension frames on request streams might cause connection failures. Since then Cloudflare has fixed a regression that addresses this problem but I'm unsure of the status in the wider ecosystem. For the above reasons, restricting PRIORITY_UPDATE to the control stream (H2 stream 0) is a safe deployable approach. But it introduces cross-stream referencing and that requires some careful consideration for implementations, such as buffering and resource usage. Channeling the WG discussion, I think it is reasonable to ask if clients are interested in implementing the reprioritization feature. Because if we don't exercise it with running code, it is hard to iron out the issues and capture the necessary detail in the document. As evidenced by the problems found in H2 stacks after they widely shipped. Cheers Lucas [1] - https://tools.ietf.org/html/rfc7540#section-8.1 [2] - https://lists.w3.org/Archives/Public/ietf-http-wg/2019OctDec/0047.html
- 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