Re: Implicitly opened streams and exposing stream IDs

[Marten Seemann <[e-mail]>]

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
SHOULD to a MUST.
Only if in order stream creation is a requirement, this question becomes an
API design question.

Regards,
Marten



On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor <[e-mail]> 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 [[e-mail]]
> *Received:* Monday, 02 Apr 2018, 7:43AM
> *To:* QUIC WG [[e-mail]]
> *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.
>