[quicwg/base-drafts] Need to clarify QUIC stream usage in HTTP/2 mapping (#1882)

Magnus Westerlund <notifications@github.com> Thu, 18 October 2018 09:23 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 9F2E2130E53 for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 02:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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, SPF_PASS=-0.001] 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 eFUXizmysuuu for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 02:23:15 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68752130E88 for <quic-issues@ietf.org>; Thu, 18 Oct 2018 02:23:15 -0700 (PDT)
Date: Thu, 18 Oct 2018 02:23:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1539854594; bh=78LPw+Wsv+D0fSCo+jp0laDQllVRWGuDCDPuOdAAGEE=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=X7ZgyeZcolQSYfas/QbSrh+w3fnaJzTiOELzp+vQCbSaubxjDUdJhuDBQ52Ay5pla VHBxfCBxLBfG6FDPYLcPVx19r/TW5qTwlEWX7TzTfR0EZVkgFsLQskAVLmgnUsIPSE GmiE7xfjvt/uCq0Nvwrts6vseFW68EY2m+tF3OVs=
From: Magnus Westerlund <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc53c655a4184c941c380c523adaa2c7256ae657792cf0000000117e0130292a169ce1623af22@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1882@github.com>
Subject: [quicwg/base-drafts] Need to clarify QUIC stream usage in HTTP/2 mapping (#1882)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bc8510211973_78b23fe1400d45c4149423"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gloinul
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/mm6iWxN2UAM17_BDWwUUmfBXegw>
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, 18 Oct 2018 09:23:18 -0000

I tried reading the HTTP/2 mapping draft (-15) to answer a question regarding the QUIC stream usage by HTTP/2 over QUIC. And that failed misserably until I looked at the slides from Montreal IETF meeting. 

Where I think there are need for clarification are:

Section 3.: Here a general overview of the how the four streams per HTTP request are used and assigned. Currently it says that client bi-directional will be every fourth 0,4, 8 etc. Nothing more aobut which streams are which of the remaining three, not even which names are used for them. 

In Section 3.3.3 the first mention of the word "push stream" occurs. That appears to indicate that a unidirectional stream that starts with a 0x43 stream type is then barred from use by any other stream type. I think 3.3 has to be clearer that the usages of unidirectional streams are not necessarily connected to the HTTP request response happening on the bi-directional stream. And that implementations needing a new unidirectional stream simple takes the next free (X+2/3) mod 4 depending on direction. 

I think it would be good to exemplify in the HTTP draft that a connection for HTTP/2 will have a number of unidirectional streams that are used long term or some short term and then closed and that one can't rely on stream ID being in the group related to a particular request. 

-- 
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/1882