Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

Vidhi Goel <vidhi_goel@apple.com> Tue, 30 March 2021 19:18 UTC

Return-Path: <vidhi_goel@apple.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DDA3A1F14 for <tcpm@ietfa.amsl.com>; Tue, 30 Mar 2021 12:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 6DGaXbLGEkoH for <tcpm@ietfa.amsl.com>; Tue, 30 Mar 2021 12:18:26 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B873A1F13 for <tcpm@ietf.org>; Tue, 30 Mar 2021 12:18:25 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.0.43/8.16.0.43) with SMTP id 12UJHnJM004097; Tue, 30 Mar 2021 12:18:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=V7CCJQqNXo74vaiyH4noiqgZRWkkJUNL/9XNiDhVhe0=; b=PXQS9MVR8cNxTz8KyQyZ/1NF6dAiU9D1R+tA7lmGkFXgHt+cdhKD5Arplf2411M9KsBW wXFlZdj+MNmWpbam4H1V+0WW6Jp1WtnyVstBmFhZk1pskdEh1uQIKotMNd4ybvz7qLnE iYJd0yYx8nCchPM6XrMYcCRF8850n564aqY+kBC7G37Q/6xoc2BiN3fKaWZDx0wvssCK tEkb02eQQIZgiVLMEE3Rfs4AFgzRlJxoJOHDhBK2hNn93tbFaEicnYStn/K+A9YvHf6J X/UcoZQroVvaY5HITjnnvszc2Y1DUGPWUKX6CmXmXB8ALyOtSq4xLrI8JULN+b9C9IX6 5g==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 37j2a9t8qg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Mar 2021 12:18:22 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QQS00VGGQYMFI90@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 30 Mar 2021 12:18:22 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QQS00X00QO6WH00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 30 Mar 2021 12:18:22 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 766d32dce0a9c027bcd9f1f38891080b
X-Va-E-CD: 47719c426864e8f33e6ed2f3f4374008
X-Va-R-CD: 0efa85ab4e10f7e59d6be459504dc429
X-Va-CD: 0
X-Va-ID: 1b6e5ca2-4091-42a9-84ca-32b748b64886
X-V-A:
X-V-T-CD: 766d32dce0a9c027bcd9f1f38891080b
X-V-E-CD: 47719c426864e8f33e6ed2f3f4374008
X-V-R-CD: 0efa85ab4e10f7e59d6be459504dc429
X-V-CD: 0
X-V-ID: 1c375c5f-a131-4c66-b20d-d91033a2ba2d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-30_09:2021-03-30, 2021-03-30 signatures=0
Received: from [17.11.113.215] (unknown [17.11.113.215]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QQS0026XQYD7000@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 30 Mar 2021 12:18:17 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Vidhi Goel <vidhi_goel@apple.com>
In-reply-to: <CO2PR00MB0166A673407CE6BD1B587E55B67D9@CO2PR00MB0166.namprd00.prod.outlook.com>
Date: Tue, 30 Mar 2021 12:18:13 -0700
Cc: "chromatix99@gmail.com" <chromatix99@gmail.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "nishida@sfc.wide.ad.jp" <nishida@sfc.wide.ad.jp>, "ietf@kuehlewind.net" <ietf@kuehlewind.net>
Content-transfer-encoding: quoted-printable
Message-id: <916A84D1-82C8-4566-A321-DA2A23451000@apple.com>
References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> <bd6ab65d-ccd5-9fa9-58be-6d9fea4af870@bobbriscoe.net> <CAAK044QgF4pz5Wamnxkobthou5ac4_LBxh8=nBYWyOxQUtcW-Q@mail.gmail.com> <8151fdef-ae78-80f3-adfc-d40db878ac8e@gmx.at> <CAAK044RhdAYexcGRj_XDkdY_o6JqB0DDo1X0H2AeFkRcsb0i4A@mail.gmail.com> <48c5910d-5340-acd6-8fd9-fff1b7758310@bobbriscoe.net> <CAAK044QOdi8DzBbLbwTvdcesFK21i1KU+Sj+4J7_odE5UQfmNg@mail.gmail.com> <dc11cd02-616e-93a7-7bcf-1e5112c2e1e1@bobbriscoe.net> <99B71B9A-EC9B-47FD-A149-FBEF9DEEC8DC@kuehlewind.net> <CAAK044SgdHAiBvDPHYOaq7-fgJTrBBoAqZQ70F5X3Q5HXvTEuw@mail.gmail.com> <ce4f09c2-2b50-8b35-3c3d-a01d45acce3b@bobbriscoe.net> <CAAK044SC4+=RBOEky34OzuirM-u_Om58Lm8uqSqkcpExSBwfHA@mail.gmail.com> <c98723ea-8cbe-5141-a127-33975676050c@gmx.at> <CO2PR00MB016662270FCE3E01AC4138D9B67D9@CO2PR00MB0166.namprd00.prod.outlook.com> <E56EF702-39F0-4EBD-A5FC-23E9EC9B8941@apple.com> <1BEBABDB-A68C-4E21-BF78-24CCE54FCFE9@gmail.com> <CO2PR00MB0166A673407CE6BD1B587E55B67D9@CO2PR00MB0166.namprd00.prod.outlook.com>
To: Praveen Balasubramanian <pravb@microsoft.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-30_09:2021-03-30, 2021-03-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/L3nWT7yEaZuFF-imNrWTKGmV8vE>
Subject: Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 19:18:31 -0000

>>> How is the sender of the pure ACKs supposed to react upon receiving the feedback that ACKs themselves are causing congestion? Option B conveys this additional information but how is it supposed to be used? Can a pure receiver get into such a state and does it need to start throttling ACKs?
>> 
>> This was discussed briefly during the WG. The receiver will act by reducing the ssthresh and cwnd (if it is not already minimum). This wouldn’t impact the receiver’s ACKing, but it would have an impact when the receiver starts sending data.
> 
> The information could also be used to tune the Delayed Ack ratio, via (for example) Gomez' Ack Rate Request option.  That *would* have a congestion control effect on ack traffic.

I don’t think we should change the ACK ratio, at the very least, we shouldn’t reduce it. ACKs are used to convey crucial information to the sender esp. when there is a congestion.

> This is uncharted territory for congestion control. To date ACK packets have not been considered part of bytes in flight in TCP and QUIC. Congestion control itself impeding the feedback loop has consequences.

Agreed. And that’s why I think the receiver should not reduce / throttle ACKs based on AccECN feedback on its pure ACKs.

-
Vidhi

> On Mar 30, 2021, at 11:51 AM, Praveen Balasubramanian <pravb@microsoft.com> wrote:
> 
> This is uncharted territory for congestion control. To date ACK packets have not been considered part of bytes in flight in TCP and QUIC. Congestion control itself impeding the feedback loop has consequences.
> 
> -----Original Message-----
> From: Jonathan Morton <chromatix99@gmail.com> 
> Sent: Tuesday, March 30, 2021 11:10 AM
> To: Vidhi Goel <vidhi_goel@apple.com>
> Cc: Praveen Balasubramanian <pravb@microsoft.com>om>; tcpm@ietf.org; nishida@sfc.wide.ad.jp; ietf@kuehlewind.net
> Subject: Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)
> 
>> On 30 Mar, 2021, at 9:04 pm, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
>> 
>>> How is the sender of the pure ACKs supposed to react upon receiving the feedback that ACKs themselves are causing congestion? Option B conveys this additional information but how is it supposed to be used? Can a pure receiver get into such a state and does it need to start throttling ACKs?
>> 
>> This was discussed briefly during the WG. The receiver will act by reducing the ssthresh and cwnd (if it is not already minimum). This wouldn’t impact the receiver’s ACKing, but it would have an impact when the receiver starts sending data.
> 
> The information could also be used to tune the Delayed Ack ratio, via (for example) Gomez' Ack Rate Request option.  That *would* have a congestion control effect on ack traffic.
> 
> - Jonathan Morton