In writing up the unidirectional stream proposal, I concluded that this was still a valuable restriction to have. Besides, creating streams out of order in that model isn't necessary.

@martinthomson writes:

In writing up the unidirectional stream proposal, I concluded that this was still a valuable restriction to have.

Why?

The same reason it is valuable now, but more so. The strict ordering restriction ensures that you can cheaply and reliably determine whether a stream is idle, open, or closed. Open streams need a bunch of state. If that state exists, the stream is open. Idle streams are those that don't have state and have higher numbers than all open streams. Closed streams are those that don't have state and have a lower number than any open stream.

Also, the only reason that you might want to open out of order is if you attached some sort of semantic to the stream ID. I think doing that is a mistake.

Could this "sequential" wording be made more precise? Is it OK to open stream 100, then 200, then 400, or should it be 100, 102, 104, ...

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.

The strict ordering restriction ensures that you can cheaply and reliably determine whether a stream is idle, open, or closed.

I do not see how that is possible. Here is an example: server receives a request that opens stream 11, yet the largest peer-initiated stream it knows about is 7. Does it mean that a) client skipped stream 9 -- and thus is in violation of protocol -- or b) previous packet got lost?

Also, the only reason that you might want to open out of order is if you attached some sort of semantic to the stream ID.

Not necessarily. One can imagine a scenario in which a multi-threaded program keeps a pool of stream IDs that could be opened and distributes these IDs among threads. The threads perform some preliminary work -- streams are opened in the same order that these threads complete.

There are probably other reasons why an implementation may want to be able to control the order in which streams are created.

I would agree that this is still valuable. Unless there is an extremely compelling reason to remove the restriction(which I don't believe we have), we should keep it.

@ianswett writes:

I would agree that this is still valuable.

Why?

I'm hearing the argument for keeping this restriction, which is that it allows for a simpler implementation. It doesn't break the protocol if the sender doesn't open streams sequentially. Together, these seem to suggest that we should keep this restriction, but make it a SHOULD from a MUST.

@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.

@janaiyengar, @mikkelfj -- could you please elaborate on the simplification part?

I think I can partially explain it. Each stream for which you're tracking state consumes some memory. You can elide out large chunks by saying that:

• Lowest idle stream ID is X
• Of streams < X, any stream not in my state table is closed
• Table contains any idle or open streams < X

If an implementation is implementing tracking in this way, the arrival of stream 200 when X=100 means inserting 100,102,...,198 into the table as idle, then 200 as open. By mandating that they be used in order, even if reordering occurs, you are less likely to do large chunks of this work at a time (you might get 108 when X=100, but not 200) and if you do have to do a large chunk of work the work is still timely because you know all those streams have data in-flight so you would have been doing the work in a few packets anyway.

@MikeBishop, I see -- thank you for the explanation. @martinthomson must have been also alluding to this
when he wrote that "open streams need a bunch of state." The draft says that

opening a stream causes all lower-numbered streams in the same direction to become open.

Now I disagree with arguments for mandating stream creation order on two counts -- implementation and protocol specification.

I. Implementation.

The way to track open streams that you describe is suboptimal. The assertion that "open streams need a bunch of state" is not true: this is because stream transition from idle to open states can be treated in a purely conceptual fashion. Real stream state -- that is, some data structures and linkages -- does not have to be allocated until the first frame received for that stream. This is how we chose to implement it at LiteSpeed, guided by a sort of rule of thumb "delay doing work until you have to."

As a side note, doing a large chunk of work to allocate stream resources is not always timely: consider the case when a connection is closed shortly after this chunk of work is performed. This is more likely to occur than not in this situation, as a large hole in the sequence of incoming stream IDs may be a symptom of network issues.

II. Protocol Specification

A protocol should strive to be simpler rather than more complex. If something is not required by the protocol itself -- which the order of stream creation is not -- it does not belong in the specification. The protocol specification should not be a place where the way to implement something is mandated. This may prevent a clever implementer from employing some optimization mechanism that the protocol authors had not thought about.

Your implementation point there seems to motivate the opposite. As Mike said, receiving stream X might open stream X-2, but the receiver doesn't have to do anything at that point.

Here's a different way to think about this: why do you want to open streams out of order?

@martinthomson, my point was that an efficient stream-tracking logic is not difficult achieve even in the face of out-of-order stream creation. Let the implementer figure out what to do, not mandate how to do it.

I do not want to create streams out of order -- HTTP over QUIC does not require it. Nevertheless, I think that the scenario I described above is plausible -- why put in constraints that would make in infeasible?