Enhancement of congestion control of Constrained Application Protocol/Congestion Control/Advanced for Internet of Things environment

Abstract

With the wide spread of Internet of Things, efficient communication between the nodes is getting more important. Constrained Application Protocol was developed to accommodate the resource-constrained nodes and low-power communication links. Being an Internet protocol, Constrained Application Protocol must adhere to congestion control, primarily to keep the backbone network stable. An advanced congestion control mechanism for Constrained Application Protocol, called Congestion Control/Advanced, has also been recently developed. In this article, we propose a new round trip time–based adaptive congestion control scheme, which further improves Congestion Control/Advanced by utilizing the retransmission count in estimating the retransmission timeout value and the lower bound in round trip time variation. An experiment is conducted based on Californium Constrained Application Protocol framework and real devices, and the performance is compared with Constrained Application Protocol, Congestion Control/Advanced, and an existing scheme. It reveals that the proposed scheme significantly increases the throughput and rate of successful transactions in comparison with the other schemes. The approach of utilizing the option field of Constrained Application Protocol enables the proposed scheme to be implemented without any conflict with the existing protocol and extra overhead.

Keywords

Constrained Application Protocol Congestion Control/Advanced congestion control Internet of Things adaptive retransmission timeout

Introduction

Internet of Things (IoT) is a prevalent paradigm conceived to interconnect a large number of devices including sensors. Here, various objects are connected together to deliver customized ubiquitous services. Typically, the nodes have small battery and operate in the presence of lossy and noisy communication links.^1–3 The Internet Engineering Task Force (IETF) has been focusing on the standardization of different aspects of the communication protocol stack trimmed to fit the requirements of constrained devices. Constrained Application Protocol (CoAP) is the protocol designed in this end.^4,5

CoAP is defined in a standard Request for Comments (RFC)⁶ managed by a working group of IETF and uses the same RESTful principle as HTTP. It is, however, much lighter to be run on constrained devices.^7,8 The base specification of CoAP adopts conservative value for the number of open requests, retransmission time, and transmission rate. The CoAP interaction is based on client–server model and handled asynchronously over a datagram transport such as User Datagram Protocol (UDP). A client sends a request specified by a method (GET, PUT, POST, or DELETE) on the resource (identified by URI) of the server. The CoAP server processes the requests and sends back a message containing the response code and payload.

One of the most important constraints on IoT is resource restriction of the nodes. The storage capacity and processing speed are limited, easily causing network congestion.^9,10 To cope with this issue, CoAP RFC defines a congestion control mechanism, which doubles the retransmission timeout (RTO) value when timeout occurs. Currently, the network manager sets up the RTO value manually.

Congestion Control/Advanced (CoCoA)^11,12 uses the round trip time (RTT) to set the RTO value automatically. CoCoA is effective when the packet transmission time increases linearly. Early research shows that its performance is better than CoAP in congested networks.^13,14 Note that proper setting of RTO value is difficult especially during congestion, in which the congestion control scheme of CoCoA based on the actual RTT can display more effect. However, CoCoA still has a limitation in selecting a proper RTO value when burst traffic exists. This is because it cannot correctly identify the RTT of retransmitted request–response, which is essential in deciding the RTO value. Also, unnecessary retransmission might be needed for the measurement of RTO when RTT is small.¹⁵

The main hurdle in observing the RTT of the retransmitted packet is the unavailability of the information required for identifying the origin of the response packet. This ambiguity was also discussed in Karn’s algorithm,¹⁶ but CoCoA uses fixed RTO even for the retransmitted packet. To resolve this problem, we propose an advanced congestion control mechanism for CoAP by utilizing the retransmission count (RC) of the request packet. The proposed scheme uses the RC information to estimate the actual RTT by matching the request and response packet. The estimated RTT is then used to set up the RTO value with which the network congestion problem can be effectively handled. Another contribution of the proposed scheme is applying the lower bound to the variation in RTT, which effectively handles the fluctuation of RTT in relatively small range. In order to analyze the effectiveness of the proposed scheme, analytical model of it and CoAP have been developed. Also, an experiment is carried out which reveals that the proposed scheme can effectively increase the throughput of the network and reduce retry rate in comparison with CoAP and CoCoA. With 100 clients, the proposed scheme allows about 150% and 50% higher throughput than CoAP and CoCoA, respectively. The proposed approach utilizes the option field of the message of CoAP, and thus, it can be implemented without any conflict with the existing protocol or extra overhead.

The rest of the article is organized as follows. Section “Related work” provides an overview of the control mechanism for CoAP and CoCoA. In sections “The proposed scheme,” a new method for dynamic congestion control is proposed. Also, analytical model of the proposed scheme and CoAP are presented. Section “Performance evaluation” gives the performance evaluation of the proposed scheme in various operation scenarios and compares it with CoAP/CoCoA using open-source library and real IoT device implemented with Raspberry Pi. Finally, section “Conclusion” concludes the article and outlines future research direction.

Related work

CoAP is the communication protocol developed for constrained network of low-power and lossy environment. CoAP provides a request–response interaction model between the endpoints of the application. Here, Confirmable (CON) or Non-confirmable (NON) message is used for carrying the request. The response is carried in the Acknowledgement (ACK) message which includes the ID of the request message. CoAP RFC defines this flow as “Piggybacked Response.”⁶ Based on this communication model, CoAP provides a default congestion control mechanism.

