Re: Unidirectional streams PR

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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.