Re: Unidirectional streams PR

[Ryan Hamilton <[e-mail]>]

On Thu, Jun 22, 2017 at 8:18 PM, Mike Bishop <[e-mail]>
wrote:

> 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's a clever observation. I think there's one slight difference though,
as it applies to stream limits. In the bidi case, a peer can open a bidi
stream if it has not yet exceeded the peer's limit, and the peer is allowed
to respond, even if the peer could not otherwise open a new stream because
of stream limits. In addition, with the bidi steam case, the stream is
considered open until both halves are closed, which would not be the case
with uni streams. (Though with the changes to stream limits this might not
actually be a terribly important distinction)


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