RE: Unidirectional streams PR

[Mike Bishop <[e-mail]>]

Moot point – there is no concurrent stream limit in the protocol.  There is only a maximum stream ID, and how your implementation decides what maximum stream ID to issue to the peer allows you to choose any resolution to these questions you like.

Now, in the unidirectional or mixed designs, you do have the corner case where a client can send a request, but not give the server enough Stream IDs to respond.  (Don’t do that.)  More realistically, the server can have a limited number of Stream IDs and spend them on pushes instead of actual responses.

From: QUIC [mailto:[e-mail]] On Behalf Of Christian Huitema
Sent: Thursday, June 29, 2017 9:35 AM
To: [e-mail]
Subject: Re: Unidirectional streams PR


On 6/28/2017 6:23 PM, Ian Swett wrote:
I updated my PR(#656<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F656&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C50b7c91a6bf441d6674d08d4bf0cd498%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636343509210959657&sdata=zdHHgc1IfzdwEWFQCPIk%2B7iufCR1jzJ9eHtqXx9Bak0%3D&reserved=0>) today, sorry for the delay.  I attempted to address the issues identified with text.  Some may prefer more tweaks to the state diagram, which are also possible, so I'm open to suggestions.

In the meantime, I've been considering other alternatives, including variations on Mike's direction and a variation of the "Do Nothing" option which involved the application signaling to the transport that streams of a certain sort(ie: server to client for server push) were unidirectional, as GQUIC does today.  Overall, I think the approach I've outlined does a good job of iterating on existing deployment experience and adding explicit signaling for unidirectional streams instead of implicit signaling at the application layer.  There are pros and cons to both explicit and implicit signaling, but I think explicit signaling is more complete and less prone to application error.


I understand how to handle concurrent stream limits with plain bidirectional streams or with plain unidirectional streams, but things are not so clear when we start mixing models by adding a unidirectional option to bidirectional or vice versa. In the clean models, we can count the number of streams initiated by one entity and not yet closed. But in the mixed models, what do we count, exactly?

For example, let's suppose that in an unidirectional stream model, the client creates a stream that also "implies" a stream creation in the other direction. Does this implied stream count against the server limit or the client limit?

Or vice versa. Suppose that in a bidirectional stream model the client creates a stream that is declared as actually unidirectional. And suppose that this stream is immediately closed -- a stream frame with both the FIN bit and the PR 656 UNI bit set. This stream counts against the client's number of concurrent streams, but it is immediately closed by both parties. Does it count as zero?
--

Christian Huitema