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

Lucas Pardue <> Tue, 23 July 2019 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AA3312087F for <>; Tue, 23 Jul 2019 11:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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] 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 Xmp8u4EyOPWb for <>; Tue, 23 Jul 2019 11:49:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77329120845 for <>; Tue, 23 Jul 2019 11:49:31 -0700 (PDT)
Date: Tue, 23 Jul 2019 11:49:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1563907770; bh=GxMKKRUBTs8dWpCrO0ny3TI76HYr+BhAjrUVQ6WitJ0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Or+cQkEzpie1ps0oAcQu9jkNvJ6pIdUd4s7D6fJGaHsrRpwo162GNOIzg8scz8353 LXQKla6hPL+9KrL4pAYsBWq/E2VjuCSoYebJmswR48g7Tmw8iryxFNcp1XGuLHxNgu PJeKulm1KPYLK8XWp45Fk2+76ae/wgP+WNmCvYk0=
From: Lucas Pardue <>
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_5d3756ba654b2_17a3fb34d6cd9601878cb"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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: Tue, 23 Jul 2019 18:49:35 -0000

> I am mainly worried about the impact on more advanced recent and proposed features, such as preload/prefetch, async/defer and priority hints. These features were explicitly added to improve (load) performance and they are difficult to adhere to without client-side scheduling. I predict that removing prioritization from H3 without a fallback will lead to performance-minded people having to provide 2 different versions of their sites, 1 for H2 and 1 for H3. For example, the H2 version can have async/defer/preloads mentioned in the head of the HTML, the H3 version without priorities probably shouldn't.

I agree with concern but not the predicted outcome. Given the number of problem H2 prioritization implementations, and the relative slugisshness in them getting fixed, we have not seen a proliferation of workaround versions of websites that solve these problems.

Order of request is a signal and in an ideal world this helps build a suitable response output queue from a server. But to backtrack a little, it is *hard* to instruct the UA , via HTML, to do this correctly.  Element decorations like preload/prefetch act as convenient runaround method, which helps to avoid requiring restructuring of HTML, by giving a supplementary signal to the server. I agree that such signals are desirable for actual applications and what I'd like to achiieve is a common form of this signal[1]. However, I don't have knowledge of the proportion of sites that are actively impacted by poor structuring.  We can't fix all problems for all people, the failure of H2's flexible toolkit demonstrates that. Therefore, as a group it might help to come to an agreement on what parity and equivalent performance actually looks like.

[1] footnote: on the server-side we base some prioritisation decision on our understanding of how the in-flight prioritisation tree is representing the UAs intent. This is a fragile approach for many reasons. Further, we don't yet know how H3 trees would look exactly, and so there is opportunity for error that affect the performance. Hoping that we'll fluke things and get stuff "just right" is an unfortunate position to be in. So I support simple or minimal signals - including some above the inherent request ordering I mentioned in my first comment.

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