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

Kazuho Oku <notifications@github.com> Fri, 10 May 2019 01:44 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 21D5F12004F for <quic-issues@ietfa.amsl.com>; Thu, 9 May 2019 18:44:24 -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 aQBZD5IqK160 for <quic-issues@ietfa.amsl.com>; Thu, 9 May 2019 18:44:22 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2AA120004 for <quic-issues@ietf.org>; Thu, 9 May 2019 18:44:22 -0700 (PDT)
Date: Thu, 09 May 2019 18:44:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557452661; bh=Ch4lyC2XDIw8RKlkszXHcrDKZn3/ZwW0Tv3LDKqNMsg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=P2UYgiqE8ZK4r2JDjI1GsiuDaJd7a+SuPGAgFJtxnEgDWHm7V0cjvvTVrQswrex5W H9GtskbxU+MNziUc8r0R3iW1ahGYOUZe+fAoCem7ZOvA+TeIVMAowmT3AjNNvl/Mps Midr0IKwCZOHCAb4Fr/PELQWaw1i6a/B/7FJq58g=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZYUAFDRDE6QPK777V24IE7LEVBNHHBR4DCTQ@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/491124286@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_5cd4d7755cba1_404c3f8cc82cd9601241d7"; 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/FfSP4wMfIgd6kSpa2q8JVbxdR9k>
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: Fri, 10 May 2019 01:44:24 -0000

> That wouldn't be a problem at all. You'd likely get more interruption than that in HTTP/2 if a TCP packet anywhere near a PRIORITY frame got dropped anyway.

Yeah. That's definitely a good and conservative way to think of the issue. And I presume that such perception would lead to what @rmarx has suggested in https://github.com/quicwg/base-drafts/issues/2502#issuecomment-490792254; i.e. assign the lowest possible precedence to requests that have yet-to-be-known priority.

I think I now agree with @rmarx that that could be the recommendation, if we are to recommend something in the specification.

That said, I think I would try to let the server "guess" the correct priority, because doing better than HTTP/2 when packet loss is involved _is_ the primary motivation of doing HTTP/3, and therefore my preference goes to clarifying in the specification that such fiddling is allowed, if we are to recommend something.

One way of making such a guess would be to check the content-type of the response. Another way would be to use the "weight" of the request stream (even though it is unknown how it is connected to the root of the prioritization tree).

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