TCP Congestion Control over live HSDPA Network
We report results obtained by an extensive measurement campaign over a live HSDPA network involving more than 3000 flows resulting in around 60 hours of active measurements. The considered TCP variants are the following:
- TCP NewReno: the only congestion control algorithm standardized by IETF
- TCP Westwood+: available in the Linux kernels 2.4 and 2.6.
- TCP BIC
- TCP Cubic: the default congestion control employed in the linux kernel
The experimental evaluation has been carried out by accessing the public Internet using a commercial HSDPA card (see figure below) and by employing the linux Kernel 2.6.24.
The following instantaneous variable measurements have been collected by using the libnetmeas library:
- Goodput
- Round Trip Time (RTT)
- packet loss ratios
- number of timeouts
The main findings of the investigation can be summarized as follows:
- Differently from the case of the UMTS scenario, the considered TCP congestion control algorithms exhibited the following characteristics in the case of the downlink channel:
- TCP variants provides similar goodputs
- TCP Bic/Cubic exhibit inflated values for average RTT due to the aggressive nature of their probing phase. TCP NewReno and TCP Westwood+ provide lower values of RTT, TCP Westwood+ exhibiting the lowest.
- TCP Bic/Cubic provoke two times packet retransmission values with respect to TCP Westwood+ and TCP NewReno.
- TCP Bic/Cubic provoke roughly three times the number of timeouts wrt TCP Westwood+ and TCP NewReno, TCP Cubic exhibiting the highest number.
- In the case of the uplink channel the algorithms exhibited similar performances, due to the fact that the moderate size of cwnd forced TCP Cubic and TCP Bic to use the linear probing in order to be TCP friendly (see [1]).
Results of the experiments and Conclusions
We report cumulative distribution function plots:
- downlink and uplink channel goodput CDFs
- downlink and uplink RTT CDFs
- Goodput-RTT plots for downlink and uplink channels.
- Timeouts and packet loss ratio bar graphs for downlink and uplink channels (3 times timeouts and 2 times packet loss ratio of BIC/CUBIC wrt NewReno/Westwood+)
Conclusions
Reasons not to deploy TCP Bic/Cubic are rooted in its more aggressive probing phase. In particular, in common network conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same goodput wrt toTCP NewReno or Westwood+.
In other terms, its more aggressive probing increases both throughput and retransmission but leaving unchanged the goodput that is neutral for the users but negative for the network.
Congestion window and RTT evolutions
Typical congestion window and RTT evolutions of the considered TCPs in the case of a single flow over the HSDPA downlink
