Re: [quicwg/base-drafts] allow PRIORITY frames referring to placeholders exceeding `SETTING_NUM_PLACEHOLDERS` (#2761)

Kazuho Oku <> Fri, 14 June 2019 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C586120122 for <>; Thu, 13 Jun 2019 17:35:13 -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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 N8f86SGJzQ-H for <>; Thu, 13 Jun 2019 17:35:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6274A1200EF for <>; Thu, 13 Jun 2019 17:35:11 -0700 (PDT)
Date: Thu, 13 Jun 2019 17:35:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560472510; bh=A5khxiAFHXqcg0b7nhFPRMmu4JUqJlozOOmN+zRh7z4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1tbCQutF1qbngxmCjjEBYfvKys3RZn2VmPy90eCcvQFwoaXrj8GIgRYN43hZBZXEE sVuIYMwj5vrRnUOeOvZUL6tuEjhaGo3Z1QgcxlPqbHtOSeJp6pqkaicIj0FSd3cQzW bw08V+8Ln/xtD6etJv8kt64scymP1aWpAs7OzDSw=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2761/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] allow PRIORITY frames referring to placeholders exceeding `SETTING_NUM_PLACEHOLDERS` (#2761)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d02ebbe3c194_58943f865e6cd96820485b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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, 14 Jun 2019 00:35:14 -0000

> From a functionality perspective, I agree this brings H3 inline with H2, but it uses a new mechanism to achieve functional parity. As we've discussed, a new mechanism seems necessary in H3, but it is new nonetheless.

Yeah. Granted that placeholders are new in HTTP/3 and therefore they _can_ be enforced as optional, I do not see why they need to be.

I think our experience in HTTP/2 tells us that clients can specify different weights for requests so that the bandwidths would be distributed based on the weights when the server does not support placeholders at all. I'd assume that most if not all clients would use that same tree if we enforce them to not use placeholders when SETTINGS_NUM_PLACEHOLDERS is set to zero.

To rephrase, I do not think there would be a benefit in terms of performance by having this enforcement, for the majority of our use case.

Compared to that, the complexity being introduced by the enforcement is a burden. Not only because it requires clients to build different priority tree based on the server's settings, but because the client needs to wait for the server's SETTINGS to arrive before it can decide the type of the priority tree to use. For the server, the complexity is the same regardless of the approach; it's either throwing away PRIORITY frames that refer to out-of-bound placeholders or sending connection errors.

Therefore, while placeholders can be considered optional, I do not think it justifies the servers enforcing the limit.

PS. Or is your problem that SETTING_NUM_PLACEHOLDERS to zero is not RECOMMENDED? If so, I think we could change to the recommendation from "at least 32" to "zero or at least 32". As stated above, setting I do not think setting it to zero would be an issue. It set to some wired small value (like 3, which is below the number of placeholders Firefox uses) is the case where we'd see performance issues.

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