RE: Unidirectional streams PR

[Mike Bishop <[e-mail]>]

Interesting design.  I was trying to avoid doubling the number of frames consumed by the STREAM frame by consuming just one.  But it's a good insight that offset is only absent on the first STREAM frame, so we could leverage that if we wanted to.  Maybe OO=0 indicates the presence of some fixed-size params, and one of those bits is directionality?

I wasn't convinced this is simpler, because HTTP/QUIC would still need a stream header.  But if we used bidirectional streams for request/response, then all unidirectional streams are PUSH_PROMISE, and they're the only ones that need a stream header.

However, let me point out that this is fundamentally still unidirectional streams with the ability to declare (as metadata) that a particular stream is "affiliated" with a stream in the opposite direction.  (And perhaps the ability for the stream initiator to declare an expectation that there will be an affiliation coming.)  This does change the request on N / response on N model.  We're just talking about moving the correlator into the QUIC framing, so that each mapping doesn't have to reconstruct how to do correlations.

That means we get (or can get) the same state simplifications as in the PR by considering the streams to have independent lifecycles -- the correlator is simply made available to the application as information about the stream.  That also means that adding the correlator can be done in a separate PR, if we prefer.

-----Original Message-----
From: Lubashev, Igor [mailto:[e-mail]] 
Sent: Thursday, June 22, 2017 6:07 PM
To: Mike Bishop <[e-mail]>; Martin Thomson <[e-mail]>; Ted Hardie <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
Subject: RE: Unidirectional streams PR

I like the idea of unidirectional streams, if they make life easier for apps -- both "traditional" apps like H2 as well as less usual apps like ssh (one stream in one direction, two associated streams in the opposite direction).

I also like Mike's idea of OPEN_STREAM frame.  The way I'd describe OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset and a set of "per-stream properties".

An important point is that when Transport is aware of the association of two unidirectional streams, the Transport API would be able to implement a bidirectional socket-like abstraction for applications that desire one.


OPEN_STREAM frame
The type byte for a OPEN_STREAM frame contains embedded flags, and is formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame.
* The PP bits encode the size of the Params Bitmap field. The values 00, 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively.

The two Least Significant bits of the Params Bitmap indicate the length of the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate lengths of 0 (none), 8, 16, and 32 bits long respectively.
We can define up to 30 additional bits to be meaningful to the transport.  (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, Priority-Delivery (aka "DontBuffer") bit, etc).

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Stream ID (8/16/24/32)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Params Bitmap  (8/16/24/32)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Associated Stream ID (0/8/16/32)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       [Data Length (16)]      |        Stream Data (*)      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to STREAM frame with OO=0.



-----Original Message-----
From: Mike Bishop [mailto:[e-mail]]
Sent: Thursday, June 22, 2017 6:48 PM
To: Martin Thomson <[e-mail]>; Ted Hardie <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
Subject: RE: Unidirectional streams PR

I suppose you could drop the stream type header from HTTP into QUIC and make the types "bidirectional stream," "unidirectional stream," and "mate of bidirectional stream"; the last would further need to identify which peer stream it corresponded to.

But making them the first couple bytes of the stream data feels kind of kludgy if this is fundamentally built into the transport, which means they really belong in a dedicated frame.  Maybe a dedicated OPEN_STREAM frame, which blocks any data received on that stream until you know what type it is?

Actually, if we're planning on introducing other per-stream properties like partial reliability, there might be value in an OPEN_STREAM frame where we can describe a stream's desired properties before any data flows....

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <[e-mail]> wrote:
> My personal take on that right answer there is to support both, with 
> an explicit signal of when each model is in use,

I have heard this request now from several folks at Google.  I don't know how to make this work without increasing complexity considerably .  I'd be willing to be wrong about this, but would prefer to see a proposal.  I don't need a fully-worked proposal with text, just a sketch of how the pieces work in enough detail to understand how this might interact with other parts of the protocol.  I think that Jana offered to do this, so maybe I can wait for that (c.f., Mark's earlier statement about priority/urgency).