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

Kazuho Oku <notifications@github.com> Wed, 08 May 2019 03:10 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 0B2C4120073 for <quic-issues@ietfa.amsl.com>; Tue, 7 May 2019 20:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Level:
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: 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 wVoOlnkdX7wD for <quic-issues@ietfa.amsl.com>; Tue, 7 May 2019 20:10:17 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D468912002E for <quic-issues@ietf.org>; Tue, 7 May 2019 20:10:16 -0700 (PDT)
Date: Tue, 07 May 2019 20:10:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557285015; bh=q4ZLmNSIT4CI4TnP4sDxmQaX15bf+y9DePetVAv+Jr8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KKPw+KNPcviCABrGpFhwudUKW0jQRnLYnAHQ3Qe0vo0p6jFKAmkW+m8Iy6TkWmAz6 Vee0Gpr0boG0RYG0y0nrZcm8HD64UnRU0h9ygjbrz3z/T+pkblMhvp2Kg8HCxTQrQ3 S7G46Xb1cze+lg0q8AUAojnGFB6R0lk4C+I4bRaA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4UFVFDGREMKEJ7TIF2355RPEVBNHHBR4DCTQ@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/490330136@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_5cd24897a93d2_87d3fa909ccd96c68094"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ow0QRs-3Ordoxzj200Oee2MHE6c>
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 03:10:19 -0000

@MikeBishop 
> I don't think simple buffering is sufficient. You would have to not only buffer the frame that updates the priority of a not-yet-created stream, but also frames that create dependencies on that stream, and frames that create dependencies on streams that would be under that tree if you weren't already buffering the frames that create the tree. That can be done, but it's not straightforward.

I second @dtikhonov's view that the current mechanism is simple enough.

What you need to do (i.e. what I do) is create a priority node (with a given ID) when receiving a PRIORITY frame that first refers to that ID. When receiving a request stream is opened, the server looks if a priority node already exists. If it does, that is used.

The node also has a `implicitly_initialized` flag, that indicates if a PRIORITY frame received on a request stream should be respected. The flag is set when a priority is received for the first time for the given node, but not when a node is created due to being referred to by PRIORITY.element_dependency.

If we are to discuss alternative designs, I'd argue that providing the server the priority information at the moment it receives a request should be a requirement (at least for the Firefox-style dependency tree, which I think we agree as the optimal design). Otherwise, we'd be risking H3 performance becoming inferior to H2 due to increased chance of mis-prioritization.

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