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

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

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


Am 17.03.2021 um 06:47 schrieb Yoshifumi Nishida:
> Hi Mirja,
>
> On Tue, Mar 16, 2021 at 9:50 AM Mirja Kuehlewind <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi all,
>
>     Actually I think there is no problem if a ACK on an ACK is
>     misinterpreted as dup ACK. What happens if a dupACK is detected? The
>     cwnd is decreased and lost data is retransmitted. However, the cwnd
>     was either already decreased with the first ACK and would not be
>     decreased again for the next RTT (in case of Reno-like cc), or
>     should be decreased anyway because the ACK carries a new CE
>     feedback. I guess we could note that one should not decrease twice
>     because if the information in the same ACK (being dup and CE
>     counter). However, there will be no retransmission because there is
>     no outstanding non-acked data given the received ack'ed only an ACK
>     and no new data. So in summary, there is no problem here with dupACK
>     generated in response to a pure CE-marked ACK that needs to be
>     addressed in any way.
>
>
> I personally am not very fine with dup acks is being misinterpreted
> This might be another corner case, but here's an example I've thought.
>
> 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.
> This is because RFC5681 states:
>
> .  For each additional duplicate ACK received (after the third),
>         cwnd MUST be incremented by SMSS.  This artificially inflates the
>         congestion window in order to reflect the additional segment that
>         has left the network.
>
>
> RFC5681 also states:
>
>
>     since the receiver can only generate a
>     duplicate ACK when a segment has arrived, that segment has left the
>     network and is in the receiver's buffer, so we know it is no longer
>     consuming network resources.
>
>
> But, I think this doesn't fit the logic in the doc very well. We might
> want to add some texts for this if we choose (B)
>
> --
> Yoshi
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>