Re: Unidirectional streams PR

[Ian Swett <[e-mail]>]

Igor,

In terms of the extra state, I believe EKR's right that this either creates
a need to change some text or add another state, which I hadn't
anticipated, but also isn't the end of the world.  However, Buck Krasic
pointed out we can now get rid of implicitly opened streams, because we've
transitioned from stream limits to max stream ID, which fixes this problem
in a simple way.  See issue #662
<https://github.com/quicwg/base-drafts/issues/662>.

I attempted to add text to specify that if a STREAM frame specifies UNI on
one packet, it must do so on all of them, but the text wasn't written
correctly, so I'll fix that in the PR.  I did consider whether to mark all
STREAM frames or only the first.  In the end, I proposed to mark all of
them because it's more resilient to reordering and it's easy to document
and understand.  I'm certainly open to other framings.





On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor <[e-mail]> wrote:

> Ian, I am not in love with a possibility of having UNI flag clear on some
> initial STREAM frames and then UNI set on subsequent STREAM frames.  The PR
> does not prohibit this.  I read the PR (state diagram) to require the
> stream to go immediately into “half-closed (local)” state on receipt of
> such STREAM+UNI frame.  This is a problem, since some packets from the
> receiver to the sender could be in flight, and absent a STREAM+FIN or
> RST_STREAM from the receiver, the sender cannot do flow control accounting.
>
>
>
> It seems best if a stream is UNI or BI from birth, and that’s indicated by
> the initial STREAM frame only.  If STREAM frames get reordered, until the
> receiver receives the initial STREAM frame (Offset=0), it should consider
> the stream to be in “implicit” state (do accounting for max stream count
> and flow control but cannot send data to it).
>
>
>
>
>
> *From:* Lubashev, Igor [mailto:[e-mail]]
> *Sent:* Thursday, June 22, 2017 10:43 PM
> *To:* Ian Swett <[e-mail]>
> *Cc:* Mike Bishop <[e-mail]>; Ted Hardie <
> [e-mail]>; Patrick McManus <[e-mail]>; Jana Iyengar
> <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <
> [e-mail]>
> *Subject:* RE: Unidirectional streams PR
>
>
>
> 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] <[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]>
> 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.
>
>
>