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

Robin Marx <> Thu, 16 May 2019 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC806120105 for <>; Thu, 16 May 2019 06:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 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, 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 hqypiJPFzJaL for <>; Thu, 16 May 2019 06:52:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E2091200F8 for <>; Thu, 16 May 2019 06:52:07 -0700 (PDT)
Date: Thu, 16 May 2019 06:52:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558014726; bh=zQMJEqT6JVmSxmSV1z1f9LtEBA8K8znVJ+MFseYIT9I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iMmRJhu7CDlN54TjgbiZoL2TEEq3PTDVsrtQSs2rBR809FDTKW8yE6owbnr4UDlqR HdMywktJ7/KJKMoHkgYmdjRTJUIf+ne9Obc+KRWsiwuK71o0gyuN6QC+EPFeRCxbGE fkqlqXLMPaoJ5O1PQz9lhiy12qgSGGsIYmXOxRHM=
From: Robin Marx <>
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_5cdd6b067e41d_bec3fae358cd96c314519e"; 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, 16 May 2019 13:52:10 -0000

Thank you for beating me to this Ian :) 

I am a bit unsure about this approach. While it seems to allow @pmeenan's setup, as I mentioned at the bottom of this comment, I'm not sure that is really necessary. 

With the existing setup (allowing dependencies on a request stream), we seem to only lose the ability to re-prioritize elements within the same "bucket". E.g., if you're sending a Font file, you cannot have a CSS file interrupt it, if they are both under the same Placeholder (HIGHEST in my example there). I am unsure if this is such a bad thing, since both the Font and CSS are similarly important and both need to be downloaded in full to be applied (iiuc). If you still wanted interruptability, you could add another placeholder "bucket" (e.g., FONTS) to go more fine-grained. 

Either way, the current proposed text in this PR is a bit ambiguous about what happens if you receive a new entry with a higher priority than the current highest-priority element: do you interrupt the current response for the new one? (e.g., you had a FONT of priority 50, it's about 50% done sending, now you get a sibling CSS of priority 60: will that interrupt the FONT? I would assume so). That goes against he "be delivered all at once or not at all" mantra. 

One of the benefits of Pat's scheme imo is that it is easier to implement and doesn't require keeping track of open/closed streams and separate placeholders etc. By integrating this into the tree-based setup here, we are losing that simplicity (also remarked by @MikeBishop earlier here). I also agree with Mike's remark that this type of thing might make more sense as a property of the Placeholder, rather than each individual stream/node.

I am probably missing something here, but it would be good to get some more clarification on what use case we are trying to support exactly (and imo we should wait for some input from @pmeenan (mainly on the importance of reprioritizing within a sequential list) before proceeding much further). 

As a side note: I assume this would be complementary to the Orphan Placeholder in #2690? Because #2502 discusses 2 (imo) separate concepts, and these 2 PRs treat them individually in my perspective. 

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