[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> Thu, 23 May 2019 05:58 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 B3B64120096 for <quic-issues@ietfa.amsl.com>; Wed, 22 May 2019 22:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.011
X-Spam-Level:
X-Spam-Status: No, score=-8.011 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 B0uYWLWT0F41 for <quic-issues@ietfa.amsl.com>; Wed, 22 May 2019 22:58:06 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEAA120086 for <quic-issues@ietf.org>; Wed, 22 May 2019 22:58:06 -0700 (PDT)
Date: Wed, 22 May 2019 22:58:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558591084; bh=YI1k6QPANMFcXaH2D1Xx4ZoLwtOdgl9hK1xeZlOboM0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=QPDHrf9T+7/1pOHXtPtuG428djdIzbJ5d7su6qaHmp/uO9lqllsiRHaS3FfRu5bmz 2qFOxbR3sfMhOFk5gqvcclG4yvH0AEtz4Ji6BHj5tGjlIdlu9OMq0SGYhXgb9MZYXx UELEVo43/Om6yJoZl51EYOsfzr4Kt1NoMvsLBw10=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3K5NSZIJLKH72YPWV26NUOZEVBNHHBVK576I@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@github.com>
Subject: [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_5ce6366c77623_48973f97d82cd968467613"; 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/NrVjUThIO3XGWMzymeSI-TmRq8E>
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, 23 May 2019 05:58:09 -0000

One of the additional complexity of the HTTP/3 prioritization scheme, compared to HTTP/2, is that PRIORITY frames might arrive out-of-order, between the control stream and the request streams.

Our previous perception has been that it's worth the complexity, but I am becoming doubtful if it's necessary.

IIUC, the need for sending a PRIORITY frame on the request stream is to handle the rare-case (like 1%) where a packet carrying the control frame is being lost. But if we are to require a server to assign the most deferred priority (i.e. weight=0) to a request for which the PRIORITY frame is yet to be received, there would be a guarantee that the performance would not be worse compared to HTTP/2 over TCP even when packet loss is involved, as @pmeenan points out in https://github.com/quicwg/base-drafts/issues/2502#issuecomment-491108296.

To rephrase, sending PRIORITY frames on request streams is an "optimization" for a rare case instead of it being a requirement to achieve comparable or better performance to HTTP/2.

Therefore, I am suggesting to stop sending PRIORITY frames on the request stream. The benefit of stopping that is that then we can have the guarantee that all the PRIORITY frames would be received by the server in the order they were sent by the client.

Then, thanks to the in-order delivery guarantee, I think we can revive the "exclusive" bit , revert the introduction of the "placeholders" concept in place of idle 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