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

[Yoshifumi Nishida <[e-mail]>]

Hi Richard,

On Wed, Mar 17, 2021 at 1:02 AM Scheffenegger, Richard <[e-mail]>
wrote:

>
> First RFC5681 states (for completeness):
>
>
>     DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
>        "duplicate" in the following algorithms when (a) the receiver of
>        the ACK has outstanding data, (b) the incoming acknowledgment
>        carries no data, (c) the SYN and FIN bits are both off, (d) the
>        acknowledgment number is equal to the greatest acknowledgment
>        received on the given connection (TCP.UNA from [RFC793]) and (e)
>        the advertised window in the incoming acknowledgment equals the
>        advertised window in the last incoming acknowledgment.
>
>        Alternatively, a TCP that utilizes selective acknowledgments
>        (SACKs) [RFC2018, RFC2883] can leverage the SACK information to
>        determine when an incoming ACK is a "duplicate" (e.g., if the ACK
>        contains previously unknown SACK information).
>
> So, there is already the strong advice, that existing SACK information
> shall be considered for DupACK detection.
>
> Also, I still believe, that we give this particular corner case more
> stage time than warranted.
>
>  > When a sender sent one data packet D1 and bunch of acks (say 30),
>  > and D1 is lost, all acks have CE marks.
>  > In my understanding, this will generate 10 dup acks that request
>  > D1 with (B)
>  > In this case, sender retransmits D1 after 3rd dupacks and it will still
>  > receive 7 dupacks.
>  > These 7 dup acks might trigger another transmission of packets on some
>  > implementations.
>
> Lets work this example:
>
> A used to be the sender of 60 segments.
> B is  ACKing all the above segments with 30 segments.
> The network is suddenly having a pathologic state, where each and every
> of these ACKs is CE marked.
> B is now transmitting D1.
>
> A ACKs every 3rd CE-marked ACK with another ACK,no SACK, TSecr reflects
> the TSval of these ACKs
> A ACKs D1 (no SACK, TSecr of D1)
>
> B observes ACKs, with a TSecr indicating they are sent before D1 could
> arrive. And they don't contain SACK. However, ACE increments, thus a CC
> reaction is needed *in this window*.
>
> Or, B ignores the indications from TSopt/SACK - reduces cwnd (either due
> to ACE incrementing, or the dupack trigger and retransmits D1.
>
> If B does ignore TSopt - it likely has no notion of the Window during
> non-data flights of segments. Thus a cwnd reduction due to DupAck is
> probably the ONLY trigger for the required CC reduction.
>
> Or B does use auxilliary information like TSopt, flight in
> segements/expected ACKs, to drive the AccECN-based CC-reduction - and
> would not mistake these ACE-incrementing ACKs as dupacks, as they belong
> to a flight before D1 could have arrived.
>
> However, from a CC perspective, the outcome (actual cwnd reduction) is
> correct. Only from a efficiency perspective, an undue retransmission
> could have been saved.
>
> (And we are still talking about a pathological situation, where suddenly
> a significant fraction of small ACK packets all get CE marked. In the
> environments analysed for step-marking, the CE-marking during steady
> state is 2 marks per window, which is lower than the threshold of 3 in
> (B). Using a higher n in (B) would further reduce the risk of spurious
> retransmission, as the higher risk of desynchonization of the CE.p
> counters between the endpoints
>

Yes, I think the logic works.
My point was that we had better have something to mitigate dupack effects
caused by acking pure acks.
Since the logic above does the job, I am fine with the logic if it's
mentioned in the draft.

Also, I think we might want to mention that this logic overwrites the
presumptions in RFC5681 in the draft.
Because RFC5681 suggests receiving a dupack packet can be considered as an
indication of arrival of data
segment at the other side.
--
Yoshi