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

Robin Marx <> Wed, 22 May 2019 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA9C212011C for <>; Wed, 22 May 2019 04:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Status: No, score=-3.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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 fFZWTbUmebkl for <>; Wed, 22 May 2019 04:28:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AAD312004D for <>; Wed, 22 May 2019 04:28:56 -0700 (PDT)
Date: Wed, 22 May 2019 04:28:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558524535; bh=UH5hZW/BYgJgJ60698+uF34A09IZBAP2dW8tO5xUDTQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bxVpwDZHirO3T/FvQ236fT7UA2Dh1feGqfdtUEKAB6q1cEi17YX6Bw4JfUrO1f15c XWy0sPVt8me8HvrUByFFl8J0fvWLDRC9NsEN5w03FGfKkxkFp1FBO6MltP39ki2XkX FwwWXU+FXgV8c0Xxbf3+1Zo7Ko8fNWA/ogOCUQ1w=
From: Robin Marx <>
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_5ce532775490a_2f393fc23a8cd96c2860c3"; 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: Wed, 22 May 2019 11:28:59 -0000

I feel we need a bit more nuance for this statement though:

> Measurement indicates that <<50% of servers implement H2 priorities (

To my understanding, the servers probably -do- implement HTTP/2 priorities, they just don't function correctly. If I interpret @pmeenan's blogposts and our conversations, this is not due to bugs in the HTTP/2 prioritization, but due to implementations not using things like TCP_NOTSENT_LOWAT, or having caches in front of their servers, or general other bufferbloat-alike problems that prevent good re-prioritization. This issue will not be solved by just moving to a simpler scheme. Because we're using UDP and iiuc kernel interfacing for UDP does not allow large kernel buffers/people are only passing what's ready to send as the congestion controller is also in their control etc. this hopefully will be less of an issue independent of the used scheme. 

With regards to browsers having bad setups, I feel that by now we do have a much better grasp of what things *should* look like for the browser side (see Patrick's proposal). It's mainly a matter of getting people to change the browser code. For the life of me, I still don't understand why Chrome hasn't touched that code for years (see also:

To re-iterate my point from yesterday: I like (semi-)#2700 because it allows new stacks to implement only the priority-based scheme without placeholders and inter-stream dependencies (send SETTINGS_NUM_PLACEHOLDER = 0). Existing stacks can be extended relatively easily to incorporate it (or fake it with internal placeholders, which is what we've been doing for tests and works well).  

So, my point: simply moving to a much simpler scheme will not automagically give better (re-)prioritization behaviour, nor is it needed to completely drop the tree-based stuff to allow easier up-front implementations. 


To jump into the other conversation going on above: this sounds like the Polaris paper (and related work), see This has been shown to work well, but it tricky to get right, and doesn't preclude the current setup from being useful in other situations.

Also, I feel this is a separate topic that might require a different issue to not take away from the core issue being discussed here. 

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