Unidirectional stream reservation

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Sat, 09 June 2018 14:43 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD45D130E8A for <quic@ietfa.amsl.com>; Sat, 9 Jun 2018 07:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 xJu3fNHj3FoD for <quic@ietfa.amsl.com>; Sat, 9 Jun 2018 07:43:50 -0700 (PDT)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F67130E89 for <quic@ietf.org>; Sat, 9 Jun 2018 07:43:50 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w59Ehmvj021673 for <quic@ietf.org>; Sat, 9 Jun 2018 15:43:48 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0361.001; Sat, 9 Jun 2018 15:43:45 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: IETF QUIC WG <quic@ietf.org>
Subject: Unidirectional stream reservation
Thread-Topic: Unidirectional stream reservation
Thread-Index: AQHUAABE0LSUozrYCESnhxU00MplGQ==
Date: Sat, 09 Jun 2018 14:43:44 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23896.006
x-tm-as-result: No--0.478600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99bgb01xud1012_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aXVdzctSW8Fikm-FoEFNUrbZOkk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jun 2018 14:43:53 -0000

Hi,

The discussion in Kista about unidirectional streams focused on not "grabbing" streams that are reserved for control or QPACK. This relates to PR #1359<https://github.com/quicwg/base-drafts/pull/1359>.

I have an HTTP/QUIC extension proposal [1] that would like to use server-initiated unidirectional streams in a dynamic, ad-hoc manner. With the current design, I hoped that I would be ok if I avoided the reserved streams. Well, while working through an implementation, I've realised that HTTP/QUIC server push effectively "grabs" all non-reserved streams. This means that clients would attempt to parse the first byte of my extension stream data as a Push ID, probably succeed, and subsequently rapidly fail.

Patrick made the point in Kista that this is a nice extension point. My view now is that it is necessary, since we can't realistically reserve other stream IDs at a later point and will lose this extension capability.

Lucas

[1]  - https://tools.ietf.org/html/draft-pardue-quic-http-unbound-server-push-00