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

[Yoshifumi Nishida <[e-mail]>]

Hi Bob,

On Thu, Mar 25, 2021 at 12:03 PM Bob Briscoe <[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]>
> wrote:
>
>> See inline.
>>
>> > On 19. Mar 2021, at 18:37, Bob Briscoe <[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]>
>> 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
>> >>
>> >> 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
>> ):
>> >> 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

>