Re: Unidirectional streams PR

[Martin Thomson <[e-mail]>]

There is probably a simpler approach here, take a bit (as Ian did) and
say that if that bit is set, then the stream is in response to another
and the stream ID of the stream to which this is responding follows
immediately after the stream ID of the stream itself.  You could then
include that only at the start of the stream, or in multiple frames
(or as we decide).

The problem with this, as with several of the other issues we're
discussing, is that unless what the transport provides is a perfect
fit for application semantics, you end up building those semantics
into the application anyway.  HTTP certainly can't survive without its
own association semantics for pushes.  That suggests to me that having
bidirectional semantics in the transport creates more duplication than
otherwise.  Hence my proposal.

On 28 June 2017 at 15:26, Mike Bishop <[e-mail]> wrote:
> As promised, a PR for adding “associated streams” is at
> https://github.com/quicwg/base-drafts/pull/672.  This very deliberately
> builds on top of MT’s PR – it’s adding a primitive which can be used to
> construct various abstractions atop unidirectional streams, but the
> lifecycle is still fundamentally unidirectional.
>
>
>
> Copying my notes here for list discussion purposes.
>
> Major changes
>
> Leveraging @igorlord's insight that OO=00 only occurs on the first STREAM
> frame of a stream, I used that as the trigger for a Stream Properties byte.
> Two bits of that byte describe the directionality of the stream:
>
> Unidirectional (no response expected)
> Initial bidirectional (one response expected)
> Initial multi-response (one or more responses expected; needs a better name)
> Response
>
> If the type is Response, there's an Associated Stream ID field, length given
> by two more bits following the same pattern as the SS bits in the STREAM
> frame ID.
>
> Personal Opinion
>
> On the plus side, these stream types seem to cover the abstractions I can
> envision for most applications. You can unilaterally send something
> (unidirectional), do request/response (bidirectional), or pub/sub (single
> subscription stream, series of update streams).
>
> I don't care for the fact that I still need the stream type header in HTTP
> after putting this in the transport. That will be ameliorated if we go back
> to one stream per request, since all unidirectional streams will be push
> streams. (As a side-note, I considered using the multiple-response option in
> the HTTP mapping, but then I need a stream header again to indicate which is
> the response and which the pushes.)
>
> I particularly don't like that you now have to look at the frame type header
> to find out whether a field exists which tells you the length of something
> else in the header. I'd like to simplify that. I went with this model over a
> CREATE_STREAM frame because of @mikkelfj's use-case of very small messages
> -- this adds only one byte to the first frame on a stream in one direction
> and 2-5 bytes to the first frame of response streams. A separate frame type
> would be somewhat larger, but could be cleaner in that respect.
>
>
>
>
>
> From: QUIC [mailto:[e-mail]] On Behalf Of Swindells, Thomas
> (Nokia - GB/Cambridge, UK)
> Sent: Wednesday, June 28, 2017 7:56 AM
> To: Jo Kulik <[e-mail]>; Mikkel Fahnøe Jørgensen
> <[e-mail]>
> Cc: QUIC WG <[e-mail]>; Dmitri Tikhonov <[e-mail]>
> Subject: RE: Unidirectional streams PR
>
>
>
> I agree that looking at the layers of abstraction is useful. In principle
> having the wire protocol just have constructs for unidirectional streams
> does not in itself limit creating bi-directional communication flows,
> supported at either the library or application layer.
>
>
>
> However, there need to be a standard way of doing bi-directional
> communication for migrating applications implemented using a socket style
> api. It needs to be easy to move an existing application from TCP to QUIC.
> This move may be attractive in many situations as QUIC gives improved
> security and may allow greater throughput due to the more modern (and
> customizable) congestion control algorithms compared to the OS TCP stack.
>
>
>
> For migrating standard socket api applications I don’t think it would be
> appropriate to leave the work to the application to do correlation, at least
> the library should be providing this service using the wire protocol as
> appropriate. Clearly we want a client written with one library to be able to
> communicate successfully with a server written using a different library.
> This needs some form of standardization of the signalling. This could either
> be a building block overlay on top of QUIC, or implemented at the wire
> protocol level.
>
>
>
> In terms of patterns I think the following may be some of the most common
> patterns (with potential to be provided at the library and or wire protocol
> level).
>
> I/O pattern  : Example
>
> 1/0   : An input only flow, perhaps a data logger like syslog with no
> confirmation/feedback
>
> 0/1  : an output only flow, perhaps a topic message bus service with no
> confirmation/feedback
>
> 1/1 : standard TCP applications with a single flow per connection
>
> 1/* : single input, many output, modelling STDIN/STDOUT+STDERR
>
> (1/1)* : multiplexed pairs of flows – supporting multiple sockets muxed onto
> a single QUIC connection
>
>
>
> Obviously, an application would always have the option to combine any single
> direction flows with application level correlators to construct more complex
> flows if desired.
>
>
>
> At the moment my gut says the 1/1 use-case is common enough that the wire
> protocol should provide a standard mechanism to support it as a standard
> overlay would probably end up being treated as part of the wire format
> anyway.
>
>
>
> Perhaps streams should be explicitly created with a CREATE_STREAM frame
> which would be capable of defining multiple related streams?
>
> There is the option of whether only (1/1) pairs can be created this way, or
> (1/n) combinations could be supported (with an application defined way to
> identify the use of each of the output streams). A step further may be that
> there is a transport parameter that defines whether the server is allowed to
> create additional streams, or if stream creation is purely client driven
> (like TCP). I don’t know if either of these would simplify how to handle
> stream accounting, and in particular only creating a flow when all parties
> have sufficient allowances left.
>
>
>
> Thomas
>
>
>
> From: QUIC [mailto:[e-mail]] On Behalf Of Jo Kulik
> Sent: 28 June 2017 15:09
> To: Mikkel Fahnøe Jørgensen <[e-mail]>
> Cc: QUIC WG <[e-mail]>; Dmitri Tikhonov <[e-mail]>
> Subject: Re: Unidirectional streams PR
>
>
>
> 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.
>
>