Re: Implicitly opened streams and exposing stream IDs

[Dmitri Tikhonov <[e-mail]>]

On Tue, Apr 03, 2018 at 12:50:16AM -0700, Mikkel Fahnøe Jørgensen wrote:
> Opening strictly in order (whether required or not) reduces those problems,
> but it also severely constrains the application. For example you cannot
> send a stream id internally to a subsystem and ask it to produce data once
> ready to do so. You need to invent a complex mapping that is difficult to
> coordinate in a distributed system. It is much simpler to deal with the
> stream id’s directly. With multi-path you could even have multiple hosts
> managing a single connection, and if not, you could still do it with proper
> address mapping.
> 
> So implicit streams and strict opening order might simplify very simple
> problems, but also make very hard problems even harder.

+1.  Very well put.

> Also, the entire idea of linearising QUIC seems to go against the spirit of
> independent non-blocking streams.

+1.  (HoL!)

> Still, having a maximum stream ID is very useful in limiting the resources
> that must be managed.

Note that QUIC does have it -- MAX_STREAM_ID.  The in-order stream
creation is unenforceable; faking it on the receiver side introduces
head-of-line blocking.  As long as the incoming stream has ID smaller
than MAX_STREAM_ID, there is no reason not to handle the stream
immediately.

  - Dmitri.