Re: [quicwg/base-drafts] Add more context and text around ACK frequency (#3706)

ianswett <notifications@github.com> Fri, 29 May 2020 01:13 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 F209B3A107D for <quic-issues@ietfa.amsl.com>; Thu, 28 May 2020 18:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level:
X-Spam-Status: No, score=-3.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 UJQyAakEb6Ii for <quic-issues@ietfa.amsl.com>; Thu, 28 May 2020 18:13:52 -0700 (PDT)
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 2E1E23A107A for <quic-issues@ietf.org>; Thu, 28 May 2020 18:13:52 -0700 (PDT)
Received: from github-lowworker-d93c4b6.va3-iad.github.net (github-lowworker-d93c4b6.va3-iad.github.net [10.48.17.47]) by smtp.github.com (Postfix) with ESMTP id 0953F8C0CA9 for <quic-issues@ietf.org>; Thu, 28 May 2020 18:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590714831; bh=M+7OU/n7ENSKsGlwbUs5SzWCWUmsNo0rLr8HUd8Jck4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yS8jFnm9VZ+VvZ/MQhXrKJCY2Wlrit8ADzEtXpE8FEu432KkVSgjv3z8yUhMgmpWl 5MO28P8BzA3okF5BVRXH9+vO4CQ/bn3xa1U1VbIKfVhdWvOuEJWFLs2rwhIFuhcc30 2kRLW1mCz83cPdASybX2dP/nngm0Vr9L8KpzN4BE=
Date: Thu, 28 May 2020 18:13:50 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3BFK3QK7HVX76DS3V43RBM5EVBNHHCKUVTR4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3706/review/420588453@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3706@github.com>
References: <quicwg/base-drafts/pull/3706@github.com>
Subject: Re: [quicwg/base-drafts] Add more context and text around ACK frequency (#3706)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed061ceedbc5_72e83fd5284cd96064084"; 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/lu4mRmKxvdsvjixwrE_PGcgaf0Y>
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: Fri, 29 May 2020 01:13:54 -0000

@ianswett commented on this pull request.

This seems to be heading in a good direction, thanks for working on it.

> +Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.

```suggestion
Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to open up congestion window,
allowing more packets to be sent, as well as increase the congestion window. In both
cases, delaying acknowledgments can adversely affect performance.
```

> -non-ack-eliciting packet, even if there are packet gaps which precede the
-received packet. Limiting ACK frames avoids an infinite feedback loop of
-acknowledgements, which could prevent the connection from ever becoming idle.
-However, the endpoint acknowledges non-ACK-eliciting packets when it sends an
-ACK frame.
+### Acknowledgement Frequency
+
+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff however.
+
+Endpoints rely on timely acknowledgment to detect loss; see Section X of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.
+
+On the other hand, reducing the frequency of acknowledgement packets reduces

Do you mean ACK-only packets?  Otherwise this could be read to include ACK frames bundled with data, which I don't believe is the intent.

> +Endpoints rely on timely acknowledgment to detect loss; see Section X of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.
+
+On the other hand, reducing the frequency of acknowledgement packets reduces
+packet processing cost at both endpoints. It can also improve connection
+throughput on severely asymmetric links; see Section 3 of {{?RFC3449}}.
+
+A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting
+packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and
+consistent with recommendations for TCP endpoint behavior {{?RFC5681}}.
+
+A receiver MAY process multiple packets before sending any ACK frames in

```suggestion
A receiver MAY process multiple available packets before determining whether to sending an ACK frame in
```

> +response. This allows for a receiver to process packets already queued for
+processing before determining whether to send an acknowledgement.

```suggestion
response.
```

> +packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and

```suggestion
packets. Knowledge of how frequently the peer's congestion controller needs feedback,
network conditions or further research and experimentation might suggest alternative
acknowledgment strategies with better performance characteristics. This
recommendation is general in nature and
```

-- 
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/3706#pullrequestreview-420588453