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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Wed, 17 March 2021 08:02 UTC

Return-Path: <rs.ietf@gmx.at>
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 589E73A0B68 for <tcpm@ietfa.amsl.com>; Wed, 17 Mar 2021 01:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=gmx.net
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 33UBkI_ibh6p for <tcpm@ietfa.amsl.com>; Wed, 17 Mar 2021 01:02:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A5BCE3A0B69 for <tcpm@ietf.org>; Wed, 17 Mar 2021 01:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615968134; bh=Ci/Opqhct4phuwtEC0GdD/tnf6Lm71VLA7huDnBm/ug=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LbT+F/f7jfLK0gSPWpnLAaTH4E1RLYPRPPXgYAKqe5aDiG9R347ZRqnt5+iUvhyMD 4XY/eUknsXktmqRyY6ArCCgjs6EH7xtfM3OSQM1srJOm4LT2MsABZHX69IqlaKOS49 rkHyBfkMJCJmvTNINlAc5xe2qEe2h63vviBe0MoE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([77.119.128.224]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9dwd-1lj8OR1Sy5-015b7w; Wed, 17 Mar 2021 09:02:14 +0100
To: Yoshifumi Nishida <nsd.ietf@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Yoshifumi Nishada <nishida@sfc.wide.ad.jp>, tcpm IETF list <tcpm@ietf.org>
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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <9d3c3043-dc5e-7377-1d97-3ea915d72110@gmx.at>
Date: Wed, 17 Mar 2021 09:02:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAAK044Q4NOMM2ymuCY4n-HwJOCSFsso4DTkpGgLN=cJUAyW1Vw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Bja3XeO7Zuivitd53jtxQzFBJ16bRyJMmcuwYuQ5J0O+CckUZZB gzhjhM1hPjI+UGWMk+NJnnk4GcXQYBX5wtii2frWeYz0l5PJigAX4odSjErYhujQvnaQM0T Xqn4NB1zD4r9ESVvldGY7rln93zIH5nzpfIjMnxNdBiblZO/GgqQPXQnIY48/bSIxN5JntX 1BKx3UGchrckr3jtolb+w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:YxDMjFwDMUw=:x16DCFHwgxXsigcBc09/dg 8BaJKApIiE1Jv8+xRrj507esS2JIfgmrxsg4D9KN5IB3jdzNdrdrDEnfK5HCIYzX+iPyQ9OnM 6fhepu1CIJzEpcBAFa4DMpJF7VXiGOtaOyB8IQEQwXx9NF0OV7cIYyVQbwnUK0EN2bCiDYJv1 SjEv8AYzAIDg59fH7sWMy19v4YlsltGT3lNqwSsKhcBlG8GY1oMj/cwh6ggS/bKksCsWzXDVl 11ODwB3/6Li1Mqv7DYs4ABe6CnRZEjAmYg5T998LdlRt1VZr3wOT+DYUjO2voLx+qjguKDWyW ALFZKp4IuU9Yob8Or4qhkQC6lLjBtvV+NVX3+6+wAvQ1YQztmszeKL//R1kh1xZxGtuFknoiJ c23WmmbjGB7EXY2md5gliGn1evcb5Fx05xu8v9GnuQrGbbCesgMbNRSvp+E7Xg38Ow4mRm6jH SCoxfOnw5zMGGFZaoZsXvHVoVHFfI9guRKukydY+4ZSfLeVTTsEs9N6KnBF9gaBMipA4+SVx7 OKh7tiypj6almB9iLeEy+yYUZ0ygjbKqZy/N7Ii+3M6GSMi6314GSgf6Vgv2IUqkmGUgEkm7m Xmce9xpO7MaxydxdNdGA4dk+5ew+allpyDVfVmjrOjEd8UCkh3K7DCno6Z8QFyjVFu93/7Xle 7tzja36/aim4+knhYnBHbBkvCoA2aTh1j4zZw6TUnsk+YftMn5dXvic9chzbr3+c8yQvb5gpV wyCxRprb3Akb0/oOlEp0hKzZs8GgYQ/lqOsvwxqhAvE2tKdtAA5Uau/sxbjvacB4NZNwhJNFq R2gCYTr6QktjJCXWSHtZnzhFv616lbZ14XDmxmHTSJEl6VL6jOMpPpn6kcUw1pfdMH0HfFQZY HOwEfQ/fxMepNzF6BWug==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/FGQswylQgQnx1K2cZjj1C6YYWYg>
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 08:02:37 -0000

First RFC5681 states (for completeness):


    DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
       "duplicate" in the following algorithms when (a) the receiver of
       the ACK has outstanding data, (b) the incoming acknowledgment
       carries no data, (c) the SYN and FIN bits are both off, (d) the
       acknowledgment number is equal to the greatest acknowledgment
       received on the given connection (TCP.UNA from [RFC793]) and (e)
       the advertised window in the incoming acknowledgment equals the
       advertised window in the last incoming acknowledgment.

       Alternatively, a TCP that utilizes selective acknowledgments
       (SACKs) [RFC2018, RFC2883] can leverage the SACK information to
       determine when an incoming ACK is a "duplicate" (e.g., if the ACK
       contains previously unknown SACK information).

So, there is already the strong advice, that existing SACK information
shall be considered for DupACK detection.

Also, I still believe, that we give this particular corner case more
stage time than warranted.

 > 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.

Lets work this example:

A used to be the sender of 60 segments.
B is  ACKing all the above segments with 30 segments.
The network is suddenly having a pathologic state, where each and every
of these ACKs is CE marked.
B is now transmitting D1.

A ACKs every 3rd CE-marked ACK with another ACK,no SACK, TSecr reflects
the TSval of these ACKs
A ACKs D1 (no SACK, TSecr of D1)

B observes ACKs, with a TSecr indicating they are sent before D1 could
arrive. And they don't contain SACK. However, ACE increments, thus a CC
reaction is needed *in this window*.

Or, B ignores the indications from TSopt/SACK - reduces cwnd (either due
to ACE incrementing, or the dupack trigger and retransmits D1.

If B does ignore TSopt - it likely has no notion of the Window during
non-data flights of segments. Thus a cwnd reduction due to DupAck is
probably the ONLY trigger for the required CC reduction.

Or B does use auxilliary information like TSopt, flight in
segements/expected ACKs, to drive the AccECN-based CC-reduction - and
would not mistake these ACE-incrementing ACKs as dupacks, as they belong
to a flight before D1 could have arrived.

However, from a CC perspective, the outcome (actual cwnd reduction) is
correct. Only from a efficiency perspective, an undue retransmission
could have been saved.

(And we are still talking about a pathological situation, where suddenly
a significant fraction of small ACK packets all get CE marked. In the
environments analysed for step-marking, the CE-marking during steady
state is 2 marks per window, which is lower than the threshold of 3 in
(B). Using a higher n in (B) would further reduce the risk of spurious
retransmission, as the higher risk of desynchonization of the CE.p
counters between the endpoints


Am 17.03.2021 um 06:47 schrieb Yoshifumi Nishida:
> Hi Mirja,
>
> On Tue, Mar 16, 2021 at 9:50 AM Mirja Kuehlewind <ietf@kuehlewind.net
> <mailto: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
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>