Re: Unidirectional streams PR

[Ian Swett <[e-mail]>]

This proposal does two things, which I don't believe need to be conflated:
 1) Adds support for unidirectional streams
 2) Removes support for bidirectional streams

I want better support in QUIC for unidirectional streams, for the reasons
laid out above and quite a few others(ie: RTP).  I believe this was the
original motivation behind this proposal, but after thinking about it a lot
and looking at the PR, I think removing support for bidirectional streams
is a huge error, because it just moves work from the transport layer to
each application layer.  I agree with Ted, that we should support both, and
I believe there are simple ways to support both, so I'll send out a PR that
proposes one later today.

If it's easy in QUIC to open a stream in either bidirectional or
unidirectional mode, then it should be easy and efficient to map virtually
every existing application written for TCP or UDP onto QUIC.  The extra
text in the RFC and extra code to support bidirectional streams vs
unidirectional is quite small.

As evidence that this doesn't result in a net simplification, even if we
only care about HTTP over QUIC, the PR adds 212 lines of text.  I'm sure
that could be minimized some, but I think it's going to be very difficult
to end up with a pure unidirectional design that's simpler than one which
supports both unidirectional and bidirectional streams.

On Thu, Jun 22, 2017 at 10:32 AM, Jo Kulik <[e-mail]> wrote:

> This sounds somewhat like a library/framework developer’s dilemma. How
>> much “hand holding” should the transport do for the applications atop (the
>> number of which is unbounded?). Sometimes providing too much
>> “implementation” works counter to the specific neefd of the application.
>> Therefore, would it suffice to describe the design pattern in the
>> transport, perhaps in terms of considerations that an application mapping
>> should make?
>
>
> I think this is an interesting idea.
>
> I'm personally in favor of the unidirectional streams proposal.  (Emphasis
> on personally, this is not some institutional opinion).  But this is
> because I have previous experience with non-request-response protocols, and
> I think they fit awkwardly over a conventional request-response-modelled
> transport.  If there's a chance that some very simple changes could make
> QUIC more viable for those protocols, then I think it's worth at least
> discussing.
>
> I feel cautious about the, "Our current goal is HTTP, design for the
> common case" argument.  HTTP is the first goal.  But it's not the only
> goal, is it?
>
> To Jana's point about not designing a hammer with no specific nail to
> speak of, gosh it would be helpful if we had, ideally more than one,
> non-HTTP protocol in mind that we could discuss concretely.  I know that
> Martin mentioned a few on his interim group slides.  But I have no idea
> whether there were any stakeholders who are planning to invest in those
> protocols.  It would be helpful, when examining the costs/benefit to say,
> "This is how this protocol fits over the current model, and this is how
> this protocol would fit over the unidirectional model."
>
> Right now, the only concrete protocols that we're discussing are H2 and
> maybe DNS, is that connect?
>
> On Thu, Jun 22, 2017 at 6:58 AM, Lucas Pardue <[e-mail]>
> wrote:
>
>> We are interested in unidirectional streams and like the concept, I have
>> reviewed the PR and made some editorial or nit comments.
>>
>>
>>
>> This is a really interesting discussion, which I don’t have much to add
>> to at the moment. To add a spectators opinion
>>
>>
>>
>> On Wed, Jun 21, 2017 Jana Iyengar wrote:
>>
>>
>>
>> > Creating a new identifier in every application to correlate
>> request/response pairs adds complexity when you start adding applications.
>> Every app has to now explicitly design and implement this incredibly common
>> design pattern. Building common design patterns into the transport _is_ the
>> role of the transport. Otherwise, we could be building HTTP directly over
>> UDP, with no QUIC in the middle. The correlator is a feature, and one that
>> is required even in your design (although you have it in HTTP). I don't see
>> how it introduces HoL blocking, but I don't want to rathole on a minor
>> point.
>>
>>
>>
>> This sounds somewhat like a library/framework developer’s dilemma. How
>> much “hand holding” should the transport do for the applications atop (the
>> number of which is unbounded?). Sometimes providing too much
>> “implementation” works counter to the specific neefd of the application.
>> Therefore, would it suffice to describe the design pattern in the
>> transport, perhaps in terms of considerations that an application mapping
>> should make?
>>
>>
>>
>> Regards
>>
>> Lucas
>>
>
>