Should we transition to Open state when recv even MAX_STREAM_DATA or RST on idle

[siyengar]

While thinking about implementation of the handling of idle state, it seems like we'd practically allocate the stream state object anyway if we get a MAX_STREAM_DATA or STREAM_BLOCKED (to keep track of flow control).

It seems better then to treat these streams as equivalent to Open streams because it'd simplify the logic of deciding the Stream limit count to advertise. If the reason we want to allow this transition is to deal with lost packets, we'd practically allocate the stream data eventually when the packets are recovered.

Proposing a change where:

Idle -> Open

transition occurs not only on STREAM, but also BLOCKED, MAX_STREAM_DATA as well.

[siyengar]

This also has the nice side effect of causing the lower order streams to be opened as well.

Thinking about it a bit more, we should do this for RST on idle streams as well.

Currently if we get a RST on an idle stream, we do:
idle -----> half closed

however this means that if stream 10 is RST, we didnt really open stream 1 - 10. Then if stream 20 is opened, we would have no idea if stream 10 was opened before or rst, so we'd have to keep track of all RST streams.

seems nicer to make this more symmetric with the stream open case:

I propose that when getting a RST on an idle stream we first move it into open state and then process the RST so that we get the lower streams opened as well, i.e. if we get a rst on an idle stream, we do the following transitions:

idle ------> (open) -------> half closed

[marten-seemann]

Opening streams as soon as you hear from them (no matter in which frame type) definitely makes sense (and is what quic-go is already doing). It avoids a whole bunch of edge cases that are only needed to deal with reordered packets.

[janaiyengar]

This is a side-effect of the change to opening all lower number streams automagically. Since we're doing auto-opening, it makes sense to do this.