Re: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)

Kazuho Oku <> Wed, 08 May 2019 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90C5312016B for <>; Wed, 8 May 2019 16:36:32 -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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 6ihytzMmNpwI for <>; Wed, 8 May 2019 16:36:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57F4E1201CA for <>; Wed, 8 May 2019 16:36:30 -0700 (PDT)
Date: Wed, 08 May 2019 16:36:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557358589; bh=rC73tujPSz4yFXsZIAhJaV1KQyu2QbV6Q8kjv/g0cJI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eLKqbhPftPUQnUCnidCH49uESnZ8nOMNO7jLZp4YXspaoOWz2lG1obcbGOl+m6hds 3T//qe+Slzojeo//7EjpSZsMVXbr24Nm5sfmpCq/f0EQmWPw45lAngyJ3go8WHW+/2 k0Z5FIPGd5FP99nSZcGxzyFl8tI5II1R2ChpQu7I=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2502/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd367fd236c2_59fb3fcd168cd96c1002c5"; 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: Wed, 08 May 2019 23:36:33 -0000

Thank you for the clarifications.

> when something has implicitly_initialized set, what priority is given to it, or more relevantly, to its children? I'm arguing that solving these misprioritizations is more complex than suggested.

In my implementation, implicitly-initialized nodes are associated to the root with weight set to 16. I agree that we have the chance of misprioritization here, and that we do no specify how servers should handle that. I also think that what my implementation does now is not optimal - if we are to learn from the lesson of HTTP/2 that some servers respect only the weights but not the structure of the tree, the server should consider children of implicitly-initialized nodes as direct descendants of the root with their respective weights, until the PRIORITY frame for the implicitly-initialized node is received.

That said, I am not too worried about the status quo, due to the following reasons:
* We are encouraging (or we should encourage) web browsers requesting HTML and assets to use Firefox-style dependency tree. That means that chance of misprioritization only exists during the exchange of very first flights when the PRIORITY frames for the placeholders are sent.
* For video streaming, daisy-chaining of streams is preferable. But because we can expect several round-trips to be spent between each request, misprioritization would not be an issue in practice.

> I continue to believe the latter is probably out of both scope and time for this working group, unless HTTPbis directs us otherwise.

+1. I also agree that it would be beneficial to call out the strategy (or strategies) that the servers might employ, and if necessary the side-effects of those strategies that the clients should take into consideration.

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