Re: QUIC stream limits exposure to application mapping

Martin Duke <> Tue, 19 May 2020 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E02713A0F8C for <>; Tue, 19 May 2020 10:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 MUVSkh9L5y1B for <>; Tue, 19 May 2020 10:52:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E99B3A0F90 for <>; Tue, 19 May 2020 10:52:37 -0700 (PDT)
Received: by with SMTP id b71so239917ilg.8 for <>; Tue, 19 May 2020 10:52:37 -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 :cc; bh=iS9bmCOOI4xkDCs82fb2fI/6z/mlCECZXExcYm1fthM=; b=fwtOAII9T10G21dgYxwkFgva96w4HZegrArvMItWMKtOcmxuNk0bbWrG1BX/MaxQb7 c3U4zDasU94N9KiSMQPmuxEqZcfvJROMZzaYH73/k++lD9UL8hhQgUvfOEzPQXtlXG2F bgeMSwl4pn4qESzALjHKsmhYL3EL47t7wexkYOCb1aVjKuiNS6BxiUx2Nt9a3en0Obsx Y+w8W0wxBAfP4nK5HvbwKiiqy7dYFog2nNo2DxDc3qpp3PQ6MEYTPkO+zREfR1M2hNTp ZLqGdsRxdqUiX02O/cY9jVIvB3jO+IH1sgRnDwGC4W0CMimhbnY3LMHOdpP7IO4mJbX7 RQ0A==
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:cc; bh=iS9bmCOOI4xkDCs82fb2fI/6z/mlCECZXExcYm1fthM=; b=Qd9Z2PD7CSFEYyTsG1XGZNAcTYRHaM912j/tZKCYlHcFbrYLgFDyl0dZlYo+Hegsat CKrg4hFu2eEJTdMO4yUsPOYXpAJIq0Pk5UZjhY6xtCBWbdCW0rC083jyR3LI5VvvFrft 5GjNFSks4FgmxM9kA7Ss2bI1xRWekxb26r7gJO3ozgIOoYEBgmF1jSrecPntMsnHUG0C O9j0aPZ9vsXVWcJ3kFIMORUFK0nOeBorBv2Qs1wB9XCbBplKXOomw0kTAkbdJys/l0WM eaGnLpn6goWpsK+J3lGAjUWH27KTHM7rVeBGNVppyZWZxzDLlckF6KmUYm2aEkKFPShH lP3w==
X-Gm-Message-State: AOAM5306os2V03syIAivyc+GChBHfM2etQAHPC3h17WmHJNbi7Kb2I29 MicZtz/PTGkPI/fRhTfqTpmTigB4SNjcdRA0zsg=
X-Google-Smtp-Source: ABdhPJyR6+5vurI7UIE6Hwb6rZQhjef47DPxHMZYlU7zWQiw8K9r2HVkI8bw5+nv7sNOX4jZdutfOF2Qresw/fHnlic=
X-Received: by 2002:a05:6e02:965:: with SMTP id q5mr174409ilt.272.1589910756595; Tue, 19 May 2020 10:52:36 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Martin Duke <>
Date: Tue, 19 May 2020 10:52:25 -0700
Message-ID: <>
Subject: Re: QUIC stream limits exposure to application mapping
To: Lucas Pardue <>
Cc: QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000df1e1805a603f1e4"
Archived-At: <>
X-Mailman-Version: 2.1.29
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, 19 May 2020 17:52:39 -0000

We (F5) expose the max_stream_id for each type to the application. We also
have a stop_allowing_streams() API to enable things like GOAWAY.

IMO that's superior to buffering stream requests QUIC can't immediately
fulfill, or making the application poll again and again until QUIC accepts
a new stream request.

On Tue, May 19, 2020 at 10:17 AM Lucas Pardue <>

> Hello folks,
> During the HTTP interim meeting today [1] we came to talk a bit about QUIC
> stream ID limits and how implementations might or might not expose this
> property of the transport layer to an application mapping layer.
> To abstract the technical discussion: we have an application-mapping
> message that can be sent on a stream and it contains a reference to a
> different stream by ID. In order to bound resource usage there is the
> requirement "if the *other* stream ID exceeds the stream ID limit, receiver
> MUST close the connection".
> To implement the above requires the application mapping to have access to
> the transport's maximum stream ID. This makes assumption about how
> implementations do things and rightfully has been questioned.
> HTTP/3 describes some resource usage considerations but makes it clear
> that QUIC is responsible for managing a connection's concurrency. There is
> an expectation that HTTP/3 can ask the transport to manage a concurrency
> limit on it's behalf, but that otherwise it need no further input or
> feedback.
> I'd like to understand what implementations actually do in practice, and
> solicit the arguments against exposing the stream ID limits. I think this
> could be useful for other application mapping documents that need to work
> with transport primitives.
> Cheers
> Lucas
> [1] Specifically, we were talking about HTTP/3 priorities and the
> PRIORITY_UPDATE frame whic is sent on a Control stream and references
> Request streams by ID.