Tools: NDM-TCP: Correction, Clarification, and Real Performance Results

Important Correction and Apology ## What I Got Wrong: The Cross-Connection Learning Claim ## The Incorrect Statement: ## Why It Was Wrong: ## The Missing Component: ## Why I Won't Add Global State: ## What IS Correct: Zero-Training Predictions ## The Zero-Training Article Was Actually Correct ## What "Zero-Training" Actually Means: ## Real Performance Test Results ## Test Configuration: ## Complete Test Results ## NDM-TCP Performance ## TCP Cubic Performance ## TCP Reno Performance ## Performance Comparison ## Overall Summary (20 Second Test): ## First 10 Seconds (Learning Phase): ## Last 10 Seconds (Adapted Phase): ## Within-Connection Improvement: ## Key Findings ## 1. NDM-TCP Truly Learns Within Connections ## 2. NDM-TCP Outperforms Traditional Algorithms ## 3. Better Initial Performance ## 4. Entropy-Aware Intelligence Works ## 5. All Algorithms Improve Over Time ## What "Zero-Training" Means for AI ## Prediction IS Training ## Why This Matters: ## Corrected Understanding ## What I Claim NOW (Accurate): ## What I NO LONGER Claim (Was Incorrect): ## Removed Articles ## What Remains Valid ## The "Zero-Training Performance Analysis" Article ## Test Environment Details ## Conclusion ## What The Data Shows: ## Moving Forward: Author: Muhammed Shafin P Date: 14th February 2026 Test System: Xubuntu 24.04 LTS, Linux Kernel 6.11.0 I need to correct and clarify statements made in my previous article titled "NDM-TCP vs TCP Cubic vs TCP Reno: Bandwidth-Constrained Network Performance Analysis" which has been removed from publication. In the removed article, I showed separate "Run 1" and "Run 2" tests and claimed NDM-TCP learned from the first run and improved performance in the second run. This was technically impossible and misleading. NDM-TCP's initialization function resets all internal state to zero every time a new TCP connection starts. Each separate iperf3 test creates a new connection, which means: I forgot to implement kernel global state variables that would enable persistent learning across connections. Without global state, each connection starts fresh. After careful consideration, I will not implement cross-connection global state due to the serious risk of race conditions in kernel space. When multiple TCP connections access shared variables simultaneously without perfect synchronization, it can cause: The risk of a fatal kernel bug is too high. Therefore, NDM-TCP will remain a safe, per-connection adaptive algorithm. My article "NDM-TCP: Zero-Training Performance Analysis" made a claim that I now realize was fundamentally correct but poorly explained. The correct understanding: For AI systems, prediction IS training. When NDM-TCP makes predictions about network conditions and adjusts congestion windows, it is simultaneously: This is online learning - the system learns by doing, not from pre-collected datasets. Traditional ML TCP algorithms: No offline training needed. Prediction itself IS the training process. All tests conducted on: Detailed Interval Data: Key Observation - Within-Connection Learning: This demonstrates real within-connection learning and adaptation. Detailed Interval Data: Detailed Interval Data: The data shows clear evidence of learning: The hidden state evolves with each packet, allowing NDM-TCP to adapt to network characteristics in real-time. NDM-TCP achieved the same throughput with significantly fewer retransmissions. Even in the learning phase (first 10 seconds), NDM-TCP performed better: This shows NDM-TCP's entropy-based decision making provides advantages even before full adaptation. NDM-TCP's ability to distinguish network noise from real congestion allows it to: Interesting observation: All three algorithms showed improvement from first 10 seconds to last 10 seconds: In reinforcement learning and online learning systems, making predictions and observing outcomes IS the training process. NDM-TCP's learning cycle: This is real machine learning happening in real-time, without any offline training phase. This is the true meaning of "zero-training" - the algorithm IS trained by the act of making predictions. I have removed the following article due to misleading claims about cross-connection learning: "NDM-TCP vs TCP Cubic vs TCP Reno: Bandwidth-Constrained Network Performance Analysis" The test data in that article was real, but I incorrectly attributed performance differences between separate runs to algorithmic learning rather than network variation. My article "NDM-TCP: Zero-Training Performance Analysis" made claims about zero-training that are fundamentally correct: This understanding is accurate and supported by AI/ML theory. Complete System Information: NDM-TCP demonstrably outperforms TCP Cubic and TCP Reno in this test scenario: These results are real, reproducible, and demonstrate the value of entropy-aware congestion control. Muhammed Shafin P 14th February 2026 System: Xubuntu 24.04 LTS, Linux Kernel 6.11.0 Test Interface: Loopback Network Conditions: 50 Mbit/s, 20ms±5ms latency, 0.5% loss For questions, code review, or testing feedback, I welcome community input to improve both NDM-TCP and its documentation. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. as well , this person and/or CODE_BLOCK: Step 1: Collect months of network data Step 2: Train neural network offline (hours/days) Step 3: Deploy trained model Step 4: Periodically retrain with new data Step 5: Redeploy updated model CODE_BLOCK: Step 1: Collect months of network data Step 2: Train neural network offline (hours/days) Step 3: Deploy trained model Step 4: Periodically retrain with new data Step 5: Redeploy updated model CODE_BLOCK: Step 1: Collect months of network data Step 2: Train neural network offline (hours/days) Step 3: Deploy trained model Step 4: Periodically retrain with new data Step 5: Redeploy updated model CODE_BLOCK: Step 1: Load kernel module Step 2: Start making predictions immediately Step 3: Learn from each prediction's outcome Step 4: Continuously adapt in real-time CODE_BLOCK: Step 1: Load kernel module Step 2: Start making predictions immediately Step 3: Learn from each prediction's outcome Step 4: Continuously adapt in real-time CODE_BLOCK: Step 1: Load kernel module Step 2: Start making predictions immediately Step 3: Learn from each prediction's outcome Step 4: Continuously adapt in real-time COMMAND_BLOCK: sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms COMMAND_BLOCK: sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms COMMAND_BLOCK: sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.4 Mbits/sec Receiver Bitrate: 49.2 Mbits/sec Total Retransmissions: 43 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.4 Mbits/sec Receiver Bitrate: 49.2 Mbits/sec Total Retransmissions: 43 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.4 Mbits/sec Receiver Bitrate: 49.2 Mbits/sec Total Retransmissions: 43 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.5 Mbits/sec Receiver Bitrate: 49.0 Mbits/sec Total Retransmissions: 94 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.5 Mbits/sec Receiver Bitrate: 49.0 Mbits/sec Total Retransmissions: 94 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 120 MBytes Total Received (receiver): 118 MBytes Average Bitrate (sender): 50.5 Mbits/sec Receiver Bitrate: 49.0 Mbits/sec Total Retransmissions: 94 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 119 MBytes Total Received (receiver): 117 MBytes Average Bitrate (sender): 50.1 Mbits/sec Receiver Bitrate: 48.9 Mbits/sec Total Retransmissions: 101 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 119 MBytes Total Received (receiver): 117 MBytes Average Bitrate (sender): 50.1 Mbits/sec Receiver Bitrate: 48.9 Mbits/sec Total Retransmissions: 101 Success Rate: 98.3% CODE_BLOCK: Total Transfer (sender): 119 MBytes Total Received (receiver): 117 MBytes Average Bitrate (sender): 50.1 Mbits/sec Receiver Bitrate: 48.9 Mbits/sec Total Retransmissions: 101 Success Rate: 98.3% CODE_BLOCK: Operating System: Xubuntu 24.04 LTS Linux Kernel: 6.11.0 Platform: VMware Virtual Platform Test Interface: Loopback (lo) Test Tool: iperf3 Network Emulation: Linux tc (traffic control) NDM-TCP Module: Loaded and active Cubic Module: Linux kernel default Reno Module: Linux kernel default CODE_BLOCK: Operating System: Xubuntu 24.04 LTS Linux Kernel: 6.11.0 Platform: VMware Virtual Platform Test Interface: Loopback (lo) Test Tool: iperf3 Network Emulation: Linux tc (traffic control) NDM-TCP Module: Loaded and active Cubic Module: Linux kernel default Reno Module: Linux kernel default CODE_BLOCK: Operating System: Xubuntu 24.04 LTS Linux Kernel: 6.11.0 Platform: VMware Virtual Platform Test Interface: Loopback (lo) Test Tool: iperf3 Network Emulation: Linux tc (traffic control) NDM-TCP Module: Loaded and active Cubic Module: Linux kernel default Reno Module: Linux kernel default COMMAND_BLOCK: # Network setup sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms # Run tests iperf3 -c localhost -t 20 -C ndm_tcp iperf3 -c localhost -t 20 -C cubic iperf3 -c localhost -t 20 -C reno # Cleanup sudo tc qdisc del dev lo root COMMAND_BLOCK: # Network setup sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms # Run tests iperf3 -c localhost -t 20 -C ndm_tcp iperf3 -c localhost -t 20 -C cubic iperf3 -c localhost -t 20 -C reno # Cleanup sudo tc qdisc del dev lo root COMMAND_BLOCK: # Network setup sudo tc qdisc add dev lo root handle 1: netem delay 20ms 5ms distribution normal loss 0.5% sudo tc qdisc add dev lo parent 1:1 handle 10: tbf rate 50mbit burst 5000kbit latency 50ms # Run tests iperf3 -c localhost -t 20 -C ndm_tcp iperf3 -c localhost -t 20 -C cubic iperf3 -c localhost -t 20 -C reno # Cleanup sudo tc qdisc del dev lo root - All neural network state resets to zero - No learning carries over between separate tests - Performance differences were due to normal network variation, not learning - System crashes - Kernel panics - Data corruption - Unpredictable behavior - Predicting network state - Observing the results - Updating internal state based on feedback - Learning from the experience - OS: Xubuntu 24.04 LTS - Kernel: Linux 6.11.0 - Hardware: VMware Virtual Platform - Test Tool: iperf3 - Bandwidth limit: 50 Mbit/s - Base latency: 20ms with ±5ms jitter (normal distribution) - Packet loss rate: 0.5% - Test duration: 20 seconds each - Interface: Loopback (localhost) - First 10 seconds: 32 retransmissions (learning phase) - Last 10 seconds: 11 retransmissions (adapted phase) - 65.6% reduction in retransmissions as the connection progressed - First 10 seconds: 86 retransmissions - Last 10 seconds: 8 retransmissions - Cubic also improves over time, but starts with much higher retransmissions - First 10 seconds: 88 retransmissions - Last 10 seconds: 13 retransmissions - Similar improvement pattern to Cubic - Seconds 0-10 (learning): 32 retransmissions - Seconds 10-20 (adapted): 11 retransmissions - 65.6% improvement as the connection progressed - NDM-TCP: 43 total retransmissions - Cubic: 94 retransmissions (+119% worse) - Reno: 101 retransmissions (+135% worse) - NDM-TCP: 32 retransmissions - Cubic: 86 retransmissions - Reno: 88 retransmissions - Stay aggressive when detecting random jitter (high entropy) - Back off appropriately when detecting queue buildup (low entropy) - Maintain throughput while minimizing unnecessary retransmissions - This is normal TCP behavior (slow start → congestion avoidance) - NDM-TCP's advantage is maintaining lower retransmissions throughout - The learning is about network conditions, not just TCP state - Predict: Calculate entropy, estimate congestion state - Act: Adjust congestion window based on prediction - Observe: See the result (ACKs received, packets lost) - Update: Modify hidden state based on observed outcome - Repeat: Next packet uses updated state - Requires months of data collection - Needs powerful computers for training - Must be retrained periodically - Has deployment delays - Works immediately on first packet - Learns from every prediction - Continuously adapts - No deployment overhead - Within-Connection Learning: NDM-TCP learns and adapts during a single TCP connection ✓ - Zero Offline Training: No pre-training required, works immediately ✓ - Better Efficiency: Fewer retransmissions than Cubic/Reno while maintaining throughput ✓ - Entropy Intelligence: Successfully distinguishes noise from congestion ✓ - Static Memory: 72 bytes per connection, never grows ✓ - Predictable CPU: Fixed operations per packet ✓ - Cross-Connection Learning: Cannot learn between separate tests (current implementation) - Persistent Global State: Does not retain knowledge after connection closes - NDM-TCP requires no offline training - It learns by making predictions - Prediction itself IS the training process - Performance improves within connections - Works immediately upon deployment - 54% fewer retransmissions than Cubic - 57% fewer retransmissions than Reno - Same throughput as both traditional algorithms - Clear within-connection learning (65.6% improvement first→last 10 seconds) - Accurate technical explanations - Clear distinction between within-connection and cross-connection learning - Honest presentation of both capabilities and limitations - Reproducible test methodology with complete details