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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Thu, 18 March 2021 20:50 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 5A6AA3A3417 for <tcpm@ietfa.amsl.com>; Thu, 18 Mar 2021 13:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 XKWTdXvRCmFG for <tcpm@ietfa.amsl.com>; Thu, 18 Mar 2021 13:50:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 E88263A3414 for <tcpm@ietf.org>; Thu, 18 Mar 2021 13:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616100630; bh=uZWNTCkLLPqrR86WWqHWt33Hih8Ual7tBhQ8Y44aD3s=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=V6us/IsBXn+p3yYCZT4uNvOcn4/SBId814YQTp7hJpQzCgVrTWlTZhJnfoMJ5/6Xw Vo7WIysOqG7LO+IbDEaVK7BIBCY97wl+Z75fhor4nYWX0KxE9CcOqe5ppfonMJJOr3 EoiW1gd2953UE7jKbclNRdMJ0mxbydkBXHvH6b8g=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([178.165.129.155]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrhUK-1m1Ut01mjM-00nfcF for <tcpm@ietf.org>; Thu, 18 Mar 2021 21:50:30 +0100
To: 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> <0ED88AD7-1989-41F0-9435-BEF6E2213CD2@apple.com> <FB955AA3-A488-48D9-A034-37E58B6E75DD@kuehlewind.net> <1EBF20D2-BE6D-4D82-91CB-CEC606104F9A@apple.com> <E5DF93F5-D5C4-4B0F-8742-CB1ECD0258E2@kuehlewind.net>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <d2f0dba7-a7d4-5bfc-e117-9853779ea043@gmx.at>
Date: Thu, 18 Mar 2021 21:50:27 +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: <E5DF93F5-D5C4-4B0F-8742-CB1ECD0258E2@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:+h/XsW5U+OW8VotYH3qdkSnac2tJtTYhf4cBbejyPTa1fKEiLZ0 dmq4JKmO6j0I90GXNTLGDRouahgYJiYZp3PaPrbwi3vreYFppkLzvVj3yB/0M2paE7Wn7K7 u4Xbn2ymSWpaTWUlG5o/OFSmiYLJYxjLTpxaNB0tZ9VjvuBZnSLaiZVV5tXxonIc/SUJAI3 ywm94ZDryXEc2vmMAzbMw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:C71+NEjskKE=:TWp0YQ057hq84TPQodUaV1 IWugqs7X2wV4qaxRX7msDISi7YvjFINrE4ZTSeUlOLWCR2ozS1ZbVULWofeNSPhTi6d3Sgk2K 8nAOifmmuHo/1Kkw0SF9ryBkH7yRxtDpV9sHxZxytQtgtq9FJXhhGvhFbkbybPkMvce6+XT+0 CZ1wVNLXJOtPAxHK0OstyjYHW8ay7KqBjJ4llf9j3S6wACnv9luf+djhbV4JQM1Xn87mu5Xu7 RipNsQ5GeM4UQZKEY/WF5xwDQSTWHrgF8Zcg2OVi4W9DKHHoBtOK+EiVzXq9kRzfbjfOGEXYe 9HNno7pmdhJKpQJuodbz2S4nNBrecXE7BlPvfdYh8QvaD9eemedL9NRhnvBEOeYIB9KXihuI1 sWMDgVT3FBhTH/0ieV1XZgVnuduT32tA/W8Y6RDAV1roxk8B0xOTuyq5ZeZNYWlE8pJzQ7WSR uY4kBBmMPwQqQdFbafDOiO/AhJbi+xmsobJSCtj/dKzOFD3tgQGEk7HbxpLDFoTybLfDkPtk1 YkmMDkux+STHhR8xtaJvpECd+pHQei6U0MwsV8lC2DBo5KwaLqSWPSJr1j1IVx2D/eqaeZUGZ DZ+I1DbIQH4Vzg2cajEK30m6C8DAig8Hz1xaRDnNapLvrUIw999J6R99td+WFXHugp2/YIlca ICdyaSfPyiXcgGhIYq2Mr1iM3su9eVjKgsxsWdI1lHL+3ev4V99qGOV1xy4GLtLFHwTUO7FDO ulAUrkArQC/HZLU8OhGtJOzduIFzvS6oGKm6CeQq3kSz/gp7RjWbCRaOLp6wFJYBiZzyF9/JE kQKCXddpeY40daU6+N0vRWB5agABGPUrRzvO37bwpsW/XhIpyFbug3/hDfNIc+IRWh1ORI4sR pxu2L841rynrWFlYCeUA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/PGN2siVAay2RprQTrHU8TrSzHrc>
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: Thu, 18 Mar 2021 20:50:37 -0000

Hi Mirjy, Vidhi,

>> Sure. But if the sender (who was receiver before) has already sent out data right after the pure ACKs, there will be outstanding data before the ACK for pure ACK (or DupACK as there is outstanding data) is received from the peer, right?
>
> I see. That means you send a whole bunch of Pure ACKs and then some data in the same RTT. In this case it would actually be nicer to wait for the data packet instead of sending a pure ACKs. Maybe should should rather use always some thing like a delayed ACK timer for pure ACK rather then saying we need to ACK each nth pure ACH?

Introducting an additional delay is further reducing the risk. (And it
would be relatively easy to implement, reusing existing functions.) But
remember we started out with the (unlikely, and rather pathological
corner case, where a re-routing event coincides with when the ACKs get
sent out, redirecting them over a path which marks near 100% of these
very small pure ACKs with CE - while the former sender has send a window
of packets of size 3*n (at least).

And yes, slightly holding off for sending the ACKs-for-CE-marked-ACKs
(e.g. activating the delayed ACK timer, or when the n+1'th CE-marked ACK
is received) further reduces the probability to trigger this.

As will the use of SACK and TSopt (I don't know recent numbers, but
suspect that a vast majority of TCP flows is currently used one or the
other (or both) of these TCP options.

All that, to avoid a spurious Retransmission (spurious retransmissions
do happen currently much more often for much more begning reasons, like
RTT step changes) - while the congestion control reaction is actually
the intended, and correct behavior. So that non-SACK (non-TS) sender is
only "behind" by one segment, which may have been a new data segement
instead...

I suspect this discussion is really about the mite-hole at the end of an
ant-hole, at the end of a rat-hole, at the end of a rabbit-hole ;)

At least I can not think of a realistic scenario, which is expected to
be encountered in a future L4S/SCE (shallow, instanteous marking)
environment, that would run into such a pathological setup on a regular
basis. But perhaps there are some...

(Extremely high RTT, very large BDP links, with cwnd measured in 100s of
segments, and extreme congestion of a shared-use return path, perhaps?
Still not convinced that here the marking will hit dominantely pure ACKs
(and not data segments of significantly larger size), and in
sufficiently high number to cross the 3*n (or, with delay, 4*n) threshold.

Yoshi, do you have a scenario in mind, where this effect may be relevant
or even dominant?

Best regards,
    Richard