Re: Extensible Priorities and Reprioritization

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 05 June 2020 14:14 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 7CD653A00B3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Jun 2020 07:14:25 -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 b5emZVrrOMUF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Jun 2020 07:14:23 -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 A509B3A00B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 5 Jun 2020 07:14:23 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jhD4Z-0004hy-Fn for ietf-http-wg-dist@listhub.w3.org; Fri, 05 Jun 2020 14:11:51 +0000
Resent-Date: Fri, 05 Jun 2020 14:11:51 +0000
Resent-Message-Id: <E1jhD4Z-0004hy-Fn@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 1jhD4X-0004hD-Ct for ietf-http-wg@listhub.w3.org; Fri, 05 Jun 2020 14:11:49 +0000
Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) 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 1jhD4V-0000EH-E3 for ietf-http-wg@w3.org; Fri, 05 Jun 2020 14:11:49 +0000
Received: by mail-wr1-x42c.google.com with SMTP id h5so9922458wrc.7 for <ietf-http-wg@w3.org>; Fri, 05 Jun 2020 07:11:47 -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=aMtFL+fnh7NNVPik1ccmFJqwyZhwVpEDzebyUOXeuv8=; b=XS7i79y+LRIgyynikyaJEyA4T/3QTmI9nFD1dKAhOG9CCRakgCJw3M5XpsfkN9DMxS h1g0JJ9+7A6ln+NWQ4Qz7L7dulAN0puauZ8e9LfHpdbKLaAKis6dx8tpjKvXUw3EGGf+ 3DKhETAAix+fNuJYXZfg84T232Bd0PMmQCOt1kUSvF6DAw5c08G5Kb+1B8F8CKPjH97d oKynvxgJBwDOZskpEScY9EyXetVUYT+SrQqoNZBSuqt3AMAN+xcJGDsehd2DJNVWssgN t33Z03uGFj8FAjfgD0sUBfIUt1cktdO9Imu4BQBehGw2dyvkMv2Wv5XOWSrCwHD7MJcD ZyAw==
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=aMtFL+fnh7NNVPik1ccmFJqwyZhwVpEDzebyUOXeuv8=; b=UlBb3aG49xLiJClwOtcpjx0kJpCErmC3u0zfmQJuQ+PXlMcnc2oTp4N9BcD5JBsNTG ccdoS0Dk/JajByo9bKhlPC7roug+K0Mp7aX5pPwgfxm4ZoNeMjTelL6fTZ4DVPbhSHJh QoRejV/C0j3PyEXaEvJ1pPDNBP19Oa4QbkALVouisw8hwU53DUEDgdvO+GQk1I3R8Q8R JfZbzkZ6FUrv+AyGZI3bciOuWiYLxZoLgaTmAcNiV/fZOJov/dRpiJrtDF8k0dCTqgbo 2bLvLpDnBSpov8QtPALDGLU/NNSfPClUdZ3p5teGeHxH8jnVWn58usw5jcd9LPJbjwnK FcEA==
X-Gm-Message-State: AOAM5330Plnw4dnQLykjWiCbgcZqrUugsp81GNZuKouui5v/JYxx57OQ fEqrjCwZtCmwctL/rxrl/hdc5r+ivi4LVT4BPsY=
X-Google-Smtp-Source: ABdhPJxJUk6bmi74vh1LvzaMnubEfc17Vvpj5lmcv7LNwUM3yDnTEIUHOHadB0YOHTJQRH1W9xtetGxfozdjD+Igzg4=
X-Received: by 2002:adf:b60b:: with SMTP id f11mr9820256wre.7.1591366296184; Fri, 05 Jun 2020 07:11:36 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <CACj=BEiOA=7ixKsnK85VEmC+6Tjkwaeb7zB78sgZEmRjeYD0kQ@mail.gmail.com>
In-Reply-To: <CACj=BEiOA=7ixKsnK85VEmC+6Tjkwaeb7zB78sgZEmRjeYD0kQ@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 05 Jun 2020 15:11:24 +0100
Message-ID: <CALGR9obohr44X1tfgWAbQ=akAiYmMsW4Yd_8NtR7jeJZwYxD8A@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: 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="000000000000caae7505a756d6b9"
Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-wr1-x42c.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 1jhD4V-0000EH-E3 36cb143a541c03c4559490443b3fe24b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CALGR9obohr44X1tfgWAbQ=akAiYmMsW4Yd_8NtR7jeJZwYxD8A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37723
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 Yoav,

On Fri, Jun 5, 2020 at 9:14 AM Yoav Weiss <yoav@yoav.ws> 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 <bnc@chromium.org> implemented that re-prioritization
> for H2, and may have data regarding its impact from the launch. Also CCing +Tarun
> Bansal <tbansal@google.com>, 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
> <https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/>
> 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


>
>