Message format of CoAP

CoAP provides RESTful functions such as HTTP, but it is much lighter to be used with constrained devices.¹⁷ It employs a lightweight protocol structure, and the messages are encoded in a simple binary format consisting of Header, Option field, and Payload. Figure 1 shows the format of CoAP message.

Figure 1.

The format of CoAP message.

As shown in Figure 1, a CoAP message is started with a 4-byte header. Here “V” denotes the version, “T” the type, and “TKL” the token length in fixed size, respectively. The detail information of each field is given in Table 1.

Table 1.

CoAP header.

Field	Length	Data type	Description
Version	2 bits	Unsigned integer	CoAP version number
Type	2 bits	Unsigned integer	Confirmable; Acknowledgment Non-confirmable; Reset
Token length	4 bits	Unsigned integer	0–8 bytes
Code	8 bits	Unsigned integer	Request–Response/Empty GET/POST/PUT/DELETE; the value is one of response code
Message ID	16 bits	Unsigned integer	Used to match the message of Acknowledgment/Reset to Confirmable/Non-confirmable

CoAP: Constrained Application Protocol.

Other fields are optional except the header. The “Token” field is used for correlating the request and response, and the “Option” field is used for handling the communication. At the end of the Option field, there is 1 byte 0xFF value payload marker used as a separator between the Option and “Payload” field.

The Option field takes an important role in the proposed scheme, which was set aside to support flexible communication. It consists of Option delta, Option length, extended Option delta, extended Option length, and Option value. The CoAP RFC defines the Options as follows. Option delta is used for identifying the Option numbers, while Option length determines the length of the subsequent Option value. The length and format of the Option value depend on the definition of each Option. An example of Option field is the content-format which represents the format of the data of the payload. The Option number of the content-format is 12, the Option length is 0–2 bytes, and the Option value is unsigned integer.

Default congestion control of CoAP

In low-power and lossy network environment, it is common that unexpected packet loss or packet delay occurs.¹⁸ To handle these problems, CoAP provides basic congestion control based on exponential backoff mechanism. After transmitting the CON message, if the sender does not receive an ACK before RTO expires, CON message is retransmitted. The format and data of the retransmitted message are the same as the initial one, while the RTO value is doubled and RC is incremented. The sender keeps retransmitting the CON message until the RC reaches MAX_RETRANSMIT, for which the default value is 4. CoAP also provides a modifiable option for RTO setup.

The initial RTO value is randomly set between ACK_TIMEOUT and ACK_RANDOM_FACTOR× ACK_TIMEOUT, with a default value of 2 s. Figure 2 shows the default congestion control mechanism adopted by CoAP. Normally, the client sends CON right after receiving the ACK message, which means that the interval of CON is the same as RTT. If congestion occurs, the interval is increased until the client receives ACK message. Because the default congestion control scheme doubles the RTO value each time, the client may need to retransmit CON several times until right RTO value is found. In the worst-case scenario, the client retransmits packet whenever the RTO value is less than RTT. The shortcoming of the default scheme is that the RTO value is not set automatically but by network manager. If a wrong RTO value is selected, some packets might be retransmitted unnecessarily.

Figure 2.

The default congestion control of CoAP.

CoCOA

To dynamically cope with the variation in the network condition, the RTO value needs to be adjusted considering the RTT of the packet. For dynamic congestion control, the IETF Constrained RESTful Environments (CoRE) working group released the draft specification of CoAP Simple CoCoA. CoCoA provides a scheme for estimating the RTO value for CON request using the RTT information. CoCoA considers two types of RTO estimator based on the algorithm defined in RFC 6298:¹⁹

Strong estimator: for packet exchanges without before retransmission, the actual RTT is used.

Weak estimator: for retransmission, the time between initial request and received response is used.

Recent research on the CoAP^20,21 uses equations (1)–(3) in the estimation of RTO with CoCoA. Here, X stands for the strong or weak estimator

RT T_{X} = (1 - α) \cdot RT T_{X} + α \cdot RT T_{X_new}

(1)

CoCoA sets α to 0.25. When a new RTT value, RTT_{X_new}, is obtained, the next RTT value is calculated using equation (1).RTTVAR_X is the variation in RTT defined in RFC 6298

RTTVA R_{X} = (1 - β) \cdot RTTVA R_{X} + β \cdot | RT T_{X} - RT T_{X_new} |

(2)

Here, β is set to 0.125 by CoCoA. RTT_x and RTTVAR_x are used to update RTO_x by equation (3)

RT O_{X} = RT T_{X} + K_{X} \cdot RTTVA R_{X}

(3)

K_x is the weight associated with the estimator, and it is K_strong = 4 and K_weak = 1. CoCoA calculates the overall RTO, RTO_overall, as follows

RT O_{overall} = 0.5 \cdot RT O_{X} + 0.5 \cdot RT O_{overall} (for strong)

(4)

RT O_{overall} = 0.25 \cdot RT O_{X} + 0.75 \cdot RT O_{overall} (for weak)

