Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt

Tom Bergan <> Fri, 12 July 2019 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6ECA1202A6 for <>; Fri, 12 Jul 2019 13:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3fMJT3yKp_uj for <>; Fri, 12 Jul 2019 13:30:08 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9BAD1200FF for <>; Fri, 12 Jul 2019 13:30:07 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hm28W-0005HA-3H for; Fri, 12 Jul 2019 20:27:20 +0000
Resent-Date: Fri, 12 Jul 2019 20:27:20 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hm28T-0005GO-S1 for; Fri, 12 Jul 2019 20:27:17 +0000
Received: from ([2607:f8b0:4864:20::b2f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hm28S-00051k-Ao for; Fri, 12 Jul 2019 20:27:17 +0000
Received: by with SMTP id 187so4078920ybw.4 for <>; Fri, 12 Jul 2019 13:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iPetZ3rO9Fy34tEAFewtfQ50E6/wNFGfNfhM+fZipyA=; b=aiydvcnEzXO0eDZNmhYrMqhGLCaoYQ0fL595a/HPnn2twowz8ZB55s1LB3Y2CSV42d NNITQjqjokhePmoSt84QJgnPFyxaQKLl/c59eQ/yllSw5nFrhitUkAvJbW0Fz2JCcIhh 3FYwRjsOGRccVvwovENMP2A8fRztZiFHYraCk=
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=iPetZ3rO9Fy34tEAFewtfQ50E6/wNFGfNfhM+fZipyA=; b=GohZidlfzevn/IsIlL45bUy8aQYw8ZbwObTcFOO7vubTPnNm4OKM4ZH78q8Q17m6E7 TNbCJ1ej/0ze62MJpcnhs3bbwlDlBEE3/MhUwYTT9JDWaRv1X053lvhaHsNEGYA3Xgi5 dXdGNb6580JFQ7n/suiu3CewAijS1Z0rJZJT/RAvA0lNJuKf+JLToaUBNav05p2BhhpV IErmNEqlNiA3d8u6G0u6kQy3UV8/OTGZ2D3SNpK9ALq63XhP14ZqgIfK1F25nZ4EMDaK 8vkmMKnpj2UGB+ftEuPhBKUnK55z7JClKZyw9pzJ9quDoIS/Tbhd6c++sqx1GV/KNuEb 3/XQ==
X-Gm-Message-State: APjAAAWoph3STHkt6swDYk/wfz7VHM3F7jR6QxoPKAc/dafxr9xrBpB/ BqhYPvK59aeKkEwOrxZzUdi2TkBBJDE=
X-Google-Smtp-Source: APXvYqxobwj1J0yMI4dmP82fybvvXJymNLXnRRL/2ARu5pdViYOH1C6BwlGtrQBbTF3vWRRAqboRaw==
X-Received: by 2002:a25:5d3:: with SMTP id 202mr7129417ybf.297.1562963214822; Fri, 12 Jul 2019 13:26:54 -0700 (PDT)
Received: from ( []) by with ESMTPSA id q132sm2345764ywb.26.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 13:26:54 -0700 (PDT)
Received: by with SMTP id l124so5465133ywd.0 for <>; Fri, 12 Jul 2019 13:26:53 -0700 (PDT)
X-Received: by 2002:a81:ad12:: with SMTP id l18mr6211952ywh.377.1562963213481; Fri, 12 Jul 2019 13:26:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Bergan <>
Date: Fri, 12 Jul 2019 13:26:41 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Patrick Meenan <>
Cc: Kazuho Oku <>, Robin MARX <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000236eb5058d81bb61"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b2f;;
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-0.228, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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: 1hm28S-00051k-Ao 2041b4bb5db31c3ca211ced4400e55c9
Subject: Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/36800
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Jul 12, 2019 at 12:36 PM Patrick Meenan <> wrote:

> I'm somewhat opposed to defaulting to concurrency=1 and using a lot of
> bits for a priority to handle sequencing because it introduces the problem
> of needing to know what other requests are in-flight and their priorities
> to set the appropriate sequence (the state that I was largely trying to get
> rid of when we implemented Cloudflare's prioritization).

There's state on the client, but it's a simple table. There's no state on
the server, unless you're expecting the server to reverse-translate the
priorities, which seems unnecessary (see below). That said, I don't feel
too strongly about this.

> By using absolute priorities tied to the request/response itself the
> browser rendering engine, the CDN back-ends and even the origin server
> application code, all of which are well outside of the connection itself,
> can influence and adjust the priorities of resources at an absolute level
> and still trust that they will be delivered in a reasonable order when it
> gets to the code that is actually managing the connection. Otherwise you're
> going to end up having an absolute scheme defined on either end (like the 5
> levels internal in Chrome and Cloudflare's header-based scheme) and doing a
> translation at the wire layer anyway.  If we encode an absolute scheme
> directly then the clients on either end can eventually migrate to using it
> directly.

I feel more strongly about this: If the server wants to suggest a
prioritization for subresources, I don't follow why the best place to do
that is in the HTTP response for the subresource itself, rather than in the
preceding HTML response. For example, we might define link elements like:

Link: rel=priority href=foo.js priotity=whatever

The HTML's response header can include link elements like this one. The
"whatever" can be some globally-understood thing, where the browser can
translate "whatever" to underlying H2/H3 priorities however it wants.

> It's also not necessarily strictly point-to-point.  At my origin I may
> decide to implement a query-param-based scheme for prioritization for
> resources that are always the same (template code in the head of my pages
> for example) where the server is configured to always set the priority for
> those as "critical script", independent of what the browser requested. The
> CDN in the middle doesn't need to know the application-specific knowledge
> that I created between the front-end code and the origin, it just needs to
> cache the priority headers along with the resources and respect whatever
> the origin responded with.

It's very roundabout to inject a priority into HTML, route that through a
CDN, to an origin server (via a subresource query param), then communicate
that back to the CDN via a response header. Not to mention:

- What about <link rel=prefetch>? You can't use different query params,
because that would break the prefetch.
- What if your page is loaded in an iframe within some other page? Your
server-assigned priority might be correct in the iframe context, but not in
the whole-page context if the browser has lowered the iframe's priority.
- What if your page is loaded in a background tab? Maybe the browser wants
to lower the priority of background tabs. But it can't, if the server will
override that decision.

The Link proposal above appears to be simpler and more flexible. The
browser might want this information anyway, for other reasons, such as to
throttle cache lookups.

For the security contexts and other uses for knowing WHY a specific
> resource is important, I'd strongly encourage not trying to overload the H3
> priority scheme with that data and leave that to the fetch metadata spec
> that Mike West is working on.
> On Fri, Jul 12, 2019 at 3:16 PM Tom Bergan <> wrote:
>> I think I did a poor job explaining my argument.
>> Your current proposal has 4 urgency bits and one concurrency bit (aka
>> "progressive" or "incremental"). I am saying that we can default to
>> concurrency=1 given enough urgency bits. For example, given ~53 bits (using
>> an sh-integer), we can define the following translation:
>> func TranslatePriority(urgency4bits int, progressive bool) uint64 {
>>   if progressive {
>>     return urgency4bits << 49
>>   } else {
>>     seq := nextSeq[urgency4bits]  // where nextSeq[x] is initialized to
>> 2^49-1
>>     nextSeq[urgency4bits]--
>>     return (urgency4bits << 49) | seq
>>   }
>> }
>> This is almost equivalent to your proposal, except for caveats about how
>> (urgency=X, progressive=false) is ordered with respect to (urgency=X,
>> progressive=true). Those caveats seem unimportant in practice.