Experimenting Transport Services for IoT

Experimental Evaluation of Congestion Control Algorithms for Constrained Application Protocol (CoAP)


In order to extend reliable data delivery and congestion control to the Internet of Things, Internet Engineering Task Force (IETF) has proposed Constrained Application Protocol (CoAP)[1], a web transfer protocol for constrained devices and networks that provides optional reliability based on retransmission timeout (RTO) together with exponential RTO backoff. CoAP basic congestion control is simple, it is relatively conservative and potentially inefficient. Hence, there is a need for a more efficient congestion control alternative, and CoCoA[2] has been proposed as an option.

We present two experimental studies on IoT transport service and conngestion control. First, we focus on evaluating the efficiency and scalability of CoAP basic congestion control and alternative congestion control algorithms for it, including CoCoA and two TCP-based mechanisms.

Second, we evaluate the performanceof three transport services, namely CoAP, HTTP and SPDY, for IoT environment.

Experimental setup

Fig 1 shows our experimental setup where multiple Californium[5] clients fetch resources from a single Californium server an emulated bottleneck link of data rate 20 Kbps, one-way link-delay of 20 ms and Maximum Transmission Unit (MTU) of 128 bytes. The above data rate, delay and MTU size roughly correspond to the data rate, latency and packet size of Zigbee[4]. We use Linux netem[3] emulator to emulate the above IoT environment.

Fig. 1

We use Californium that implements the congestion control algorithms, namely, Default CoAP, CoCoA, Linux RTO and the Peak-Hopper. The basic CoAP congestion control mechanism is referred to as Default CoAP here. Linux RTO and Peak-Hopper are TCP-based RTO algorithms. Linux RTO follows RFC 6298[6] except that when round trip time (RTT) decreases, the contribution from the variance in RTT to the RTO is decreased such that small RTT measurements do not increase the RTO estimate to an unnecessarily high value. In Peak-Hopper[7], RTO estimation uses two estimators, namely, a short history and a long history estimator. The maximum of the two estimators is taken as the RTO value. We use multiple instances of Californium client to fetch resources from a Californium server over an IoT environment.

Experiments and workloads

In our experiments we have two types of clients, Continuous Client: 50 CON-ACK (request-reply) pairs are sent continuously and Random Client: mimics short exchanges. A client exchanges1-10 CON-ACK pairs after which a new client started and the RTO estimator gets reset. Clients continue till total of 50 CON-ACK exchanges completed.

The workloads we use in our experiments are, Simple workload : Either Continuous or Random clients, Mixed: Half Continuous and half Random and Competing: Half clients use Default CoAP and the other half uses one of the other three alternative algorithms with either Continuous or Random clients We use 10, 20, 30, 40 and 80 clients to see the increasing effect of network traffic in the IoT environment.

We use the metrics, namely, Client completion time: Time to complete the 50 CON-ACK exchanges by a client, Client RTOmax: The highest expired RTO value for a client, and Frequency of transmissions: Number of (re)transmissions to Successfully exchange a CON-ACK pair.


Figures 2a and 2b show the client completion time, that is the time to complete the 50 CON-ACK exchanges by a client. The workloads are Continuous, Random and Mixed for 10 and 40 clients. Figures 3a and 3b (clientcompletiontime.fairness.n10.eps, clientcompletiontime.fairness.n40.eps) show the the client completion time for Competing workload for 10 and 40 clients.

Fig. 2a

Fig. 2b

Fig. 3a

Fig. 3b

To support our analysis for the reasons behind the differences in client completion time, we present our observations on retransmission behaviour and RTO values.

Table 1 (success-tables-10-40-80.pdf )shows the frequency of transmissions for the Simple workload with 40 and 80 clients. The table represents the number of CON-ACK pairs that were successful in the original transmission as well as the number of retransmissions that were required to successfully complete a CON-ACK exchange. A total of 10000 CON-ACK pairs were exchanged for 10 clients, whereas for 40 and 80 clients the corresponding number of CON-ACK pairs are 40000 and 80000 respectively.

Table 1: Frequency of transmissions for 10, 40 and 80 clients

Frequency of Transmission 10 clients
WorkloadCC algorithmOrig. transRetransmissions
Frequency of Transmission 40 clients
WorkloadCC algorithmOrig. transRetransmissions
Frequency of Transmission 80 clients
WorkloadCC algorithmOrig. transRetransmissions

With 40 and 80 clients, 17-24 % and 16-30 % of CONs require to be retransmitted, respectively. This is clearly more than the corresponding numbers with 10 clients, where only 3-14 % of the CONs need to be retransmitted. This is also in line with the increasing client completion time when the congestion level increases as discussed earlier.

The results of our study show that Default CoAP has higher client completion time than CoCoA and the TCP-based algorithms in high congestion scenarios. Our results also show that all the alternatives are not only scalable but also more efficient than Default CoAP at high congestion level(s).


Experimental Evaluation of HTTP, SPDY and CoAP for IoT

To extend the Internet services to IoT devices, a suitable transport service is needed. As the IoT devices have limited resources in terms of computation, communication, radio and battery life, the transport services should be simple, scalable, robust, efficient in making near-optimal use of resources, easy to maintain and deploy and also customisable to the need of the applications.

In this set of experiments whether HTTP[7] and SPDY[8] can be adapted to favourably compare with CoAP as they can directly connect the IoT devices to the Internet without the need for proxies. In order to have comparable performance with CoAP in terms of object download time and total bytes transferred to fetch an object, we propose minimizing the HTTP and SPDY headers along with TCP enhancements. We use an extension to TCP known as TCP Fast Open [9] to reduce the object download time. We refer to the enhanced HTTP and SPDY proposed here as IoT-HTTP and IoT-SPDY.

Experimental setup

The experiments are carried out over an emulated IoT environment using Linux netem, with the bottleneck link emulated with the characteristics of Zigbee[4]. In our test environment, the client fetches from the server a single object of size that varies from 10 bytes to 1000 bytes over an error free channel.


Fig 4 shows the object download times for different object sizes from server to the client when using the different transport services CoAP, HTTP, SPDY, IoT-HTTP and IoT-SPDY. The object download time is the duration between the time the client initiates the request for the object to the time the last byte of the object arrives at the client. We observe that the object download times increase with the size of the object requested in all the five cases. CoAP has the lowest object download times as the protocol overhead for CoAP is quite small. It can be clearly seen that TFO decreases the object download times for IoT-HTTP and IoT-SPDY. The object download time is decreased also due to the minimized headers for IoT-HTTP and IoT- SPDY. There is at least 50 % reduction in object download time for IoT-HTTP and IoT-SPDY compared to HTTP and SPDY.

Fig. 4

Fig 5 shows the total bytes transferred including IP/TCP/UDP headers when objects of different sizes are requested by the client from the server when using the different transport services CoAP, HTTP, SPDY, IoT-HTTP and IoT-SPDY. As the protocol overhead is minimum for CoAP it transfers the lowest number of bytes for each object compared to that of HTTP and SPDY. SPDY’s header compression accounts for the slight reduction in object download time compared to HTTP. The minimized header and TFO is responsible for the reduction in total bytes transferred for IoT-HTTP and IoT-SPDY compared to SPDY and HTTP.

Fig. 5




Markku Kojo, University of Helsinki markku.kojo@cs.helsinki.fi