# Improving Congestion Control of TCP for Constrained IoT Networks
## 6 Performance Evaluation  
To evaluate the performance of our proposed scheme, we used the grid topologies as in the preliminary test. The maximum number of retransmissions was set to 15. We used three performance metrics: throughput (i.e., TCP goodput), total number of retransmissions, and fairness. Fairness between TCP flows is quantified using [PERSON]'s index. We compared performance between three schemes: the original uIP TCP, the uIP TCP with dithering, and our proposed scheme. The uIP TCP with dithering was made by adding only dithering to the original uIP TCP. All simulations were run for 10 min and repeated 10 times. In the figures for simulation results, we added the 95% confidence intervals for the means in each plot. Firstly, to investigate the effect of the network size, we compared performance of the three schemes for the \(4\times 4\) grid and \(5\times 5\) grid topology networks. Compared to the \(4\times 4\) grid topology, the \(5\times 5\) grid topology not only causes larger differences of path lengths but also worsens the hidden terminal problem. In this test, we set the random loss rates to 0% and the number of packets in the link-layer queue to eight packets. Figure 4 shows the performance when an RDC mechanism is not enabled. In terms of total goodput, the original uIP TCP underperforms the other two schemes. The uIP TCP with dithering and our proposed scheme show almost equal performance, but the uIP TCP with dithering performs slightly better, which indicates the benefits of dithering. The reason why the \begin{table}
\begin{tabular}{l l} \hline \hline
**Event** & \multicolumn{2}{c}{**Action**} \\ \hline Initiation & MDEV = 16 s \\ \hline \multirow{7}{*}{An RTT sample is taken from the latest transmission} & Err = RTT – SRTT + SRTT + SRTT + 0.125 x Err \\  & MDEV = MDEV + 0.25 * ([Err] – MDEV) \\  & RTO = SRTT + \(4\times\) MDEV \\ \cline{1-1}  & RTT = SRTT + \(4\times\) MDEV \\ \cline{1-1}  & retransmission\_timer = RTO \\ \cline{1-1}  & // dithering \\ \cline{1-1}  & If (retransmission\_timer \(>\) 4 s) \\ \cline{1-1}  & retransmission\_timer += random integer in [0, retransmission\_timer \(\times\) 0.5) \\ \cline{1-1}  & else \\ \cline{1-1}  & retransmission\_timer += random integer in [0, retransmission\_timer) \\ \hline \multirow{7}{*}{Retransmission timer expires} & // variable limits on the maximum backoffs \\ \cline{1-1}  & If RTO \(\leq\) 3 s then \\ \cline{1-1}  & n\_backoff = max (\#retransmissions, 4) \\ \cline{1-1}  & else if RTO \(\leq\) 6 s then \\ \cline{1-1}  & n\_backoff = max (\#retransmissions, 3) \\ \cline{1-1}  & else if RTO \(\leq\) 12 s then \\ \cline{1-1}  & n\_backoff = max (\#retransmissions, 2) \\ \cline{1-1}  & else \\ \cline{1-1}  & n\_backoff = max (\#retransmissions, 1) \\ \cline{1-1}  & retransmission\_timer = max(RTO \(<\) \(<\) n\_backoff, 48 s) \\ \cline{1-1}  & // dithering \\ \cline{1-1}  & If (retransmission\_timer \(>\) 12 s) \\ \cline{1-1}  & retransmission\_timer += random integer in [0, retransmission\_timer \(\times\) 0.25) \\ \cline{1-1}  & else \\ \cline{1-1}  & retransmission\_timer += random integer in [0, retransmission\_timer \(\times\) 0.5) \\ \cline{1-1}  & else \\ \cline{1-1}  & retransmission\_timer += random integer in [0, retransmission\_timer] \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Proposed algorithm. goodput difference between three schemes is not extremely large is that RTT is very small. In terms of the number of retransmitted segments, our proposed scheme underperforms slightly. The schemes using the fixed RTO of 3 s benefit from very small RTT and the random loss rate of 0%. The fairness index of the original uIP TCP is lower than that of the other two schemes. The fairness index of our proposed scheme is almost the same as that of the uIP TCP with dithering. Figure 5 shows the performance when ContikiMAC is used. For all schemes, the total goodput is much lower than when no RDC mechanism is used. The reason is that, as mentioned in Section 4.2.1, ContikiMAC worsens the hidden terminal problem.