Re: Unidirectional streams PR

[Jo Kulik <[e-mail]>]

I'd like to pop back up to a comment Igor made last week, because I find it
helpful in thinking about the design space:

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)

I think there is some argument to be made that Martin's original proposal
did not take into account how we would achieve (2) for bi-directional
streams.  (I don't think it strictly said "thou shalt not do (2)" either,
but that is up to interpretation.)

Several people have argued that we do not want every application to have to
re-implement bi-directional streams (3) for every application, and this is
not how g-quic (our largest deployment) works right now.  These arguments
make sense to me, but YMMV.

Just because the particular *mechanism* that is being proposed has some
issues, however, doesn't scream out to me, at least, that we should abandon
this particular *design goal*.  The goal being a transport protocol that
can elegantly fit with a uni/bi stream model.  Now, if we conclude that
there can never be an elegant model that achieves this goal, then so be
it.  But I also feel like we haven't reached that point in the discussion
yet.  (At the very least, this discussion has been fruitful to me in terms
of mapping the design space and elucidating requirements).

One of the reasons I still think this design goal is under consideration is
that Ian and Igor/Mike have been talking about alternate solutions which
have a similar flavor.  During the recent "quiet"ness on the thread,
personally, I've been waiting to hear more from them.

On Wed, Jun 28, 2017 at 9:41 AM, Mikkel Fahnøe Jørgensen <[e-mail]
> wrote:

> In reply to Ranjeeth
>
> It is not only a matter of simplicity for the sake of simplicity:
>
> - A complex transport layer might end up being poorly implemented leading
> to reduced interoperability and ultimately adoption. This complexity is not
> only in implementation but also in understanding the exact semantics of
> stream lifetime. Even if the spec is sufficiently clear, it will still be
> open to misinterpretations.
>
> - Bi-directional state may have to be maintained longer and with more
> overhead than with uni-directional streams, especially under loss,
> potentially leading to poor performance and poor resource utilisation
> because the transport layer has insufficient information.
>
> - The extra complexity at the application layer may be overstated - it is
> significantly simpler to manage a map that associates to two streams than
> it is to maintain bi-directional state at the transport layer. It is even
> possible to implicitly link streams with same identifiers, e.g. in a RPC
> scenario. That said, I do see a potential benefit of a wrapper that
> implements the common bi-directional case.
>
> - Complexity at the application layer may be duplicated, but
> implementation errors are also isolated to that application. Specifically
> for HTTP I would assume that QUIC transport and QUIC HTTP implementers
> would be large the same for a long time to come, so I would not expect the
> tradeoff here to be particularly concerning.
>
> - Unix pipes are traditionally constructed as a pair of uni-directional
> file descriptors and that is a reasonably proven model. C’s standard
> library stdin, stdout and stderr is an example of an asymmetric model with
> implicit linkage between uni-directional file descriptors.
>
> - There are lots of use cases for non-HTTP like connectivity - Kafka high
> volume message queuing for example. The industry trend appears to move
> towards asynchronous processing and messaging. It depends on whether you
> look at QUIC as a TCP + TLS replacement, or as a HTTPS / REST RPC
> replacement.
>
> - Uni-directional streams may currently be unproven in the wild, but a
> proposal is needed before an implementation can be made and testet. I agree
> that it is easy to design into wrong assumptions without real world testing.
>
> - There will hopefully not be a large number of successors to QUIC -
> perhaps some purpose specific variants, e.g. for embedded use. Widespread
> adaptation and compatibility is very necessary so it makes sense to have
> QUIC being sufficiently simple and expressive to achieve this goal. A
> polymorf QUIC will not achieve that goal. On the other hand, a solid QUIC
> foundation can be used for a large number of application protocols.
>
> - Finally, it may turn out that uni-directional streams just is a bad idea
> - I doubt it, but I do believe real world tests are needed.
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 28 June 2017 at 14.42.36, Dmitri Tikhonov ([e-mail])
> wrote:
>
> On Tue, Jun 27, 2017 at 02:31:38PM -0700, Ranjeeth Kumar Dasineni wrote:
> > 2. We are overplaying the simplicity of design. Even if we deem
> deployment
> > experience not a concern, if every application layer protocol that needs
> > support for bidirectional streams has to implement some correlators and
> > such above, that's a net negative in terms of complexity.
>
> This is an important point: we want QUIC adoption to be made easy.
> A program that speaks HTTP today should be able to use an existing QUIC
> library without having to emulate bidirectional streams in order to fit
> it into HTTP usage pattern. Forcing every one of these programs to do
> this is certainly a hurdle.
>
> - Dmitri.
>
>