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

[Yoshifumi Nishida <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> On Behalf Of Scheffenegger, Richard
> Sent: Tuesday, March 30, 2021 4:13 AM
> To: Yoshifumi Nishida <[e-mail]>; Bob Briscoe <
> [e-mail]>
> Cc: Yoshifumi Nishada <[e-mail]>; tcpm IETF list <
> [e-mail]>; Mirja Kuehlewind <[e-mail]>
> 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 <[e-mail]
> > <mailto:[e-mail]>> 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
> >>     <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >>         See inline.
> >>
> >>         > On 19. Mar 2021, at 18:37, Bob Briscoe <[e-mail]
> >>         <mailto:[e-mail]>> wrote:
> >>         >
> >>         > Yoshi,
> >>         >
> >>         > On 17/03/2021 07:22, Yoshifumi Nishida wrote:
> >>         >> Hi Bob,
> >>         >>
> >>         >> On Fri, Mar 12, 2021 at 2:54 AM Bob Briscoe
> >>         <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
>
> 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
>