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

Kazuho Oku <> Mon, 15 April 2019 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E491512032F for <>; Sun, 14 Apr 2019 20:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.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_HI=-5, 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 vjQr8dqZi1Nz for <>; Sun, 14 Apr 2019 20:27:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2522F12032A for <>; Sun, 14 Apr 2019 20:27:32 -0700 (PDT)
Date: Sun, 14 Apr 2019 20:27:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1555298850; bh=8Iilg0mPW6D2/qC+9uNGFR2WYXOhabe7iDdjEgswZoE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZqO7Tdv28Edf9xHJP/Nwk+5DgxDmQwbSQIDWrwfgoScj+cVaAy/4pCh4Mf3E2inlW 4Gjt1kFNA21lOTBHgg4BMBmhKjpktPkwR3s5OH8nBrwhg9w3X8MAbD5hjZxv4T99OP 9BvtOyZBlCLTxLjXz+b8FtdMW8qmctDZBmnIPtZA=
From: Kazuho Oku <>
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_5cb3fa22c5392_37a93faabc0d45c0650959"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
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: Mon, 15 Apr 2019 03:27:34 -0000

kazuho 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
+possibility of this situation occuring, both clients and servers SHOULD send a
+value of three or greater for the QUIC transport parameter
+`initial_max_uni_streams`, and a value of eight or greater for the QUIC
+transport `initial_max_stream_data_uni`.

While I understand the motivation to suggest something for `initial_max_stream_data_uni`, 8 bytes sounds strangely small.

I'd argue that we should recommend a value that is greater than the size of SETTINGS frames that most endpoints would send. Also, considering the fact that QUIC endpoint needs to be capable of processing at least one full-sized packet at a time, I do not think that even the most restricted endpoints would set `initial_max_stream_data_uni` below one MTU.

Therefore, I might propose something like "SHOULD be at least 1,024 bytes."

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