How to mitigate TCP Delayed ACK RTT spikes

[Maria Eduarda Veras Martins]

Hi everyone,

I'm observing periodic ~200ms RTT spikes in a one-way TCP flow (BulkSendApplication -> PacketSink).

After a detailed analysis of ns-3 logs and PCAP traces, I've confirmed these spikes are not caused by network congestion but are an artifact of the receiver's 200ms DelAckTimeout expiring.

I also confirmed why only some packets have a high RTT: the spikes occur predictably for the last packet of a TCP transmission burst. During a burst, the "every second packet" rule correctly forces immediate ACKs, keeping the RTT low. The spikes are for the isolated packets at the end of each flight that are forced to wait for the full 200ms timer.

The plots below correlate the measured RTT (top graph) with the server's packet transmission pattern (bottom graph).

As shown, the ~200ms RTT spike for the Prague flow occurs precisely during a gap in transmissions.

My goal is to obtain "cleaner" RTT statistics that reflect network-level delays rather than this protocol-level optimization. How can I best work around this Delayed ACK behavior? I'm open to suggestions.

Thank you.

[Gabriel Ferreira]

Better post this in ns-3-users, since it is more TCP related than nr. :)