Pulse Wave Responsiveness Experiment
A congestion control algorithm (CCA) should be responsive to sudden changes in network conditions. In the responsiveness pulse wave experiment, sudden changes are triggered periodically at predefined instants that let a network parameter alternate between an upper and lower value. The goal of a CCA should be to adapt its rate control decisions to the change of network conditions. There are three types of changes depending on which network parameter is affected:
Bandwidth: An increase in bandwidth frees up resources that can be acquired by a CCA. To avoid underutilization, a CCA should grab the bandwidth quickly. On the other hand, a decrease in bandwidth may lead to congestion. Then, a CCA should reduce its sending rate. The sending rate governed by a CCA should follow the periodic changes of bandwidth. Hence, in the best case, the sending rate also follows a pulse wave function.
Delay: An increase of the propagation delay prolongs feedback cycles of the congestion control loop. A CCA might slow down if the growth rate of its sending rate is proportional to feedback cycle period. Furthermore, CCAs that estimate the two-way propagation delay to set their rate may have to update their estimate in response. A decrease of the propagation delay may affect CCAs in the opposite way.
Loss: An increase in the random loss probability may cause CCAs to back off more frequently in response to packet loss. Hence, CCAs may underutilize the bandwidth resources at times with high loss. Vice versa, a decrease may let CCAs grab more bandwidth. CCAs that are resilient to random losses might not be affected by a change of the random loss probability.
Scenario
In the responsiveness step function experiment, a single flow
operates in a static dumbbell network. The flow generates greedy source
traffic and uses a CCA. The target parameter is either
rate, rtt, or loss and decides
which network parameter is changed. The period parameter
sets the period time and thereby the frequency of changes. The
lower and upper parameters set the alternating
values of the network parameter.
To summarize the experiment setup:
Topology: Dumbbell topology (\(K=1\)) with static network parameters, but one parameter changes its value once during the experiment
Flows: A single flow (\(K=1\)) that uses a CCA
Traffic Generation Model: Greedy source traffic
Experiment Results
Experiment #67
Parameters
Command: ns3-dev-ccperf-responsiveness-default --experiment-name=responsiveness_pulse_wave --db-path=benchmark_TcpNewReno.db '--parameters={aut:TcpNewReno,target:rtt,period:5s,lower:15ms,upper:30ms}' --aut=TcpNewReno --stop-time=15s --seed=42 --time-series=0s,2.5s,5s,7.5s,10s,12.5s,15s --rate-series=16Mbps,16Mbps,16Mbps,16Mbps,16Mbps,16Mbps,16Mbps --rtt-series=30ms,15ms,30ms,15ms,30ms,15ms,30ms --loss-series=0.0,0.0,0.0,0.0,0.0,0.0,0.0 --bw=16Mbps --loss=0.0 --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 #67. 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.29 |
| cov_throughput_l4 | 0.11 |
| flow_completion_time_l4 | 15.00 |
| mean_cwnd_l4 | 39.68 |
| mean_delivery_rate_l4 | 14.84 |
| mean_est_qdelay_l4 | 7.81 |
| mean_idt_ewma_l4 | 0.78 |
| mean_in_flight_l4 | 39.19 |
| mean_network_power_l4 | 524.73 |
| mean_one_way_delay_l7 | 1978.84 |
| mean_recovery_time_l4 | 43.66 |
| mean_sending_rate_l4 | 14.95 |
| mean_sending_rate_l7 | 16.98 |
| mean_srtt_l4 | 30.29 |
| mean_throughput_l4 | 14.85 |
| mean_throughput_l7 | 14.85 |
| mean_utility_mpdf_l4 | -0.07 |
| mean_utility_pf_l4 | 2.69 |
| mean_utilization_bdp_l4 | 1.45 |
| mean_utilization_bw_l4 | 0.93 |
| total_retransmissions_l4 | 124.00 |
| total_rtos_l4 | 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 | 6.17 |
| mean_qdisc_length_l2 | 8.57 |
| mean_sending_rate_l1 | 15.42 |
| total_qdisc_drops_l2 | 105.00 |
Figures
The following figures show the results of the experiment #67.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.
