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

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

Thank you Jonathan!

Your argument that this effect has to be considered to be a valid
(hopefully) temporary one is understood.


Am 19.03.2021 um 05:27 schrieb Jonathan Morton:
> - When the receiver of a CE-marked pure ack *does not* have data to send, it must either generate a pure ack to carry the notification, or store the notification for some future opportunity.
>
> - The former choice can be described as "acking an ack", and can lead to an infinite series of ack-acking exchanges if all such acks are CE marked in the network, and no mechanism for ending the exchange is specified.
>
> - Additionally, if the sender of an ECN-Capable pure ack subsequently has data available to send, and does so in more than one segment, a subsequent notification of a CE mark on the ack could be misinterpreted as a DupAck indicating possible loss of the data segment, combined with a CE mark on the second segment or later.
>
> The latter two points are what we need to evaluate, and guard against to the extent deemed necessary.
>
> One very simple method of breaking the infinite chain of notifications would be to specify that acks of acks should themselves be Not-ECT.  These will never be CE marked (modulo broken middleboxes).  Another is to require at least two outstanding "pure ack" CE marks before a pure ack can be generated as a notification; this does not preclude immediate notification of CE marks either upon or via data segments.  The latter method would guarantee an exponential decay of the volume of acks exchanged per RTT, and eventually halt them entirely.


This is already in the text (one ACK at most as often as every other
CE-mark received, as a MUST).

One proposal (maintaining the CE-mark feedback in these situations) was
to change the exponential decay factor, by sending out one
ACK-for-CE-ACKs only after a cumulative change of at least 3 counts (not
just two).

An additional (implementation specific) heuristic would be to send out
the ACK for n with the receipt of the n+1'th marked ACK, while priming
the delayed ACK timeout for sending a ACE counter change - improving the
chances that this information can be sent along with new data somewhat.

> I would recommend language specifying that one of the above methods, or some equivalently effective protection, SHOULD be implemented.

> I would recommend language stating that ECN-Capable pure acks SHOULD NOT be generated unless either TCP Timestamps or TCP SACK has been successfully negotiated on the connection, or some equivalent disambiguating information is available, AND that disambiguating information is actually used to prevent spurious retransmissions.  Since both Timestamps and SACK are in common use, that shouldn't be onerous.

Not ECT-marking these ACKs-for-CE-marked ACKs is actually an alternative
we (authors) haven't thought about, actually. For flows not doing either
SACK or Timestamps, that may be another SHOULD recommendation to include.

>
> However, it is also true that a spurious retransmission on occasion is probably not very harmful.
>
>   - Jonathan Morton
>


Thanks,
   Richard