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

Robin Marx <notifications@github.com> Thu, 07 March 2019 16:42 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 62C821277E0 for <quic-issues@ietfa.amsl.com>; Thu, 7 Mar 2019 08:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q63bkEfNwKrV for <quic-issues@ietfa.amsl.com>; Thu, 7 Mar 2019 08:42:35 -0800 (PST)
Received: from o11.sgmail.github.com (o11.sgmail.github.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2376F1277DB for <quic-issues@ietf.org>; Thu, 7 Mar 2019 08:42:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=lH9T/d+7rUdoIcp/E/q4IwNvOjo=; b=Eb8jcsutwXbXOCQM keIja+m5Yj1fOnmA/FvQclyRN9893rtDZKXPAkxQGzKVhEDpQziXhHz/oPvRO+hj ioaT52s8dUaNnqmOvFY8Y0cfINXONz8yPmKO82wl8G+UkksZdVCoWY7FzFVV1sT7 BeGHwZ4gmc0izBbk0Q/HHO4AbXQ=
Received: by filter1219p1las1.sendgrid.net with SMTP id filter1219p1las1-8714-5C8149F9-B 2019-03-07 16:42:33.293486403 +0000 UTC m=+55276.070073733
Received: from github-lowworker-e711880.cp1-iad.github.net (unknown []) by ismtpd0010p1iad1.sendgrid.net (SG) with ESMTP id x9pVVaKfQFGCfImkqlMYRA for <quic-issues@ietf.org>; Thu, 07 Mar 2019 16:42:33.188 +0000 (UTC)
Received: from github.com (localhost []) by github-lowworker-e711880.cp1-iad.github.net (Postfix) with ESMTP id 2CE17440851 for <quic-issues@ietf.org>; Thu, 7 Mar 2019 08:42:33 -0800 (PST)
Date: Thu, 07 Mar 2019 16:42:33 +0000 (UTC)
From: Robin Marx <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab91a279c5946924b8e6a98cad14b89c5549f4cd9092cf0000000118990bf992a169ce18f0629c@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2502@github.com>
Subject: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c8149f92a1e5_1ca63fd7784d45c45000e2"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2guwrAvPscgDo44cycJrq3PK7mvbeevEpqYj GNqaj4J53tRlqwPTaL1cd6+lJrF6ZVlHXk/VxnUlrWowChbZMTgSNm4vbb4LTSJTjUPeBj0sLn7Etl yI96uHS9TdF92uuhziz0S7OWpFu+FHoKN9nwMcUlcD1lkMJqtCZpU+nz1o3QtxTn6nEK5Xeb8oRUbT 4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/FiVvT7NoVUJCT3Tzr6toOaFTAzg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 16:42:37 -0000

There is a specific prioritization situation which to my interpretation isn't fully clear in the draft-18 text.

Context: trying to re-create the concept of exclusive prioritization (which was removed from h3 a while ago). 
Approach: simulate exclusivity by sending new PRIORITY frames on the control stream for all the streams we want to be dependent on a new request stream.

A                      B                         C
1                      1                         1   
|                     |  \                       |
2                     2   3                      3
Step A: stream 1 and 2 are opened in sequence with priority frame as first frame of their stream
Step B: stream 3 is opened with priority frame as first frame
Step C: we have sent a priority frame on the control stream for stream 2, updating its dependency to stream 3

(In http/2, step B and C would be the same due to exclusivity, in h3 we need step C to simulate this).

The question:

**What happens if the priority frame from step C arrives before stream 3 is opened? We then have a priority update for stream 2, making it dependent on stream 3, which does not exist yet (at least at the receiving endpoint).**

There are various points in the text that might lead to an interpretation of this, but none really reference this exact situation (afaict).


> A PRIORITY frame that references a non-existent Push ID, a
   Placeholder ID greater than the server's limit, or a Stream ID the
   client is not yet permitted to open MUST be treated as an

Here, stream 3 is certainly "permitted to open"

>  A reference to an element which
   is no longer in the tree is treated as a reference to the root of the

"no longer" != "not yet"
If this is the current intended behavior here though, I would suggest to change it to allow the use case above.

> Due to reordering between streams, an element can also be prioritized
   which is not yet in the tree.  Such elements are added to the tree
   with the requested priority.

This one reads a bit weird to me... I assume it is talking about the case where you don't send an initial priority frame on the request stream itself, but rather only on the control stream, and that can arrive before the request stream itself. In this case I assume the priority frame is buffered until the stream is opened. 

This *could* be read to also apply to my situation above, but if that's the case I would make it a bit more explicit. If that's not the case, I would change it to something like "Due to reordering between the control stream and request streams, ..."


If I'm not missing something and this case is indeed not yet handled in the text, we might add something like "If a priority frame references a request stream that is permitted to be opened but which has not yet been opened, the priority frame MUST be applied once the referenced request stream becomes opened."

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