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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 30 March 2021 11:13 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 15ED63A0AFE for <tcpm@ietfa.amsl.com>; Tue, 30 Mar 2021 04:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 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_DNSWL_LOW=-0.7, 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 (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 TlB-1vbC73Rs for <tcpm@ietfa.amsl.com>; Tue, 30 Mar 2021 04:13:51 -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 AB8203A0AE1 for <tcpm@ietf.org>; Tue, 30 Mar 2021 04:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617102769; bh=oJnVA6gKX4IL880itpLn701LWik1OApr6ftLsi58lnQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bT+PbNvin1tFuWn+wfQo7J6jRqv9ZLLpBk4Nzu1kuGw4nGqbcmSD+kaU0uGpzRKCX zycYXIgMWQfegoRhWC8/wPhJ8BlD4uhTNv97qIN85TAssgPc9Wlj7WgXzF7zuM5vlI hanFZ1U/McCaS9fSWGYRaKY37dfxQgGvkJrU8tZE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N79uI-1lhxSX0Pq0-017XUm; Tue, 30 Mar 2021 13:12:49 +0200
To: Yoshifumi Nishida <nsd.ietf@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, tcpm IETF list <tcpm@ietf.org>, Yoshifumi Nishada <nishida@sfc.wide.ad.jp>
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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <c98723ea-8cbe-5141-a127-33975676050c@gmx.at>
Date: Tue, 30 Mar 2021 13:12:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAAK044SC4+=RBOEky34OzuirM-u_Om58Lm8uqSqkcpExSBwfHA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:7mPv0BOCcH/jpPGS+gK8qtqD9UMnaE+TmM6S2u5axWb2EmH+jwu ZNGYhf9IbPBxvUivo0S10TfqmAoHsaPcXp1iXY4x90e3yuYc69hAcyRPDnkUfawc3+6SHwo VYNcp4mirVnKh8QWXJgpgjg9opZqHMPAQSL4iJ4FZVE/pbpnZPnJtiNnk+E6YTTukXmRMq3 VAmjYr4wWtmgOrCcC3ZdA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:O5BCvec70Qk=:gagO/fdxqK8CO6YvJ5d+Le nnt/N9OSv1I82UcLMRk4tFxVZI6jvCAGi/5RcYQ0JQbDTOFIYZctMKBqyXCW/Y51Arf2bI0fa vhRRPTxTNKBShdnPm0KPyFsIUVYvDi74Y06hwNm111QUG2iq5iBwFHLtxEiSXiqWF0SD5ZIfd bb5J0PM+OIDIhxt86gmaEC0tlSp+C/0geLBrN3DjbJDPSVjPFIGdH5QJ5RtKyh231Z538BGzK XmZ570E9PUYtPxNh0C2aXs4Jhn7uQL9bPkyUgVASU6NSFYGo3SIEjRliif2XFF1JweXuEqAm0 82kILHWDRLckmf0nWDezZjBFhAi/neowllrkp7JXwKxg97c2JUjzF7qaQku4vgYpXVPdcW4+i I3vmXZu0lUYTlrdfzs9/ZSdYFLW76uBVm7lxNRzfkNEozeX3idW+8SGDtnOoEch8JiSNySJ0G 1bMdsVaM6bZ/V2CoWpaX0zBLqjUcE9WMFs7WImSzzvDePRLGbr2JDxdGVmzdmCJH5jcrB+ZQH q8yXMA0hhW3CZT1ip7rKQVbi/nIbb1UuTiVIjFTV9xfTBAb+DgKqTNA1dv2BdMbIwCfTzJGgu 0hZQIKt+61WrcDqFUgGiIflu+vDkKFvQr+A1s7dFSYxXs+QUOH5rV4GKGCqpLEWvfSe0X+yae SBxlw+WWO7SMy80K+DXwusB/JB2i157ueYPfPe2LUrfv3/9EP7kaNQF8G8MuFqZIOB9/CD74k t4hbrsmzGm6oJtluKahGVxGUxSWjE8qSTxuU1J6gst0GTCxJD5O80Bos8MFZ1jHGh/JvzKTrF oJUealBtKb32A8Qpmmvuv/Qsxj6+iQfFDPnTkecJaHwI4w8kqaenxjCewemr+OOGp/bV7Jdv7 I8nT3xtFirSaYiI0lhUEynz8Qcprq4HpQqIg+ByOjDHy5Vx3B+jbHZG5IWFeB/+LBpxdxmQ1F Fj6RLPqQEboZFnZFX1gTcdMldqlTwr/nDgVnWPu18/WQQU/+n43BnrPKQiPhkrQ5FdDyMpbrj uGTc6TANVD7EU7HO0H3CygzgQsFyC67kLrOZaNVdy2tLOL8dR0J0o7AnVLkZcIlrk5TAXK02C mDapB3amZApSF//PYzTgDgzmFgl8sqZ4UEN9tioHmzZBJKrPPdcbTRWODtnTgFG8VUtTtjw5w wgGsbKnu604aA+XosOYZOgc/jK+zjTQ2Vixv9SbjmbpeOBuBUIPPAKL5/BduGVVopaG9g=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/yThtemxqSGSQZ7152CsjRhbVv78>
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: Tue, 30 Mar 2021 11:13:56 -0000

As a co-author and implementor, I would prefer (B).

While I understand the concerns raised about additional ACKs, formally
these ACKs-for-CE-ACks do convey new information.

Also, the risk of rare spurious retransmissions (because of a
misclassification, or not considering present SACK / TS information) by
the NEW sender is IMHO lower, than the benefit of maintaining good
congetion state in the OLD sender for subsequent transmissions.

As mentioned earlier, additional heuristics (activating delayed timeout,
eliciting the response for 'n' immediately on receipt of 'n+1' (and
retaining the one pending delta) can further help diminish the
ping-pong, while an 'n' of 3 dramatically dampens the number of
ACKs-for-CE-ACKs.

However, I suspect that the above mentioned changes would not be
necessary in non-pathological circumstances at all.

Best regards,
   Richard





Am 30.03.2021 um 11:35 schrieb Yoshifumi Nishida:
> Hi Bob,
>
> On Thu, Mar 25, 2021 at 12:03 PM Bob Briscoe <ietf@bobbriscoe.net
> <mailto:ietf@bobbriscoe.net>> wrote:
>
>     Yoshi,
>
>     On 24/03/2021 08:44, Yoshifumi Nishida wrote:
>>     Hi Bob, Mirja
>>
>>     On Mon, Mar 22, 2021 at 3:08 AM Mirja Kuehlewind
>>     <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
>>
>>         See inline.
>>
>>         > On 19. Mar 2021, at 18:37, Bob Briscoe <ietf@bobbriscoe.net
>>         <mailto:ietf@bobbriscoe.net>> wrote:
>>         >
>>         > Yoshi,
>>         >
>>         > On 17/03/2021 07:22, Yoshifumi Nishida wrote:
>>         >> Hi Bob,
>>         >>
>>         >> On Fri, Mar 12, 2021 at 2:54 AM Bob Briscoe
>>         <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:
>>         >> Yoshi, tcpm list,
>>         >>
>>         >> As promised we set up a small design team on the single
>>         issue of occasionally ACKing pure ACKs if they carry new info
>>         (ECN marking at the IP layer). The design team has two
>>         solutions and everyone would be prepared to accept either, but
>>         preferences differ. So we're seeking wider opinions (more
>>         opinions obviously won't narrow the choices, but at least the
>>         WG can then make a decision informed by those who care).
>>         >>
>>         >> To understand the question, you can either read the email
>>         below. Or the 3 slides for the tcpm meeting are briefer, and
>>         include pictures:
>>         >>
>>         https://datatracker.ietf.org/meeting/110/materials/slides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00#page=6
>>         <https://datatracker.ietf.org/meeting/110/materials/slides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00#page=6>
>>         >>
>>         >> Here's the current draft text in question (see here for
>>         context
>>         https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5
>>         <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5>
>>         ):
>>         >> 3.2.2.5.1 Data Receiver Safety Procedures
>>         >>
>>         >>    An AccECN Data Receiver:
>>         >>
>>         >>    o  SHOULD immediately send an ACK whenever a data packet
>>         marked CE
>>         >>       arrives after the previous packet was not CE.
>>         >>
>>         >>    o  MUST immediately send an ACK once 'n' CE marks have
>>         arrived since
>>         >>       the previous ACK, where 'n' SHOULD be 2 and MUST be
>>         in the range 2
>>         >>       to 6 inclusive.
>>         >>
>>         >>
>>         >> Only the second bullet is in question. Here is the proposed
>>         diff for each alternative, then we explain:
>>         >>
>>         >> Alternative A
>>         >>    o  MUST immediately send an ACK once 'n' CE marks have
>>         arrived since
>>         >> -     the previous ACK,
>>         >> +     the previous ACK and there is outstanding data to
>>         acknowledge,
>>         >>       where 'n' SHOULD be 2 and MUST be in the range 2 to 6
>>         inclusive.
>>         >>
>>         >>
>>         >> Alternative B
>>         >>    o  MUST immediately send an ACK once 'n' CE marks have
>>         arrived since
>>         >> -     the previous ACK, where 'n' SHOULD be 2 and MUST be
>>         in the range 2
>>         >> +     the previous ACK, where 'n' SHOULD be 3 and MUST be
>>         in the range 3
>>         >>       to 6 inclusive.
>>         >>
>>         >>
>>         >> Extra guidance text would be required in each case too (see
>>         the end).
>>         >>
>>         >> Background:
>>         >> AccECN is a change to the TCP wire protocol that requires
>>         the packet count of congestion feedback to include any
>>         congestion experienced (CE) arriving on Pure ACKs (amongst
>>         other things). AccECN doesn't require Pure ACKs to be
>>         ECN-capable, but allows for them to be. Similarly, AccECN
>>         doesn't require any congestion response to CE on pure ACKs,
>>         but having the feedback information there allows a response to
>>         be added with a one-ended update, if desired/necessary.
>>         Basically the data receiver is a 'dumb reflector'.
>>         >>
>>         >> The above two bullets were designed to ensure that an ACK
>>         is triggered a) on the first sign of congestion, and b)
>>         frequently enough for the count of CE markings to be fed back
>>         using the 3-bit ACE field before it wraps, even if an
>>              occasional pure ACK is lost.
>>         >>
>>         >> We then realized that the wording could require an ACK to
>>         be triggered in response to a CE-marked pure ACK. The
>>         circumstance when this could occur would be when peer X sends
>>         a volley of data to Y then stops, and the path back from Y to
>>         X is congested (probably by other flow(s) so that many of the
>>         ACKs are CE-marked. The second bullet above under alternative
>>         (B) would require X to ACK every 'n-th' CE-marked pure ACK.
>>         However, if Y immediately started sending a volley of data to
>>         X, Y could misinterpret those ACKs (of ACKs) from X as DupACKs.
>>         >>
>>         >> There are two ways to deal with this:
>>         >> A) Some of us prefer to completely prevent ACKs on pure
>>         ACKs, on the basis that they do not want to risk sometimes
>>         generating more ACKs today
>>         >> B) Others want to ensure that these rules will cause pure
>>         ACKs to be ACKed when the amount of CE on the ACKs merits it.
>>         But sparingly and strongly damping any ACK ping-pong.
>>         >>
>>         >> Hmm. This is not easy..
>>         >> My personal preference is if SACK is negotiated and it 's
>>         utilized to distinguish dupacks, then (B) is fine for me.
>>         Otherwise, I would prefer (A).
>>         >>
>>         >> BTW, I am wondering if this could leave it to
>>         implementations since both methods have pros and cons.
>>         >> I think It's hard to tell one is much better than the order.
>>         >
>>         > [BB] The problem is that the decision impacts the complexity
>>         of the other end, not just the implementer's own code.
>>         >
>>         > * If an implementer chooses (A) (doesn't ACK pure ACKs at
>>         all), when it finally does send some data, it's CE counter
>>         could have built up an (unlimited) store of unreported CE
>>         marks, which it will report all at once. So implementations
>>         will have to include code that copes with receiving
>>         potentially multiple wraps of the ACE field (or just ignore
>>         the possibility).
>>
>>         You always need to cover this case because it is always
>>         possible to lose ACKs  and then counter may wrap. However, I
>>         don’t think you actually need to implement any logic to detect
>>         this. It only means the counters on both ends are off by N x 8
>>         but congestion information is only valid that the point when
>>         it happens and resyncing on outdated information doesn’t help
>>         anybody.
>>
>>
>>     So, in my understanding, there are two types of choices for
>>     implementations on the other end.
>>     1) need to decide whether ignore CE counter wraps or prepare for
>>     it  (for both A and B)
>>     2) need to decide whether identify ACKs on pure ACKs by accecn or
>>     accept possible ack ping-pong  (for only B)
>>
>>     In this case,
>>     For 1)
>>        Choosing (A) or (B) doesn't matter because both (A) and (B)
>>     have this potential risk.
>>     For 2)
>>        if we pick A, we don't need this.
>>        if we pick B, we need this
>>        if we allow both, we need this
>>     If I think in this way, choosing (B) is not much different from
>>     allowing both?
>
>     [BB] Yes,...
>     ...but I should make it clear that these pros and cons solely
>     describe the implementation complexity of each choice. They don't
>     say anything about the benefit of the feedback itself being
>     available during that switch-over round trip...
>
>     In scenarios where the direction of data switches, option A is
>     simpler for one peer, but it denies its peer the benefit of
>     continuing to maintain cwnd up to the point it starts sending. So:
>
>     If we pick A, no-one gets the benefit but there's not the complexity
>     of the extra check for B
>     If we pick B, everyone gets the benefit and everyone has the
>     complexity of the extra check for B
>     If we allow both, one peer only gets the benefit if the other peer
>     chooses the complexity of the extra check for B.
>
>     If we allow both, one peer also has the uncertainty of not knowing
>     whether the other peer implements B. An implementater might be able
>     to develop a  better cwnd validation algorithm if it knows for
>     certain whether absence of feedback from the other end is purely
>     because it hasn't implemented option B.
>
>
> Yes, It seems that they all have pros and cons.
> It would be good if we can get feedback from implementers here..
> If there is no strong opinion on this point in the community, I think
> the author will need to pick one at some point.
> --
> Yoshi
>