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

Robin Marx <notifications@github.com> Tue, 12 March 2019 12:57 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991D2130F56 for <quic-issues@ietfa.amsl.com>; Tue, 12 Mar 2019 05:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuSSqq7DzDul for <quic-issues@ietfa.amsl.com>; Tue, 12 Mar 2019 05:57:56 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D75C130F35 for <quic-issues@ietf.org>; Tue, 12 Mar 2019 05:57:56 -0700 (PDT)
Date: Tue, 12 Mar 2019 05:57:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1552395475; bh=9S9MiKnLrdQD78uXm2G6EZQNlgRUsyBsX6JFF/brVQA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pcHWcmqh6hO92Q/VVzyE14nTWK+p7BBg5BUVmPtR9eetynTrOJjQGZ06wYVCyrPtC DH24Q4B+0IrZ5V88cgvvr8sjISg3ggO9KG/mg0R0p/pmizHhZT4tagOIOSFyLOOOar wKmpWlafVZaeRsLegfRJkWltG5i+1teUhlObDGpE=
From: Robin Marx <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdab5a98fd256086d6327fa6f19122562461b0d8f92cf00000001189f6ed392a169ce18f0629c@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/471989303@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2502@github.com>
References: <quicwg/base-drafts/issues/2502@github.com>
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_5c87acd33e79b_7adb3fb6d9ad45c4516748"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Mn5mcvrSM15Aj9I8MS37Zmvn_7Q>
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: Tue, 12 Mar 2019 12:57:59 -0000

Thank you all for the comments.

While I agree with Lucas' point that not all streams in the priority tree have to exist yet (and that this is a nicer solution than buffering the priority frame), the fact that this can happen and that this should be treated as "unable to make progress" imo should be mentioned explicitly in the text then. 

The problem then indeed becomes that you get the situation described by Mike: there is no stream 3 yet, we don't know where it is in the tree, temporary 3 gets added as child of root node, stream 2 is now in effect a sibling of 1 instead of a child (since stream 3 is "unable to make progress"). This could be "briefly" but if the control stream is experiencing loss, it might last for 1RTT+, which might lead to some difficult to debug unwanted bandwidth allocations. 

The solution to that could indeed be to replicate stream 3's PRIORITY frame on the control stream as well, but that also feels a bit dirty... especially since a) this scheme is Chrome's default behavior for H2 and b) some of our tests indicate that this is a better default scheme than the current full round-robin one<sup>1</sup>. In this case, buffering the priority frame feels better to me. If we decide not to got for that route, I feel this use case (aka: "how to fake exclusive dependencies in H3") should be mentioned in the text. 

Summary of proposal: Either change to buffering behaviour or add additional text describing/clarifying A) non-opened streams can exist in the tree and B) how to fake exclusive dependencies. 

[1]: https://speeder.edm.uhasselt.be/www18/files/h2priorities_mwijnants_www2018.pdf


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2502#issuecomment-471989303