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

Mike Bishop <notifications@github.com> Wed, 08 May 2019 16:00 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 908EE120155 for <quic-issues@ietfa.amsl.com>; Wed, 8 May 2019 09:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.392
X-Spam-Level:
X-Spam-Status: No, score=-6.392 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_24=1.618, 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: 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 nKVmZwCsmMss for <quic-issues@ietfa.amsl.com>; Wed, 8 May 2019 09:00:10 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2A212012D for <quic-issues@ietf.org>; Wed, 8 May 2019 09:00:10 -0700 (PDT)
Date: Wed, 08 May 2019 09:00:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557331209; bh=h+YNwbDpIq678gpJ9+Gt0HQ7YezRaS5Ti3fhbHap0d0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZI2AyuG75xmxn5z86gwuG9qw7JpL8e768UF1ywmXC585A0as7mnkmohqemrsVCiS6 qd196BM4Wl+XF7+Oso/Qkw4iWfbVCL7AxMh68vzaspOoo7xY9uwQ0QN0REutBmI+TF UQFcBNgkNGlVi+IQU1TsI8Es9Z5e+eSJSzmIsGx8=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZHDDC73LJKCJZ54OF24AXYTEVBNHHBR4DCTQ@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/490545898@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_5cd2fd09767d8_72be3fce572cd96c125685"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/uh0tqE4UOCBo4Jp0L1dCK3jMxFQ>
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: Wed, 08 May 2019 16:00:13 -0000

To be clear, I'm not advocating for a more complicated scheme than what we have now -- I think that your implementation sounds very reasonable.  The issue as filed, however, describes that implementing that way creates (hopefully brief) misprioritizations before consistency is achieved:  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.

I think our choices are:

- Live with the misprioritizations -- what we have is fine
- Block processing of priority instructions entirely when an uncreated stream is encountered as a dependency -- better to delay updates than get things wrong
- Totally replace the priority scheme before RFC

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

The discussion of moving to more unidirectional stream types is largely orthogonal to this choice; I'm going to suggest we take it to a separate issue and decide that independently.

-- 
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-490545898