Re: QUIC stream limits exposure to application mapping

Ian Swett <> Tue, 19 May 2020 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D8C03A0863 for <>; Tue, 19 May 2020 11:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Yb4LJa2FIXXp for <>; Tue, 19 May 2020 11:24:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 089F13A09EC for <>; Tue, 19 May 2020 11:24:56 -0700 (PDT)
Received: by with SMTP id e1so493359wrt.5 for <>; Tue, 19 May 2020 11:24:56 -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=KZzDKDJvyZUSfVXx9I52Hp988vOrJZqbMZ+6DL6exh8=; b=LRPME15Xr5MVkllY/VGCyoOtC2P3oFbgtmqjF2hlHL9nH2B68/Xa6iQjluDfaadEop My8DG1O4z7fQgs+eLxa5KcrbmGV+3JKAVcmETetqXBk3CJY+ROyszcrx7qwRIJC3BB+q 8c7clQyXc3S+AndM3ZvR8oI9q9lUF2EZkiOeainey8eMQSxOlto0GqI+/2WRPwX1R7f5 /ze3Tfg4nGbgYMoy0yPXdZ6SEPojbEpB4H9yioVek8otDSW2yZYPQsRxKUKXTZeYCmTW HfrooCuvzg4SCvyxMRW6YBjWDXtpeTTQx/7EylcRb+32ww3LsPcoV6oUFC7hg/PveeBT PrrA==
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=KZzDKDJvyZUSfVXx9I52Hp988vOrJZqbMZ+6DL6exh8=; b=eqZA4I66JKiSGoqiy0BCXnz3NvkcOPxHB7vCIpBV5rHUr0jlBrIG9YzFzg0PL+wWN+ TfSq2DfMfHIgwILw7Yvcofg7/FOuVB6wlA5vZkiFhljXhfLkN6GLv4AgvDc2KhnRo4wA LCJOS9R8Ul3eb4wxQ68KNKnSiqOnembtvTzZt7w/SINrxRlloT2w/bs/FW2WwoREwCDL 378kVzCige6v0d5sc6K14K7A474H6xOOwbIbiU+Ho7L30vYhav5CHzWKJfQ0BOgfIZbz uiAs62L6dvjQ+G1W6xDQmnpqfhuOirc+upU7OIGaFGiUR6fKeABCtKPvK5+F1wmpNdDP Rz7A==
X-Gm-Message-State: AOAM530Evqp6AwqI1LZohiWrCB3A6mWlu4VtHuzmdVE5z5glODwC//+O bXWJfX4bIsGTC+BAi2Y5vi4hp6QcnYk6NDg9cPGKGw==
X-Google-Smtp-Source: ABdhPJy8rH8P4GUVBNruOEQxgL/tEoNRVldNB5MkA1EHkKVoWclPcnsZRpyLWvuMg2sqkTXwD99GdpJHDun7iH/p1YA=
X-Received: by 2002:a5d:67cb:: with SMTP id n11mr180551wrw.275.1589912695231; Tue, 19 May 2020 11:24:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Tue, 19 May 2020 14:24:41 -0400
Message-ID: <>
Subject: Re: QUIC stream limits exposure to application mapping
To: Martin Duke <>
Cc: Lucas Pardue <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000006cc7ff05a604650f"
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 18:25:01 -0000

Chrome exposes the maximum number of uni or bidi streams we've allowed the
peer to open so far(as indicated by MAX_STREAMS, code
so we do some conversion to determine the largest stream ID.

This question is somewhat similar to the question of whether HTTP/3
GOAWAY should reference a transport stream ID, and in that case we decided
it was ok(#3273 <>)

On Tue, May 19, 2020 at 1:52 PM Martin Duke <> wrote:

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