RE: Unidirectional streams PR

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

I think of three layers of abstraction:


1.       QUIC Wire Protocol (the thing described by the QUIC Transport RFC)

2.       QUIC Library API (a library exposing some useful abstractions -- such as blocking/non-blocking unidirectional streams and bidirectional “sockets” -- and implementing them using QUIC Wire Protocol)

3.       Application (something that uses QUIC Library APIs)

What I am saying is that Martin’s unidirectional streams proposal does not have a way to implement generic bidirectional socket-like abstractions on the QUIC Library API layer.  However, if we follow Mike’s suggestion and allow an Associated Stream ID in OPEN_STREAM frames, this would make it easy for QUICK Libraries to provide generic bidirectional socket-like abstractions.

So what I am suggesting is that we keep QUIC Wire Protocol state machine simple and unchanged.  However, with the OPEN_STREAM frame, we would allow QUIC Libraries to implement both unidirectional and bidirectional streams.


-          Igor


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

On Thu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor <[e-mail]<mailto:[e-mail]>> wrote:
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.

I'm not sure I follow your thinking here: are you suggesting that QUIC implement bidirectional streams in addition to unidirectional streams?

- jana


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]<mailto:[e-mail]>]
Sent: Thursday, June 22, 2017 6:48 PM
To: Martin Thomson <[e-mail]<mailto:[e-mail]>>; Ted Hardie <[e-mail]<mailto:[e-mail]>>
Cc: Jana Iyengar <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>; Patrick McManus <[e-mail]<mailto:[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]<mailto:[e-mail]>] On Behalf Of Martin Thomson
Sent: Thursday, June 22, 2017 3:32 PM
To: Ted Hardie <[e-mail]<mailto:[e-mail]>>
Cc: Jana Iyengar <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>; Patrick McManus <[e-mail]<mailto:[e-mail]>>
Subject: Re: Unidirectional streams PR

On 23 June 2017 at 05:15, Ted Hardie <[e-mail]<mailto:[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).