# Improving Congestion Control of TCP for Constrained IoT Networks
## 4 Preliminary Performance Evaluation  
### Simulation Settings  
We performed a preliminary test using the Cooja network simulator in Contiki 3.x [33]. We simulated two topologies consisting of Sky motes: a \(4\times 4\) grid topology and a \(5\times 5\) grid topology. In the \(4\times 4\) grid topology, the top leftmost node was designated as the LBR, whereas the LBR in the \(5\times 5\) grid topology was the node in the center. As shown in Figure 1, the LBR was connected to a Linux machine (on a virtual machine) using a slip protocol. While the transmission range and interference range were 50 m and 100 m, respectively, the nodes in a same row or column were 40 m away from each other. Consequently, many nodes suffered severe packet losses due to the hidden terminal problem. Table 1 summarizes the main simulation parameters pertaining to all simulations in this paper. For the preliminary test, we set the random loss rate to 0% in order to focus on congestion; thus, packets were lost only due to packet collision or buffer overflow. The number of packets in the link-layer queue was set to 8 in the preliminary test. We wanted to observe the behavior of uIP TCP in networks with an RDC mechanism enabled, which most previous studies on TCP and CoAP for constrained networks did not consider. Simulating both nullRDC and ContikiMAC, we compared the TCP behavior with and without an RDC mechanism enabled. ContikiMAC [17] proposed by [PERSON] is the default RDC mechanism in Contiki OS. ContikiMAC is a sender-initiated asynchronous mechanism that uses periodic wake-ups to listen for packet transmissions from neighbors. Nodes sleep most of the time and periodically wake up to check for radio activity. If a packet transmission is detected during a wake-up, the receiver stays awake to receive the packet. When the packet is successfully received, the receiver sends a link layer acknowledgement. A sender repeatedly sends the same packet until it receives a link acknowledgement from the receiver. Once a sender learns the wake-up phase of a receiver via a link layer acknowledgment, the sender can start its successive transmissions to the receiver just before the receiver is expected to be awake. To simulate a typical data collection scenario, each TCP client connects to the TCP server in the Linux machine and sends one segment every 6 s on average. Each TCP segment has a payload with the length of 48 bytes. At first, we made every node try to connect with the TCP server almost at the same time, but several nodes suffered from TCP connection failures. To avoid TCP connection failures, we made the nodes send connection requests sequentially in a given order with an interval of several seconds so that distant nodes could try connection establishment first. Once a connection is established, each node waits until all the sender nodes can transmit their first TCP data segments almost at the same time. Then, TCP data segments are transmitted for 10 min. Before obtaining the preliminary test results, we had to fix a problem with handling the retransmission timer. As described in the previous section, the retransmission timer for each connection is decremented every 0.5 s. The problem is that, while the retransmission timer is set in time units of 1 s, it is decremented by one every 0.5 s and, consequently, expires sooner than expected. We fixed this problem by setting the retransmission timer in time units of 0.5 s. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameters** & **Values** \\ \hline Radio model & Unit Disk Graph Medium (UDGM) \\ Random loss rate & 0\%, 5\%, 10\%, or 15\% \\ Transmission/interference range & 50 m/100 m \\ Radio duty cycling mechanism & NullRDC or \\  & ContikiMAC (RDC channel check rate: 8 Hz) \\  & MRHOF (Minimum Rank with Hysteresis \\  & Objective Function) \\ Number of packets in the link-layer queue & 4 or 8 \\ Length of TCP payload & 48 bytes \\ Offered load per node & 64 bps \\ Simulation duration & 10 min \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Simulation parameters.