(5)

In CoCoA draft, the response after third retransmission is not used to update the estimated value. This is because it is not known whether the response is for the initial transmission or retransmission.

The RTO value cannot be calculated until the sender receives a response packet. When timeout occurs, CoCoA uses variable backoff factor (VBF) to set up the RTO value, which is also based on RFC6298. It is to make the interval regular

RT O_{re} = RT O_{overall} \cdot VBF

(6)

CoCoA calculates the retransmission RTO using equation (6). Here, VBF is 3 when RTO_overall is under 1 s, 2 between 1 and 3 s, or 1.5 higher than 3 s. Figure 3 depicts the overall flow of congestion control of CoCoA. During the normal condition, RTO is updated using RTO_strong estimator and original RTT. If a packet is retransmitted once, RTO_weak estimator is used with the estimated RTT. If retransmission occurs more than twice, RTO is not updated. This policy works well with linearly increasing traffic, but not for burst traffic. A research improves CoCoA by modifying the weak estimator with different weight values of RTT.²²

Figure 3.

The flow of congestion control of CoCoA.

When the number of incoming packets increases rapidly, the overall processing time is delayed and the RTT of each packet increases unexpectedly. Note that the processing time of resource-constrained device is significantly influenced by the number of incoming requests causing several retransmissions of the request. In this case, CoCoA avoids RTO update because CoAP cannot tell whether the response packet is for the original request or not. The right-hand side of Figure 3 shows the flow of congestion control of CoCoA with burst traffic.

Another problem with CoCoA is redundant retransmissions when the RTT is small. As shown in equations (1)–(6), the calculated RTO of CoCoA is close to the actual RTT with the margin, RTTVAR. In the case of small RTT, however, the calculated RTO is almost the same as the original RTT. Note that RTT usually fluctuates even when the network is stable.^23,24 Therefore, the probability of redundant retransmission increases if the RTT value is small. Burst traffic is generated when unexpected events occur in a monitoring system, for example, while non-burst traffic is generated during normal routine operation. The proposed scheme effectively enhancing CoCoA is presented next.

The proposed scheme

In this section, we present the proposed scheme which dynamically updates RTO based on packet matching and the lower bound on RTTVAR. The proposed scheme utilizes RC to correctly estimate the RTT of every packet of burst traffic. In addition, the lower bound is applied to RTT to handle the fluctuation even in stable network condition. The adopted approaches effectively improve the accuracy of RTO estimation, and as a result enhance the performance of CoAP.

Overview

In section “Related work,” the issues of congestion control with CoAP were introduced. The proposed scheme improves the congestion control mechanism of CoCoA by applying the following features:

Insertion of RC of a packet to the Option field;

Dynamic RTO update with packet matching based on RC;

Elimination of RTO_weak estimator of CoCoA;

Application of the lower bound on RTTVAR for RTO update of stable network.

Figure 4 shows the flow of RTO update with the proposed scheme. When the RTO value is smaller than RTT of a packet, the client retransmits the request. After receiving the response, it measures the RTT by matching the RC of the request and response packet. Here, RTO_observe estimator is used to adjust RTO. While updating RTO based on the RTT, a lower bound in the variation of RTT is imposed to cover the fluctuation of RTT. In the proposed scheme, the estimator can be used for handling multiple retransmitted packets because the matching process is based on RC used as a unique identifier of every packet.

Figure 4.

The flow of RTO update of the proposed scheme.

Estimation of RTO

The main difficulty of CoAP in obtaining the RTT of the retransmitted packet is the lack of the information on the origin of the response packet. When a request is retransmitted, it has the same message ID and data as the initial one. Also, the response packet generated by the piggyback method has the same message ID as the request.

Figure 5 compares the transaction of default CoAP with the proposed scheme. Figure 5(a) shows that Device A with default CoAP cannot obtain the correct RTT because there is no information in the final ACK packet which is a response of the second CON request. To identify the origin of a request packet, the RC is used in the proposed scheme as shown in Figure 5(b). Observe from the figure that when retransmission occurs at Device A, RC is put in the request packet. Device B generates ACK packet with the copied RC using the piggyback mechanism. If timeout occurs for a packet, the count value of the first retransmitted CON request is 1. While Device B is sending an ACK packet, another timeout occurs at Device A. The count value of the second retransmitted request is 2. When Device A receives an ACK packet, it contains the RC copied from the original request. By comparing the transmission time of CON and reception time of ACK of the same count value, Device A can obtain the correct RTT of the packet.

Figure 5.

The flow of retransmission in congested network: (a) default CoAP transaction and (b) proposed scheme transaction.

To minimize the operation overhead, the insertion occurs only with retransmitted request. Equation (7) is for the calculation of RTT with the proposed scheme

RT T_{X} = (1 - α) \cdot RT T_{X} + α \cdot RT T_{X_new}

(7)

For properly reflecting the network condition in the estimation of RTT, the previous RTT and the currently observed RTT value are combined. Here, the weight value α is set to 0.25 by following the guideline of CoCoA. RTT_{x_new} is decided by matching the request and response packet based on the count value.

