Re: Implicitly opened streams and exposing stream IDs

[Ian Swett <[e-mail]>]

I don't like implicitly opened streams, for the reasons above and I'd
prefer to avoid relying on implicit anything in QUIC.  However, I hadn't
considered ordering of stream opening as a way to avoid exposing stream
id.  It's interesting, though I think it's probably easier to just expose
Stream ID.

On Tue, Apr 3, 2018 at 10:07 AM Dmitri Tikhonov <[e-mail]>
wrote:

> On Tue, Apr 03, 2018 at 02:02:28PM +0000, Nick Banks wrote:
> > For implicit opening, you only need to track the following, and you
> > know the state of all stream IDs:
> >
> >  - Set of all currently opened stream objects
> >  - Largest stream ID ever opened
> >
> > For explicit opening, since the streams below the largest stream ID
> > ever opened, may never have been opened, you need to additionally
> > track the stream IDs that have been closed (or inversely the set of
> > stream IDs that have ever been opened).
>

As discussed on the issue, the tracking data structure is the same, but the
state of the stream is slightly different.  In one case, you have a marker
for 'not yet open'(maybe a null as the value in your hashmap) and in the
other case it's open and writable.

To avoid allocating a large amount of memory with a small number of bytes,
one may want to not create a stream object until it's actually needed.
That would prevent writing, but as we've said, it's not necessary
implementations support writing on implicitly opened streams.

Chrome does this today with stream tracking, see:
https://cs.chromium.org/chromium/src/net/quic/core/quic_session.cc?sq=package:chromium&l=845


>
> Ah yes, that's true -- I remember adding this code now.
>
> The tracking is simpler with implicit stream opening.
>
>   - Dmitri.
>
>