Implicitly opened streams and exposing stream IDs

Marten Seemann <martenseemann@gmail.com> Mon, 02 April 2018 11:43 UTC

MIME-Version: 1.0
From: Marten Seemann <martenseemann@gmail.com>
Date: Mon, 02 Apr 2018 11:43:23 +0000
Message-ID: <CAOYVs2qp3L-dTdFfBNDQT0Q=nCu+6Ew3gmF=0GMS2vVw1JfWCg@mail.gmail.com>
Subject: Implicitly opened streams and exposing stream IDs
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fbf5c91e1b10568dc19a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/a2NzdCILLGqJPsn-NS4L4cQCKZ0>
Precedence: list

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.

Implicitly opened streams and exposing stream IDs Marten Seemann
RE: Implicitly opened streams and exposing stream… Lucas Pardue
RE: Implicitly opened streams and exposing stream… Mikkel Fahnøe Jørgensen
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
Re: Implicitly opened streams and exposing stream… Marten Seemann
Re: Implicitly opened streams and exposing stream… Martin Thomson
Re: Implicitly opened streams and exposing stream… Mikkel Fahnøe Jørgensen
Re: Implicitly opened streams and exposing stream… Marten Seemann
Re: Implicitly opened streams and exposing stream… Martin Thomson
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
RE: Implicitly opened streams and exposing stream… Nick Banks
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
RE: Implicitly opened streams and exposing stream… Nick Banks
RE: Implicitly opened streams and exposing stream… Nick Banks
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
Re: Implicitly opened streams and exposing stream… Ian Swett
RE: Implicitly opened streams and exposing stream… Lubashev, Igor
Re: Implicitly opened streams and exposing stream… Marten Seemann
RE: Implicitly opened streams and exposing stream… Lubashev, Igor
RE: Implicitly opened streams and exposing stream… Lubashev, Igor
Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov