Steady-state Start-time Fairness Experiment
This experiment evaluates how the start time influences the steady-state operating point of a congestion control algorithm (CCA). The sending rates of all flows are controlled by the same congestion control algorithm (CCA), i.e., it is an intra-protocol competition scenario.
Similar to the steady-state experiment with a single flow, the flows should jointly exhaust the bandwidth (bottleneck rate) of the dumbbell network and avoid self-inflicted queueing delay. The CCA should let the sending rates of the flows eventually converge to a steady-state equilibrium. At best, the flows share the shared bandwidth resources fairly. Network metrics quantify wheter or not efficiency (bandwidth utilization) and fairness is reached by a CCA.
Scenario
Multiple flows are set up to operate compete against each other in a
static dumbbell network. Greedy source traffic ensures that flows are
network-limited. The flows start at different times, but have the same
two-way propagation delay. The number of flows can be varied with the
experiment parameter k. The start times are set with the
parameter start_times.
To summarize the setup:
Topology: Dumbbell topology (\(K>1\)) with static network parameters defined by the
pathparameterFlows: Multiple flows (\(K>1\)) starting at different times using the same CCA (intra-protocol competition)
Traffic Generation Model: Greedy source traffic
Experiment Results
Experiment #16
Parameters
Command: ns3-dev-ccperf-static-dumbbell-default --experiment-name=steady_state_start_time_fairness --db-path=benchmark_TcpNewReno.db '--parameters={aut:TcpNewReno,k:2,path:static.default,start_times:[0s,1.87s]}' --aut=TcpNewReno --stop-time=15s --seed=42 --start-times=0s,1.87s --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,TcpNewReno --recoveries=TcpPrrRecovery,TcpPrrRecovery --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 | TcpNewReno | TcpPrrRecovery | Greedy(bytes=0) | 1.87 | 15.00 |
Metrics
The following tables list the flow, link, and network metrics of experiment #16. 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.37 | 0.23 |
| cov_throughput_l4 | 0.31 | 0.18 |
| flow_completion_time_l4 | 15.00 | 13.12 |
| mean_cwnd_l4 | 37.10 | 31.20 |
| mean_delivery_rate_l4 | 17.72 | 14.82 |
| mean_est_qdelay_l4 | 8.82 | 8.90 |
| mean_idt_ewma_l4 | 0.60 | 0.68 |
| mean_in_flight_l4 | 36.61 | 30.70 |
| mean_network_power_l4 | 777.73 | 646.78 |
| mean_one_way_delay_l7 | 1788.53 | 1926.28 |
| mean_recovery_time_l4 | 30.70 | 30.81 |
| mean_sending_rate_l4 | 17.84 | 14.89 |
| mean_sending_rate_l7 | 19.86 | 17.26 |
| mean_srtt_l4 | 23.82 | 23.90 |
| mean_throughput_l4 | 17.74 | 14.83 |
| mean_throughput_l7 | 17.74 | 14.83 |
| mean_utility_mpdf_l4 | -0.06 | -0.07 |
| mean_utility_pf_l4 | 2.84 | 2.68 |
| mean_utilization_bdp_l4 | 0.95 | 0.80 |
| mean_utilization_bw_l4 | 0.55 | 0.46 |
| total_retransmissions_l4 | 107.00 | 37.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 | 7.58 |
| mean_qdisc_length_l2 | 21.31 |
| mean_sending_rate_l1 | 31.88 |
| total_qdisc_drops_l2 | 144.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 | 67.32 |
| mean_agg_throughput_l4 | 32.56 |
| mean_agg_utility_mpdf_l4 | -0.13 |
| mean_agg_utility_pf_l4 | 5.52 |
| mean_agg_utilization_bdp_l4 | 1.75 |
| mean_agg_utilization_bw_l4 | 1.02 |
| mean_entropy_fairness_throughput_l4 | 0.60 |
| mean_jains_fairness_throughput_l4 | 0.98 |
| mean_product_fairness_throughput_l4 | 205.18 |
Figures
The following figures show the results of the experiment #16.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.
Mean Operating Point Plane
The mean throughput and mean smoothed round-trip time (sRTT) at the transport layer of each flow.
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
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.
Comparison of Congestion Control Algorithms (CCAs)
Figures
