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

Yoshifumi Nishida <nsd.ietf@gmail.com> Tue, 06 April 2021 07:44 UTC

Return-Path: <nsd.ietf@gmail.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 482E13A13B1 for <tcpm@ietfa.amsl.com>; Tue, 6 Apr 2021 00:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (2048-bit key) header.d=gmail.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 p3In4lUfqClQ for <tcpm@ietfa.amsl.com>; Tue, 6 Apr 2021 00:44:51 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D443A13B4 for <tcpm@ietf.org>; Tue, 6 Apr 2021 00:44:45 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id g20so14054022qkk.1 for <tcpm@ietf.org>; Tue, 06 Apr 2021 00:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UG47y3B3DTVORe9HRSVMW2J9uk/Z7l1izr38764RkNQ=; b=pmxrsrn/iFY9YvkQBbbxbobAKNBH7HfHnv93ss808mX8B5tk9L4n6RpWsDi/L0RmgK FgBzHfJGbx7fE+B1kJBZZxuqRW99Qy4Rv1bvevjffiK0qC++feIR6ShszMZDNw+cPlpS 4swYHa3EXObnERBfBMbT1Ys3TR0kHdjJNrU3kj8O4CIkz4hOooXFgprFgiFxSwv8cf+B keVVYtJAax3Crm18XxT/ZYiLWcDjxHg54wHFMulZ6MVXybEhpuH9yGviXgpTjkdP461U d04Q6BtMVRYhYAzJgOSL9kDwxHS0Bn0GGNzz0L5zoHljwkhjZKlS8yi61A3vRIva+p9h Ef8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UG47y3B3DTVORe9HRSVMW2J9uk/Z7l1izr38764RkNQ=; b=Ud2ciCiZgzNyO53ItKcPCFnN4aZmHUW4RbJuFHf/o5YFT3KYgs+JF7ga9+GyrinfOC jgz6psGn+r+AB+J2HKZSrGOmioNdlxaTp6Eo1sNSwpIZEZbynOdU7nABVb+RmsIL+kkb wCIszuRRpU+AFKUmYZavyB19wbBHoy4Epp8e4QH/RXoS2AkUMpi2/4ZG+SomMS3nqxcp Q4JDapJbsubjJTXZnAkX8MX+MBtYbcfmNTjrnk10IpjKhzps0iO4+lWRTuLUCAZdQuNZ abkl48j2CT+Yg1gdY5Er5eNQwdiVZyk4LhpDivtOOkBWVTAU1TvPBZ+EVmV9TkjLr61I 2MJQ==
X-Gm-Message-State: AOAM531KdTOZhiMEIV0FM0SKsGHb0J7vaiEbmwAz1OA3VeounSXPcYUI D81uH3Eo3E+vqU3UJF7DHzoZgoUAaUc/LNhNLLo=
X-Google-Smtp-Source: ABdhPJw4ly+KeROfY7CmS/h5S4ZRA2OgvyluK7agGK19UBR60U3bL0zNLhKijI09mckBE24gwc8pp1ohNjw/fOXeGYA=
X-Received: by 2002:a05:620a:15eb:: with SMTP id p11mr27717193qkm.454.1617695084585; Tue, 06 Apr 2021 00:44:44 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CO2PR00MB016662270FCE3E01AC4138D9B67D9@CO2PR00MB0166.namprd00.prod.outlook.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Tue, 6 Apr 2021 00:44:33 -0700
Message-ID: <CAAK044QxkxxuuRXyRQB4U5q+SOKqUYLBqv7-tRJHybkFQjsO2A@mail.gmail.com>
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: "rs.ietf@gmx.at" <rs.ietf@gmx.at>, "ietf@bobbriscoe.net" <ietf@bobbriscoe.net>, "nishida@sfc.wide.ad.jp" <nishida@sfc.wide.ad.jp>, "tcpm@ietf.org" <tcpm@ietf.org>, "ietf@kuehlewind.net" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="000000000000df26ca05bf48fc4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ZaCJoz4_t6vqiqNnfz9qCiH-pjs>
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, 06 Apr 2021 07:44:56 -0000

Hi,

It seems this is a part of CC although this looks an interesting topic for
discussion.
I am thinking that the detailed of CC would be outside of this draft.
we might need another draft to define this behavior.
--
Yoshi

On Tue, Mar 30, 2021 at 9:30 AM Praveen Balasubramanian <pravb@microsoft.com>
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?
>
> ECN++ draft section 3.3.3 leaves the reaction to the AccECN draft but I am
> not able to locate the text in the latest AccECN draft.
>
> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Scheffenegger, Richard
> Sent: Tuesday, March 30, 2021 4:13 AM
> To: Yoshifumi Nishida <nsd.ietf@gmail.com>om>; Bob Briscoe <
> ietf@bobbriscoe.net>
> Cc: Yoshifumi Nishada <nishida@sfc.wide.ad.jp>jp>; tcpm IETF list <
> tcpm@ietf.org>gt;; Mirja Kuehlewind <ietf@kuehlewind.net>
> Subject: [EXTERNAL] Re: [tcpm] Seeking WG opinions on ACKing ACKs with
> good cause (was: Possible error in accurate-ecn)
>
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00%23page%3D6&amp;data=04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=t5T6laDBNruH4VDgCEjhHYI7IpbVAOrktd9iCw1MpKg%3D&amp;reserved=0
> >>         <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00%23page%3D6&amp;data=04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=t5T6laDBNruH4VDgCEjhHYI7IpbVAOrktd9iCw1MpKg%3D&amp;reserved=0
> >
> >>         >>
> >>         >> Here's the current draft text in question (see here for
> >>         context
> >>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accurate-ecn-14%23section-3.2.2.5&amp;data=04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FJrrumB1WBtsjRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&amp;reserved=0
> >>         <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accurate-ecn-14%23section-3.2.2.5&amp;data=04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FJrrumB1WBtsjRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&amp;reserved=0
> >
> >>         ):
> >>         >> 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
> >
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=zEm1fZiCGkXdJIK3RUzItPrKvuRm9WypbyWzRX0D8wA%3D&amp;reserved=0
>