RE: Unidirectional streams PR

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

Yes, getting rid of implicitly open streams can work.  To get rid of “implicit” state entirely with your design, you would need to keep UNI bit on all packets.  Otherwise, reordering of the initial STREAM and a subsequent STREAM would require the receiver to enter “implicit” state for the stream (stream is no longer idle, but one cannot assume it is bidirectional).




From: Ian Swett [mailto:[e-mail]]
Sent: Friday, June 23, 2017 4:00 PM
To: Lubashev, Igor <[e-mail]>
Cc: Mike Bishop <[e-mail]>; Ted Hardie <[e-mail]>; Patrick McManus <[e-mail]>; Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>
Subject: Re: Unidirectional streams PR

Igor,

In terms of the extra state, I believe EKR's right that this either creates a need to change some text or add another state, which I hadn't anticipated, but also isn't the end of the world.  However, Buck Krasic pointed out we can now get rid of implicitly opened streams, because we've transitioned from stream limits to max stream ID, which fixes this problem in a simple way.  See issue #662<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_662&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=gv2nW8KsHS6Lu2KcNFaw91ojaVQERu816iviQ20Vwkc&s=6kSCQxFc0DF2n1FyODQcprN8J8KATca2FHRLEm02adc&e=>.

I attempted to add text to specify that if a STREAM frame specifies UNI on one packet, it must do so on all of them, but the text wasn't written correctly, so I'll fix that in the PR.  I did consider whether to mark all STREAM frames or only the first.  In the end, I proposed to mark all of them because it's more resilient to reordering and it's easy to document and understand.  I'm certainly open to other framings.





On Fri, Jun 23, 2017 at 1:31 AM, Lubashev, Igor <[e-mail]<mailto:[e-mail]>> wrote:
Ian, I am not in love with a possibility of having UNI flag clear on some initial STREAM frames and then UNI set on subsequent STREAM frames.  The PR does not prohibit this.  I read the PR (state diagram) to require the stream to go immediately into “half-closed (local)” state on receipt of such STREAM+UNI frame.  This is a problem, since some packets from the receiver to the sender could be in flight, and absent a STREAM+FIN or RST_STREAM from the receiver, the sender cannot do flow control accounting.

It seems best if a stream is UNI or BI from birth, and that’s indicated by the initial STREAM frame only.  If STREAM frames get reordered, until the receiver receives the initial STREAM frame (Offset=0), it should consider the stream to be in “implicit” state (do accounting for max stream count and flow control but cannot send data to it).