Another shortcoming of CoCoA exists with small RTT in which the effect of RTO estimation is reduced. As shown in equation (3), the RTO value is decided by RTT and RTTVAR with CoCoA. The RTTVAR value depends on the RTT value as described in equation (2). Therefore, small size RTT leads shrunk RTO which cannot cover the entire range of fluctuation in RTT. Figure 6(a) depicts the problem of CoCoA with small RTT.

Figure 6.

The two schemes of RTO update with small size RTT: (a) CoCoA and (b) proposed scheme.

To avoid excessively shrunk RTO causing uncovered RTT, a lower bound is adopted for RTTVAR. In the communication of typical wireless sensor network, RTTs of the packets fluctuate with a similar range. The range varies according to the structure of the network, and thus, the lower bound is decided when the network is given. Figure 6(b) shows how the lower bound is used with the proposed scheme

RTTVA R_{X} = (1 - β) \cdot RTTVA R_{X} + β \cdot | RT T_{X} - RT T_{X_new} |

(8)

The calculation of the lower bound starts from adjusting the RTT value as equation (8). Here, β is set to 0.125. RTT_x and RTTVAR_x are used to update the RTO value

RT O_{observe} = RT T_{X} + \max (L, K \cdot RTTVA R_{X})

(9)

Equation (9) shows how the lower bound, L, is applied. RTTVAR_x is multiplied by the weight variable, K. Note that the proposed scheme eliminates the weak estimator because it does not need to calculate RTT, and thus, K is fixed to 4. The value is then compared with the lower bound, and the larger one is decided as the final RTTVAR which is added to RTT_x to get the RTO value.

For final RTO update, the mechanism employed by CoCoA is used with RTO_observe estimator even when an ACK packet is received after retransmission occurs. Also, VBF is used for RTO during retransmission. As a result, the RTO estimation model is similar to RTO_strong estimator of CoCoA. Eliminating RTO_weak estimator also reduces the resource required for the communication

RT O_{p} = 0.5 \cdot RT O_{observe} + 0.5 \cdot RT O_{overall}

(10)

RT O_{re} = RT O_{overall} \cdot VBF

(11)

In equation (10), RTO_p is the RTO estimation model of the proposed scheme. Equation (11) is the RTO for retransmission, RTO_re. Since the model is the same as CoCoA specification, the proposed scheme does not cause any conflict.

RC

The option field of CoAP is utilized with the proposed scheme for avoiding any implementation overhead. Note that the operation of the proposed scheme is based on the congestion control of CoCoA. In order to put the RC, the option registry policy described in CoAP RFC 7252 is used. Table 2 shows the properties of the RC option of the proposed scheme. Here, C, U, N, and R indicate the property of Critical, Unsafe, NoCachKey, and Repeatable, respectively. With this option, the proposed scheme readily generates the request and response packet containing RC. Figure 7 shows an example of a transaction message.

Table 2.

The properties of retransmission count option.

No.	C	U	N	R	Format	Length	Default
65002	X	O	X	X	Unsigned int	1 byte	None

Figure 7.

The request and response message with RC.

RC is not used if retransmission does not occur because it is used only for the retransmitted packet. Utilizing the count information will also be effective for handling unexpected delay and loss.

Implementation

The proposed scheme is pluggable to CoAP protocol stack without changing any operational mechanism. It has three main features: (1) extraction of the actual RTT of the retransmitted packet, (2) estimation of RTO by properly reflecting the change in network condition, and (3) application of the lower bound to the variation in RTT to avoid overly shrunk RTO. The proposed scheme starts to measure RTT when the client sends a request message to the server. If the client does not receive a response until RTO expires, the client updates RTO using equation (11) and retransmits the request. After receiving the response message, RTO is updated. The entire scheme is summarized in the following, and Table 3 lists the variables used in the scheme.

Table 3.

The notation used in the proposed scheme.

Noun	Description
RC	Retransmission count of a packet
RTT_x	Estimated RTT calculated by equation (7)
RTTVAR_x	RTT variation calculated by equation (8)
RTT_new	Measured RTT by matching request and response
RTO_observe	Calculated RTO by adding RTT and RTT variation as in equation (9)
RTO_update	Updated RTO by equation (10)

RTT: round trip time; RTO: retransmission timeout.

Initialization stage

In this stage, CoAP sets up the RTO value by randomly selecting a value between ACK_TIMEOUT and ACK_TIMEOUT × f (f ≥ 1). Here, f is the ACK_RANDOM_FACTOR which is described in CoAP RFC.

RTT measurement stage

Here, the client transmits a request message and waits for the response. During this transaction, RC is put in the retransmitted packet. After receiving the response, the client calculates RTT by matching the message ID and RC of the request and response.

RTO update stage

To properly reflect the network condition, the proposed scheme updates RTO by merging the current RTT and previous RTO. The updated RTO is used for the next transaction. Refer to equations (7)–(10).

Since the proposed mechanism adheres to the guideline of CoAP RFC for option registry, it can be implemented without any extra overhead.

Transmission rate

Transmission rate is the rate of transmitting request packet from a client. It is one of the most important metrics affecting the network quality.^25,26 As shown in Figure 3, the transmission rate is bounded by RTT in normal operation condition. For congested network, finding proper RTO is a key to maximize the network performance. In this section, the model of the transmission rate of CoAP and the proposed scheme are developed using an approach similar to the work of Balandina et al.²²

