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.

[Tommaso Pecorella]

Hi,

two suggestions:

1) Check in the traffic logs if there is an ARP (or NDP) exchange immediately before these spikes. If there is, you found a bug (please report it).

2) Check to have the latest ns-3-dev code, I know that there have been some bug fixes.

If neither of the above helps, please get in touch with the TCP maintainers and file a bug report.

Thanks.

[Maria Eduarda Veras Martins]

Hi Tommaso,

Thanks for the suggestions!

I enabled logs for ArpCache and ArpL3Protocol. The ArpL3 protocol logs only appear at the beginning and end of the simulation, while ArpCache logs don't appear at all.

I noticed that the PointToPoint class has the NeedsArp function set to false, which I believe is the reason the cache logs aren't appearing.

I updated the ns3 version before asking this question, so everything is fine in that regard.

How can I contact the TCP maintainers for more suggestions?

[Tom Henderson]

Hello Maria,
I do not think ARP is relevant here; it is not being used by point-to-point.

I think that the delays you are observing are normal. If you want to
avoid the delays, you could turn off delayed ACKs, which would increase
the number of ACKs sent. If you instead want to filter out these
delays, you could do something like TCP LEDBAT does, which is to use the
minimum of the most recent N RTT measurements (thereby discarding the
occasional ones that are delayed due to delayed ACK mechanism).

https://www.ietf.org/archive/id/draft-irtf-iccrg-ledbat-plus-plus-03.html#name-use-of-round-trip-time-inst

ns-3 has a LEDBAT implementation and I think the attribute to control
this is called NoiseFilterLen.

- Tom

> comparacao_rtt.png

> prague_tx.png
> 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.
>

> --
> Posting to this group should follow these guidelines https://
> www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting <https://
> www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com <mailto:ns-3-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/ns-3-
> users/b1142080-0f8f-471f-b1ea-abeeefd1c81dn%40googlegroups.com <https://
> groups.google.com/d/msgid/ns-3-users/b1142080-0f8f-471f-b1ea-
> abeeefd1c81dn%40googlegroups.com?utm_medium=email&utm_source=footer>.