ACK Compression Experiment
Acknowledgements (ACKs) contain the feedback information congestion control algorithms (CCAs) leverage to make rate control decisions. A CCA stays responsive as long as ACKs are steadily returned by the destination. Typically, transport layer protocols let CCAs make rate control decisions whenever an ACK arrives at the sender. The senders are said to be ACK-clocked. In the best case, the pacing of the arriving ACKs at the sender matches the pacing of the pacing of acknowledged packets sent out earlier.
A phenomenon called ACK compression changes the pacing of ACKs. With ACK compression, many packets are acknowledged in a short period of time, i.e., in a burst. Such a burst may either happen because many ACKs arrive at the sender almost simultaneously or because multiple ACKs are aggregated to a single cumulative ACK. When ACK compression occurs, the sender may respond with a burst of packet transmissions, which may cause queue overflows. Furthermore, the estimation of the round-trip time (RTT) may be impaired by ACK compression.
This experiment evaluates if a CCA can converge to an efficient operating point when ACK compression is present. The level of ACK compression can be controlled with experiment parameters.
Scenario
In the ACK compression experiment, a single flow operates in a static
dumbbell network with a link that compresses ACKs. The link that causes
the ACK compression is scheduled to only transmit ACKs in periodic
intervals. The interval is set set by the parameter
interval. Furthermore, at every transmission slot the link
sends a quota of ACKs at once with a high speed. The number of packets
that the link sends at one transmission slot is set by the parameter
quota.
To summarize the experiment setup:
Topology: Dumbbell topology (\(K=1\)) with static network parameters and an ACK compression link
Flows: A single flow (\(K=1\)) that uses a CCA
Traffic Generation Model: Greedy source traffic
Experiment Results
Experiment #55
Parameters
Command: ns3-dev-ccperf-ack-compression-default --experiment-name=ack_compression --db-path=benchmark_TcpNewReno.db '--parameters={aut:TcpNewReno,interval:5ms,quota:10}' --aut=TcpNewReno --stop-time=15s --seed=42 --interval=5ms --quota=10 --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 #55. 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.23 |
| cov_throughput_l4 | 0.25 |
| flow_completion_time_l4 | 15.00 |
| mean_cwnd_l4 | 32.90 |
| mean_delivery_rate_l4 | 13.91 |
| mean_est_qdelay_l4 | 10.48 |
| mean_idt_ewma_l4 | 0.95 |
| mean_in_flight_l4 | 32.49 |
| mean_network_power_l4 | 565.16 |
| mean_one_way_delay_l7 | 1984.92 |
| mean_recovery_time_l4 | 94.09 |
| mean_sending_rate_l4 | 13.99 |
| mean_sending_rate_l7 | 16.05 |
| mean_srtt_l4 | 25.48 |
| mean_throughput_l4 | 13.92 |
| mean_throughput_l7 | 13.92 |
| mean_utility_mpdf_l4 | -0.10 |
| mean_utility_pf_l4 | 2.56 |
| mean_utilization_bdp_l4 | 1.69 |
| mean_utilization_bw_l4 | 0.87 |
| total_retransmissions_l4 | 74.00 |
| total_rtos_l4 | 1.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 | 5.39 |
| mean_qdisc_length_l2 | 7.44 |
| mean_sending_rate_l1 | 14.45 |
| total_qdisc_drops_l2 | 74.00 |
Figures
The following figures show the results of the experiment #55.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
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.
Mean Operating Point Plane
The mean throughput and mean smoothed round-trip time (sRTT) at the transport layer of each flow.
Comparison of Congestion Control Algorithms (CCAs)
Figures