Algorithm 1: CoAP communication with the proposed scheme
1: //Initialization stage
2: set random value (ACK_TIMEOUT < x < ACK_TIMEOUT*f)
3: RTO = x
4:
5: RC = 0
6: //Measure RTT stage
7: if RC = 0 do
8: send request
9: else
10: send request with RC option
11: end if
12: record request time (message ID with RC);
13: wait response
14:
15: //Time out operation
16: if wait time > RTO
17: if RC < MAX_RETRANSMIT
18: RC++
19: RTO = equation (11)
20: go to 7
21: else
22: job fail
23: end if
24: end if
25:
26: receive response
27: record response time
28: RTT_new = calculate RTT(message ID with RC);
29:
30: //RTO update stage
31: RTT_x = equation (7)
32: RTTVAR_x = equation (8)
33: RTO_observe = equation (9)
34: RTO_update = equation (10)
35: RTO = RTO_update
36: job success
37:
38: go to 5

CoAP

Let T_t denote the total time of packet transmission. If congestion occurs during T_t, the relationship between the time interval for normal transmission, T_n, and the waiting time due to packet loss, T_to, is as follows. Assume that S_t, S_n, and S_to are the total number of packets sent during T_t, T_n, and T_to, respectively

T_{t} = T_{n} + T_{to}

(12)

S_{t} = S_{n} + S_{to}

(13)

Using equations (12) and (13), the transmission rate, R_b, is calculated as follows

R_{b} = \frac{S_{t}}{T_{t}} = \frac{S_{n} + S_{to}}{T_{n} + T_{to}}

(14)

As shown in the default operation of Figure 2, the client sends a request right after receiving the response packet. This means that the operation time during the normal condition can be decided by multiplying the average RTT, RTT_avg, and the number of packets, i

\frac{S_{n}}{T_{n}} = \frac{i}{RT T_{avg} \cdot i} = \frac{1}{RT T_{avg}}

(15)

In congested network, timeout may occur continuously. Let p be the probability of successful transmission between the CoAP client and server and k the number of retransmissions. The number of failures until the first successful packet transmission can be modeled using geometric distribution as follows

P [S_{to} = k] = (1 - p)^{k} p

(16)

The expected value of S_to, E[S_to], is then

E [S_{to}] = P [S_{to} = k] = \frac{(1 - p)}{p}

(17)

CoAP RFC sets the default retransmission limit, n, to 4. However, it is not fixed in the proposed scheme. During retransmission, CoAP keeps doubling the initial RTO, RTO_init. Therefore, the wait time for k packet retransmissions, W_k, is as follows

W_{k} = \sum_{k = 1}^{n} 2^{(k - 1)} RT O_{init}

(18)

By calculating the wait time and the probability of retransmission, the expected packet wait time during congestion condition, E[T_to], is obtained by combining equations (16) and (18)

\begin{matrix} E [T_{to}] = \sum_{k = 1}^{n} W_{k} P [T_{to} = K] \\ = \sum_{k = 1}^{n} 2^{(k - 1)} RT O_{init} {(1 - p)}^{k} p \end{matrix}

(19)

The transmission rate of CoAP, R_b(p), can be rewritten based on RTT and RTO with the probability of successful transmission

R_{b} (p) = \frac{1 + (1 - p) / p}{RT T_{avg} + \sum_{k = 1}^{n} 2^{(k - 1)} RT O_{init} {(1 - p)}^{k} p}

(20)

Proposed scheme

As shown in Figure 5, the difference between CoAP and the proposed scheme is the interval of retransmission in the congested network. Therefore, equations (14) and (15) are reused. The transmission rate of the proposed scheme is derived starting from the following equation

R_{p} = \frac{S_{t}}{T_{t}} = \frac{1 + S_{to}}{RT T_{avg} + T_{to}}

(21)

As shown in equation (8), the proposed scheme uses VBF to calculate RTO when retransmission occurs. Note that VBF changes based on the value of RTO_overall. As mentioned earlier, the weak estimator is not used for RTO update in the proposed scheme unlike CoCoA. In other words, equation (7) is used with the proposed scheme instead of the overall RTO estimator of CoCoA which contains the strong and weak estimators. The wait time during nth retransmission, W_n, is then decided as follows

W_{n} = \sum_{k = 1}^{n} VB F^{k - 1} \cdot RT O_{p}

(22)

The expected wait time during congestion condition is obtained by equation (19). By combining equation (22) and the probability of successful transmission

\begin{matrix} E [T_{to}] = \sum_{k = 1}^{n} W_{n} (P [T_{to} = K]) \\ = \sum_{k = 1}^{n} VB F^{(k - 1)} \cdot RT O_{p} {(1 - p)}^{k} p \end{matrix}

(23)

Finally, the transmission rate of the proposed scheme, R_p(p), is derived as follows

R_{p} (p) = \frac{1 + 1 / (1 - p)}{RT T_{avg} + \sum_{k = 1}^{n} VB F^{(k - 1)} \cdot RT O_{p} {(1 - p)}^{k} p}

(24)

