IETF Logo Mail Archive

Re: [quicwg/base-drafts] Lessen the divergence from the HTTP/2 prioritization scheme by requiring all PRIORITY frames to be sent on the control stream (#2754)

Kazuho Oku <notifications@github.com> Mon, 27 May 2019 05:31 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 BD87112008C for <quic-issues@ietfa.amsl.com>; Sun, 26 May 2019 22:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Level:
X-Spam-Status: No, score=-6.391 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_HELO_NONE=0.001, 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 rBfyWBWlU8YD for <quic-issues@ietfa.amsl.com>; Sun, 26 May 2019 22:31:42 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB6412004E for <quic-issues@ietf.org>; Sun, 26 May 2019 22:31:42 -0700 (PDT)
Date: Sun, 26 May 2019 22:31:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558935100; bh=QNQin9JiMGNNxguKVq7eElzK7jU/esRcZR7K2HrPVnw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yWseCA1daFdnYALkw+yGFNttW7pnreZ4SpHB0XlKSgzRsNvrKvuge52RsmfkzL6gh klmnoTiBGl8GBNrRriXWmNMLH2unSr6MpdBlwX/O/J1T5OLK/LuVOS1uK3lidB2FGW 3rBHdDroiuUPwOMWk7V0wjZqhORWKxklwF+dn2FM=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4ROJJD32UMSCBZDZN27CULZEVBNHHBVK576I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2754/496082579@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2754@github.com>
References: <quicwg/base-drafts/issues/2754@github.com>
Subject: Re: [quicwg/base-drafts] Lessen the divergence from the HTTP/2 prioritization scheme by requiring all PRIORITY frames to be sent on the control stream (#2754)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ceb763c4611b_7e903f8bd24cd964261885"; 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/7ctECKXM5u22qSY3QwqaRfCwz1U>
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: Mon, 27 May 2019 05:31:44 -0000

> I have a nagging feeling, the QUIC streams can close in non-deterministic order from the remote peer perspective. This risks a H3 priority scheme that looks similar to H2 on paper but behaves quite differently. In the worst case this requires holding more state on the server in order to increase the chances that the client and server have similar global views.

While I agree that the the streams are being closed in a different manner, it is my view that things would generally work better in HTTP/3, because closure of streams would be notified earlier to the client (due to having less HoLB). Earlier synchronization of states lead to less need for retaining information of closed streams.

-- 
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/2754#issuecomment-496082579

v2.23.0 | Report a Bug | By Email