Re: Unidirectional streams PR

[Wenbo Zhu <[e-mail]>]

My personal opinions.

1) is much harder to add later. QUIC will definitely be used by non-RPC
protocols.

It would be useful to see a concrete example on how to map something like
HTTP request/response to QUIC uni-streams. Could Mike publish two reference
versions, before/after the PR is Incorporated to the HTTP mapping spec?

Most L7 (application) protocols will keep using HTTP/* as the transport.
Other L7 protocols will have their own state machines on top of the QUIC
streams to manage the client-server conversation, inc. flow-control. The
less state the QUIC layer maintains, the better IMO unless other
transport-level features may benefit from the bidi model. I don't have any
specific feature in mind.




On Thu, Jun 22, 2017 at 9:16 AM, Ian Swett <[e-mail]> wrote:

> 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
>>>
>>
>>
>