# Improving Congestion Control of TCP for Constrained IoT Networks
## 1 Introduction  
TCP, which is a de facto transport layer protocol for the Internet, was not considered a suitable protocol for wireless sensor networks which enable IoT [1; 2]. However, protocol standardization for IoT resulted in TCP emerging as a major candidate transport protocol, even for constrained IoT networks, because TCP is better than UDP (User Datagram Protocol) for integration with the existing network infrastructures where middleboxes such as firewalls or NATs (Network Address Translation devices) may block UDP packets. In Reference [1], [PERSON] et al. stated that the recent industry and standardization tendencies such as the Constrained Application Protocol (CoAP) over TCP, HTTP (Hypertext Transport Protocol) optimized for IoT, and messaging protocols such as the Message Queuing Telemetry Transport (MQTT) and the Advanced Message Queuing Protocol (AMQP) suggest that TCP may gain extensive support in IoT scenarios. Regarding the historically claimed issues of TCP in IoT scenarios, they argue that most of the issues are found in well-accepted IoT end-to-end reliability mechanisms, can be solved, or are not actual issues. The major challenge of designing a protocol for constrained networks is how to make it work well under severe resource constraints such as limited battery and computing power, small memory, or insufficient wireless bandwidth and ability to communicate [3]. To reduce memory usage, for example, TCP of the uIP stack [4; 5] does not implement a sliding window for sending and receiving data and limits the number of outstanding segments to one. Several other embedded TCP implementationsincluding BLIP (the Berkeley Low-power IP) stack [6] in TinyOS [7] and GNRC (the Generic Network Stack) [8] in RIOT OS [9] also keep the TCP window size of one segment [10; 11; 12]. However, this does not mean that these TCP implementations do not need any congestion control mechanism. Since periodic reporting by every node in scenarios such as continuous monitoring may cause congestion around the sink, TCP still needs to control congestion. In this case, managing the retransmission timer is a primary approach to congestion control. The optimal mechanism for setting the retransmission timer value will reduce retransmissions while maintaining high throughput. Reducing TCP retransmissions in wireless sensor networks is very important because end-to-end retransmission consumes much more energy than hop-by-hop retransmission. Radio duty cycling (RDC) is a major tool which is considered to save battery power in wireless sensor networks. However, despite a number of prior works on TCP for wireless sensor networks [10; 13; 14; 15; 16], few studies considered RDC. TCP is required to work well regardless of whether an RDC mechanism runs underneath. We examined TCP performance in constrained networks with RDC enabled. In the preliminary test using the Cooja network simulator, we found that uIP TCP causes lots of retransmissions when ContikiMAC [17], which is the default radio duty cycling mechanism in the Contiki OS, is enabled. uIP TCP's mechanism for managing the retransmission timer explains a considerable part of the problem. uIP TCP sets the retransmission timer based on RTT measurements for first transmissions. However, for retransmissions, it sets the retransmission timer based on the fixed retransmission timeout (RTO) of 3 s. Since ContikiMAC may cause large RTT variations due to the hidden terminal problem, the retransmission timer based on the fixed RTO value may cause lots of retransmissions, which could be reduced with the estimated RTO based on RTT measurements. This motivated us to design a scheme that enhances uIP TCP's performance in networks with RDC enabled. In devising a mechanism for managing the retransmission timer, we note that CoAP [18], which is an application protocol for constrained networks, also usually limits the number of outstanding messages to one. Congestion control relying only on RTO management was actively studied in the context of CoAP over UDP.