Re: Extensible Priorities and Reprioritization

Patrick Meenan <> Fri, 05 June 2020 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 432B53A07F8 for <>; Fri, 5 Jun 2020 07:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ns708jFmhTno for <>; Fri, 5 Jun 2020 07:44:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C8763A07F6 for <>; Fri, 5 Jun 2020 07:44:03 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jhDX1-0003vZ-Tr for; Fri, 05 Jun 2020 14:41:15 +0000
Resent-Date: Fri, 05 Jun 2020 14:41:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jhDWz-0003ui-1W for; Fri, 05 Jun 2020 14:41:13 +0000
Received: from ([2607:f8b0:4864:20::d29]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jhDWx-00087O-3V for; Fri, 05 Jun 2020 14:41:12 +0000
Received: by with SMTP id c8so10555418iob.6 for <>; Fri, 05 Jun 2020 07:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FGX3UyyMcZxY0D2tYCpqSegF0pG4uiqFjq9vh7q8EtM=; b=WLPbzFsnyH3TuPJMm3xm0HAl9kxIFJueTZJSV6g58kKkNcM0wIrWCxhwNrTsbAh9QK ldI8q261vVQFJOxlOiG8Ge6YiWcNwxUGj1Szw0fkktiyLXnvPoKm3+LxC2XkQ1HTpVlv QTBpdyCasrja712637ugsHQZ91qaUtoZElFPy6wDzDDuQH4u3X4/EDi74KaaIEQzye18 dVZlM87ZvNFqbyvhzX4V/Q9wPxSydCwl24E59Dhg2oXz14CEFJSD2O4dynGJVVMJsA6l a0HDJW+D/QmMU843T0OuwtaISr/3CBqyh7636o6NBnij6ndUM/spa1sTDpe4cGzlSvfQ KuVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FGX3UyyMcZxY0D2tYCpqSegF0pG4uiqFjq9vh7q8EtM=; b=XY+mba1rmCn0sjPnlftTzUfrCy4MDYMuIOsEGVvkgUZhGRi4X7vPlEiDGIb2a3W59o nN1o/+/QhImtNXFSiMENtJiO0uuubDpjVr1gkvlfWgW/BhqAwzQuqBbNm781NwwakUiA AB6BMtUdOI0lGTBgp9flB/ATXjbVsDjEbx/yVcOY+DY835MV2dyhXvBT4W5mVa1fk8OH Cuo5JjyNYADhUsOIm7VlAQC4RSykUaGnQQD5UR0WLJ1qZClwdHgxU3t9amU0fFX4LLi5 2pqiBf6zNOrnEwqiB+CrUjqnuYy+rk7Sa8HXO4tAuGfs0zac++AIQBDvbmCPv3Z7DFjZ m6Eg==
X-Gm-Message-State: AOAM533jOk7kAz5URq5O3gr+nIbTe9xkI8ZWADWy/FG0zsk9C3NKAUxz iBCSTaWa5ohgOuMUlGcV4Co3HQV8JVfc7YWAcAXYyTLS
X-Google-Smtp-Source: ABdhPJx2mg9jm3ztPqMQerEHsn/SBDTRBFavFGBj478t7FTAuGDxONbOhr3307w+2/Cpax8/Z8BEBJgPpBRZ0VgU/hU=
X-Received: by 2002:a5d:8c8a:: with SMTP id g10mr8645030ion.208.1591368060084; Fri, 05 Jun 2020 07:41:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Patrick Meenan <>
Date: Fri, 5 Jun 2020 10:40:49 -0400
Message-ID: <>
To: Lucas Pardue <>
Cc: Yoav Weiss <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Tarun Bansal <>, HTTP Working Group <>, Kazuho Oku <>
Content-Type: multipart/alternative; boundary="000000000000eda5cf05a7573f9e"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d29;;
X-W3C-Hub-Spam-Status: No, score=-4.1
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_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_WL=-1
X-W3C-Scan-Sig: 1jhDWx-00087O-3V afa079ddf36ace93a0dadbc054c4ff50
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37724
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

If you're looking for a distilled test case, my HTTP/2 prioritization test
page <>
used for the 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.

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.

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

On Fri, Jun 5, 2020 at 10:15 AM Lucas Pardue <>

> Hey Yoav,
> On Fri, Jun 5, 2020 at 9:14 AM Yoav Weiss <> wrote:
>> Chromium is re-prioritizing image requests. Images are sent with low
>> priority and in-viewport images are later re-prioritized (once
>> layout happens and the browser knows they are actually in the viewport).
>> IIRC +Bence Béky <> implemented that re-prioritization
>> for H2, and may have data regarding its impact from the launch. Also CCing +Tarun
>> Bansal <>om>, as he may be aware of data to its efficacy.
>> Note that any such data regarding H2 would be biased by current H2
>> implementations and their challenges
>> <>
>> with buffer bloat. So I'd tend to trust test cases/examples from known
>> good-actors more than internet-wide data that's more likely to be watered
>> down with other issues.
>> What's the timeline for us to provide supporting data and/or tests cases
>> in order to keep re-prioritization in?
> Thanks for bringing up the challenges with H2, presenting data with this
> in mind seems important. Prioritization considerations wrt server-side TCP
> buffering [1] apply not only to reprioritization but preemption (the case I
> described as a bunch of requests where later requests are more urgent than
> earlier ones).
> Picking specifically on browsers, they have many options at their disposal
> to improve page load metrics. I think it would be useful to understand how
> big a role reprioritization plays in that. Maybe the WG would benefit from
> a distilled test case that can used to exercise reprioritization. For
> instance, is there a way to script and/or create a reproducible test for
> viewport changes?
> In terms of timeline, that's a bit tricky to answer and I assume the WG
> and chairs might have some opinions. To put the question back to you, is
> this data you have close to hand or are we talking weeks or months of
> experimental data gathering subject to engineering work or product release
> cycles?
> I'll close with a curveball idea: IIUC the viewport case, the dilemma is
> that when a browser makes the first set of requests, it is very unlikely to
> have the information required to know what is in-viewport vs.
> out-of-viewport. So for some types of resource you *always* want to
> promote/demote the resource's importance when discovering this, but for
> other types of resource you *never* need to. Could you make this a more
> explicit signal? I.e. rather than creating a general-purpose
> reprioritization mechanism that is applicable in a fraction of cases, one
> could create a "viewport/layout change" signal that tackles this specific
> case? For instance a frame called VIEWPORT that contains a boolean flag and
> a set of stream IDs that identify the affected requests.  Such a thing
> would suit being defined in an independent I-D.
> Cheers,
> Lucas