Re: Implicitly opened streams and exposing stream IDs

Ian Swett <> Tue, 03 April 2018 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E35712EA76 for <>; Tue, 3 Apr 2018 11:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XfYMSUGsExUq for <>; Tue, 3 Apr 2018 11:56:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 918E312EA64 for <>; Tue, 3 Apr 2018 11:56:13 -0700 (PDT)
Received: by with SMTP id l3so23298073iog.0 for <>; Tue, 03 Apr 2018 11:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0JCap35S6lRAwSMrXvIL9dSKzaxF0cXVk9CcN8e0hX8=; b=mzzfWyM0JzBwMQYqZCQZNew8WeMn5dQ3zXjXiRQGi/F22BmLY3aLedexBkT5y9y6xa 2XUn8hCJXWkDpqwt933pyOy/qsVnGmDhfm1Td3Sdqb4l5Xr4xBf2OTcxgOc4wbvtDQMp tmportfA3iNomVn7rJn97z2+CVEHH1qHgBL4CimpR++gjomT/amPReFN2y5Ze4SBlW3k 6xSPFN8n+6OmkpsSXkHp431i1AUnL4X5iy46FvO/xGVTDGzCm2DvY/a92DoofXtY5bLi P0Dy2farOtbSLmNEu56eN2ySDxHOjX8J4G1oE3uVPPXhLn5fvdm8lMcvTKS90x4P7bpi 0EUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0JCap35S6lRAwSMrXvIL9dSKzaxF0cXVk9CcN8e0hX8=; b=QWhVSzy9h3h4Q2IISATN6mkinPvWnyciLQb8geENfcM/JUqea4POFRyopEAP+UCCns K28oj6XeC8OiVRAfmIvNuLHxqslalxDb5D/dyxCoDLfUr6jlNstdzKSMIMdj5edG0hYM 411Ih4RP52rTuVbJadoQ61STsBOQSNq8w4MO53QeIpHncpoJ5wSjtc1DfKT9BfDQ0G0T a8YxS07KbIY9aj4QEslERlMKNPOaP5PjMBrsBuv5ISKnz9VQgxZt+Y4c/coaAeqq+cPP fgYgLxemluFWw56wcmJbjZqegztMWGw6k8o/dGULC0qz195ghWtibWQxBNAu3KIM/sd2 ibSg==
X-Gm-Message-State: AElRT7Fm8z8f4/tcDd/GC0FhGlMSklB7eiOzOF2gkTMr4bHjsmJTjMag ejWgRMQT0lT+TRWTahLz8IHOoyBMleQykG7CiPBonw==
X-Google-Smtp-Source: AIpwx49cDaffn+UWPuA2hH6OrZ1x6XCF2FEPrC1S30j75sQ9lKiO+cpwMiuYsapshwkrBo1fHkV7tcfefHSv7cY41sE=
X-Received: by with SMTP id v18mr14264098iog.212.1522781772629; Tue, 03 Apr 2018 11:56:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <> <> <20180403120717.GA1695@ubuntu-dmitri> <> <20180403135644.GC1695@ubuntu-dmitri> <> <20180403140712.GE1695@ubuntu-dmitri>
In-Reply-To: <20180403140712.GE1695@ubuntu-dmitri>
From: Ian Swett <>
Date: Tue, 03 Apr 2018 18:56:01 +0000
Message-ID: <>
Subject: Re: Implicitly opened streams and exposing stream IDs
To: Nick Banks <>, Martin Thomson <>, Marten Seemann <>, Lucas Pardue <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="f403043ce430a1a3220568f642a6"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Apr 2018 18:56:16 -0000

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

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

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