GoodputRTTPLR/TimeoutsGoodput/RTT
Back downlink/ uplink downlink/ uplink downlink / uplink downlink / uplink

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.

HsdpaTestbed.png

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:
  1. TCP variants provides similar goodputs
  2. 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.
  3. TCP Bic/Cubic provoke two times packet retransmission values with respect to TCP Westwood+ and TCP NewReno.
  4. 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:

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

Hsdpa cwnd 1 flow downlink westwood.png Hsdpa cwnd 1 flow downlink newreno.png Hsdpa cwnd 1 flow downlink bic.png Hsdpa cwnd 1 flow downlink cubic.png