Tools: NDM-TCP vs Reno vs Cubic vs BBR: Pure Delay Test (Extreme Latency Variation)

Introduction: Testing with Pure Delay Only ## Why This Test Reveals NDM-TCP's Drawbacks ## Complete Test Results ## NDM-TCP Standard v1.0 Results ## TCP Cubic Results ## TCP Reno Results (First Run) ## TCP Reno Results (Second Run) ## BBR (Assumed v1) Results ## Comparative Analysis: First Test Series ## Overall Performance Summary ## Key Findings: NDM-TCP's Clear Drawbacks ## Why Did NDM-TCP Fail Here? ## Why Did BBR Excel Here? ## Reno's Success: ## Second Test Series: Moderate Delay Variation (Also Delay-Only) ## Introduction to Second Test Series ## Test Setup: Moderate Delay Only ## Second Series Results ## NDM-TCP Results (Moderate Delay Only) ## TCP Cubic Results (Moderate Delay Only) ## TCP Reno Results (Moderate Delay Only) ## BBR Results (Moderate Delay Only) ## Second Series Comparative Analysis ## Performance Summary: Moderate Delay Only ## Critical Findings from Second Series ## Algorithm Behavior Differences ## Combined Analysis: Both Test Series ## What the Two Test Series Reveal ## Algorithm Suitability by Network Type ## NDM-TCP's Design Limitations Confirmed ## Critical Analysis: Second Series Limitations ## Proposed Solution: Delay-Based Handling in NDM-TCP ## Current Model Limitation ## Community Support Needed ## Call to Action ## Recommendations Based on Both Test Series ## For NDM-TCP Development: ## For Users/Implementers: ## Community Testing Recommendations ## Priority 1: Real Hardware Testing ## Priority 2: Realistic Conditions ## Priority 3: Diverse Scenarios ## Priority 4: Comparative Analysis ## Conclusions from Both Test Series ## First Series (Extreme Delay ±200ms) Conclusions: ## Second Series (Moderate Delay ±100ms) Conclusions: ## Root Cause Identified: ## Overall Assessment: ## Proposed Path Forward: ## Final Recommendation: ## Key Takeaway: ## Call for Community Support ## We Need Your Help! ## Final Notes GitHub Repository: https://github.com/hejhdiss/lkm-ndm-tcp This article presents a unique test scenario: pure delay-only testing with extreme latency variation. Unlike previous tests that combined delay with packet loss, bandwidth limits, and other constraints, this test uses only delay to observe how each algorithm responds to highly variable round-trip times. BBR Version Note: BBR is assumed to be v1, as the source code does not contain explicit version information. Even though this is an artificial loopback test, NDM-TCP shows clear drawbacks in this scenario. Critical Context: Pure Delay-Only Networks Don't Exist in Reality This pure delay-only test is highly unusual because the chance of a normal network acting as only pure delay-based is around zero. Real networks with high latency variation also always have: This test environment is purely artificial and doesn't represent real-world conditions. In production networks, you will never encounter pure delay variation without any packet loss or other network effects. However, NDM-TCP Still Needs Updates to Handle This: Even though this is an artificial scenario with near-zero probability in real networks, NDM-TCP should be able to handle even these artificial edge cases. A robust algorithm should work across all conditions, including purely theoretical ones. The fact that NDM-TCP fails in this artificial scenario indicates a design gap that needs addressing, even if this exact scenario will never occur in practice. We don't know if this type of environment can be compared to any real-world case. This is purely an experimental localhost scenario to observe algorithm behavior under extreme delay variation without other confounding factors. But the algorithm should still be robust enough to handle it. 1. NDM-TCP Performed Worst in Throughput: 2. BBR Performed Best in Throughput: 3. Reno Showed Balanced Performance: 4. Cubic Similar to NDM-TCP: NDM-TCP's Drawbacks Exposed: Overly Conservative with Pure Delay: Entropy Detection Failed: No Adaptation Mechanism for Pure Delay: BBR's Design Matches This Scenario: Delay-Based Algorithm: Model-Based Approach: Following the pure delay tests with extreme variation, a second series of tests was conducted with moderate delay variation, also delay-only. This test series aims to determine whether NDM-TCP's poor performance was due to the extreme delay variation (±200ms) or if the algorithm struggles with any delay-only scenario. Important Context: This is Also Purely Artificial Like the first test series, the chance of a normal network acting as only pure delay-based is around zero. Real-world networks always combine delay with packet loss, bandwidth constraints, queueing, and other effects. This second test is also purely artificial and will never occur in production environments. However, even though both test series are artificial with near-zero real-world probability, NDM-TCP should still be robust enough to handle these edge cases. A well-designed algorithm should work across all conditions, including purely theoretical ones, even if they'll never happen in practice. Rationale for Second Test Series: 1. NDM-TCP Shows Dramatic Recovery with Moderate Delay: 2. Delay Variation Magnitude Matters: 3. BBR Still Dominates but Shows Impact: 4. Both Tests Were Delay-Only - Rankings: Extreme Delay (±200ms) Rankings: Moderate Delay (±100ms) Rankings: NDM-TCP with Moderate Delay: Cubic with Moderate Delay: Reno with Moderate Delay: BBR with Moderate Delay: Extreme Delay Test (±200ms) Revealed: Moderate Delay Test (±100ms) Revealed: Key Insight: The magnitude of delay variation matters significantly. Moderate delay (±100ms) allows traditional algorithms to function adequately, while extreme delay (±200ms) breaks most algorithms except BBR. Note: We have only tested delay-only scenarios. Performance with packet loss, bandwidth constraints, and other real-world conditions remains unknown. The second test series confirms: Sensitivity to Delay Variation Magnitude: Not Suited for Extreme Delay Scenarios: Conservative by Design: Better Than Initial Impression But Still Limited: Second Test Series Also Artificial: Still Localhost Testing: Simplified Delay Model: No Bandwidth Constraints: Networks with Only Delay Have Near-Zero Probability: What This Still Doesn't Tell Us: NDM-TCP's neural network currently has 10 inputs: I am requesting community support for this enhancement: Why Community Support Matters: This enhancement would transform NDM-TCP from an algorithm that fails in pure delay to one that handles both loss and delay effectively. PRIORITY: Implement Delay-Based Handling (Use Dummy Inputs 7-8): The most critical enhancement needed is adding delay-based computation to currently unused model inputs 7 and 8. This would: Specific Implementation Steps: Add Pure Delay Handling: Reduce Over-Conservatism: Improve Entropy Detection: Community Support Required: This enhancement requires community involvement for development, testing, and validation. See "Community Support Needed" section above for how to contribute. Avoid NDM-TCP for (until delay-based enhancement is implemented): Consider NDM-TCP for: Prefer Established Algorithms (current recommendation): Future Recommendation (after delay-based enhancement): Once inputs 7-8 are utilized for delay handling, NDM-TCP could become competitive and worth considering for production use. Community testing will determine this. Based on both test series, community members should test: The Design Intent: NDM-TCP was designed to work with both delay and loss conditions. The algorithm should handle networks with varying delay, packet loss, or both simultaneously. What These Tests Revealed: However, these two test series (extreme delay and moderate delay - both delay-only) showed that NDM-TCP is not working as designed in these specific scenarios. The algorithm failed in extreme delay and underperformed significantly in moderate delay. These are the only two test conditions we've evaluated so far, but both revealed problems with delay-only scenarios. Important Note: Both test series were delay-only without any packet loss. We have not yet tested NDM-TCP with packet loss present, bandwidth constraints, or other real-world network conditions. Earlier tests mentioned showed NDM-TCP working with delay+loss combinations. The Technical Problem: NDM-TCP uses only 6 out of 10 neural network inputs. Inputs 7 and 8 are currently DUMMY (unused), and delay information is not computed or utilized for adaptation. While the algorithm was intended to work with delay conditions, the implementation is incomplete for handling delay variation properly. The Solution: Add delay-based handling to inputs 7-8: Why This Matters: Networks with only delay (and no loss) have near-zero probability in reality - they simply don't exist. Real networks always combine delay with packet loss, bandwidth limits, queueing, and other constraints. This makes both test series completely artificial with no real-world equivalent. However, proper delay handling would still make NDM-TCP work as originally intended - robust across ALL network types, including even these artificial edge cases that will never occur in practice. The current implementation doesn't match the design goals and should be updated to handle even theoretical scenarios, even though the chance of encountering pure delay-only conditions in normal networks is around zero. NDM-TCP's Design Intent: NDM-TCP's Actual Performance (Based on These Two Delay-Only Tests): These two specific test cases revealed problems that were unexpected. NDM-TCP does not work properly in these two artificial delay-only scenarios (extreme delay ±200ms and moderate delay ±100ms on localhost). The algorithm shows significant sensitivity to delay variation magnitude - extreme variation causes failure, moderate variation allows adequate function but still underperforms. These unexpected failures in delay-only scenarios indicate that an update is needed in v1. The algorithm needs enhancement to handle delay variation more robustly without relying solely on packet loss signals. Earlier tests with delay and loss conditions showed NDM-TCP working, even though those were also artificial environments. Important Note: We've only tested two conditions so far: pure delay and delay+loss on localhost. NDM-TCP is not working as intended in either scenario. More testing on different network types and real hardware is needed to fully understand its capabilities and limitations. Established Algorithms: Immediate Action Required: Expected Outcome After Enhancement: For Current Production Use: For Future (After Delay-Based Enhancement): NDM-TCP could become a strong contender if the community helps implement delay-based handling in inputs 7-8. This would address all identified weaknesses. For Research/Development (Now): Both test series consistently show NDM-TCP underperforming established algorithms. However, the root cause is identified and fixable: add delay-based computation to currently unused model inputs 7 and 8. This is not a fundamental flaw - it's an incomplete implementation that can be fixed with community support. While the second series demonstrates NDM-TCP can function when given appropriate signals (packet loss), implementing delay-based handling would make it robust across all network types without requiring loss signals. Community validation on real networks remains essential, both to confirm current findings and to validate the proposed delay-based enhancement. NDM-TCP is an open-source project that revealed clear limitations in these tests. However, we've identified a specific solution: utilize dummy inputs 7-8 for delay-based adaptation. GitHub Repository: https://github.com/hejhdiss/lkm-ndm-tcp We welcome community contributions in any form. If you're a developer, you can implement your own version of delay-based handling for inputs 7 and 8. Researchers can design alternative metrics and validate approaches. Network engineers and students can test on real networks and share results. Everyone can provide feedback, suggest improvements, and help spread the word. Create your own solution. Test it. Share your findings. The goal is to improve NDM-TCP through collaborative effort, not prescribe one specific implementation. Your approach might be better than what's proposed here. Together, we can transform NDM-TCP from an incomplete algorithm to a competitive, production-ready TCP variant that handles both loss and delay effectively. Critical Reality Check: The chance of encountering pure delay-only networks in reality is around zero. Real networks always have packet loss, bandwidth constraints, queueing effects, and multiple simultaneous impairments. These test scenarios are completely artificial and will never occur in production environments. However, a robust algorithm should still handle even these theoretical edge cases, which is why NDM-TCP needs updates despite the artificial nature of these tests. Both series limitations: Honest Assessment: NDM-TCP has clear, documented limitations in these artificial delay-only scenarios. The algorithm shows interesting concepts but needs enhancement to handle even theoretical edge cases robustly. Even though these scenarios have near-zero probability in real networks, the updates would improve overall algorithm robustness and completeness. Disclaimer: All results from artificial localhost testing with pure delay-only constraints and tc-emulated conditions. The probability of encountering pure delay-only conditions in real networks is around zero - real networks always have packet loss, bandwidth limits, queueing, and other constraints simultaneously. BBR is assumed to be v1. These test scenarios are completely artificial and will never occur in production environments. However, NDM-TCP should still be robust enough to handle even these theoretical cases. Performance on real hardware with realistic network conditions (including packet loss) may differ significantly. Community validation on real networks with packet loss and other real-world constraints is essential to determine practical applicability of these findings. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C ndm_tcp Network: delay 100ms 200ms distribution normal Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C ndm_tcp Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C ndm_tcp Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C cubic Network: delay 100ms 200ms distribution normal Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C cubic Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C cubic Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno Network: delay 100ms 200ms distribution normal Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno (repeated) Network: delay 100ms 200ms distribution normal Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno (repeated) Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C reno (repeated) Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C bbr Network: delay 100ms 200ms distribution normal Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C bbr Network: delay 100ms 200ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 40 -C bbr Network: delay 100ms 200ms distribution normal COMMAND_BLOCK: sudo tc qdisc add dev lo root netem delay 50ms 100ms distribution normal Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: sudo tc qdisc add dev lo root netem delay 50ms 100ms distribution normal COMMAND_BLOCK: sudo tc qdisc add dev lo root netem delay 50ms 100ms distribution normal CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C ndm_tcp Network: delay 50ms 100ms distribution normal (NO packet loss) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C ndm_tcp Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C ndm_tcp Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C cubic Network: delay 50ms 100ms distribution normal (NO packet loss) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C cubic Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C cubic Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C reno Network: delay 50ms 100ms distribution normal (NO packet loss) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C reno Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C reno Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C bbr Network: delay 50ms 100ms distribution normal (NO packet loss) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C bbr Network: delay 50ms 100ms distribution normal (NO packet loss) CODE_BLOCK: Test Command: iperf3 -c localhost -t 60 -C bbr Network: delay 50ms 100ms distribution normal (NO packet loss) - Network Constraint: sudo tc qdisc add dev lo root netem delay 100ms 200ms distribution normal - Base Delay: 100ms - Delay Variation: ±200ms (normal distribution) - Resulting Delay Range: Approximately 0ms to 300ms+ (extreme variation) - NO packet loss, NO bandwidth limits, NO duplication/reordering - Test Duration: 40 seconds - Test Environment: Localhost (127.0.0.1) on Xubuntu 24.04, VMware 17, Linux kernel 6.11.0 - Packet loss (congestion, interference, radio issues) - Bandwidth constraints (link capacity limits) - Queueing behavior (bufferbloat, queue drops) - Jitter patterns correlated with congestion - Multiple simultaneous impairments - Total Transfer (Sender): 32.5 MB - Average Bitrate (Sender): 6.82 Mbps - Total Retransmissions: 34 - Total Transfer (Receiver): 29.9 MB - Average Bitrate (Receiver): 6.26 Mbps - Zero-throughput intervals: 20 out of 40 (50%) - Total Transfer (Sender): 32.8 MB - Average Bitrate (Sender): 6.87 Mbps - Total Retransmissions: 54 - Total Transfer (Receiver): 30.4 MB - Average Bitrate (Receiver): 6.34 Mbps - Zero-throughput intervals: 6 out of 40 (15%) - Total Transfer (Sender): 64.4 MB - Average Bitrate (Sender): 13.5 Mbps - Total Retransmissions: 76 - Total Transfer (Receiver): 61.2 MB - Average Bitrate (Receiver): 12.8 Mbps - Total Transfer (Sender): 75.0 MB - Average Bitrate (Sender): 15.7 Mbps - Total Retransmissions: 78 - Total Transfer (Receiver): 72.6 MB - Average Bitrate (Receiver): 15.2 Mbps - Zero-throughput intervals: 1 out of 40 (2.5%) - Total Transfer (Sender): 389 MB - Average Bitrate (Sender): 81.6 Mbps - Total Retransmissions: 885 - Total Transfer (Receiver): 389 MB - Average Bitrate (Receiver): 81.1 Mbps - Zero-throughput intervals: 0 out of 40 (0%) - 6.82 Mbps - lowest average bitrate - 50% of intervals with zero throughput (20 out of 40 seconds) - Only transferred 32.5 MB over 40 seconds - Cwnd remained very small (63.9 KB - 256 KB range) - 81.6 Mbps - highest average bitrate (12x better than NDM-TCP) - No zero-throughput intervals - Transferred 389 MB (12x more than NDM-TCP) - However: 885 retransmissions (26x more than NDM-TCP) - 13.5-15.7 Mbps - moderate throughput (2x better than NDM-TCP) - Only 1 zero-throughput interval - 76-78 retransmissions (2.2x more than NDM-TCP) - More consistent than NDM-TCP - 6.87 Mbps - nearly identical to NDM-TCP - 54 retransmissions (1.6x more than NDM-TCP) - 6 zero-throughput intervals (much better than NDM-TCP's 20) - Overly Conservative with Pure Delay: Extreme delay variation (0-300ms) confused NDM-TCP's entropy detection The algorithm became too cautious Cwnd remained extremely small (63.9-256 KB) Half the test time had zero throughput - Extreme delay variation (0-300ms) confused NDM-TCP's entropy detection - The algorithm became too cautious - Cwnd remained extremely small (63.9-256 KB) - Half the test time had zero throughput - Entropy Detection Failed: Without packet loss or other signals, entropy from RTT variation alone wasn't sufficient The algorithm couldn't distinguish "safe to send" from "dangerous to send" Default behavior: be extremely conservative = zero throughput - Without packet loss or other signals, entropy from RTT variation alone wasn't sufficient - The algorithm couldn't distinguish "safe to send" from "dangerous to send" - Default behavior: be extremely conservative = zero throughput - Timeout Issues: With delays up to 300ms+, packets likely timed out NDM-TCP's conservative response to timeouts: reduce cwnd drastically Result: alternating between brief transmission and long pauses - With delays up to 300ms+, packets likely timed out - NDM-TCP's conservative response to timeouts: reduce cwnd drastically - Result: alternating between brief transmission and long pauses - No Adaptation Mechanism for Pure Delay: NDM-TCP's neural network and entropy calculation work well with loss patterns Pure delay variation without loss doesn't trigger proper adaptive responses The algorithm got "stuck" in ultra-conservative mode - NDM-TCP's neural network and entropy calculation work well with loss patterns - Pure delay variation without loss doesn't trigger proper adaptive responses - The algorithm got "stuck" in ultra-conservative mode - Extreme delay variation (0-300ms) confused NDM-TCP's entropy detection - The algorithm became too cautious - Cwnd remained extremely small (63.9-256 KB) - Half the test time had zero throughput - Without packet loss or other signals, entropy from RTT variation alone wasn't sufficient - The algorithm couldn't distinguish "safe to send" from "dangerous to send" - Default behavior: be extremely conservative = zero throughput - With delays up to 300ms+, packets likely timed out - NDM-TCP's conservative response to timeouts: reduce cwnd drastically - Result: alternating between brief transmission and long pauses - NDM-TCP's neural network and entropy calculation work well with loss patterns - Pure delay variation without loss doesn't trigger proper adaptive responses - The algorithm got "stuck" in ultra-conservative mode - Delay-Based Algorithm: BBR measures RTT and bottleneck bandwidth directly High delay variation doesn't confuse it—it adapts cwnd based on measured capacity Continued to probe aggressively throughout the test - BBR measures RTT and bottleneck bandwidth directly - High delay variation doesn't confuse it—it adapts cwnd based on measured capacity - Continued to probe aggressively throughout the test - Probing Behavior: Constantly probing for available bandwidth Not deterred by delay variation Willing to tolerate retransmissions (885) to maintain high throughput - Constantly probing for available bandwidth - Not deterred by delay variation - Willing to tolerate retransmissions (885) to maintain high throughput - Model-Based Approach: BBR's model of bottleneck bandwidth worked well here No artificial bandwidth limit meant BBR could scale cwnd appropriately Delay variation didn't stop bandwidth estimation - BBR's model of bottleneck bandwidth worked well here - No artificial bandwidth limit meant BBR could scale cwnd appropriately - Delay variation didn't stop bandwidth estimation - BBR measures RTT and bottleneck bandwidth directly - High delay variation doesn't confuse it—it adapts cwnd based on measured capacity - Continued to probe aggressively throughout the test - Constantly probing for available bandwidth - Not deterred by delay variation - Willing to tolerate retransmissions (885) to maintain high throughput - BBR's model of bottleneck bandwidth worked well here - No artificial bandwidth limit meant BBR could scale cwnd appropriately - Delay variation didn't stop bandwidth estimation - Traditional loss-based algorithm handled pure delay reasonably well - Additive increase allowed it to scale cwnd gradually - 76-78 retransmissions were acceptable for 2-2.3x better throughput than NDM-TCP - Only 1 zero-throughput interval shows better consistency - Base Delay: 50ms - Delay Variation: ±100ms (normal distribution) - Resulting Delay Range: Approximately 0ms to 150ms (moderate variation) - NO packet loss, NO bandwidth limits, NO duplication/reordering - Test Duration: 60 seconds (longer than first series) - Test Environment: Same (Localhost, Xubuntu 24.04, VMware 17, Linux kernel 6.11.0) - More moderate delay variation (±100ms vs ±200ms from first test) - Still delay-only (no packet loss added) - Tests whether NDM-TCP can handle moderate delay variation - 60-second duration for more statistical stability - Determines if the problem is extreme variation or delay-only scenarios in general - Total Transfer (Sender): 156 MB - Average Bitrate (Sender): 21.8 Mbps - Total Retransmissions: 142 - Total Transfer (Receiver): 152 MB - Average Bitrate (Receiver): 21.2 Mbps - Zero-throughput intervals: 3 out of 60 (5%) - Average Cwnd: 384 KB - 512 KB range - Significant improvement compared to extreme delay test (21.8 Mbps vs 6.82 Mbps) - Only 5% zero-throughput intervals vs 50% in extreme delay - Higher and more stable cwnd values - Still delay-only, but moderate variation helped - Shows NDM-TCP can handle moderate delay better than extreme delay - Total Transfer (Sender): 168 MB - Average Bitrate (Sender): 23.5 Mbps - Total Retransmissions: 178 - Total Transfer (Receiver): 164 MB - Average Bitrate (Receiver): 22.9 Mbps - Zero-throughput intervals: 2 out of 60 (3.3%) - Average Cwnd: 512 KB - 768 KB range - Slightly better than NDM-TCP (23.5 Mbps vs 21.8 Mbps) - More retransmissions than NDM-TCP (178 vs 142) - Similar zero-throughput interval rate - Moderate delay allows cubic growth curve to function better - Total Transfer (Sender): 195 MB - Average Bitrate (Sender): 27.3 Mbps - Total Retransmissions: 224 - Total Transfer (Receiver): 189 MB - Average Bitrate (Receiver): 26.4 Mbps - Zero-throughput intervals: 1 out of 60 (1.7%) - Average Cwnd: 576 KB - 896 KB range - Best loss-based algorithm performance (27.3 Mbps) - More aggressive than NDM-TCP and Cubic - Higher retransmissions but better throughput - Consistent performance throughout test - Handles moderate delay variation well - Total Transfer (Sender): 412 MB - Average Bitrate (Sender): 57.6 Mbps - Total Retransmissions: 1,247 - Total Transfer (Receiver): 409 MB - Average Bitrate (Receiver): 57.1 Mbps - Zero-throughput intervals: 0 out of 60 (0%) - Average Cwnd: 1.2 MB - 1.8 MB range - Still highest throughput (57.6 Mbps) - Lower throughput than extreme delay test (57.6 Mbps vs 81.6 Mbps) - Moderate delay still allows aggressive probing - Significantly high retransmissions (1,247) - No stalling despite delay variation - BBR's delay-based design effective even with moderate variation - 220% improvement with moderate vs extreme delay (6.82 → 21.8 Mbps) - Zero-throughput intervals reduced from 50% to 5% - Cwnd stability improved significantly - Still delay-only, but moderate variation is manageable - All algorithms improved with moderate delay (±100ms) vs extreme delay (±200ms) - NDM-TCP and Cubic showed the largest relative improvements - Suggests these algorithms have thresholds for delay tolerance - 57.6 Mbps still highest (2.6x better than NDM-TCP) - 29% throughput reduction compared to extreme delay - Retransmission rate increased by 41% (885 → 1,247) - Even BBR affected by delay variation magnitude - BBR: 81.6 Mbps - Reno: 13.5-15.7 Mbps - Cubic: 6.87 Mbps - NDM-TCP: 6.82 Mbps - BBR: 57.6 Mbps - Reno: 27.3 Mbps - Cubic: 23.5 Mbps - NDM-TCP: 21.8 Mbps - ✅ Much better than extreme delay - ✅ Adaptive cwnd adjustment improves - ✅ Low zero-throughput intervals (5%) - ⚠️ Still conservative compared to Reno - ⚠️ Still lowest throughput overall - ⚠️ Lacks specific delay-handling logic - ✅ Significant improvement over extreme delay - ✅ Better than NDM-TCP in moderate conditions - ⚠️ Still more conservative than Reno - ⚠️ Higher retransmissions than NDM-TCP - ✅ Best traditional algorithm performance - ✅ Consistent across both delay variations - ✅ Balanced throughput/retransmission ratio - ⚠️ Can't compete with BBR - ✅ Still highest absolute throughput - ❌ Throughput reduced with moderate vs extreme delay - ❌ Very high retransmissions (1,247) - ⚠️ Aggressive probing creates retransmissions even without packet loss - NDM-TCP's critical weakness: cannot handle extreme delay variation - BBR's strength in high delay variation scenarios - Reno's surprising robustness - All loss-based algorithms struggle with extreme delay - NDM-TCP recovers significantly with moderate delay variation - All algorithms perform better with moderate vs extreme delay - BBR's throughput advantage diminishes with moderate delay - Both tests were delay-only - no packet loss in either series - Sensitivity to Delay Variation Magnitude: NDM-TCP struggles with extreme delay variation (±200ms) NDM-TCP can handle moderate delay variation (±100ms) much better 220% performance improvement shows threshold exists Algorithm needs enhancement for wide delay ranges - NDM-TCP struggles with extreme delay variation (±200ms) - NDM-TCP can handle moderate delay variation (±100ms) much better - 220% performance improvement shows threshold exists - Algorithm needs enhancement for wide delay ranges - Not Suited for Extreme Delay Scenarios: Even with recovery in moderate delay tests NDM-TCP still performed worst overall in both series Cannot compete with traditional algorithms - Even with recovery in moderate delay tests - NDM-TCP still performed worst overall in both series - Cannot compete with traditional algorithms - Conservative by Design: Even when functional (moderate delay), NDM-TCP is most conservative 21.8 Mbps vs Reno's 27.3 Mbps in same conditions Lower throughput is intentional (safety vs performance trade-off) - Even when functional (moderate delay), NDM-TCP is most conservative - 21.8 Mbps vs Reno's 27.3 Mbps in same conditions - Lower throughput is intentional (safety vs performance trade-off) - Better Than Initial Impression But Still Limited: First test series (extreme delay) showed worst-case scenario Second series (moderate delay) shows NDM-TCP can function adequately Still not competitive with established algorithms in either case Both tests were delay-only - behavior with packet loss unknown - First test series (extreme delay) showed worst-case scenario - Second series (moderate delay) shows NDM-TCP can function adequately - Still not competitive with established algorithms in either case - Both tests were delay-only - behavior with packet loss unknown - NDM-TCP struggles with extreme delay variation (±200ms) - NDM-TCP can handle moderate delay variation (±100ms) much better - 220% performance improvement shows threshold exists - Algorithm needs enhancement for wide delay ranges - Even with recovery in moderate delay tests - NDM-TCP still performed worst overall in both series - Cannot compete with traditional algorithms - Even when functional (moderate delay), NDM-TCP is most conservative - 21.8 Mbps vs Reno's 27.3 Mbps in same conditions - Lower throughput is intentional (safety vs performance trade-off) - First test series (extreme delay) showed worst-case scenario - Second series (moderate delay) shows NDM-TCP can function adequately - Still not competitive with established algorithms in either case - Both tests were delay-only - behavior with packet loss unknown - Still Localhost Testing: No real network hardware tc-emulated conditions VMware virtualization layer - No real network hardware - tc-emulated conditions - VMware virtualization layer - Simplified Delay Model: Random delay variation (not realistic delay patterns) Real delay correlated with network congestion and routing No correlation with queue depth or bandwidth utilization - Random delay variation (not realistic delay patterns) - Real delay correlated with network congestion and routing - No correlation with queue depth or bandwidth utilization - No Bandwidth Constraints: Localhost essentially unlimited bandwidth Real networks have capacity limits Queue behavior missing - Localhost essentially unlimited bandwidth - Real networks have capacity limits - Queue behavior missing - Short Test Duration: 60 seconds insufficient for long-term behavior Real world: hours, days of operation Transient effects may dominate - 60 seconds insufficient for long-term behavior - Real world: hours, days of operation - Transient effects may dominate - Networks with Only Delay Have Near-Zero Probability: Pure delay-only networks don't exist in reality - chance is around zero Real-world networks always have some combination of delay + loss + bandwidth constraints + queueing Second test series still completely artificial by having only delay variation Most production networks have multiple simultaneous constraints However, NDM-TCP should still handle even these artificial cases with near-zero real-world probability - Pure delay-only networks don't exist in reality - chance is around zero - Real-world networks always have some combination of delay + loss + bandwidth constraints + queueing - Second test series still completely artificial by having only delay variation - Most production networks have multiple simultaneous constraints - However, NDM-TCP should still handle even these artificial cases with near-zero real-world probability - No real network hardware - tc-emulated conditions - VMware virtualization layer - Random delay variation (not realistic delay patterns) - Real delay correlated with network congestion and routing - No correlation with queue depth or bandwidth utilization - Localhost essentially unlimited bandwidth - Real networks have capacity limits - Queue behavior missing - 60 seconds insufficient for long-term behavior - Real world: hours, days of operation - Transient effects may dominate - Pure delay-only networks don't exist in reality - chance is around zero - Real-world networks always have some combination of delay + loss + bandwidth constraints + queueing - Second test series still completely artificial by having only delay variation - Most production networks have multiple simultaneous constraints - However, NDM-TCP should still handle even these artificial cases with near-zero real-world probability - Performance on real satellite links - Behavior on actual mobile networks - Long-term stability over hours/days - Interaction with real queueing disciplines - Performance under realistic traffic patterns - Behavior with competing flows - Most importantly: Performance with packet loss present (not tested in either series) - Inputs 1-6: Active features (RTT, loss rate, cwnd, etc.) - Inputs 7-8: Currently DUMMY inputs (not used) - Inputs 9-10: Other active features - NDM-TCP relies entirely on loss-based entropy calculation - Dummy inputs 7-8 are not utilized for delay-based adaptation - Algorithm fails in pure delay scenarios because it has no delay-specific logic - Even in delay+loss scenarios, delay information is underutilized - Development Support: Help implement delay-based computations Assist with neural network retraining Code review and testing Algorithm optimization - Help implement delay-based computations - Assist with neural network retraining - Code review and testing - Algorithm optimization - Testing Support: Test on various network conditions Validate on real hardware (not just localhost) Long-duration stability testing Compare against established algorithms - Test on various network conditions - Validate on real hardware (not just localhost) - Long-duration stability testing - Compare against established algorithms - Research Support: Determine optimal entropy weighting (loss vs delay) Find best RTT variation thresholds Research delay-based cwnd control strategies Academic validation and publication - Determine optimal entropy weighting (loss vs delay) - Find best RTT variation thresholds - Research delay-based cwnd control strategies - Academic validation and publication - Feedback: Review proposed approach Suggest improvements Share results from your networks Report edge cases and issues - Review proposed approach - Suggest improvements - Share results from your networks - Report edge cases and issues - Help implement delay-based computations - Assist with neural network retraining - Code review and testing - Algorithm optimization - Test on various network conditions - Validate on real hardware (not just localhost) - Long-duration stability testing - Compare against established algorithms - Determine optimal entropy weighting (loss vs delay) - Find best RTT variation thresholds - Research delay-based cwnd control strategies - Academic validation and publication - Review proposed approach - Suggest improvements - Share results from your networks - Report edge cases and issues - NDM-TCP is an open-source project (GitHub: hejhdiss/lkm-ndm-tcp) - These test results show clear limitations - The proposed solution requires extensive validation - Community testing on real networks is essential - Diverse network conditions need coverage - Independent verification builds credibility - Developers: Contribute code for delay-based handling - Researchers: Help design and validate the approach - Network Engineers: Test on your production networks - Students: Use this as a research project - Anyone: Share feedback and results - GitHub Repository: https://github.com/hejhdiss/lkm-ndm-tcp - Open issues for discussion - Submit pull requests - Share test results - Fix NDM-TCP's delay-only weakness - Make it competitive with established algorithms - Validate on real-world networks - Contribute to TCP research - Fix the pure delay scenario failure completely - Make NDM-TCP competitive across all network types - Utilize existing model capacity (no architecture change needed) - Enable both loss-based and delay-based adaptation - Add Pure Delay Handling: Utilize input 7 for RTT variation metrics Utilize input 8 for RTT gradient computation Implement delay-based entropy calculation Combine with existing loss-based entropy - Utilize input 7 for RTT variation metrics - Utilize input 8 for RTT gradient computation - Implement delay-based entropy calculation - Combine with existing loss-based entropy - Reduce Over-Conservatism: Current design sacrifices too much throughput for safety Consider more aggressive probing when signals are weak Balance safety and performance better Use delay signals to guide aggressiveness - Current design sacrifices too much throughput for safety - Consider more aggressive probing when signals are weak - Balance safety and performance better - Use delay signals to guide aggressiveness - Improve Entropy Detection: Current entropy calculation insufficient for delay-only Add delay-based entropy alongside loss-based entropy Weighted combination: total_entropy = loss_entropy * 0.6 + delay_entropy * 0.4 Consider hybrid approaches (RTT + loss + bandwidth) - Current entropy calculation insufficient for delay-only - Add delay-based entropy alongside loss-based entropy - Weighted combination: total_entropy = loss_entropy * 0.6 + delay_entropy * 0.4 - Consider hybrid approaches (RTT + loss + bandwidth) - Utilize input 7 for RTT variation metrics - Utilize input 8 for RTT gradient computation - Implement delay-based entropy calculation - Combine with existing loss-based entropy - Current design sacrifices too much throughput for safety - Consider more aggressive probing when signals are weak - Balance safety and performance better - Use delay signals to guide aggressiveness - Current entropy calculation insufficient for delay-only - Add delay-based entropy alongside loss-based entropy - Weighted combination: total_entropy = loss_entropy * 0.6 + delay_entropy * 0.4 - Consider hybrid approaches (RTT + loss + bandwidth) - Avoid NDM-TCP for (until delay-based enhancement is implemented): Networks with primarily delay variation High-delay, low-loss environments Applications requiring maximum throughput - Networks with primarily delay variation - High-delay, low-loss environments - Applications requiring maximum throughput - Consider NDM-TCP for: Networks with clear loss patterns Scenarios where conservative behavior is acceptable Experimental/research purposes Contributing to development (testing, feedback) - Networks with clear loss patterns - Scenarios where conservative behavior is acceptable - Experimental/research purposes - Contributing to development (testing, feedback) - Prefer Established Algorithms (current recommendation): Reno: balanced, consistent, well-understood Cubic: default in most systems, generally good BBR: maximum throughput, accepts higher retransmissions - Reno: balanced, consistent, well-understood - Cubic: default in most systems, generally good - BBR: maximum throughput, accepts higher retransmissions - Networks with primarily delay variation - High-delay, low-loss environments - Applications requiring maximum throughput - Networks with clear loss patterns - Scenarios where conservative behavior is acceptable - Experimental/research purposes - Contributing to development (testing, feedback) - Reno: balanced, consistent, well-understood - Cubic: default in most systems, generally good - BBR: maximum throughput, accepts higher retransmissions - Actual satellite connections (not simulated) - Real mobile networks (4G/5G) - Production internet paths - Various geographic distances - Multiple competing flows - Real traffic patterns (not just iperf) - Mixed application types - Long-duration tests (hours/days) - Various delay ranges (10ms to 500ms) - Different loss rates (0.1% to 5%) - Bandwidth constraints (1Mbps to 1Gbps) - Queue discipline effects (fq_codel, cake, etc.) - Test all algorithms in identical conditions - Document cwnd evolution over time - Measure fairness with competing flows - Assess application-level impact - NDM-TCP has fundamental weakness in extreme delay variation scenarios - BBR clearly superior for extreme delay variation - Reno surprisingly robust across conditions - Critical limitation exposed - but fixable! - NDM-TCP recovers substantially with moderate delay variation - Still underperforms traditional algorithms - Conservative design limits throughput - Can function adequately but not competitively - Input 7: RTT variation metric - Input 8: RTT gradient computation - Implement delay-based entropy - Combine loss and delay signals - ✅ Designed to work with delay and loss conditions - ✅ Should handle variable delay networks - ✅ Should adapt to packet loss - ✅ Should work in combined scenarios - ✅ Has unused model capacity (inputs 7-8) that can fix this! - ✅ Reno: most balanced and consistent - ✅ Cubic: good default choice - ✅ BBR: maximum throughput leader - ⚠️ BBR: very high retransmissions under loss - Implement delay-based handling in dummy inputs 7-8 - Retrain neural network with new delay-based features - Community testing on real networks - Validate improvements with new test series - ✅ Handle pure delay scenarios (no stalling) - ✅ Improved delay+loss performance - ✅ Competitive with established algorithms - ✅ Comprehensive network awareness - ✅ Production-ready - First Choice: TCP Reno (balanced, reliable) - Second Choice: TCP Cubic (good general performance) - Third Choice: BBR (if maximum throughput needed and retransmissions acceptable) - Avoid (for now): NDM-TCP (not competitive, design limitations) - NDM-TCP interesting as experimental algorithm - Clear path to improvement identified (use inputs 7-8) - Community support needed for implementation - Testing on real networks essential - Series 1: Extreme delay variation (±200ms) - exposed critical weakness - Series 2: Moderate delay variation (±100ms) - showed recovery but still weakest - Both series: Purely delay-only with NO packet loss - Localhost testing (not real networks) - Artificial tc constraints (not real conditions) - Short duration (not long-term behavior) - Simplified models (not realistic patterns) - Near-zero real-world probability (pure delay-only doesn't exist) - Real hardware testing with packet loss present - Production network validation - Long-term stability assessment - Realistic traffic patterns - Independent community verification - Testing with bandwidth constraints and queueing