On 9/25/25 4:46 PM, Chia-Yu Chang (Nokia) wrote: >From: Paolo Abeni <[email protected]> Sent: Tuesday, September 23, 2025 12:52 >PM >> On 9/18/25 6:21 PM, [email protected] wrote: >>> From: Chia-Yu Chang <[email protected]> >>> >>> 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
