RE: Unidirectional streams PR

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

Yes, we are in an agreement that we want “QUIC Libraries” to provide an easy way of doing both unidirectional streams as well as bidirectional streams.

I do not have a strong preference as to the details of framing. On one hand, I am not worried about libraries implementing bidirectional streams differently with OPEN_STREAM – there is really just one sane way of doing it, and the OPEN_STREAM model is more flexible.  On the other hand, OPEN_STREAM comes at a cost of a few extra bytes for a simple bidirectional stream implementation.

The UNI does complicate the state machine a bit by adding an extra state, as ekr pointed out.  You need a special state for implicitly opened streams.  They are not “idle” (they count toward the max), and they are not “open” (you cannot write to them), and they are not “local half-closed” (they may transition to “open”).  I do not think this is a huge deal, though – TCP has a lot more states!


From: Ian Swett [mailto:[e-mail]]
Sent: Thursday, June 22, 2017 10:10 PM
To: Lubashev, Igor <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; 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 9:49 PM, Lubashev, Igor <[e-mail]<mailto:[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.