Vegas-Friendliness Experiment
To be deployable, new congestion control algorithms (CCAs) have to be able to compete against established CCAs. Vegas is a delay-based CCA that sets its sending rate depending on observed changes in the round-trip time (RTT). Vegas represents delay-based algorithms that i) detect congestion levels early based on RTT changes and ii) have the objective to avoid queueing delay. Such CCAs back off when they estimate that the queueing delay grows, because they conclude that the bandwidth is fully utilized.
In the Vegas-friendliness experiment, it is evaluated if a CCA is fair towards Vegas. CCAs that fill buffers up during their operating, so called buffer fillers, may cause Vegas to back off and reduce its sending rate. As a consequence, such CCAs may dominate Vegas and therefore exhibit unfairness towards pure delay-based algorithms. However, if such unfairness is a problematic property is debatable, since pure delay-based CCAs are not widespread.
Scenario
In the Vegas-friendliness experiment, multiple flows operate in a
static dumbbell network. Each flow generates greedy source traffic and
uses either the CCA under test or Vegas. The experiment has one
parameter k, which sets the number of flows. Half of the
flows (rounded down) use the CCA under test, whereas the other half
(rounded up) use Vegas.
To summarize the experiment setup:
Topology: Dumbbell topology (\(K>1\)) with static network parameters
Flows: Multiple flows (\(K>1\)) that use either the CCA under test or Vegas
Traffic Generation Model: Greedy source traffic
Experiment Results
Experiment #95
Parameters
Command: ns3-dev-ccperf-static-dumbbell-default --experiment-name=vegas_fairness --db-path=benchmark_TcpNewReno.db '--parameters={aut:TcpNewReno,k:2}' --aut=TcpNewReno --stop-time=15s --seed=42 --bw=32Mbps --loss=0.0 --qlen=40p --qdisc=FifoQueueDisc --rtts=15ms,15ms --sources=src_0,src_1 --destinations=dst_0,dst_1 --protocols=TCP,TCP --algs=TcpNewReno,TcpVegas --recoveries=TcpPrrRecovery,TcpPrrRecovery --start-times=0s,0s --stop-times=15s,15s '--traffic-models=Greedy(bytes=0),Greedy(bytes=0)'
Flows
| src | dst | transport_protocol | cca | cc_recovery_alg | traffic_model | start_time | stop_time |
|---|---|---|---|---|---|---|---|
| src_0 | dst_0 | TCP | TcpNewReno | TcpPrrRecovery | Greedy(bytes=0) | 0.00 | 15.00 |
| src_1 | dst_1 | TCP | TcpVegas | TcpPrrRecovery | Greedy(bytes=0) | 0.00 | 15.00 |
Metrics
The following tables list the flow, link, and network metrics of experiment #95. Refer to the the metrics page for definitions of the listed metrics.
Flow Metrics
Flow metrics capture the performance of an individual flow. They are measured at the endpoints of a network path at either the source, the receiver, or both. Bold values indicate which flow achieved the best performance.
| Metric | flow_1 | flow_2 |
|---|---|---|
| cov_in_flight_l4 | 0.20 | 0.29 |
| cov_throughput_l4 | 0.08 | 0.39 |
| flow_completion_time_l4 | 15.00 | 14.99 |
| mean_cwnd_l4 | 57.40 | 9.40 |
| mean_delivery_rate_l4 | 26.28 | 4.49 |
| mean_est_qdelay_l4 | 9.82 | 9.82 |
| mean_idt_ewma_l4 | 0.44 | 2.33 |
| mean_in_flight_l4 | 56.91 | 9.41 |
| mean_network_power_l4 | 1084.39 | 190.15 |
| mean_one_way_delay_l7 | 1152.33 | 5534.07 |
| mean_recovery_time_l4 | 33.75 | nan |
| mean_sending_rate_l4 | 26.37 | 4.49 |
| mean_sending_rate_l7 | 28.39 | 6.62 |
| mean_srtt_l4 | 24.82 | 24.82 |
| mean_throughput_l4 | 26.30 | 4.49 |
| mean_throughput_l7 | 26.25 | 4.49 |
| mean_utility_mpdf_l4 | -0.04 | -0.25 |
| mean_utility_pf_l4 | 3.26 | 1.44 |
| mean_utilization_bdp_l4 | 1.48 | 0.24 |
| mean_utilization_bw_l4 | 0.82 | 0.14 |
| total_retransmissions_l4 | 58.00 | 0.00 |
| total_rtos_l4 | 0.00 | 0.00 |
Link Metrics
Link metrics are recorded at the network links of interest, typically at bottlenecks. They include metrics that measure queue states. Bold values indicate which link achieved the best performance.
| Metric | btl_forward |
|---|---|
| mean_qdisc_delay_l2 | 8.65 |
| mean_qdisc_length_l2 | 24.24 |
| mean_sending_rate_l1 | 31.95 |
| total_qdisc_drops_l2 | 58.00 |
Network Metrics
Network metrics assess the entire network as a
whole by aggregating other metrics, e.g., the aggregated throughput of
all flows.
Hence, the network metrics has only one column named net.
| Metric | net |
|---|---|
| mean_agg_in_flight_l4 | 66.32 |
| mean_agg_throughput_l4 | 30.79 |
| mean_agg_utility_mpdf_l4 | -0.29 |
| mean_agg_utility_pf_l4 | 4.71 |
| mean_agg_utilization_bdp_l4 | 1.72 |
| mean_agg_utilization_bw_l4 | 0.96 |
| mean_entropy_fairness_throughput_l4 | 0.63 |
| mean_jains_fairness_throughput_l4 | 0.67 |
| mean_product_fairness_throughput_l4 | 114.99 |
Figures
The following figures show the results of the experiment #95.Time Series Plot of the Operating Point
Time series plot of the number of segments in flight, the smoothed round-trip time (sRTT), and the throughput at the transport layer.
In Flight vs Mean Operating Point
The mean throughput and mean smoothed round-trip time (sRTT) at the transport layer of each flow. The optimal operating point is highlighted with a star (magenta). The joint operating point is given by the aggregated throughput and the mean sRTT over all flows
Mean Operating Point Plane
The mean throughput and mean smoothed round-trip time (sRTT) at the transport layer of each flow.
Distribution of the Operating Point
The empirical cumulative distribution function (eCDF) of the throughput and smoothed round-trip time (sRTT) at the transport layer of each flow.
