Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)

Lucas Pardue <> Fri, 17 May 2019 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1990412038A for <>; Fri, 17 May 2019 08:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 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_32=0.001, 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 o9wVf5WbZE1h for <>; Fri, 17 May 2019 08:49:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5299F120384 for <>; Fri, 17 May 2019 08:49:27 -0700 (PDT)
Date: Fri, 17 May 2019 08:49:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558108165; bh=mTqjUpHfzzSO26MBt2igg0djrqIXQT56KWYux9BnhGE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sdvidDPP7Z0Rn+hGEkOzPLqJnPUJkF1ZZeBI1e5wC8yI++2m1bWr3mAjVtjmmvnEk 4JLL+UkR6yyRbi5yTdUS0FqlaydjGz/NrgdmKWpeasiZZZ/yW3yv+0HyPvjR4678NC icg5R1/ohxoW1Xh1AiG/YqAiv5DO8uNfUmx1CnvY=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2700/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cded805dcdc0_ae23fb4176cd968628291"; 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: Fri, 17 May 2019 15:49:29 -0000

> This is an important aspect of this discussion. Extant HTTP/2 stacks can use the current (ID-20) version of HTTP/3 prioritization with few changes. Radical departures from it will inevitably result in more work for them -- not just in programming effort, but also to research how to use the new prioritization scheme effectively.

Which stacks do you have in mind? 

A survey of user agents indicates that the priority trees were designed once and not iterated on. Developers or users have little control to modify behaviour here. 

On the server side, the priority tree is an input into the logic. If the servers' processing is tightly coupled to the input scheme, that would suggest difficulty in trying out alternatives, which is maybe an indicator to the feasible success of prioritisation extensions.

As Cloudflare recently blogged about, our extant HTTP/2 stack has many problems in trying to deliver on the intended design expections. However, a broad set of those problems had nothing to do with the priority tree itself.

Yes, we don't want to throw the baby out with the bathwater. However, we should also be aware that there's going to be a ton of work to determine how HTTP/3 performs in real-world usage scenarios. Predicting the effects of HTTP/3's design on that work is hard.

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