RE: Unidirectional streams PR

[Lucas Pardue <[e-mail]>]

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