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

[Dmitri Tikhonov <[e-mail]>]

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

-- 
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-332707015