Note that T_to and S_to of equation (21) are changed in equation (24). It reveals that the waiting time due to packet loss (T_to) depends on VBF and the RTO estimator in the proposed scheme. Also, the total number of packets sent during T_to is affected by the probability of packet loss.

Performance evaluation

In this section, an experiment is conducted to evaluate the performance of the proposed scheme. Also, the performance is compared with CoAP, CoCoA, and an enhancement scheme of CoCoA²² named as CoCoA-E.

Experiment environment

To properly evaluate the proposed congestion control scheme, the devices of limited resource need to be tested in congested network. For this, Raspberry Pi is used as a server generating congestion condition.²⁷ The specification of the server is 700 MHz CPU, 512 MB SDRAM, 10/100 BaseT Ethernet, and 8 GB Micro SD card with Raspbian Linux OS. For the client, multiple clients are implemented based on threads. The specification of client PC is 3.2 GHz quad core CPU, 8 GB RAM, 64-bit Windows 7 Ultimate K OS. Between the client and server, UDP is used for Ethernet communication. Figure 8 shows the overall structure of the experiment environment, which is implemented with the open-source library of CoAP. At the server side, libCoAP is used which is the lightweight CoAP communication library based on C. For the clients, Californium library is used with customized multithread packet generator.²⁸

Figure 8.

The structure of the experiment.

Here, each client generates CoAP message with one of the three types of congestion control schemes. The first one is the default CoAP, which is provided by Californium as a default with MAX_RETRANSMIT (MR) as 4. The second scheme is the CoCoA with NSTART value of 1. It means that the packet does not send multiple requests in one transaction as in default CoAP. MR is also set to 4 for CoCoA. The last one is the proposed scheme with the same parameter values as the others for fair comparison of the schemes in handling network congestion.

The performance metrics adopted in the experiment include the throughput and cumulative distribution function (CDF) of successful communication. The throughput is calculated as the number of successful transactions divided by the total time of transactions. The CDF measures the effectiveness of congestion control. If a scheme sets a proper RTO value, the communication will be successful with few retransmissions.

Results of experiment

First, the performance of the scheme is investigated during congestion condition, which occurs with the requests generated by multiple clients at the same time. For this, 10 request packets are generated for each client thread, while the number of threads is increased from 1 to 100. Every client employs the same congestion control mechanism. The communication flow based on each congestion control mechanism is then observed.

Figure 9 compares the throughputs of the four schemes. When the number of clients is smaller than 25, congestion does not occur and almost every communication is successful. Some packets might be retransmitted with CoCoA and the proposed scheme even when the network is stable due to dynamic RTO estimation. The RTT usually fluctuates and thus RTO needs to be updated which may cause retransmission and decrease the throughput. If RTO is fixed like default CoAP, there is no retransmission until RTT becomes less than RTO. Note that CoAP was designed for constrained environment of limited resource and unstable network. As revealed by the experiment, request packets are not retransmitted with less than 25 clients. Also, non-retransmitted request does not trigger congestion control. Therefore, the performance of the schemes needs to be tested for congested network, which may occur with more than 50 clients. With congested network of 100 clients, the proposed scheme allows about 150%, 50%, and 25% higher throughput than CoAP, CoCoA, and CoCoA-E, respectively. Note also from Figure 9 that the throughput of default CoAP and CoCoA drops dramatically while the decrease rate of the proposed scheme is much smaller.

Figure 9.

The comparison of throughputs with multiple clients.

Figure 10 shows similar result as Figure 9 which compares the rate of successful transaction. Higher rate of successful transaction implies less retransmission. A rapid drop in the rate of default CoAP with increasing number of clients reveals that fixed RTO is not effective in handling congested network. Note that RTT-based RTO update allows to sustain the rate. Observe that the proposed approach is quite effective in improving the existing schemes.

Figure 10.

The comparison of the rate of successful transaction.

The distributions of retransmissions and RTO value with 100 clients of the four schemes are compared in Figure 11. Here, the CDFs of successful transactions are shown for the given number of transactions.²⁰ During the experiment with 100 clients, some jobs may not be able to be completed, and thus, 1500 transaction logs are checked for each scheme. The RTO value is limited to 25 s. In the graphs, the solid line and “x” mark represent the CDF and the RTO of the retransmitted packet, respectively.

Figure 11.

The RTO and CDF of successful transaction: (a) CoAP, (b) CoCoA, (c) CoCoA-E, and (d) proposed scheme.

Observe from Figure 11(a) that three groups of RTOs exist, where the first RTO group exists at the bottom and the third RTO group at the top. Note that fixed RTO causes a large number of retransmissions. On the other hand, Figure 11(b) of CoCoA displays alleviation of this problem. Until about 1200 transactions, a proper value of RTO seems to be found. After that, the CDF value of CoCoA quickly rises. Figure 11(c) of CoCoA-E shows better result than CoCoA in the number of retransmissions. Also, the entire job can be successfully completed under 1400 transactions. Figure 11(d) reveals the effectiveness of the proposed scheme. A proper RTO value is found under 400 transactions and the rate of CDF becomes almost linear afterward. As a result, the proposed scheme completes the job with the least number of transmissions.

