Frequent route changes in modern SDN-based net works are known to severely degrade the performance of TCP Cubic. This degradation is caused by two factors: sudden RTT changes, and packet reordering which Cubic misinterprets as congestion. This research investigates how a modern alter native, BBRv3, performs under these same conditions. Using ns-3 simulations with rerouting intervals of 3, 5, and 10seconds, we show that BBRv3is significantly more resilient. While Cubic through put is reduced by nearly 50% at 3-second intervals, BBRv3 performance degrades by less than 10%, as its probing mechanism does not use packet re ordering as a congestion signal. We also examined a second scenario where a flow leaves a saturated link. We concluded Cubic flows take much longer to fill the newly freed up bandwidth, as much as 8 seconds for a 25% increase in available bandwidth. BBR performs much better as its able to recognize that the link is not saturated during its next probing phase and mediately fill it. Therefore, we conclude that BBRv3 is better suited for the dynamic network conditions found in SDN environments

Modern TCP congestion control algorithms rely on timely ACK feedback to adjust their parameters. However, some networks deliberately suppress ACKs. This study uses the ns-3 simulator to experiment with the impact of suppressing ACKs on the reverse path on four TCP variants (BBRv3, Cubic, NewReno, Vegas) in both wired and wireless dumbbell topologies. In wired experiments, we implement a custom queue that allows us to test fixed aggregation ratios at the transport-layer. In wireless scenarios, we utilize the IEEE 802.11n standard’s MAC-layer aggregation schemes (A-MSDU, A-MPDU), both individually and in combination, and also evaluate varying maximum A-MPDU aggregation sizes. Our results show that while transport-layer aggregation can degrade performance and fairness, especially for BBRv3 and Cubic, MAC-layer aggregation consistently improves throughput without destabilizing TCP behaviour. NewReno demonstrates strong resilience across both setups, while Vegas exhibits highly inconsistent performance. These findings highlight the importance of aligning aggregation
mechanisms with congestion control strategies carefully.

Most TCP data transfers in the Internet are short. This makes the startup algorithms an important factor that impacts TCP performance. Several startup algorithms have been developed. However, not a lot of research has been conducted into how these behave and interact when used for short flows. This paper aims to provide a thorough evaluation of these algorithms and their interactions under different network conditions, focusing on short flows and using ns-3. We have observed that JumpStart seems to outperform the other algorithms used when it comes to flow completion time for short flows. That is likely because it starts to send data with an aggressive initial congestion window and the flow is finished after the first few RTTs. However, JumpStart performs more poorly when the flows are longer. We have shown that JumpStart has a great potential to make communication more efficient in the Internet but further research has to be conducted into its behavior in more adversarial conditions that represent real life situations better.

The Low-Latency, Low-Loss, ScalableThroughput (L4S) service aims to support real-time applications by enabling high throughput with sub-millisecond queueing delay. It combines
scalable ECN-based congestion control (e.g., TCP Prague) with a Dual-Queue AQM such as DualPI2 to separate low-latency and classic traffic.
This paper evaluates how L4S behaves under stressful network conditions using an extended ns-3
testbed with DualPI2, TCP Prague, and ECNenabled BBRv3. We test five scenarios: RTT jitter, bandwidth shifts, mixed traffic, wireless loss, and scalable-to-scalable coexistence.
Our results show that TCP Prague consistently delivers low delay and stable throughput, whereas
legacy TCP Cubic shows elevated and more variable delay—especially under jitter and in shared
queues. ECN-BBRv3 coexists cleanly with Prague, but when Cubic and Prague share a queue, Prague dominates bandwidth. L4S thus meets its latency goals, but fairness with classic TCP remains an open issue.

The Transmission Control Protocol (TCP) remains the cornerstone of modern network communication, enabling reliable and ordered data delivery across a wide range of network environments. Despite its ubiquity, TCP’s variants’ performance under extreme and highly variable network conditions remains insufficiently explored. This paper investigates the behavior of two common TCP variants - CUBIC and BBRv1 - when subjected to dynamic bandwidth and delay fluctuation. Such conditions are increasingly common in real-world wireless networks and can have a significant impact on TCP flows. We conduct a series of tests using the ns-3 framework, employing a dumbbell topology to simulate wireless connections. The results of 6 different testing scenarios are presented. They showcase that both algorithms experience significant packet loss in the event of bandwidth variance in-transmission, with BBRv1 adapting to these changes better, but not dominating over CUBIC in a multi-flow connection. In addition, both TCP variants experience harsh throughput drops and lose very few packets in the event of delay spikes. When faced with both delay and bandwidth variance, BBRv1 experiences high packet loss while CUBIC’s connection remains stable.