Re: [quicwg/base-drafts] Remove PRIORITY (#2924)

Robin Marx <> Thu, 25 July 2019 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF12A1205D4 for <>; Thu, 25 Jul 2019 02:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 PWrLEq0CF9P7 for <>; Thu, 25 Jul 2019 02:53:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42C9F1200F9 for <>; Thu, 25 Jul 2019 02:53:09 -0700 (PDT)
Date: Thu, 25 Jul 2019 02:53:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1564048388; bh=XHOWSzvK2R3yr4eosXwvbxaW/T5zyFvIYemd1i+7ViY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MMaQDnB+LMkA7uznyB5SUFv6thsIO/nVpK+FV2X4DD2MhzoOmKxR0bdW4If5QbjK8 x2eMmiIObB+r2AajIikRnnsOxSkRm+OQbzWGJhpzcmNBHRjnp4qh08nKm5Wl4cvCNO 1N1uoiVEMoWH3SqiS1Hgp22y+Uf2f7z3E3CwgYro=
From: Robin Marx <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2924/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Remove PRIORITY (#2924)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d397c04557d2_66ea3f80dc2cd96c937d2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: rmarx
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jul 2019 09:53:12 -0000

> This seems a little controversial. Patrick expressed a desire to limit the number of potential schemes. One of the source of the failings in h2 was the way that it enabled proliferation of schemes. 

I understand the argument, but I don't see how we could move prioritization to an extension (and mainly: allow more than one extension) and not add some kind of negotiation/setting to specify what is supported/will be used. I am a big proponent of adding this in if we decide not to fix priorities in H3 core **properly** (which is very much looking like it will be the case). Even if the SETTING ends up being moot down the line (e.g., all browsers decided to just support 1 approach), it will still be very useful for testing various extension proposals in the mean time (see it as a prioritization ALPN). I am interested in working on the design of such a setting. 

> Given the time pressure that you mention, I would be strongly inclined to support a very basic scheme.

This seems to be the most sensible way forward at this point. I would suggest to use the scheme proposed by Kazuho and Lucas ( It uses 8 different semantic prioritization levels ("urgency") and a progressive/non-progressive indicator. It could be seen as a simple variation on both Patrick Meenan's proposal and the original SPDY approach, while still allowing enough flexibility to represent some of the more subtle peculiarities of resource loading semantics. As I feel the best way to "finally fix" priorities down the line is to add a lot more semantic information with each request (see, I feel this simpler approach is a good foundation for that, that will also make "upgrading" easier down the line.

Concretely, I would suggest **adding the 8 urgencies and progressive boolean to the core H3 draft** (making a note that it's not perfect, but not awful either, and that they remain "hints") and to use (an) H3 frame(s) to transport them. Kazuho's and Lucas' proposal of using an HTTP-header to transmit the same information, can be done as an extension (hopefully to be implemented by most of us as well, especially the browsers). Patrick Meenan's setup can also be an extension, which people can use for experimentation. The "final fix" (whatever it may be) can start as a relatively simple extension, can be implemented by a subset of stacks to get some experience, and then grow organically. 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: