Re: [quicwg/base-drafts] HTTP/3 priorities are too complex for a majority of implementations (#2739)

Lucas Pardue <> Wed, 22 May 2019 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3853A120128 for <>; Wed, 22 May 2019 04:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.606
X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 S9LdfHNQi3Bi for <>; Wed, 22 May 2019 04:17:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CA81120077 for <>; Wed, 22 May 2019 04:17:23 -0700 (PDT)
Date: Wed, 22 May 2019 04:17:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558523843; bh=yYm2M44iUzV/vAKCaeY3TKCnspHYIIhjwQoWWohKuNA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=unuhZz8tgOkQdED3Wy4+/lAD2Ycs1mj67VbxfBTkadtQRVYmzB6SzBEzb+PVg9ElH vCjfRKCNh940YsSyhQ+cKi1dKNnILFkAfiZwkL1i92cghhKqClMERH0pd+oi5G8i32 8wgO7oo1lmXQ3JdVSUM48bTafdqad3BoXLPN5He8=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2739/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] HTTP/3 priorities are too complex for a majority of implementations (#2739)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce52fc2badf7_76b23fcaef6cd9607100a"; 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: Wed, 22 May 2019 11:17:25 -0000

Thanks for the clarification. I'm not an expert is the area you describe, so I'll let others step in if they want.

The approach sounds fragile because several factors may work against it. 

Assume a model where a HTTP/2 or HTTP/3 server is best placed to make use of its available bandwidth based on its view of the client wants and the availability of response data. If defering load means that a client holds back requests, then the server knowledge is limited. In this case, if the server experiences delays in accessing image data, it can't serve the lower priority items in the available time window.

Another problem with the approach is connection coalescing. A website may not be aware that the browser is reusing a connection for different domains.

I think prioritisation is important. However, I think the user agent is able to articulate its requirements without a depedency tree. A simpler model of prioritisation may improve the likelihood that the server bothers to use it in decision making. 

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