Re: Unidirectional streams PR

[Ian Swett <[e-mail]>]

On Thu, Jun 22, 2017 at 9:49 PM, Lubashev, Igor <[e-mail]> wrote:

> 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
>
> Igor, I think you and I are in agreement that we both want a relatively
easy way of doing both unidirectional streams as well as bidirectional
streams?  Given that, it comes down to what to standardize at the transport
layer and some framing.

In regards to the unidirectional only model:
 1) The QUIC stream state machine is really not that complex, and the
current documentation does a nice job of explaining it.  Changing to
unidirectional only streams only saves 2 states, from 5 to 3, and a small
bit of text.
 2) I'm very concerned that if we don't standardize a way to do
bidirectional streams, different 'QUIC Library API's will internally
standardize on different approaches for recreating bidirectional streams.
I fear this may create more work and interoperability challenges down the
road.

So if we think literally no one will have any use for the bidirectional
stream model, then I agree we should remove it.  But even today, the HTTP
mapping is simpler with the bidirectional stream model than with only
unidirectional streams, which means the total amount of work of
implementing HTTP + QUIC is about the same either way, and I believe if
bidirectional streams and unidirectional streams do exist in QUIC(as in my
PR above), then the HTTP would/should use both.


>
>
>
>
> *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]>
> 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]]
> 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).
>
>
>