RE: Unidirectional streams PR

["Lubashev, Igor" <[e-mail]>]

I am worried about silent (app-directed) stream closing. This it a layering violation, since it introduces transport-layer semantics (stream state transition) that are not signaled on the wire.

Such silent stream closing would make it hard (impossible?) to write a generic QUIC proxy, for example. A generic proxy must be able to know when a stream is closed, so it can release resources. In fact, the proxy would provide a better experience, if it could also know stream priorities and other possible stream attributes explicitly.

 (The proxy may be a good idea, if you have limited devices attached to your low latency/high quality network, which is connected to the rest of the Net over high latency/low quality links. You’d deploy such a proxy, so it can maintain deep buffers, needed for communication over high latency/low quality links.)


As for Ian's Uni-bit proposal, the state machine is no more complicated than in the original spec. (You would probably want to add a Uni bit to RST_STREAM frame to keep stream directionality unambiguous at all times.)

- Igor



-----Original Message-----
From: Subodh Iyengar [[e-mail]]
Received: Friday, 30 Jun 2017, 7:14PM
To: Mikkel Fahnøe Jørgensen [[e-mail]]; [e-mail] [[e-mail]]; Christian Huitema [[e-mail]]; Mike Bishop [[e-mail]]
Subject: Re: Unidirectional streams PR

I've read through both approaches and commented on both PR with concrete issues. I would like to voice some high level thoughts as well.

I believe the purpose of the unidirectional streams exercise is two-fold: maybe reduce complexity of transport, enable applications to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that no matter what state diagram we specify in the draft, the implementation of the state machine will not match 1:1, there are always hidden states. One such concrete example is when you reset a stream you might want to discard any incoming data vs if you're in half closed you would want to process and buffer it. This creates a new hidden state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make the transport easier to implement and not so much the easier mappings of applications. We're chartered to work on HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it only needs unidirectional support for pushes. I think unidirectional streams doesn't add new functionality to HTTP/2.

However after looking at the proposals and the feedback, as a transport implementor I'm rethinking my initial draw towards purely unidirectional streams such that I might as well take up the burden to implement bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the transport to support the push use case for HTTP/2. It is kind of awkward right now that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machine, however I'm more of a fan of @Ian's do nothing + app dictates a manual transition, since that allows us to keep the same state machine flow and let the app get undirectionality by explicitly having the app transition the stream state machine as needed. There are some cool things in @Martin's proposal that I would actually like to see back in the HTTP mapping with bidi streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transition states with application coordination.

Subodh
________________________________
From: QUIC <[e-mail]> on behalf of Mikkel Fahnøe Jørgensen <[e-mail]>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: [e-mail]; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR

On 29 June 2017 at 20.40.50, Christian Huitema ([e-mail]<mailto:[e-mail]>) wrote:

I am looking at the "mixed" scenario, in which the client would open an unidirectional stream with an associated "stream N" in the other direction. Will we say that doing so automatically pushes the server's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A open a unidirectional stream A/N that can be responded to by endpoint B necessarily requires that B has granted A a limit of at least the value A/N. If the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessarily must be at or below the limit granted by A but only once those streams are in fact opened. Endpoint A might never grant sufficient streams to enable B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be associated with A/N because A/N might be closed and gone. Keeping state is problematic. On the other hand it is trivial to reject associations with streams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lower valued streams will not work, and is not needed.