Re: Implicitly opened streams and exposing stream IDs

[Marten Seemann <[e-mail]>]

Hi Martin,

I don't think delayed stream usage is a problem here. To be precise, what I
mean is not opening the stream (as in actually sending a frame on this
stream), but creation of the stream. So all I want is to REQUIRE here is
that peers *create* streams in order.

There's an important difference in how the receiving peer is allowed to
act. Assume for example the receiver wants to grant a higher flow control
limit than it advertised during the handshake:

   - If streams MUST be created in order, the receiver can send a
   MAX_STREAM_DATA for streams N and N+4 as soon as it receives a frame for
   N+4.
   - If streams only SHOULD be created in order, sending a MAX_STREAM_DATA
   for stream N (after receiving a frame for N+4) will cause a connection
   error, if the sender decided to skip stream N.

I'm not saying that this is an important use case, but this example shows
that implementations *only* have the two options for handling out of order
streams described in my last email *if* we require in order stream creation.

I'd therefore suggest to change the text in the spec to something like
this: "Endpoints MUST create the send side of streams for each type in
order".

Best,
Marten

On Tue, Apr 3, 2018 at 2:28 PM Martin Thomson <[e-mail]>
wrote:

> Requiring in-order opening is harder than it sounds.  Say you have a
> multithreaded application that is initiating requests.  The usual
> process is something like:
>
> s = connection.OpenStream()
> s.Write(request.Headers.Encode())
>
> That is, there is time between acquisition of the stream and its use.
> Do that with enough concurrency and you end up having to add late
> binding of stream identifiers to streams, which complicates the design
> of the stack considerably.  It also complicates usage because now
> there is a period where s.Id() returns an undefined result.
>
> Alternatively, you could track the highest stream ID on which data has
> been sent and send an empty, offset 0 STREAM frame rather than create
> a gap.
>
> Or, you could decide that a MUST here is unenforceable (even more so
> than the flow control limits one) and just wantonly ignore that
> requirement if this race condition happens.  While it is in theory
> possible to catch someone in a violation, it requires some interesting
> conditions (like zero packet loss).
>
> BTW, I also wish to make it possible to avoid relying on specific
> stream IDs for special functions.  I hadn't considered opening order
> as a way to do that though and had assumed that we'd use an in-stream
> header for that.  I don't think that makes the complexity worse, or at
> least no worse than having to deal with different frame types for
> different functions.
>
>
> On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann <[e-mail]>
> wrote:
> > Hello,
> >
> > Sure, the application could deal with it by starting every stream with
> some
> > kind of header, to signal what kind of stream type this is. I'm not sure
> if
> > I like this solution, since it creates additional complexity, and it is
> only
> > necessary because we removed a useful feature from the spec.
> > What did we actually gain from removing implicit stream opening from the
> > protocol? As far as I can see, we were able to relax the requirement
> > "endpoints MUST open the send side of streams for each type in order" to
> > "endpoints SHOULD open the send side of streams for each type in order".
> > This might seem nice from a conceptual viewpoint, but honestly, I don't
> > really see why anyone would actually want to do this. I think the main
> > argument against the MUST was that it's not enforceable anyway, but this
> > applies to a lot of other MUSTs in the spec as well (e.g. that flow
> control
> > limits can't be decreased).
> >
> > The fix for this is straightforward: We should REQUIRE a peer to open
> > streams in order. How the receiver handles out of order streams then is
> an
> > implementation and API decision. I see two ways that an implementation
> could
> > reasonably deal with this:
> >
> > Return streams in the order they are received, e.g. return N+4 before N,
> if
> > packets are reordered.
> > Return streams ordered by stream ID, i.e. return first N and then N+4 if
> a
> > frame for N+4 is received.
> >
> > This way, we wouldn't need to reintroduce implicitly opened streams, but
> > leave this up to implementations. I should have named this thread
> > differently, if only I had realized this earlier ;)
> >
> > Regards,
> > Marten
> >
> > On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue <[e-mail]>
> 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.
> >>
> >> Regards
> >> Lucas
> >> ________________________________________
> >> From: QUIC [[e-mail]] on behalf of Marten Seemann
> >> [[e-mail]]
> >> Sent: 02 April 2018 12:43
> >> 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.
> >>
> >>
> >> -----------------------------
> >> http://www.bbc.co.uk
> >> 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
> >> immediately.
> >> Please note that the BBC monitors e-mails
> >> sent or received.
> >> Further communication will signify your consent to
> >> this.
> >> -----------------------------
>