Re: Unidirectional streams PR

[Ian Swett <[e-mail]>]

As promised, here is my 1 bit extension to the existing QUIC STREAM frame
to support unidirectional streams in addition to bidirectional streams.  It
uses an extra bit in the type byte to indicate a STREAM frame is
unidirectional, and hence the stream is to be opened in a
half-closed(unidirectional) state.

There are many ways to frame this, which I'm happy to discuss, but the key
idea is that adding unidirectional streams to the existing design does not
add much complexity, and provides a more flexible API to use cases
including server push and RTP.

https://github.com/quicwg/base-drafts/pull/656

PS: This does not solve the issue Ryan identified above with PUSH_PROMISE
transitioning to a push id to avoid using up open stream limits.  I think
that should be separable and easy to put on top of this PR as well.

On Thu, Jun 22, 2017 at 9:06 PM, Lubashev, Igor <[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.
>
>
> 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).
>
>