# Improving Congestion Control of TCP for Constrained IoT Networks
## 3 Overview of uIP TCP and CoCoA  
### uIP TCP  
The uIP TCP/IP stack is an extremely small implementation of the TCP/IP protocol suite that was designed for embedded systems [4]. uIP uses a single global buffer which is large enough to hold one packet of the maximum size. The same global packet buffer is used both for incoming packets and for the TCP/IP headers of outgoing data. When a packet arrives from the network, the device driver places it in the global buffer and calls the TCP/IP stack. To send data, the application passes a pointer to the data, as well as the length of the data, to the stack. The TCP/IP headers are written into the global buffer, and then the device driver sends the headers and the application data out on the network. Since the data are not saved for retransmission, the application has to reproduce the data if retransmission is necessary.  
In uIP, the application is invoked in response to events such as data arriving, an incoming connection request, or a poll request from the stack. The main control loop repeatedly checks whether a packet arrived from the network and whether the periodic timer expires. If a packet arrived, the input handler of the TCP/IP stack is invoked. The periodic timer, which expires every 0.5 s in the current implementation, serves several purposes. Firstly, retransmission is driven by the periodic timer. Whenever the periodic timer expires, the retransmission timer for each connection is decremented. When the retransmission timer reaches zero, a retransmission is performed. Secondly, the periodic timer is used to measure RTT. Each time the periodic timer expires, uIP increments a counter for each connection that has unacknowledged data in the network. When an acknowledgement is received, the current value of the counter is recorded as sampled RTT. uIP TCP uses [PERSON]'s algorithm which does not measure RTT for a retransmitted segment. The basic time unit for RTT and RTO is 1 s. Since RTT and RTO estimations are calculated using [PERSON]'s fast algorithm [32], which relies only on integer operations, the computational overhead is low. The algorithm for setting RTO is as follows:  
\[\text{Err}=\text{RTT}-\text{SRTT};\]  
\[\text{SRTT}=\text{SRTT}+0.125\times\text{Err};\]  
\[\text{MDEV}=\text{MDEV}+0.25\times(|\text{Err}|-\text{MDEV});\]  
\[\text{RTO}=\text{SRTT}+4\times\text{MDEV}.\]  
While the maximum number of retransmissions is set to eight by default, the retransmission timer backs off exponentially up to four times with the fixed RTO value of 3 s.  
uIP TCP does not implement the sliding window algorithm, which requires a lot of 32-bit operations. Instead, it allows only a single TCP segment per connection to be unacknowledged at any given time. Even though each node generates low-rate traffic via a stop-and-wait protocol, congestion can occur at areas where traffic is concentrated. Hence, uIP TCP needs congestion control, and an RTO algorithm comes into play.  
Allowing only one outstanding TCP segment may cause the uIP TCP sender to interact poorly with the delayed acknowledgement mechanism of the receiver. Because the receiver only receives a single segment at a time, it may wait until the delay acknowledgement timer (which is typically 200 ms but can be as high as 500 ms) expires, which limits the maximum possible throughput of the sender.