On 9/25/25 4:46 PM, Chia-Yu Chang (Nokia) wrote:

From: Paolo Abeni <pabeni@redhat.com> Sent: Tuesday, September 23, 2025 12:52 PM

quoted

On 9/18/25 6:21 PM, chia-yu.chang@nokia-bell-labs.com wrote:

quoted

From: Chia-Yu Chang <redacted>

Detect spurious retransmission of a previously sent ACK carrying the 
AccECN option after the second retransmission. Since this might be 
caused by the middlebox dropping ACK with options it does not 
recognize, disable the sending of the AccECN option in all subsequent 
ACKs. This patch follows Section 3.2.3.2.2 of AccECN spec (RFC9768).

Is this really useful/triggers in practice?

AFAICS it will take effect only it the retransmission happens just after an egress AccECN packet, i.e. will not trigger if the there are more later non AccECN packets pending.

Hi Paolo,

This is a simplied implementation than what is mentieond in the RFC9768: 
"Such a host detect loss of ACKs carrying the AccECN Option by detecting whether the acknowledged data alwaysreappears as a retransmission. In such cases, the host disable the sending of the AccECN Option for this half-connection."

However, to implement the case that not that just after egressing the ACK with AccECN, I was thinking to modify struct tcp_sack_block but that maybe an over engineering.

I agree touching tcp_sack_block looks overkill. I think that the
simplified implementation is a bit too far from the RFC specification
and too simplistic to be effective. I suggest dropping this change.

Thanks,

Paolo