RE: Implicitly opened streams and exposing stream IDs

Lucas Pardue <> Mon, 02 April 2018 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A0BA1276AF for <>; Mon, 2 Apr 2018 05:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZM25skLOeOXU for <>; Mon, 2 Apr 2018 05:05:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 489141275AB for <>; Mon, 2 Apr 2018 05:05:54 -0700 (PDT)
Received: from ([]) by (8.15.2/8.15.2) with ESMTP id w32C5qgk008899; Mon, 2 Apr 2018 13:05:52 +0100 (BST)
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Mon, 2 Apr 2018 13:05:52 +0100
From: Lucas Pardue <>
To: Marten Seemann <>, QUIC WG <>
Subject: RE: Implicitly opened streams and exposing stream IDs
Thread-Topic: Implicitly opened streams and exposing stream IDs
Thread-Index: AQHTynffVfsbpETavE+fePgnAUwmm6PtYJd5
Date: Mon, 02 Apr 2018 12:05:51 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-originating-ip: []
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--16.104300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 12:05:56 -0000

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 separately.

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