RTT inflation due to Delayed ACK?
Maria Eduarda Veras Martins
I am currently implementing and validating the L4S architecture in ns-3. During my validation in low-bandwidth (4 Mbps) and low-latency (5 ms base RTT) scenarios, I noticed a massive discrepancy in the RTT measurements depending on whether Delayed ACK was enabled or disabled.
To isolate the issue and rule out any bugs in my TCP Prague implementation, I decided to test the same scenario using the native TcpDctcp and RED queue models. My test uses a single flow over a single bottleneck with a 4 Mbps rate, 5 ms base RTT, and a 1448-byte segment size (script attached).
Please notice in the plots how distinct the simulations are, with the RTT degrading significantly just by enabling Delayed ACK.
My questions for the community are:
Is this severe RTT inflation an expected behavior?
Is there any additional configuration I should apply to mitigate this?
Thank you for your time and any insights!
Tom Henderson
Maria, I had a look at your test program that you had attached. I think the problem you are encountering (at least with DCTCP) is that you are running it in an operating region that is outside of DCTCP's normal operating region. Your test program has a bandwidth-delay product of 4 Mbps * 5 ms = 2500 bytes which is less than 2 TCP segments. MinTh is also less than 2 segments. Whether delayed acks are configured or not is not really the problem here; it will contribute but the baseline of no delayed acks also has high RTT because of the low bandwidth delay product.
I changed some configuration in the test program to a more typical DCTCP configuration (minTh = 500 us, bottleneck queue rate 1 Gbps, 1 ms base RTT, point to point links of 10 Gbps) and got expected DCTCP performance. Namely, the bandwidth delay product is now about 86 packets and the mean RTT is only 1.18 ms (vs. 1 ms base RTT).
As for your Prague experience, if you are seeing similar problems (that your Prague is sensitive to delayed ACKs, or is inflating RTT by a lot), I would check whether AccECN is working correctly. Prague should not be sensitive to delayed ACK configuration. Perhaps also check that your flow is getting into the L4S queue and it is marking appropriately.
- Tom
On 4/15/26 2:15 PM, Maria Eduarda Veras Martins wrote:
Hi everyone
Thank you for your time and any insights! --
Posting to this group should follow these guidelines 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.
To view this discussion visit https://groups.google.com/d/msgid/ns-3-users/994033d6-a444-484c-9cbd-5da795bb91dcn%40googlegroups.com.