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

[Martin Duke <[e-mail]>]

Hi Bob,

On Mon, Mar 15, 2021 at 3:57 PM Bob Briscoe <[e-mail]> wrote:

> [BB] I think Martin is not disagreeing with your assessment. He was just
> pointing out that the knock-on effects of ACKing pure ACKs originally
> stems from allowing pure ACKs to be ECN capable in the first place. He's
> not saying that's bad. Just it's the root cause of the new phenomenon
> we're seeing here.
>

Yep


> [BB] I was going to say roughly the same as Richard in response to
> Martin here.
>
> Just because some apparent DupACKs with an increased CE count are not
> DupACKs, does not imply that a true DupACK cannot have increase CE count.
>
> That's why we need other tests, like lack of SACK when negotiated, or
> timestamp evidence.
>
>
> Bob
>

Absolutely: by the same token, a window update could also be a genuine
duplicate ACK, but TCP uses a heuristic.

If people are uncomfortable with the heuristic, we could eliminate it by
saying.
- pure counter updates are not duplicate acks, as an extension to the 5681
definition, and
- A receiver that gets both an OOO packet (which might be CE marked) and
one or more CE-marked ACKs must send *two* acks; one that updates the
counter and one that does not. The one that does not is unambiguously a
duplicate ack.

I don't think this is necessary, but it would resolve the problem.