Figure 12 shows the transmission rate and CDF of successful transactions with 100 clients. Here, the transmission rates are obtained using equations (20) and (24), with the data of 100 clients shown in Figure 11. The CDFs of successful transactions are reused to show the performance of the schemes. In Figure 12(a), the transmission rates are similar after 200 transactions, and also the CDF value does not grow much.

Figure 12.

Transmission rate and CDF of successful transactions: (a) CoAP and (b) proposed scheme.

On the other hand, Figure 12(b) shows that the proposed scheme allows more than 100% higher CDF than CoAP even with lower transmission rate. Figure 12 confirms that proper RTT-based adjustment of the transmission rate of the proposed scheme significantly affects the rate of successful transactions.

In order to test the effectiveness of employing the lower bound for covering the variation in RTT, the responses are randomly delayed from 5 to 500 ms. The lower bound of the experiment is set to 5000 ms.

To compare the schemes, 30 clients are activated at the same time and each client generates 100 requests. Table 4 summarizes the results of the experiment. Note that the success rate of the transactions of the proposed scheme is highest through effective handling of the fluctuation.

Table 4.

The comparison of success rates of the transactions.

Scheme	Initial	Retry	Total	Success rate
CoAP	3000	2837	5837	51.39
CoCoA	3000	636	3636	82.50
CoCoA-E²²	3000	128	3128	95.90
Proposed	3000	22	3022	99.27

CoAP: Constrained Application Protocol; CoCoA: Congestion Control/Advanced.

Figure 13 shows the relationship of RTO and CDF of each scheme with the same setup employed for obtaining the data of Table 4. To reveal the effect of the lower bound mechanism, the RTO value of every packet is marked unlike Figure 11.

Figure 13.

The RTO and CDF of successful transactions: (a) CoAP, (b) CoCoA, (c) CoCoA-E, and (d) proposed scheme.

The upper three groups of xs of Figure 13(a) show the vulnerability of the default scheme with fluctuated network. Observe from Figure 13(c) of CoCoA-E that the RTO values also follow the fluctuating RTT. Figure 13(b) and (d) displays that RTT-based RTO estimation allows to decide proper RTO value.

The CDFs of Figure 13(b)–(d) are similar, but the distribution of RTO of the proposed scheme indicates that employing the lower bound for RTT is quite effective in the long run.

To reveal the relative effectiveness of each of the two mechanisms of the proposed scheme, the success rate of transactions with each of them is compared in Figure 14. Here, RTTestimate is implemented with equation (7) only, while equation (9) only for Lowerbound. Other settings are the same as Figure 13. Observe from the figure that the effectiveness of Lowerbound is slightly better, while the rate of both of them drops significantly with 90 clients because of the congested network. On the other hand, the composition of them (the proposed scheme) allows to sustain the rate.

Figure 14.

The comparison of the two mechanisms.

Conclusion

In this article, we have presented a novel congestion control scheme for CoAP by utilizing RTT. Here, the correct RTT is obtained using the option field of the message which includes the RC. Also, applying the lower bound to cover the variation in RTT allows to obtain proper RTO value and as a result effective congestion control. The approach of utilizing the option field of CoAP enables the proposed scheme to be implemented without any conflict with the existing protocol and extra overhead. Also, the model of the transmission rate of CoAP and the proposed scheme have been developed. An experiment with the actual IoT devices reveals that the proposed scheme significantly improves the efficiency of congestion control compared with CoAP, CoCoA, and an enhancement scheme of CoCoA.

Congestion control is a crucial issue for CoAP since the deployed nodes have limited resource. Continuous retransmissions make the congestion condition worse, and as a result reduce the lifetime of the devices. In the future, more comprehensive performance model based on queuing theory will be investigated for the proposed scheme. It can be used to decide the various parameter values of the proposed scheme for maximizing the performance. Enhancement of the proposed scheme with respect to RTO will also be investigated, including formal estimation of the range of the fluctuation of the RTT for setting proper lower bound.

Footnotes

Academic Editor: Eleonora Borgia

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (2014R1A1A2040257 and 2014R1A1A 2060398), the second Brain Korea 21 PLUS project, and Samsung Electronics.

References

Borges

Velez

Lebres

AS.

Survey on the characterization and classification of wireless sensor network applications. IEEE Commun Surv Tutor 2014; 16(4): 1860–1890.

Al-Fuqaha

Guizani

Mohammadi

. Internet of Things: a survey on enabling technologies, protocols and applications (An upcoming or future generation computer communication system technology). IEEE Commun Surv Tutor 2015; 17: 1.

Misra

Kumar

Agarwal

. IoT—a technological analysis and survey on vision, concepts, challenges, innovation directions, technologies, and applications. Am J Electr Electron Eng 2016; 4: 23–32.

Ishaq

Carels

Teklemariam

. IETF standardization in the field of the Internet of Things (IoT): a survey. J Sens Actuator Netw 2013; 2: 235–287.

Coltti

Steenhaut

De Caro

. Evaluation of constrained application protocol for wireless sensor networks. In: Proceedings of the 2011 18th IEEE workshop on local and metropolitan area networks (LANMAN), Chapel Hill, NC, 13–14 October 2011, pp.1–6. New York: IEEE.

