Re: [quicwg/base-drafts] Stream creation order (#634)

[MikkelFJ <[e-mail]>]

stream frame simplification - it’s been a while since I had time to work on
my implementation so it is from rough memory, and - I haven’t read the full
discussion in this thread - so please bear with me:

Once a stream state closes there is a period where you still have to accept
incoming stream frames for the pariticular stream id. This might be
retransmission of stream data in reverse direction stream data or stream
control frames with flow control etc. Those frames may be silently
discarded or handled as per protocol. After a while those frames should be
considered a serious error resulting in connection termination because
clearly the peer isn’t paying attention.

The simplest way to handle this is to track a lower bound on stream ID. For
this reason it is also really important that “sequential”   means next
higher value and not just an arbitrary higher number (I made a comment on
some issue asking for clarification on this).

If stream ID's are unordered, it is necessary to keep track of all recently
active streams. The rate of new streams can be high, and the lifetime low,
so the dictionary can potentially hold millions of streams.

Another concern is new streams. These must be rejected if they have already
been closed. For unordered streams this is intractable because you need to
keep a dictionary holding billions of random stream id.

OTOH - if unordered streams are permitted AND it is permitted to reuse
stream ID’s after a while (past grace period of pending stream frames),
then stream IDs can be used for context, such as file id on a host.This
still requires a dictionary of all recently closed streams, but it is not
intractable.

Further, ordereded stream ID’s are significant when using unidirectional
partial reliable streams where each part of a virtual stream (message) is a
new stream ID. Here ordering of stream IDs provide the necessary sequencing
- of course a protocol is free to impose this constraint, and it doesn’t
affect transport.


If streams move to unidirectional only, this changes a lot because you only
need to keep the lower level ack logic and the stream context can be closed
immediately after sending FIN or RST. I strongly recommend moving to
unidirectional only.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 27 September 2017 at 22.09.57, Dmitri Tikhonov ([e-mail])
wrote:

@mikkelfj <https://github.com/mikkelfj> writes:

It matters because you have a period where you still accept stream frames
before considering them an error - and if there are holes in the stream
range it might confuse the logic determing this.

Which stream frames do you mean? If stream frames for the streams that are
in the "hole," then I do not see where the confusion would be: A stream
frame for a stream that is not yet open opens that stream. If the stream
count goes over the limit, a connection error is flagged and the connection
is aborted.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/634#issuecomment-332640629>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALzN2pXkXrsiGrJ9qMIbn2DEKtRaKaLks5smquVgaJpZM4N73Yh>
.


-- 
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/issues/634#issuecomment-332746949