Re: Implicitly opened streams and exposing stream IDs

Marten Seemann <> Thu, 05 April 2018 12:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB91A12778E for <>; Thu, 5 Apr 2018 05:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yufm04mZuX0n for <>; Thu, 5 Apr 2018 05:51:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C35D127201 for <>; Thu, 5 Apr 2018 05:51:44 -0700 (PDT)
Received: by with SMTP id e79so30478779ioi.7 for <>; Thu, 05 Apr 2018 05:51:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azQWq3yA4/cFRT2Hhm0FSHuvObdAYqmnRI5/ptyO8Eo=; b=QBfkr6TVFb5To3aMtizle5nS0OkR7dTS/z3H/qsH66tow6XdQ8kci80BQRDwN8IpZo xFzOpNE3DbgNJdrLMzglcqUl5eHxw426csgQULxIX/AQD9Hv/9g5204WEtDi/KtoVBPb b9NEtDfm0ALyDRNA7ReYMGG+6hzeFUY8KvI6FqfHFknzLIuDrdoFC7OpWcUWHoJoD8Zy PnY3pbpb0dJ3gKwUwJLvdNlMvSvg+XV76K+OkKnw8z04AT/vYBG5NWz2ML6/JFmZcdPW 6RqiVGuEHALhcQ7wnw73m1e5RlAPdXh2Rao7zOK8RkSNxLGxkfeD5JQtXZk/pmRqrJyw u6bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azQWq3yA4/cFRT2Hhm0FSHuvObdAYqmnRI5/ptyO8Eo=; b=QUFProEm9BCi5sxzvgYGn1EwreYxZm/GNpXPZeNU/ucsJIC9TiwKUs24mY6NgOQjNb 6W4FBJM89rBS0mHHSWXs4XHNUD25kr32SkkJl1/WLlHUE86jPzFY6xmqwn4By8uEwg/m MzLc9ctR/FwhN8SBxS9le6O1f4rkNaCOIImBcQW27sqqkbd9lIW6qF04qABT6aMH5ZYo yBXWNh9Rx6FN2tF/DDTq5a+SD3KK7VvLXs0Bp/kCeRDVSvCh8ZYFDWnroxMdy2pUUutQ GD8MUaD9h5kqn7jyl67IWvUv6Hojk3ctWQv2s2O1HETAEww8UTnt0sSV+armRzphJ6ar Tb+A==
X-Gm-Message-State: AElRT7GB72ipeFhdpyFXlMJAHncArGWqoVJccu0MpqsWrw19Bz0xHDpg lQe6mxNwGlHgaYpEXPdZ39eXa8oB3IBTstoZbDTK4A==
X-Google-Smtp-Source: AIpwx49/57Uvu//6ylmLBJIGasNpLPe8qvpo2XUhnIHN4SfCdaKs76PI7I/vQmD28GpjOje57+2ikXdqKzl/IQKQewY=
X-Received: by with SMTP id 32mr20919474iog.24.1522932703250; Thu, 05 Apr 2018 05:51:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Marten Seemann <>
Date: Thu, 05 Apr 2018 12:51:32 +0000
Message-ID: <>
Subject: Re: Implicitly opened streams and exposing stream IDs
To: "Lubashev, Igor" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113fbf5ccb52be05691966b4"
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: Thu, 05 Apr 2018 12:51:47 -0000

Hi Igor,

This is exactly the change I'm proposing. Currently, the draft says that
you SHOULD create streams in order (section 9.2). I'd like to change that
Only if in order stream creation is a requirement, this question becomes an
API design question.


On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor <> wrote:

> This is not a QUIC transport draft concern. This is a question of QUIC
> library API design. Your API may choose to have Accept return streams in
> order. My API may choose to have Accept return streams as they come in (and
> expose steam IDs). As long as the transport draft requires that streams are
> CREATED in order (as it does now), both API designs are valid.
> It would be a matter of a very different draft to standardize QUIC APIs
> (like we have for POSIX) so an application can be easily ported to use a
> different vendor's QUIC libraries.
> - Igor
> -----Original Message-----
> *From:* Marten Seemann []
> *Received:* Monday, 02 Apr 2018, 7:43AM
> *To:* QUIC WG []
> *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
>         else:
>             // 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.