RE: Implicitly opened streams and exposing stream IDs

Mikkel Fahnøe Jørgensen <> Mon, 02 April 2018 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E62B124BE8 for <>; Mon, 2 Apr 2018 10:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 04nbZOTuTITe for <>; Mon, 2 Apr 2018 10:39:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C4AC126B72 for <>; Mon, 2 Apr 2018 10:39:33 -0700 (PDT)
Received: by with SMTP id o4so18762570iod.3 for <>; Mon, 02 Apr 2018 10:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=XtNOFw875udm4SJgvcFCdHohvk3RA0Iq7rWZgkH9LtU=; b=RXz90Pya468bpP99uS3pudsptXX+n+olgXV1f7hz4DaI72hVTu88xPzaP7ccsmPICM +Nxngv8G5Vxrrk+bX1W3R2URj+Th2j2ddg0RbH9xUhCVq9st8BM5IWMy/SXTy7T8VGhW wcIZ0llF89irgNlGmjOlT993qxIx7qzwS/BYA6mKmRJpdzdpDBlrEmh0autMNGfPb/kK 5TGO7HI6wZi/+sPfBhsOsiSmPspGZ05FB5IF7NQe4rlBw/ZqYS9O0zQaVWv5O6ScY58y f1E7ErZExJ2mRWDSibCAbaAzsw5/6kC4BOvCMLwvi1GGxUuy3c+YKVJLAN6D4Xm2VspF VDzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=XtNOFw875udm4SJgvcFCdHohvk3RA0Iq7rWZgkH9LtU=; b=ko3d6Ai9NGpaIubfivqe8LWuBeRHnT+/4e/nNJYwSucCjdjBDkNjJJ08awFugNU42c dZ1O/OjYmCoqBqDpnaWzUX+YwuhKebC+BuyKdSnN8CQjkpSu7BkC20TW2yIVc1CbNxsR uD7/Dln5VM0GWl3TR4mqBbAQwzzIB8gc3czK7azK9NMOT+Xxh4+hWMD2LYeR5J8qD7DV P8SyrsdkNkBwot1pxkuo3W5jRZ1P7Y/zQKsq7QGtP2qQoogg0yqETf+eWKJEdEEaLv9Q inOssWa1AnVVnDXwCqsvK4KfLwrwYrbgSASWrGcCaZ/ykWVlhKPJZ6/3dKriHG2WfzSc bpqw==
X-Gm-Message-State: ALQs6tCnsC2onYuIY8ub8yeVesxyjlMjyUK+tsEWOrsAZZ6AJ5itlv1o +XzgAmwy4ixy4OfSbKtC7glU3Nj1HXSksdiQsdw=
X-Google-Smtp-Source: AIpwx48xhLic5uUWLrT58oEXGFfeHrt2+mYRgJRIjZ4TQBhztRtF9DRUOg8tglj8iIjpN1/vL6ZCuf5lrysZ/7NZxWg=
X-Received: by with SMTP id f35mr9948157ioi.165.1522690772793; Mon, 02 Apr 2018 10:39:32 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 2 Apr 2018 14:39:31 -0300
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 02 Apr 2018 14:39:31 -0300
Message-ID: <>
Subject: RE: Implicitly opened streams and exposing stream IDs
To: Lucas Pardue <>, QUIC WG <>, Marten Seemann <>
Content-Type: multipart/alternative; boundary="001a113e06a29d7bb20568e112b0"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Apr 2018 17:39:36 -0000

Isn’t this between QUIC, the QUIC application API, and the application

If you tell QUIC to feed streams in order, just like you it to feed data
inside a stream in order, then it can virtually open streams in order
stream towards the API without affecting the network.

QUIC is also permitted to deliver data out of order inside a stream AFAIR,
although this would not be the usual API behaviour.

In the end, specific broadly accepted app protocols like QUIC/HTTP will
drive the API design.

For other use cases such as some small brief message streams and some heavy
data loaded streams, you might very well want to have the latest stream
arrive first, to process priority messages. Saying that QUIC can never, as
opposed to usually, expose the stream ID seems pointless. It is like saying
a QUIC api can never expose holes in a single streams data stream.

I don’t really see an issue on the wire, and I believe removing implicit
open takes a way some fear, uncertainty and doubt about stream resource
handling - at least I never felt completely comfortable with the stream
design until now.


On 2 April 2018 at 14.06.04, Lucas Pardue ( wrote:

Hi Marten,

Would Stream headers fix this problem? I.e. anything that requires special
behaviour other than "bulk data" has some bytes of of magic at the start of
the stream.

From: QUIC [] on behalf of Marten Seemann []
Sent: 02 April 2018 12:43
Subject: Implicitly opened streams and exposing stream IDs

Recently, the implicit opening of streams (i.e. that when a receiver
receives a frame for stream N+4, it can assume that stream N was already
opened, but the packet might have been reordered) was removed from the
draft. I think this change has some consequences that we haven't discussed
so far.

For the purpose of writing some pseudocode, I'm assuming a QUIC API that
provides an AcceptStream() method, but the conclusions will be the same for
a callback-based API.

* If QUIC has implicit stream opening, AcceptStream() would return the
streams in order (and if a frame opening stream N+4 is received before
stream n is opened, AcceptStream() will first return stream N and then
stream N+4).
* Without implicit stream opening, AcceptStream() just returns whatever
stream is received first. Streams might be returned in arbitrary order, if
the peer doesn't open streams consecutively or if packets are reordered.

Now imagine an application protocol where the first unidirectional stream
opened by the client is a control stream, and all higher unidirectional
streams are data streams. The application on the server side needs to find
out which stream is the control stream, because it needs to be handled

With implicit stream opening, the server code would be:

control_stream = AcceptStream() // is guaranteed to open the first stream
// handle the control stream
while true:
stream = AcceptStream()
// handle the data stream

and without implicit stream opening:

while true:
stream = AcceptStream()
if stream.ID() == kControlStreamID:
// handle the control stream
// handle the data stream

In this case, after accepting a stream, we first have to check the stream
ID, since there's no guarantee if the control stream will actually be
received first.

For this stream mapping, it seems like the removal of implicitly opened
streams implies that QUIC has to expose stream IDs to the application
layer. I'm not sure if this was intended when making the change, especially
since we're considering to change HQ such that it doesn't rely on QUIC
stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping,
because the HTTP control streams are unidirectional and the request streams
are bidirectional, and can therefore be told apart by their directionality.
However, as a general transport protocol, other applications built on top
of QUIC will have to find some way to deal with it.

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless
specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to