Re: [quicwg/base-drafts] Unidirectional stream (some or) all the control things in HTTP/3 (#2678)

Kazuho Oku <notifications@github.com> Thu, 09 May 2019 07:05 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 3EFAC12029C for <quic-issues@ietfa.amsl.com>; Thu, 9 May 2019 00:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vq9QoTfLnqNr for <quic-issues@ietfa.amsl.com>; Thu, 9 May 2019 00:05:23 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B6E120296 for <quic-issues@ietf.org>; Thu, 9 May 2019 00:05:22 -0700 (PDT)
Date: Thu, 09 May 2019 00:05:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557385521; bh=6GRznLJUstivhNUayWbMTBx1WjxzPxQ7gRO1FjBwfLc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SbRy6/ChwmcticZMkEMkQG/1KzBtvPZIGD7wAZJ2zyBI+8yzxCLs3GVUHoik09X/B qykynjRRf1XT/XdEWRgOB65naPLFb0OmqQG78iWoAJGjE4ruFROhlq2KE7nQ1Z76/w zcf6GxK1aha843VviuD3UWm4fgvVC/aMoDgPBcjk=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYQTCLPLROCMZFQYX524EB3DEVBNHHBUVMWDQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2678/490770664@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2678@github.com>
References: <quicwg/base-drafts/issues/2678@github.com>
Subject: Re: [quicwg/base-drafts] Unidirectional stream (some or) all the control things in HTTP/3 (#2678)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd3d131289e9_79203fbf312cd96051658"; 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/HWyxTFPlUUblYUf5jPGnGUiJhFQ>
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, 09 May 2019 07:05:34 -0000

I think I am opposed to having a dedicated stream for PRIORITY frames.

If I understand correctly, the suggestion is based on either of the following two conceptions:
* sending priority information only on a dedicated stream is better than allowing the initial priority to be specified on the request stream
* it is a good idea to block processing of PRIORITY frames if there is a unresolved inter-stream dependency

I am not sure if either of the two is true. For the first point, the increased chance of not having prioritization information when receiving a request is a concern (see https://github.com/quicwg/base-drafts/issues/2502#issuecomment-490330136). For the second point, my understanding is that the ideal behavior is different. It is my understanding that the server should solely refer to the weight of the request stream when the stream's location within the tree cannot be resolved (see https://github.com/quicwg/base-drafts/issues/2502#issuecomment-490689310).

Considering these points, I am not sure if we want to incentivize servers processing PRIORITY frames in order. I might also point out that the servers willing to process them in order can buffer the PRIORITY frames after reading them out from the receive buffer of the control stream, and that the clients willing to send all the prioritization information in order can do that by sending the PRIORITY frames only on the control stream.

-- 
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/2678#issuecomment-490770664