Re: Extensible Priorities and Reprioritization

Kazuho Oku <> Wed, 17 June 2020 07:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 489A23A00AE for <>; Wed, 17 Jun 2020 00:59:18 -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 rR9lJ52WaBXV for <>; Wed, 17 Jun 2020 00:59:16 -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 606593A0063 for <>; Wed, 17 Jun 2020 00:59:15 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jlSva-0003DQ-7v for; Wed, 17 Jun 2020 07:56:10 +0000
Resent-Date: Wed, 17 Jun 2020 07:56:10 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jlSvW-0003CZ-IR for; Wed, 17 Jun 2020 07:56:06 +0000
Received: from ([2a00:1450:4864:20::530]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jlSvR-0008Vf-1p for; Wed, 17 Jun 2020 07:56:06 +0000
Received: by with SMTP id p18so1174860eds.7 for <>; Wed, 17 Jun 2020 00:56:00 -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=zl2dIr//5NzLwlDrDzkpb8gpIarKPHgAHOAUfPMjuCc=; b=vPD1xbdePN/3msOOSyoi3NuaZB5FqyXSe15nnctATItF7Rd3xqIV/W5PSHm30AAnFR 2QD0rfIBmZxalolRZ0+WnfzpPMu7AFJJB80VpEeQw7SPVXA1p2yIZ5Wc7XdV+bgCsn/i WUqeNHTce0yp4/7Bb17WTivsE5CsbmQ4QBv4DFcAqPz/uqnHpelOU+sQxKBww1yVpHAl gOlvEoxT1fnpXl8B4JwrowaAHgYQWEl+z8QG4jj31p8jUiRtm/tIyadQaXKe5NvgmxlE +x87AxV5S7jb6L3/mM6I16tvrnZxUp+r5yA9uPPtHipyYLTPg7d3R0eKMKcX+AbmyE0W 8ZcA==
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=zl2dIr//5NzLwlDrDzkpb8gpIarKPHgAHOAUfPMjuCc=; b=AVQFYTwW287SWMVDAgLnkJkTl/ZcOYG3oUeCdeXX7xz2FMkuYORp8wwO0gczQ3UId6 VMtYzcJmtvcdLCSNfXpOYRlbQsIbje6drES1NC4IXDeUhGV0l9edbhSLtoemhI+Qemtr EtoXCm0ldYnKamH3Q5PfoIgiccmRynnD2Wc7QymoneipL9gc7uVLfdSbaTVU3NiozzO6 9r0+zTjU+TIdv8Mh2eRDcvpeaezABJxcLqmorkz9MRXfekQqofrTz9Xat/MhLo/44u/2 dKb7V6xvcJH1MPJOWLGSThEtQI6I5/jSDl/p7JTUKvat4idRYibMHe/BgpJuybg3kDMS r2wA==
X-Gm-Message-State: AOAM531dWs/pbdTjamxdD7FCM/jPcxJ4bhigpPgzq3s6MVJ6Rnk/sF7S CA8zZXbodzFXfkudoGBo4nv9zOYYKqb7qjLcRUZ/xg==
X-Google-Smtp-Source: ABdhPJw1cFKwtG0DKxFg0CN/X8667Vf59PVT8oYBAqQjfd2y9GTiU0EVc1KKOwpNmSWKJZKogjMtHirrcHmjqDCNqh0=
X-Received: by 2002:a50:9b13:: with SMTP id o19mr6008468edi.143.1592380549727; Wed, 17 Jun 2020 00:55:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Wed, 17 Jun 2020 16:55:38 +0900
Message-ID: <>
To: Kinuko Yasuda <>
Cc: Lucas Pardue <>, Patrick Meenan <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Eric Kinnear <>, Yoav Weiss <>, Patrick Meenan <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000038acb05a842fdd8"
Received-SPF: pass client-ip=2a00:1450:4864:20::530;;
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: 1jlSvR-0008Vf-1p d6510b3950aeac0f9eb819997648476e
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37774
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2020年6月11日(木) 6:46 Kinuko Yasuda <>rg>:

> (Sorry, sent it too soon...)
> On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <> wrote:
>> Hi all,
>> Reg: reprioritization benefit I can share some recent data for Chrome.
>> For the two cases that are currently discussed I'm actually not fully sure
>> about its benefit.
>> For the renderer-triggered image reprioritization cases: this is a bit
>> interesting one, we recently found two things:
>> - Delaying to start low-prio requests could often work better (partly
>> because of server-side handling) than re-prioritizing while inflight
>> - In-lab measurements (tested with top 10k real sites, both on Mobile and
>> Desktop) showed that removing in-flight re-prioritization doesn't impact
>> page load performance a lot
> Let me stress though that testing this with servers that can properly
> handle reprioritization could change the landscape, and again this isn't
> really capturing how it affects long-lived request cases, or cases where
> tabs go foreground & background while loading, so for now I'm not very
> motivated to remove the reprioritization feature either.

Hi Kinuko,

Thank you for sharing your data. I feel a bit sad that reprioritization
isn't showing much benefit at the moment. I tend to agree that we are
likely to see different results between server implementations and HTTP
versions being used. The effectiveness of reprioritization depends on the
depth of the send buffer (after prioritization decision is made), at least
to certain extent.

>> I suspect this is maybe because server-side handling is not always
>> perfect and most of requests on the web are short-lived, and this may not
>> be true for the cases where long-running requests matter.  I don't have
>> data for whether may impact background / foreground cases (e.g. Chrome
>> tries to lower priorities when tabs become background)
>> For download cases, Chrome always starts a new download with a low
>> priority (even if it has started as a navigation), so reprioritization
>> doesn't happen.
>> Kinuko
>> On Wed, Jun 10, 2020 at 1:21 AM Lucas Pardue <>
>> wrote:
>>> On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <>
>>> wrote:
>>>> 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.
>>> Thanks Eric for presenting this case, and Patrick for breaking it down.
>>> That does seem like a pretty bad outcome.
>>> Is this a good candidate for a test case? IIUC correctly the problem
>>> might occur today with HTTP/2 depending on how exclusive priorities are
>>> used. I'm curious if browsers can share any more information about what
>>> they do already. How does Firefox manage such a resource with it's priority
>>> groups?
>>> Cheers
>>> Lucas

Kazuho Oku