Re: [quicwg/base-drafts] Reference RFC7661 for application limited (#2605)

Jana Iyengar <notifications@github.com> Sat, 13 April 2019 01:28 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 F1F8F1200F9 for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 18:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
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: 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 hGFC-ju5NMsz for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 18:28:43 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D1E1200FD for <quic-issues@ietf.org>; Fri, 12 Apr 2019 18:28:42 -0700 (PDT)
Date: Fri, 12 Apr 2019 18:28:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555118921; bh=Gc8t+YGbpLFvOYoyn0chsh0/bWJ/GVSMh//yqIAtyZ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NW6M2dxt4Q1u+678BvWYquCgPNR97WPFc7GDIQYiS+zj1ImLZ/TWcHdW1nOK6+iyn 8pf/otKPKXMXkrPAfyQir40A+k6bPdqsk3c8vO0QtehMMlqMpGKZ/t4xOwTkhd9fsw 3vIkQkJYqOJNckWVIRVL14Piogu9F25TCty0QGyA=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abad8eb3bb539e1cf1e6697ea523303f54a08ed86b92cebabe6dc992a169ce19bb17fa@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2605/review/226331010@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2605@github.com>
References: <quicwg/base-drafts/pull/2605@github.com>
Subject: Re: [quicwg/base-drafts] Reference RFC7661 for application limited (#2605)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb13b494e0fc_4a4d3f8bc36d45b475378"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/ljOkpbzPmt_98fK5V4eEuiA8e9I>
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, 13 Apr 2019 01:28:45 -0000

janaiyengar commented on this pull request.

Thanks for this -- I think it's the right direction. Some comments to try and herd this text some more.

>  ## Application Limited Sending
 
-The congestion window should not be increased in slow start or congestion
-avoidance when it is not fully utilized.  The congestion window could be
-under-utilized due to insufficient application data or flow control credit.
+A sender's congestion window MUST NOT increase when no packets are newly
+acknowledged, such as when the connection is idle. The congestion window

This is a strange requirement, since the specified CC only increases on receiving ACKs. This was already written earlier in other words, and I realize now that it was a strange requirement then as well. I wonder if just removing this first sentence makes sense.

>  ## Application Limited Sending
 
-The congestion window should not be increased in slow start or congestion
-avoidance when it is not fully utilized.  The congestion window could be
-under-utilized due to insufficient application data or flow control credit.
+A sender's congestion window MUST NOT increase when no packets are newly
+acknowledged, such as when the connection is idle. The congestion window
+SHOULD NOT be increased in slow start or congestion avoidance when it is not
+sufficiently utilized.  The congestion window could be under-utilized due to
+insufficient application data or flow control credit.

Editorial suggestion, after removing the first sentence: "A congestion window that is under-utilized SHOULD NOT be increased in either slow start or congestion avoidance.  This can happen due to insufficient application data or flow control credit."

I don't think saying "idle" is necessary, this text captures it in "insufficient app data", IMO.

>  ## Application Limited Sending
 
-The congestion window should not be increased in slow start or congestion
-avoidance when it is not fully utilized.  The congestion window could be
-under-utilized due to insufficient application data or flow control credit.
+A sender's congestion window MUST NOT increase when no packets are newly
+acknowledged, such as when the connection is idle. The congestion window
+SHOULD NOT be increased in slow start or congestion avoidance when it is not
+sufficiently utilized.  The congestion window could be under-utilized due to
+insufficient application data or flow control credit.
+
+A sender MAY use the pipeACK method described in section 4.3 of {{?RFC7661}}
+to determine if the congestion window is sufficiently utilized.

I'm not sure how to read this. We are saying that the sender SHOULD NOT increase the cwnd if it's under-utilized, but we are not quite defining what under-utilized means and instead pointing to pipeACK for one way of defining it (for TCP). This doesn't seem great to me.

For the purpose of this PR, how about you leave it like this and open a new issue to summarize a definition of an under-utilized cwnd?

>  
 A sender that paces packets (see {{pacing}}) might delay sending packets
 and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
+Sending more than intial window into the network at once may cause losses.

```suggestion
Bursting more than an intial window's worth of data into the network might cause short-term congestion and losses.
```

>  
 A sender that paces packets (see {{pacing}}) might delay sending packets
 and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
+Sending more than intial window into the network at once may cause losses.
+Implemementations SHOULD use pacing, ACK-clocking, a reduction in CWND and/or

```suggestion
Implemementations SHOULD either use pacing or reduce their congestion window to limit such bursts.
```
Reducing the cwnd basically means using ack-clocking to increase the cwnd.

>  
 A sender that paces packets (see {{pacing}}) might delay sending packets
 and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
+Sending more than intial window into the network at once may cause losses.
+Implemementations SHOULD use pacing, ACK-clocking, a reduction in CWND and/or
+timers to minimize bursts.
+
+A sender MAY implement alternate mechanisms to update its congestion window
+after idle periods, such as those proposed for TCP in {{?RFC7661}}.

```suggestion
after periods of under-utilization, such as those proposed for TCP in {{?RFC7661}}.
```

> @@ -742,31 +742,28 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
-
-## Sending data after an idle period
-
-A sender becomes idle if it ceases to send data and has no bytes in flight.  A
-sender's congestion window MUST NOT increase while it is idle.
-
-When sending data after becoming idle, a sender MUST reset its congestion window
-to the initial congestion window (see Section 4.1 of {{?RFC5681}}), unless it
-paces the sending of packets. A sender MAY retain its congestion window if it
-paces the sending of any packets in excess of the initial congestion window.
-
-A sender MAY implement alternate mechanisms to update its congestion window
-after idle periods, such as those proposed for TCP in {{?RFC7661}}.
-
 ## Application Limited Sending

How about "Under-utilizing the Congestion Window"?

-- 
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/2605#pullrequestreview-226331010