Re: [quicwg/base-drafts] Don't recommend 3 RTTs of credit (and other editorial) (#3301)

ianswett <notifications@github.com> Tue, 17 December 2019 17:12 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 65EBE120B80 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 09:12:50 -0800 (PST)
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 axxJ4qxsueEm for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 09:12:48 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D76120B79 for <quic-issues@ietf.org>; Tue, 17 Dec 2019 09:12:48 -0800 (PST)
Date: Tue, 17 Dec 2019 09:12:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576602767; bh=DXF48+i6aIqAAtgqSzbmMPdLzhAEF2vOJ60p01hA2x0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=07F8UONNQ/bdZgHSFIovZxlSkk539d+J9yDObGUi3kRKbIQ/1cPiGlVWuz4K7Xlsd j9iAEIeJAJ32PyFoQ93IR+UX/mIRJzdIFdJEElSdft/tolwDXiqTnu3qYqMZLpRUox ayR3xkVMjUjNWOvNp96M39I5VhG80C0902Qqt918=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3S6PSBZ2JWWGL3OHV4AY7Q7EVBNHHCADX3MM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3301/review/333436130@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3301@github.com>
References: <quicwg/base-drafts/pull/3301@github.com>
Subject: Re: [quicwg/base-drafts] Don't recommend 3 RTTs of credit (and other editorial) (#3301)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df90c8f213d0_19f3f9c932cd96c1624a"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/hDSJOVg0RRHjvsLSDifoibecz5A>
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: Tue, 17 Dec 2019 17:12:50 -0000

ianswett commented on this pull request.

Some editorial suggestions

> @@ -801,33 +801,41 @@ limit is increased.
 
 ## Flow Credit Increments {#fc-credit}
 
-This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a

```suggestion
sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so means a sender will
```

> @@ -801,33 +801,41 @@ limit is increased.
 
 ## Flow Credit Increments {#fc-credit}
 
-This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to

```suggestion
be blocked for the rest of the connection if the peer chooses not to
```

> -This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these

```suggestion
send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
```

> +and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
+multiple times within a round trip or send it early enough to allow for recovery
+from potential loss.

```suggestion
from loss of the frame.
```

> -resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the

```suggestion
connection. To avoid blocking a sender,
```

> -advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame

```suggestion
a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
```

> +sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
+multiple times within a round trip or send it early enough to allow for recovery
+from potential loss.
+
+Control frames contribute to connection overhead. Therefore, frequently sending
+MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable.  At the
+same time, larger increments to limits are necessary to avoid blocking if

I'd switch this around, ie:
"At the same time, less frequent updates require larger increments to the limits to avoid blocking."

-- 
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/3301#pullrequestreview-333436130