Re: [quicwg/base-drafts] Define terms for application actions (#2857)

Lucas Pardue <notifications@github.com> Sat, 29 June 2019 13:47 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9493B1200DF for <quic-issues@ietfa.amsl.com>; Sat, 29 Jun 2019 06:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADYqqDVWmmo9 for <quic-issues@ietfa.amsl.com>; Sat, 29 Jun 2019 06:47:42 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108FB12006A for <quic-issues@ietf.org>; Sat, 29 Jun 2019 06:47:42 -0700 (PDT)
Date: Sat, 29 Jun 2019 06:47:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561816060; bh=uT5jFUdwYxh9uHy7i2OdpFmEer0t7cMfd40dGGymODU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FTUG1rp7YVNdYSAckBfuK7h06yaa844jIvG63r0xHE/btfNUsBFffIkv3rYsSUjso hq3WLxNQvylVu3hwsWla9ipt5xp9aiNiCSkjGJFebjDP1pJEzUtRml6HuP2CeJYnxP VOl+HDlRaz7pL8mZ1b4Gp7BJrmsZ0bp3KxAVuTvA=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5UGOIWH5KW6UKM4IN3ESPHZEVBNHHBXBSRPY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2857/review/256037561@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2857@github.com>
References: <quicwg/base-drafts/pull/2857@github.com>
Subject: Re: [quicwg/base-drafts] Define terms for application actions (#2857)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d176bfcc5f18_10b23fbc5b6cd96c25869"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/I8s8bfb1Raxzcy5fFQa96SDDe3s>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jun 2019 13:47:55 -0000

LPardue commented on this pull request.



> @@ -962,18 +960,16 @@ see {{extensions}} for more details.
 
 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 and becomes blocked. In
-particular, the value chosen for `initial_max_uni_streams` should consider that
-remote peers may wish to exercise reserved stream behavior ({{stream-grease}}).
-To avoid blocking, both clients and servers MUST allow the peer to create at
-least one unidirectional stream for the HTTP control stream plus the number of
-unidirectional streams required by mandatory extensions (such as QPACK) by
-setting an appropriate value for the QUIC transport parameter
-`initial_max_uni_streams` (three being the minimum value required for the base
-HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 or greater for the
-QUIC transport parameter `initial_max_stream_data_uni`.
+Endpoints that excessively restrict the number or flow control window of these

This reads weird to me, my brain keeps thinking "or" is a typo for "of", which is untrue. I think it could read better to say

"Endpoints that excessively restrict the number of these streams or the size of each stream's flow control window will increase the chance that the remote peer reaches the limit early and becomes blocked." 

> -least one unidirectional stream for the HTTP control stream plus the number of
-unidirectional streams required by mandatory extensions (such as QPACK) by
-setting an appropriate value for the QUIC transport parameter
-`initial_max_uni_streams` (three being the minimum value required for the base
-HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 or greater for the
-QUIC transport parameter `initial_max_stream_data_uni`.
+Endpoints that excessively restrict the number or flow control window of these
+streams will increase the chance that the remote peer reaches the limit early
+and becomes blocked. In particular, implementations should consider that remote
+peers may wish to exercise reserved stream behavior ({{stream-grease}}) with
+some of the unidirectional streams they are permitted to use. To avoid blocking,
+both clients and servers MUST allow the peer to create at least one
+unidirectional stream for the HTTP control stream plus the number of
+unidirectional streams required by mandatory extensions (three being the minimum
+number required for the base HTTP/3 protocol and QPACK), and SHOULD provide at
+least 1,024 bytes of flow control credit to each stream.

observation: the change to remove references to Transport Parameters in this paragraph could lead to some interesting unintended issues. Previously it was clear that the problems mentioned were related to small values of initial limits (imposed by TPs). One way to interpet the new text is that it is ok to advertise low values in TPs as long as you send MAX_STREAMS or MAX_STREAM_DATA.

Just wondering if that was the intent of this change, given some of the problems we've seen with these values during interop.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2857#pullrequestreview-256037561