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
On 9/18/25 6:21 PM, chia-yu.chang@nokia-bell-labs.com wrote:
From: Chia-Yu Chang chia-yu.chang@nokia-bell-labs.com
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