AT
A. Tabacaru
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
1 records found
1
Simulating and Analyzing the Performance of TCP Under Extreme Conditions
Evaluating the Impact of L4S on TCP Performance
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.
...
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 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.
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.