Loss Resilience Experiment

Random losses (e.g. packet loss due to random bit corruptions) can deteriorate the bandwidth utilization of congestion control algorithms (CCAs). Many CCAs misinterpret random losses as a signal for congestion and as a consequence the CCAs decrease the sending rate of a flow. The loss resilience experiment evaluates the influence of random losses on the operating point of CCAs.

A CCA should be resilient against random losses. There are two ways to achieve that resilience. First, a CCA may not decrease the sending rate when packet loss is detected. By doing that, a CCA can maintain its bandwidth utilization at the risk of ignoring a possible congestion signal. Second, a CCA may recover from a decrease of the sending rate quickly.

Scenario

To evaluate the loss resilience, a static dumbbell topology with a single flow that uses greedy source traffic is set up. The experiment is repeated with different random loss probabilities set by the parameter loss.

To summarize the experiment setup:

  • Topology: Dumbbell topology (\(K=1\)) with static network parameters

  • Flows: A single flow (\(K=1\)) that uses a CCA

  • Traffic Generation Model: Greedy source traffic

Experiment Results

Experiment #7

Parameters

Command: ns3-dev-ccperf-static-dumbbell-default --experiment-name=loss_resilience --db-path=benchmark_TcpNewReno.db '--parameters={aut:TcpNewReno,loss:0.02}' --aut=TcpNewReno --stop-time=15s --seed=42 --loss=0.02 --bw=16Mbps --qlen=20p --qdisc=FifoQueueDisc --rtts=15ms --sources=src_0 --destinations=dst_0 --protocols=TCP --algs=TcpNewReno --recoveries=TcpPrrRecovery --start-times=0s --stop-times=15s '--traffic-models=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

Metrics

The following tables list the flow, link, and network metrics of experiment #7. 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
cov_in_flight_l4 0.67
cov_throughput_l4 0.88
flow_completion_time_l4 14.93
mean_cwnd_l4 5.90
mean_delivery_rate_l4 3.31
mean_est_qdelay_l4 1.05
mean_idt_ewma_l4 5.06
mean_in_flight_l4 5.62
mean_network_power_l4 206.01
mean_one_way_delay_l7 6470.69
mean_recovery_time_l4 97.93
mean_sending_rate_l4 3.39
mean_sending_rate_l7 5.36
mean_srtt_l4 16.05
mean_throughput_l4 3.31
mean_throughput_l7 3.22
mean_utility_mpdf_l4 -0.41
mean_utility_pf_l4 1.17
mean_utilization_bdp_l4 0.29
mean_utilization_bw_l4 0.21
total_retransmissions_l4 97.00
total_rtos_l4 5.00

Figures

The following figures show the results of the experiment #7.

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.

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.

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

Comparison of Congestion Control Algorithms (CCAs)

Figures