RE: Implicitly opened streams and exposing stream IDs

["Lubashev, Igor" <[e-mail]>]

> Creation isn't an observable action, so we need to use observable actions to drive what the spec says.

Creation is a wire-observable action, if an endpoint creates just a single stream, when MAX_STREAMS allows creation of streams n through n+m.  If a single stream is created, there will only be a single STREAM(id=x, off=0) on the wire (possibly retransmitted).  It will be very observable if x != n.

- Igor


-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Tuesday, April 03, 2018 5:24 AM
To: Marten Seemann <[e-mail]>
Cc: Lucas Pardue <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: Implicitly opened streams and exposing stream IDs

Creation isn't an observable action, so we need to use observable actions to drive what the spec says.  So that would seem to be equivalent to restoring implicit open in my mind.  Which - for the record - I was a proponent of.  But you don't need to convince me :)

As you say, the observable difference is in whether sending MAX_STREAM_DATA on stream N is permitted once stream N+4 has been opened.  (And similar such things.)

I found the rather strident arguments in favour of dropping implicit open convincing, in the sense that a strict requirement for in order creation was onerous for those who want to parallelize stream consumption.  But it's entirely possible that that could be dealt with by saying that the streams are still created in order, but used out of order.  I don't know.  Those who argued for a lifting of the requirement should weigh in.

On Tue, Apr 3, 2018 at 6:40 PM, Marten Seemann <[e-mail]> wrote:
> 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.
>> >> -----------------------------