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

["Scheffenegger, Richard" <[e-mail]>]

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://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
>