Re: [quicwg/base-drafts] Add further guidance related to unidirectional stream TPs (#2612)

Lucas Pardue <> Fri, 12 April 2019 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5F961202E2 for <>; Fri, 12 Apr 2019 08:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g4_9vhzqon3a for <>; Fri, 12 Apr 2019 08:36:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDC3A12021F for <>; Fri, 12 Apr 2019 08:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=wmx3X1csNC43RNR5KRyTvKstYAQ=; b=VfQiLUFXUJ9wqihZ s0SnZ3cV0li2B20PryN8Y5PILSc/idVBG0JB6pG3wbKWND+mPu6IJS0+C/ugOAxQ TAOV7BqYFMXcvlxXTZBJmhiqykkqxLUllxvw9SvPFhtFQKZHhfwdeFX/GCQIg23y 1yi5fk9sR8BVNzvYF1Y/QF3YAEY=
Received: by with SMTP id filter0977p1las1-27460-5CB0B06C-41 2019-04-12 15:36:12.946815099 +0000 UTC m=+312328.971892846
Received: from (unknown []) by (SG) with ESMTP id 7g7zlGStTuavqRB-4fdcrw for <>; Fri, 12 Apr 2019 15:36:12.876 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id CAEC33E007C for <>; Fri, 12 Apr 2019 08:36:12 -0700 (PDT)
Date: Fri, 12 Apr 2019 15:36:13 +0000
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2612/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add further guidance related to unidirectional stream TPs (#2612)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb0b06cc8c2b_7a7b3ff72a2d45b88492b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2AEPCCx8VYZwPvzpEX+aK/NLpLDx4B3KnMMo ueh5h7hxEzh16hyhKRAYQmoUtFxQT6uwaQvYYRW/vQarNNyPPuvhMd4pPaRMtfNaUl2nN5z23xUyfw paEktZSGUOmNOVk5jH4IJy//ohOWYtezKsBPCLLnhr+UqItmovcglMnDrGKyDf6UsisqQ/7Rdbd8Yf U=
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Apr 2019 15:36:18 -0000

LPardue commented on this pull request.

> @@ -321,8 +321,19 @@ defined in this document: control streams ({{control-streams}}) and push streams
 ({{push-streams}}).  Other stream types can be defined by extensions to HTTP/3;
 see {{extensions}} for more details.
-Both clients and servers SHOULD send a value of three or greater for the QUIC
-transport parameter `initial_max_uni_streams`.
+The performance of HTTP/3 connections in the early phase of their lifetime is
+sensitive to the creation and exchange of data on unidirectional streams.
+Endpoints that set low values for the QUIC transport parameters
+`initial_max_uni_streams` and `initial_max_stream_data_uni` will increase the
+chance that the remote peer reaches the limit early. In particular, the value
+chosen for `initial_max_uni_streams` should consider that remote peers may wish
+to exercise reserved stream behaviour ({{stream-grease}}). Limits can be
+increased post handshake at the cost of additional RTT, for example by
+exchanging `STREAMS_BLOCKED` and `MAX_STREAMS` QUIC frames. To reduce the

That's a fair point. However, practically speaking, if a peer spends credit legitimately and needs more, how does it get it?

We're seeing various HTTP/3 issues around getting blocked by conservative initial values, and there is little guidance on ways to mitigate this happening. If the answer is to aggressively dole out credit, it kind of devalues having limits.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: