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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 17 March 2021 18:01 UTC

Return-Path: <ietf@kuehlewind.net>
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 2D00D3A0EBA for <tcpm@ietfa.amsl.com>; Wed, 17 Mar 2021 11:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sKSIRx5gYOA1 for <tcpm@ietfa.amsl.com>; Wed, 17 Mar 2021 11:01:23 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 75ECE3A0EAF for <tcpm@ietf.org>; Wed, 17 Mar 2021 11:01:23 -0700 (PDT)
Received: from p200300dee71fe600f85f69662fd7c281.dip0.t-ipconnect.de ([2003:de:e71f:e600:f85f:6966:2fd7:c281]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lMaTu-0004e2-Qa; Wed, 17 Mar 2021 19:01:18 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAAK044Q4NOMM2ymuCY4n-HwJOCSFsso4DTkpGgLN=cJUAyW1Vw@mail.gmail.com>
Date: Wed, 17 Mar 2021 19:01:18 +0100
Cc: Bob Briscoe <ietf@bobbriscoe.net>, Yoshifumi Nishada <nishida@sfc.wide.ad.jp>, tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <847A6D2D-F532-4C87-9AE1-25A11F33CE87@kuehlewind.net>
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> <CAM4esxTiw7_es60DDK2E1wa3-c1nUD2W_Rf7Fhw5u0qJ0bFQpg@mail.gmail.com> <8275e3ff-24af-7f0c-d251-867673503741@gmx.at> <631a3f3d-52e1-68c0-8b5f-ce41b30d2e7f@bobbriscoe.net> <48BF06D1-F362-450F-9F89-6DAC6E96B1AC@kuehlewind.net> <CAAK044Q4NOMM2ymuCY4n-HwJOCSFsso4DTkpGgLN=cJUAyW1Vw@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1616004083;0c128bfc;
X-HE-SMSGID: 1lMaTu-0004e2-Qa
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KGr5pUnte8IyvQ3acCQp7ECV6oI>
Subject: Re: [tcpm] 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: Wed, 17 Mar 2021 18:01:25 -0000

This is a corner concern case; and you shouldn’t retransmit a second time if more dupACK are received within the next RTT.


> On 17. Mar 2021, at 06:47, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
> 
> Hi Mirja,
> 
> On Tue, Mar 16, 2021 at 9:50 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> Hi all,
> 
> Actually I think there is no problem if a ACK on an ACK is misinterpreted as dup ACK. What happens if a dupACK is detected? The cwnd is decreased and lost data is retransmitted. However, the cwnd was either already decreased with the first ACK and would not be decreased again for the next RTT (in case of Reno-like cc), or should be decreased anyway because the ACK carries a new CE feedback. I guess we could note that one should not decrease twice because if the information in the same ACK (being dup and CE counter). However, there will be no retransmission because there is no outstanding non-acked data given the received ack'ed only an ACK and no new data. So in summary, there is no problem here with dupACK generated in response to a pure CE-marked ACK that needs to be addressed in any way.
> 
> I personally am not very fine with dup acks is being misinterpreted 
> This might be another corner case, but here's an example I've thought.
> 
> When a sender sent one data packet D1 and bunch of acks (say 30), and D1 is lost, all acks have CE marks.
> In my understanding, this will generate 10 dup acks that request D1 with (B) 
> In this case, sender retransmits D1 after 3rd dupacks and it will still receive 7 dupacks.
> These 7 dup acks might trigger another transmission of packets on some implementations. 
> This is because RFC5681 states:
>  
> .  For each additional duplicate ACK received (after the third),
>        cwnd MUST be incremented by SMSS.  This artificially inflates the
>        congestion window in order to reflect the additional segment that
>        has left the network.
> 
> 
> RFC5681 also states:
> 
>    since the receiver can only generate a
>    duplicate ACK when a segment has arrived, that segment has left the
>    network and is in the receiver's buffer, so we know it is no longer
>    consuming network resources.
> 
> 
> But, I think this doesn't fit the logic in the doc very well. We might want to add some texts for this if we choose (B)
> --
> Yoshi
> 
> 
>