Shelby

Hartke

Bormann

The Constrained Application Protocol (CoAP). IETF RFC 7252, June 2014.

Thangavel

Valera

. Performance evaluation of MQTT and CoAP via a common middleware. In: Proceedings of the 2014 IEEE ninth international conference on intelligent sensors, sensor networks and information processing (ISSNIP), Singapore, 21–24 April 2014, pp.1–6. New York: IEEE.

Potsch

Kuladinithi

Becker

. Performance evaluation of CoAP using RPL and LPL in TinyOS. In: Proceedings of the 2012 5th international conference on new technologies, mobility and security, Istanbul, 7–10 May 2012, pp.1–5. New York: IEEE.

Yuan

Yugang

Fenghao

. Congestion control for wireless sensor networks: a survey. In: Proceedings of the 26th Chinese control and decision conference, Changsha, China, 31 May–2 June 2014, pp.4853–4858. New York: IEEE.

10.

Huang

Duan

. Modeling and analysis on congestion control in the Internet of Things. In: Proceedings of the 2014 IEEE international conference on communications (ICC), Sydney, NSW, Australia, 10–14 June 2014, pp.434–439. New York: IEEE.

11.

Bormann

Betzler

Gomez

. CoAP simple congestion control/advanced. IETF I-D draft-bormann-core-cocoa-02, January 2015.

12.

Bormann

Betzler

Gomez

. CoAP simple congestion control/advanced. IETF I-D draft-bormann-core-cocoa-03, October 2015.

13.

Järvinen

Daniel

Kojo

. Experimental evaluation of alternative congestion control algorithms for Constrained Application Protocol (CoAP). In: Proceedings of the 2015 IEEE 2nd world forum on Internet of Things (WF-IoT), Milan, 14–16 December 2015, pp.453–458. New York: IEEE.

14.

Bhalerao

Subramanian

Pasquale

. An analysis and improvement of congestion control in the CoAP Internet-of-Things protocol. In: Proceedings of the 2016 13th IEEE annual consumer communications and networking conference (CCNC), Las Vegas, NV, 9–12 January 2016, pp.889–894. New York: ACM.

15.

Betzler

Gomez

Demirkol

. Congestion control in reliable CoAP communication. In: Proceedings of the 16th ACM international conference on modeling, analysis and simulation of wireless and mobile systems, Barcelona, 3–8 November 2013, pp.365–372. New York: ACM.

16.

Karn

Partridge

Improving round-trip time estimates in reliable transport protocols. ACM SIGCOMM Comput Commun Rev 1987; 17: 2–7.

17.

Bormann

Castellani

Shelby

CoAP: an application protocol for billions of tiny Internet nodes. IEEE Internet Comput 2012; 16(2): 62–67.

18.

Kaur

Grewal

Saini

. A survey on recent congestion control schemes in wireless sensor network. In: Proceedings of the 2015 IEEE advance computing conference, Bangalore, India, 12–13 June 2015, pp.387–392. New York: IEEE.

19.

Paxson

Allman

Chu

. Computing TCP’s retransmission timer. IETF RFC 6298, June 2011.

20.

Betzler

Gomez

Demirkol

. Congestion control for CoAP cloud services. In: Proceedings of the 2014 IEEE emerging technology and factory automation, Barcelona, 16–19 September 2014, pp.1–6. New York: IEEE.

21.

Betzler

Gomez

Demirkol

. CoCoA+: an advanced congestion control mechanism for CoAP. Ad Hoc Netw 2015; 33: 126–139.

22.

Balandina

Koucheryavy

Gurtov

Computing the retransmission timeout in CoAP. In: Balandin

Andreev

Koucheryavy

(eds) Internet of Things, smart spaces, and next generation networking, vol. 8121. Berlin: Springer, 2013, pp.352–362.

23.

Wang

Traffic analysis & modeling in wireless sensor networks and their applications on network optimization and anomaly detection. PhD Thesis, 2010, http://miun.diva-portal.org/smash/get/diva2:281643/FULLTEXT01.pdf

24.

Katoh

Sato

Watanabe

. Traffic engineering for IoT. In: Proceedings of the 2016 international conference on information networking (ICOIN), Kota Kinabalu, Malaysia, 13–15 January 2016, pp.195–200. New York: IEEE.

25.

Padhye

Firoiu

Towsley

. Modeling TCP Reno performance: a simple model and its empirical validation. IEEE/ACM T Network 2000; 8: 133–145.

26.

Zheng

El Kamel

Wang

. Node performance model of wireless sensor networks. In: Proceedings of the 2013 9th Asian control conference (ASCC), Istanbul, 23–26 June 2013, pp.1–6. New York: IEEE.

27.

Kruger

Hancke

. Benchmarking Internet of Things devices. In: Proceedings of the 2014 12th IEEE international conference on industrial informatics (INDIN), Porto Alegre, Brazil, 27–30 July 2014, pp.611–616. New York: IEEE.

28.

Kovatsch

Lanter

Shelby

. Californium: scalable cloud services for the Internet of Things with CoAP. In: Proceedings of the 2014 international conference on the Internet of Things (IOT), Cambridge, MA, 6–8 October 2014, pp.1–6.