Re: Implicitly opened streams and exposing stream IDs

Dmitri Tikhonov <> Tue, 03 April 2018 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BF5B124D68 for <>; Tue, 3 Apr 2018 07:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 C6pfzsNeAXAX for <>; Tue, 3 Apr 2018 07:27:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64A861271DF for <>; Tue, 3 Apr 2018 07:27:39 -0700 (PDT)
Received: by with SMTP id o205so18789242qke.3 for <>; Tue, 03 Apr 2018 07:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=1EBfzUGuWRqG1nFng7x+cFvQov3i0NhLISogVYOqYTc=; b=Cbdnb9dOsWYah2qSDW9i3fz5zLvSJmVRb9506I32xdXUiuvYS9wrmMPZg1sm6Y0yXa PFYr287K5waDA8eUawaFKvU11Gj/Q4p+/TMErW6/BtTwinLvIfKHKQK0Z4rYRxRynENF /j15a9L0W1dkoJgbSEsn3b/epCIMyWhVBNCjee+4yoOC9wV9aSbS0apCUyr2kDAyW0Un Ylf0Zulh+dENo+Aib5BkRAJMcBQ7Dudnhfd63wDBFq5YasuXUbkKEnTZ4zrNYYMdsvxU 6wjcneg43G3TZRnG++IPTvS4VW+i8FPVXkr5+1V3ZWWChuexZdn5xp9oG9mEVwsRf78x icaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=1EBfzUGuWRqG1nFng7x+cFvQov3i0NhLISogVYOqYTc=; b=TgIgTxRjHz+hNPjdaTnRNUKzxAWKZnFTQlDVMBvnWyzarHtBLftG2vWRQ8M/M89jSo Hb4LcxbTEvNvO01M95mPfB359tLtxplmkgz5Hl8z7ys6oIqRnseRVZUH5baEM/hBE0ZV 1Kot8EIyGth6z3RhNY0uJWKvqufyJnG2gCyEe5vgRWdsSTt2flamlQ2/spu9jnFNKmr5 XGhZnCaGxn3QyQP5XTh3cxtuqcGMqGOg5yoa60LyI/+jBYrzu8S8b7PYw3y3DrX6iH/G /1IlIXaIi7Uw4fs2+ZSp5TwHSUOhv1BgNOiVsNCrvQFBgxiTH2qlLIHzYKBWrwdQaCvv MY7g==
X-Gm-Message-State: ALQs6tCt495RQIwdDTM037OXxA9Zjasg3c7QTgfTMZtM2t6Q4KHV2iJz 4uXe32380nSIXB3kq2Ps6DAbLQ==
X-Google-Smtp-Source: AIpwx4+hzNhYInRuD8y0SX9YefzBMcpMALx7YTaBdUuyPDLDw3pjJQ49m7lKVLxRvSlug9VqC+1RzQ==
X-Received: by with SMTP id s65mr17885994qkf.177.1522765658560; Tue, 03 Apr 2018 07:27:38 -0700 (PDT)
Received: from ubuntu-dmitri ( []) by with ESMTPSA id g14sm2421988qtk.71.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 07:27:38 -0700 (PDT)
Date: Tue, 03 Apr 2018 10:27:36 -0400
From: Dmitri Tikhonov <>
To: Mikkel Fahnøe Jørgensen <>
Cc: Martin Thomson <>, Marten Seemann <>, Lucas Pardue <>, QUIC WG <>
Subject: Re: Implicitly opened streams and exposing stream IDs
Message-ID: <20180403142736.GG1695@ubuntu-dmitri>
Mail-Followup-To: Mikkel Fahnøe Jørgensen <>, Martin Thomson <>, Marten Seemann <>, Lucas Pardue <>, QUIC WG <>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
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 14:27:42 -0000

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

  - Dmitri.