Re: Unidirectional streams PR

[Ranjeeth Kumar Dasineni <[e-mail]>]

This thread has gone quiet. So, I am voicing my concerns about Martin's
proposal here to reiterate the importance of deployment experience, making
things no simpler than necessary and to generally evoke a sense of urgency.
Personal opinions, of course!!

1. We are the underplaying the importance of deployment experience. I am
afraid that IETF-QUIC, after these changes, diverges quite far from the
deployed G-QUIC. Far enough, to throw serious doubt on all assumptions
about performance and deployability. It becomes effectively a brand new
protocol designed not based on running code but what seems to be an obvious
simplification of one layer, at the cost of complexity at another layer.
Leaving the benefits of simplification aside, I am wary of standardizing
things that have not been deployed anywhere. H2 push and priorities should
serve as a lesson here where one could clearly articulate the benefits when
designing them and yet it was extremely hard to realize those benefits in
practice. Here, I have a hard time even articulating the benefits of a
simple transport layer, speaking of which ...

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. Arguably, it's
far simpler for an application to simulate/enforce unidirectionality when
it needs. Not to mention there does not seem a deployed application or an
immediate candidate that needs it. H2 Push is a special pony which is yet
to be deployed widely and something that I would treat as an exception, not
norm. Even with H2, where implementation of application level correlators
seems simple enough, it raises the questions on ease of deployment (if
proxies will get this right), debuggability (examining a single request +
response is now harder) and the impact of bug (more prone to sending
critical data to the wrong destination). The demonstrated success of G-QUIC
and the first likely role for IETF-QUIC is as an approximately drop-in
replacement for H2. I would like the focus to be on succeeding there first
before attempting to build an overly generic transport protocol. Which
leads me to ...

3. QUIC is not the last transport that will be built. Not to speak of
future versions of QUIC itself. Part of the allure of moving transport to
user space, to me, is the ability to iterate faster. The success of H2 and
the wide interest in QUIC convinces me that protocols will evolve at a much
faster rate going forward. And that there will be enough time and
opportunities to experiment as more applications use QUIC and evolve a
different set of needs. Such experiments and implementation experience
should drive the changes, I believe. Having said that, some ideas in the PR
(like the explicit type field in stream header and the push id) are not
really tied to unidirectionality and I would like to see them absorbed into
IETF-QUIC anyway.

This is my first mail to the working group. My biggest motivation was to
reiterate on the sense of urgency. Pardon me if I flouted any rules in the
process.

Cheers,
Ranjeeth

On Sat, Jun 24, 2017 at 12:15 PM, Christian Huitema <[e-mail]>
wrote:

> Nice discussion. Seeing this design by many PR, I am afraid we will meet
> an old friend: https://en.wikipedia.org/wiki/Camel.
>
> --
> Christian Huitema
>
>