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

Patrick Meenan <> Fri, 12 July 2019 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CFAF1200D7 for <>; Fri, 12 Jul 2019 12:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 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, 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 iKPHRAAhEqaI for <>; Fri, 12 Jul 2019 12:38:40 -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 09B0C1200B7 for <>; Fri, 12 Jul 2019 12:38:40 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hm1LT-0004A5-MS for; Fri, 12 Jul 2019 19:36:39 +0000
Resent-Date: Fri, 12 Jul 2019 19:36:39 +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 1hm1LR-00049K-LG for; Fri, 12 Jul 2019 19:36:37 +0000
Received: from ([2607:f8b0:4864:20::d30]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hm1LP-0003Sk-SA for; Fri, 12 Jul 2019 19:36:37 +0000
Received: by with SMTP id j5so18640026ioj.8 for <>; Fri, 12 Jul 2019 12:36:15 -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=txHpeNLbUaHoupu8suAMn0iKKV41I4e8W8N4o0EgJok=; b=AHZNB+XVHiruSbLscuhK6vtHwGrje+olcPvdbEksvdzsoKwEXzlmfsCyj/1Iqxgacq 3JoHd80AZP1m8X0vfUj8bzyRvBe3A2XVgh5JwT4hFUwixK4vjnALz6HqAWywFUqbwqIH gxPHjs/CI5vOiGhatBiLzDlZiP2MnjgaeOnBe5Py8i8RbW0qahWvDRypjwfpP3B5B1ZZ 3K8U6HXNKR4kHC5m3au8PcHpO7GQXtgRFmqlwYRhTB/GoM5ImhpVxRVKwM4vUJn7rW/Y PpKVoSlVWgBGeC6ppCQq3WKFuBG2dZ2yMJX2Nkab26s/SEselJVK7BVssfdeHWvbBzm1 tBEw==
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=txHpeNLbUaHoupu8suAMn0iKKV41I4e8W8N4o0EgJok=; b=eNkc47Fex/ELkwh37MOPS+N/okgONb+OJS85uhoW+OghA1gm7AtJj/ZppsBu0lKXPN YtqbC7gdSwYstB/iH7TtM4Ui1RskEGAbJ0DQVPenqBd0fIjlOCkcf+n39WXLGKEluHLW 7tL3P0knP14GK9rSbtej1WJbViA5NopWvIf4UScvdlmGxGTFAfnhy/bNp/V3B82B4Bj9 MxvRaPe0CV2R6hyLV3nPPmpBNQiP0iHVlbMmXEQaCYtpf6YGUKnp8JVDc0SAFp/2vNre TYqCckRJ+VogUlV9Znvn1dqRkr9jkKcscvMktY0gfjc6kdw7InkxxQ83h2j5A+/6+7ML xmaw==
X-Gm-Message-State: APjAAAUNMyVZI5scEUjTpC9mYCkhfDnf7dUGKhc2SjuguaHVnhB6xETR oEZIm3NBbaZjVqmGynZw+qRZVyI0+WaJUc0oibA=
X-Google-Smtp-Source: APXvYqx+sv/cQoNzFPxbsEcWBfx5ji6yo3CNu2TWbf48MWNRxIvYqmtWBKEJT1LW4sGq4chg2qeDDd/gCwj+jY+ET/Q=
X-Received: by 2002:a02:a595:: with SMTP id b21mr13904706jam.28.1562960174240; Fri, 12 Jul 2019 12:36:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Patrick Meenan <>
Date: Fri, 12 Jul 2019 15:36:03 -0400
Message-ID: <>
To: Tom Bergan <>
Cc: Kazuho Oku <>, Robin MARX <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000fbd660058d81059f"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d30;;
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=1.333, 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: 1hm1LP-0003Sk-SA e156f6c3b2ec9b4a72e66d5eb35b3965
Subject: Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/36799
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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).

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

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.

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.