Re: QUIC stream limits exposure to application mapping

Lucas Pardue <> Tue, 19 May 2020 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F334C3A0D32 for <>; Tue, 19 May 2020 12:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 B-ExPdOvyc8t for <>; Tue, 19 May 2020 12:33:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4C6D3A0D72 for <>; Tue, 19 May 2020 12:33:23 -0700 (PDT)
Received: by with SMTP id z72so493339wmc.2 for <>; Tue, 19 May 2020 12:33:23 -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=GvWjrLhRMGLZDJcX2zfpFgqn8/ZRc4XLY2L35NocNkY=; b=DhsXLLm3zn666QXRQ9cKbhTMPFQ3MWEeYQxK8M3BGeXGJTcqT0ZsGH09PfqReLW/o9 Q92H6GcolEcMsHdkfNxUGDHkOH6i5TQDXciepgSP8RCwCi8WWqbM7JD4xyF2n/MzJb4g Ee0VhWDncaFgfqKX3Ugpb44DSFP6MjzE3Qaro3YDRDQL5scxlY8M+KZ63NS6KfXovyhE hIJwSxD0GxdkGLsoQWOh0aQzPTyeHmKXsFXn8b5LjAH0DcqxiZlw1ooBJYhrCCDmTR0W ACkcP+LFkLgU0pUfI5rQ2ibDeffohusb9mDg4jSshzKl/9zW51L6Xvk+3loUJnNvXbrO XBqg==
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=GvWjrLhRMGLZDJcX2zfpFgqn8/ZRc4XLY2L35NocNkY=; b=tFGStlfDTnWr1S84T29VDR3drtg/Q+zgjlE9bVdNLxvwyfLMeySV4IEyViAGnaLr+v hPyUT1EcWPdv8aUaChwrTW2rLA1sQ2BAi/YaH0qlZrRO3jgjfbe1no5j6yjQgPRBJH31 9oCUOg9rgLVhpohM+VHXFv2LqZ463S1zKm0fVWkhWgok+054LDw6Bl07QLeBT5E2mgEQ TmP7U7kqx3YN9GnyH+qkUm6t+sqRvDt9T3+T3Q3AGHrZnl3nTkvmEzF+dadIVNymY/VN 95EBppvlqBWRr58YdSCCysjH4FxXMVxS0oZ+hp0Zm/1RBnsaUUyYvS6Xo0uPZ27AUvWO mXFw==
X-Gm-Message-State: AOAM533cG6T3lOf8uC+xrm4x7Xiad2yZooWMy1JlvemKffu3+5lB7H8e tgZoTYuodnsAXXJ6+TIWj3Ll80XQE4AdnM8ITgo=
X-Google-Smtp-Source: ABdhPJwybg4k59eje+Q/bgtofR8w+iArDeXQXS0XpbZIhJeiz7XWcZ3vieKrdT11z5XR1iRtoSgv1qW+JlCwmVyeINE=
X-Received: by 2002:a1c:e157:: with SMTP id y84mr944066wmg.15.1589916802200; Tue, 19 May 2020 12:33:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 19 May 2020 20:33:11 +0100
Message-ID: <>
Subject: Re: QUIC stream limits exposure to application mapping
To: Ian Swett <>
Cc: Martin Duke <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000037b94005a6055a72"
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 19:33:26 -0000

Thanks for the replies so far.

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.

Interesting. Since QUIC manages stream concurrency I hadn't before
considered the benefits of asking the transport layer to stop sending
MAX_STREAMS when the application want to scheduled closure.

On Tue, May 19, 2020 at 7:24 PM Ian Swett <> wrote:

> 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
> <;drc=2f11470d7ad8963a9add116df64d2edd1b85d3a4;bpv=1;bpt=1;l=1698?>),
> 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 <>)
Thanks for reminding me of that discussion. After the HTTP meeting I
remembered the similarities to GOAWAY. However, there are is no upper bound
on the the GOAWAY stream ID because it doesn't have the same type of
processing requirements.

Another consideration here is that an application mapping might not know
the explicit maximum stream ID but it probably knows the stream concurrency
value and the number of streams in-flight. From that it can make a pretty
well-informed guess at the limit. There's practical issues such as
receiving FIN acks etc, that affect the precision but rough approximation
is possibly close enough to protect resource usage.