Re: [quicwg/base-drafts] Unidirectional Streams (#643)

[MikkelFJ <[e-mail]>]

I can't speak for HTTP/2 that I have not studied in detail, but I believe this is a very significant improvement for the transport layer.

As mentioned above, DISINTEREST (#171) or some other mechanism for receiver to cancel is needed, and because it can cause some race conditions on stream state, I think it would be good to consider in more detail before settling on a unidirectional solution.

I am concerned about the STREAM_BLOCKED being able to force the receivers stream in open state if it is above the stream limit, or did I miss something. I know it is also there to hint at a need for more streams, but I think that should be an application level issue. Regardless - if naively implemented, a transmitter could force a lot of undesired resource usage at receiver by allocating stream state. I suggest that any stream related transmission above MAX_STREAM_LIMIT is a fatal error.

As to MAX_STREAM_LIMIT - this was a great improvement to avoid race conditions in the bi-directional design, and I do immediately suggest removing it. However, I think it might be worthwhile to consider alternatives for a better insight into the problem. For example: assume that we do not require incremental stream identifiers: there is no internal gain in incremental order such as keeping a simple stream table because old streams can randomly linger (e.g. stream 0), so open streams must be tracked via a map anyway. With a unidirectional design there is no ambigouty of the senders view of how many streams are at most open at the receiving end. It is the difference between received ACKS for RST_STREAM and FIN STREAMS and streams placed in senders open state.

Unless there is a flaw in the above argument, this suggests that streams can be opened with arbitrary identifiers. If we permit that, applications could use their own identifiers. However, it becomes intractable to make sure that a stream identifier is not being reused. Thus, the next question is: is it a problem to reuse stream identifiers once they have been closed? A sender cannot start reusing the stream before receiving an ACK for RST_STREAM or FIN STREAM of the old version of the stream and in this case the receiver cannot have many doubts about a new stream arriving being new. However, there may still be spurious retransmissions. This can be managed by looking at packet numbers but requires to remember the packet number of a closed stream, which is complicated.

Thus, I believe the MAX_STREAM_LIMIT is still the simplest approach.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/643#issuecomment-309673734