Analysis of QUIC Transported CoAP

Abstract

Many IoT deployments rely on an access network that is characterized by densely distributed power constrained devices. Power restrictions, in turns, lead to transmission rate limitations and increased bit errors responsible of network packet loss. Among the many technologies available to deal with these issues, the Constrained Application Protocol (CoAP) introduces an efficient session layer mechanism that provides, as the Hypertext Transport Protocol (HTTP), Representational State Transfer (REST) functionality. However, as opposed to HTTP that relies mostly on the transmission of TCP segments, CoAP has been standardized to support both UDP and TCP transport layers. In IoT scenarios, the CoAP transport protocol selection combined with network conditions can greatly affect overall application Quality of Service (QoS). Under HTTP, the Quick UDP Internet Connection (QUIC) protocol has been introduced as a hybrid alternative to TCP. In this paper, we analyze, model and compare the use of QUIC transport against that of both UDP and TCP in the context of CoAP traffic.

Introduction

REST mechanisms play a very important role in IoT system solutions as they are the main drivers of service enablement. Specifically, data generated and consumed at devices are made application friendly by means of generic interfaces that support well known REST verbs. Diverse IoT applications can interact with devices by means of their representational objects in order to create, read, update and delete them (CRUD paradigm). HTTP is the quintessential example of a session layer protocol that enables clients and servers to exchange application messages following REST conventions. HTTP, however, has certain characteristics that challenge its use in the context of IoT networks. First, when compared to binary compressed session protocols, HTTP is text based and requires higher transmission rates that are not typically available on power constrained devices and networks. Also, and more importantly, because HTTP relies on TCP for transport, it is affected by Head-of-Line (HOL) blocking associated to TCP retransmissions that result from network packet loss [17]. HOL, in turns, causes messages to arrive too late to the application layer of clients so that, for all intents and purposes, they can be considered lost. The IoT alternative to HTTP, CoAP, addresses some of these issues by binary encoding as well as compressing session parameters and by relying on UDP for transport. To deal with some of the shortcomings associated to UDP, CoAP introduces two modes of operation; (1) non-confirmable where a packet is sent as “fire-and-forget” without any guarantee of successful delivery and (2) confirmable where a packet is considered delivered once a far-end initiated acknowledgment is received. Specifically, confirmable CoAP introduces a much simpler retransmission mechanism than that of TCP. Yet confirmable CoAP does not solve all the problems; (1) by relying on UDP transport, it is subjected to firewall traversal blocking on end-to-end scenarios [13] and (2) its congestion control by being designed to run in low complexity constrained devices is not as reactive as the TCP equivalent. Congestion control in the context of CoAP has been addressed by several proposed mechanisms but ultimately IETF RFC 8323 “CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” introduces a framing mechanism for transmission of CoAP traffic over TCP [4]. Unfortunately, CoAP over TCP brings back the HOL problems seen with HTTP over TCP. Summarizing, the use of confirmable CoAP and CoAP over TCP solve and introduce different sets of problems that, depending on the circumstances, may be mutually exclusive.

Fig. 1
figure1

UDP, QUIC and TCP driven CoAP

QUIC, initially introduced by Google as an alternative to TCP in the context of HTTP, is a transport layer protocol that, being in the process of standardization by IETF, attempts to lower connection setup as well as transmission latency and consequently improve congestion performance [16]. QUIC accomplishes this flexibility, by building a mechanism to multiplex several connections over UDP. Moreover, QUIC provides built-in security in opposition to TCP and UDP transport that, respectively, requires Transport Layer Security (TLS) and Datagram TLS (DTLS) security layers. In this paper, we propose the use of QUIC as an alternative to both UDP and TCP for transport of CoAP traffic. Specifically, Fig. 1 shows a comparison of UDP, TCP and QUIC as drivers of CoAP traffic in a context of an IoT Wireless Personal Area Network (WPAN). In this scenario, IEEE 802.15.4 is one of the preferred physical and link layer WPAN technologies that enables low power consumption at a maximum nominal transmission rate of 250 Kbps. This low transmission rate, to minimize channel contention, limits the Maximum Transmission Unit (MTU) size to around 127 bytes. Since IPv6 can generate datagrams that are a lot larger than 127 bytes, an adaptation layer known as IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) is typically used to provide, among other things, compression and fragmentation. In general, whenever IEEE 802.15.4 and IPv6 are combined, 6LoWPAN is also part of the mix. When CoAP relies purely on UDP for transport, security is by means of DTLS. Similarly, when CoAP runs on top of TCP, security results from TLS. If CoAP is used over QUIC, then UDP is still at play to act as a very thin layer below the main transport functionality supported by QUIC itself. In addition, QUIC also provides built-in security without the need of any other additional mechanism like TLS or DTLS.

To this end, we first focus on introducing an analytical model that approximates application layer message loss as a function of network layer datagram loss for CoAP transmission over all three transport mechanisms; UDP, TCP and QUIC. This model is used to generalize the best transport scenario and determine the system parameters that end up affecting application message loss. The model is then validated against an experimental framework that is subjected to diverse network conditions to verify the comparative advantages of QUIC with respect to both UDP and TCP transport.

The remainder of the paper is organized as follows; a literature review of related work is presented in “Related Work and Motivation”. The transport model and its theoretical analysis are introduced in “UDP, TCP and QUIC Transport Analysis”. In “Experimental Analysis”, an experimental framework is presented and used to validate the analytical model. Conclusion and future work are provided in “Conclusion and Future Work”.

Related Work and Motivation

There are no studies that address the use of CoAP over QUIC transport. Papers that revolve around QUIC transport, typically focus on HTTP sessions in the context of web traffic and media streaming. In [16], the authors analyze the performance of QUIC with respects to that of TCP. A performance analysis of both QUIC and TCP in the context of media streaming is presented in [18]. Similarly, in [3] QUIC performance as transport of HTTP sessions is detailed. A study on the latency and throughput in QUIC transported media is presented in [5].

Most of the studies of CoAP performance explore traditional UDP transport with special focus on the different modes of operation; namely confirmable and non-confirmable transactions. Some of these papers include [20] where the authors measure impairments in a CoAP-based Wireless Sensor Network (WSN) with multi-hop routing. In [6], the authors analyze impairments and throughput that are measured in the context of CoAP and other session layer protocols like Message Queuing Telemetry Transport (MQTT). Congestion control mechanisms introduced by both CoAP and MQTT are presented in [7] for different network conditions. Similarly, in [19], the authors compare CoAP against other more traditional information management protocols like Simple Network Management Protocol (SNMP) where latency is used as common element of comparison.

Related to transport is congestion control and its improvements. Papers that address these issues include [1] where the authors present CoAP Simple Congestion Control/Advanced (CoCoA), a congestion control mechanism that relies on a Round Time Trip (RTT) estimation-based mechanism. CoCoA and its limitations along with several improvements are detailed in [2]. An alternative congestion control method is introduced in [15]. In [13] and in [11], CoAP encapsulation as well as CoAP media transport are modeled and compared against an experimental framework. Finally, a mechanism for dynamic CoAP mode selection over UDP transport is presented in [12].

UDP, TCP and QUIC Transport Analysis

One of the goals of this paper is to introduce a mathematical model that can be used to estimate the impairments that affect sensor data transmitted over CoAP. Specifically, application layer packet loss and latency are obtained for UDP, TCP and QUIC transported CoAP as a function of datagram loss at the network layer. In the context of IoT, application layer latency causes lost messages since messages that arrive too late can be considered lost. Deciding when a message has arrived too late, however, depends on QoS requirements; an application that relies on processing offline sensor data is a lot less restrictive than another application attempting to set flightpath “way-points” calculated from real-time on-board sensor readouts on an Unmanned Aerial Vehicle (UAV). As part of this analysis it is critical to present the wireless IoT channel model.

Gilbert-Elliot Two-State Channel Model

Bursty packet loss, the main characteristic of dynamic multipath fading in wireless environments, can be accurately represented by the Gilbert-Elliot two-state Markov channel model [14] shown in Fig. 2. The model introduces a good and a bad state that imply low and high packet loss with loss rates given by \(e_{\mathrm{G}}\) and \(e_{\mathrm{B}}\), respectively. Gibert [9] further simplifies the model with the special case of an error-free good state (\(e_{\mathrm{G}} =0\)) and left the extension to include losses generated in both states to Elliott [8].

Fig. 2
figure2

Gilbert-Elliot channel model

The model is characterized by four parameters; (1) p, the transition probability from the good to the bad state, (2) \(\alpha\), the probability that the channel remains in the bad state, (3) \(e_{\mathrm{G}}\), the packet loss probability when the channel is in the good state and (4) \(e_{\mathrm{B}}\), the packet loss probability when the channel is in the bad state. Note that p and \(\alpha\) can be thought of as parameters controlling network packet loss and loss burstiness respectively. When simplifying the model by assuming \(e_{\mathrm{G}} = 0\) and \(e_{\mathrm{B}} = 1\) the steady state probabilities that the channel is either in a “bad” or “good” state are given by

$$\begin{aligned} P_{\mathrm {bad}} = \frac{p}{1 - \alpha + p} \end{aligned}$$

and

$$\begin{aligned} P_\mathrm {good} = \frac{1 - \alpha }{1 - \alpha + p} \end{aligned}$$

respectively.

In the context of typical IoT scenarios, devices talk to applications through gateways. Communication between a device and the gateway is wireless over a single-hop access low-power lossy network (LLN), while communication between the gateway and the application is over a core network. Because wireless access packet loss associated with fading is significantly larger than the core network loss, the latter can be considered negligible when estimating overall system loss. Therefore, in this paper, the channel model represents the effect of the loss associated with the IEEE 802.15.4 single-hop communication between a device and the gateway. Note that this model has been used to represent wireless channels from a network layer perspective in some of the papers introduced in “Related Work and Motivation” [11, 13]. This is because the model is quite accurate as it captures bursty packet loss associated with multipath fading. This paper, however, is the first to rely on this model to represent QUIC transport and to compare it against UDP and TCP transport layers.

CoAP over UDP

Device data, either sensor readouts or actuator information, are transmitted by means of CoAP transactions that typically rely on UDP for transport. In this scenario, CoAP configured in confirmable mode provides reliability that makes the comparison against TCP and QUIC relevant.

Fig. 3
figure3

CoAP header under UDP transport

Figure 3 shows a CoAP header associated to UDP transport. For performance sake and to minimize throughput as well as to lower the MTU size, CoAP encoding, when compared to that of HTTP, is binary. The header starts with two 2-bit version and message type fields that, respectively, indicate the CoAP version and whether the message is confirmable or non-confirmable. If the CoAP session is identified by a variable length token, the token length is encoded next as a 4-bit number. The 8-bit code field that follows is used to indicate, among other things, the numeric response code. The 16-bit message id field serves to identify individual transactions within a given session. If the variable length token is present, it is encoded right after. Similarly, if options are present, they are encoded next. The payload, then, concludes the body of the message.

Fig. 4
figure4

Transactions of CoAP over UDP

Figure 4 shows the the confirmable CoAP transactions associated to a device periodically transmitting messages that are received by an application. In many real time scenarios, like media transmission, messages must be processed in the order in which they are transmitted; for example, message 1 must be processed before message 2 and message 2 must be processed before message 3. The mechanism relies on a jitter (or playout) buffer that attempts to queue a number of messages or wait for a fixed period of time before starting to process messages. In either case the end result is extra latency. Note that confirmable CoAP retransmissions follow an exponential pattern as shown in aforementioned Figure. Message 1 is retransmitted but because of network loss, the exponentially timed retransmissions result in the message arriving too late to be considered relevant. By this point, message 2 has been already delivered to the application.

Although the initial timeout, defined as \(\varDelta\), is configurable and depends on the application under consideration, it is randomly selected to be somewhere in the 2–3.5 s range. Similarly, the maximum number of retransmissions, before a confirmable packet is considered lost, is \(N = 3\). The probability of a successful transmission and acknowledgment, defined as \(P_\mathrm {ack,trans}\), is given by

$$\begin{aligned} P_\mathrm {ack,trans}&= P_\mathrm {ack|trans,good} P_\mathrm {trans|good} P_\mathrm {good} \nonumber \\&\quad + P_\mathrm {ack|trans,bad} P_\mathrm {trans|bad} P_\mathrm {bad} \end{aligned}$$
(1)

where \(P_\mathrm {ack|trans,good}\) and \(P_\mathrm {ack|trans,bad}\) are the conditional probabilities of successful acknowledgment given a successful transmission for the channel in the good and bad states, respectively, \(P_\mathrm {trans|good}\) and \(P_\mathrm {trans|bad}\) are the conditional probabilities of successful transmission for the channel in the good and bad states, respectively, and \(P_\mathrm {good}\) as well as \(P_\mathrm {bad}\) are the steady-state channel probabilities discussed in “Gilbert-Elliot Two-State Channel Model”. Considering that the probabilities of transmission of confirmable packets and their acknowledgments are the same, the conditional probabilities of successful acknowledgment given a successful transmission are as follows

$$\begin{aligned} P_\mathrm {ack|trans,good}&= \; P_\mathrm {trans|good} P_{\mathrm {good} \rightarrow \mathrm {good}} \nonumber \\&\quad + P_\mathrm {trans|bad} P_{\mathrm {good} \rightarrow \mathrm {bad}} \end{aligned}$$
(2)

and

$$\begin{aligned} P_\mathrm {ack|trans,bad}&= P_\mathrm {trans|good} P_{\mathrm {bad} \rightarrow \mathrm {good}} \nonumber \\&\quad + P_\mathrm {trans|bad} P_{\mathrm {bad} \rightarrow \mathrm {bad}} \end{aligned}$$
(3)

where \(P_{\mathrm {good} \rightarrow \mathrm {good}}\), \(P_{\mathrm {good} \rightarrow \mathrm {bad}}\), \(P_{\mathrm {bad} \rightarrow \mathrm {good}}\) and \(P_{\mathrm {bad} \rightarrow \mathrm {bad}}\) are all possible transition probabilities of the channel switching from one state to another.

As indicated in “Gilbert-Elliot Two-State Channel Model”, the steady state probabilities are \(P_\mathrm {good} = \frac{1-\alpha }{1-\alpha +p}\) and \(P_\mathrm {bad} = \frac{p}{1-\alpha +p}\) and the successful transmission probabilities for good as well as bad channel states are \(P_\mathrm {trans|good} = 1 - e_{\mathrm{B}}\) and \(P_\mathrm {trans|bad} = 1 - e_{\mathrm{G}}\), respectively. From the channel model in Fig. 2, the transition probabilities are \(P_{\mathrm {good} \rightarrow \mathrm {bad}} = p\), \(P_{\mathrm {bad} \rightarrow \mathrm {good}} = 1 - \alpha\) and \(P_{\mathrm {bad} \rightarrow \mathrm {bad}} = \alpha\) and, therefore, the probability of a successful transmission and acknowledgment is given by

$$\begin{aligned} P_{\mathrm {ack,trans}}&= \frac{1}{1 - \alpha + p} \Big [ \left( 1 - \alpha \right) \left( 1 - e_{\mathrm{B}} \right) \big [ 1 - e_{\mathrm{G}} p - e_{\mathrm{B}} \left( 1 - p \right) \big ] \nonumber \\&\quad + p \left( 1 - e_{\mathrm{G}} \right) \big [ 1 - e_{\mathrm{G}} \alpha - e_{\mathrm{B}} \left( 1 - \alpha \right) \big ] \Big ] \end{aligned}$$
(4)

such that for ideal conditions, that is when \(e_{\mathrm{G}} = 1\) and \(e_{\mathrm{B}} = 0\), the expression becomes

$$\begin{aligned} P_{\mathrm {ack,trans}} = \frac{\left( 1 - \alpha \right) \left( 1- p \right) }{1 - \alpha + p}. \end{aligned}$$
(5)

The overall probability of success after \(R = k\) retransmissions of a packet frame follows a geometric distribution with probability mass function (pmf) given by

$$\begin{aligned} P_\mathrm {udp}\left( R = k\right) = P_\mathrm {ack,trans} \left( 1 - P_\mathrm {ack,trans} \right) ^k. \end{aligned}$$
(6)

In real-time IoT applications, it can be assumed that any packet received after \(\varLambda\) seconds is considered lost. \(\varLambda \in \mathbb {R}\) is, therefore, a QoS parameter that depends on the application under consideration and it specifies how long the jitter buffer must be filled before processing starts. The loss probability is therefore given by

$$\begin{aligned} P_\mathrm {udp}\left( \mathrm {loss}\right)&= P_\mathrm {udp}\left( \mathrm {latency} > \varLambda \right) \nonumber \\&= 1 - P_\mathrm {udp}\left( \mathrm {latency} < \varLambda \right) , \end{aligned}$$
(7)

where \(P_\mathrm {udp}\left( \mathrm {latency} < \varLambda \right)\) is the probability that the average transmission latency is less than \(\varLambda\). Because under confirmable CoAP retransmissions are exponentially spaced, the overall latency after k retransmissions is \(\varDelta \left( 2^k - 1 \right)\). Accordingly, the number of retransmissions associated to a latency shorter than \(\varLambda\) is given by \(k \le \log _2{\left( \frac{\varLambda }{\varDelta } + 1 \right) } \le N\). The application message loss in this case is given by

$$\begin{aligned} P_\mathrm {udp}\left( \mathrm {loss}\right)&= 1 - \sum _{k=0}^{ \varGamma } P_\mathrm {udp}\left( R = k\right) \nonumber \\&= 1 - P_\mathrm {ack,trans} \sum _{k=0}^{ \varGamma } \left( 1 - P_\mathrm {ack,trans} \right) ^k \nonumber \\&= \left( 1 - P_\mathrm {ack,trans} \right) ^{ \varGamma + 1 } \end{aligned}$$
(8)

where \(\varGamma = \min \left( N, \log _2{\left( \frac{\varLambda }{\varDelta } + 1 \right) } \right)\) and \(P_\mathrm {ack,trans}\) is obtained from Eq. 5 above.

CoAP over TCP

CoAP was designed to be transported over UDP with reliability provided by means of the confirmable mode of operation. In certain scenarios in which the simplicity of the confirmable CoAP congestion control mechanism is not efficient enough, CoAP can be transported over TCP. TCP transport has some additional benefits like enabling the transmission of CoAP traffic over restrictive networks with firewalls that filter UDP datagrams.

Fig. 5
figure5

CoAP header under TCP transport

CoAP transmission over TCP relies on a special header, shown in Fig. 5, that provides basic framing that enables the packing of CoAP messages inside TCP streams. The header starts with a 4-bit length field that specifies the length of the message starting at the options field. The maximum length size allowed is 12 bytes and reserved values 13, 14 and 15 are used to indicate that the message length is, respectively, a 8-bit, 16-bit and 32-bit extended length field. If the CoAP session is identified by a variable length token, the token length is encoded next as a 4-bit number. The extended length field is next if selected by the length field. The 8-bit code field that follows is used to indicate, among other things, the numeric response code. If the variable length token is present, it is encoded right after. Similarly, if options are present, they are encoded next. The payload, then, concludes the body of the message. When compared to CoAP over UDP, neither message identifier nor message type fields are needed as the TCP layer keeps track of the request/response pairs.

Fig. 6
figure6

Transactions of CoAP over TCP

Figure 6 shows the CoAP over TCP transactions associated to a device periodically transmitting messages that are received by an application. This is analogous to the scenario shown in Fig. 4 for CoAP over UDP. Under TCP transport stack parameters like Nagle’s algorithm support and window sizes are specifically configured to guarantee that the application layer becomes aware of network packet loss. Instead of pumping frames at a constant rate and being affected by TCP HOL blocking, the application sends one message upon successful acknowledgment of the delivery of the previously transmitted message. While waiting for a message delivery, however, those later messages that are due for transmission are dropped at the application layer. This mechanism can be implemented at user space and requires no TCP stack changes.

Similar to confirmable CoAP over UDP, under TCP the overall probability of success after \(R = k\) retransmissions of a packet frame follows a geometric distribution with probability mass function (pmf) given by

$$\begin{aligned} P_\mathrm {tcp}\left( R = k\right) = P_\mathrm {ack,trans} \left( 1 - P_\mathrm {ack,trans} \right) ^k. \end{aligned}$$
(9)

Another important factor to take into account under TCP is latency. TCP retransmissions are typically triggered whenever a timeout is detected. The timeout is dynamically estimated from the Round-Trip Time (RTT) as a moving average that takes into account the standard deviation between real-time RTT samples and the aforementioned average. As a simplification it can be assumed that for the \(k\mathrm {th}\) retransmission, the timeout is \(k \; \mathrm{RTT}\). Overall latency is, therefore, given by

$$\begin{aligned} P_\mathrm {tcp}\left( \mathrm {latency}\right)&= \mathrm{RTT} \sum _{k=0}^{\infty } P_\mathrm {tcp}\left( R = k\right) \nonumber \\&= \mathrm{RTT} P_\mathrm {ack,trans} \sum _{k=0}^{\infty } \left( 2^k - 1 \right) \left( 1 - P_\mathrm {ack,trans} \right) ^k \nonumber \\&= \mathrm{RTT} \frac{1 - P_\mathrm {ack,trans}}{2P_\mathrm {ack,trans} - 1}. \end{aligned}$$
(10)

As in the previous case, \(\varLambda\) is a value that represents the maximum allowable latency such that the number of retransmissions results \(k \le \log _2 \left( \frac{\varLambda }{\rm{RTT}} + 1 \right)\). The application message loss in this case is, therefore, given by

$$\begin{aligned} P_\mathrm {tcp}\left( \mathrm {loss}\right)&= \min \left( 1, \left[ 1 - \sum _{k=0}^{ \log _2 \left( \frac{\varLambda }{ RTT } + 1 \right) } P_\mathrm {tcp}\left( R = k\right) \right] \varPsi \right) \nonumber \\&= \min \left( 1, \left( 1 - P_\mathrm {ack,trans} \right) ^{ \log _2 \left( \frac{\varLambda }{\rm{RTT}} + 1 \right) + 1 } \varPsi \right) \end{aligned}$$
(11)

where \(P_\mathrm {ack,trans}\) is obtained from Eq. 5 and \(\varPsi\) results from

$$\begin{aligned} \varPsi&= \frac{{\rm{RTT}} \left( 1 - P_\mathrm {ack,trans} \right) }{T P_\mathrm {ack,trans}} \end{aligned}$$
(12)

where T is the packet transmission period. As expected, as \(P_\mathrm {ack,trans} \rightarrow 1\) then \(P_\mathrm {tcp}\left( \mathrm {loss}\right) \rightarrow 0\) and similarly as \(P_\mathrm {ack,trans} \rightarrow 0\) then \(P_\mathrm {tcp}\left( \mathrm {loss}\right) \rightarrow 1\).

CoAP over QUIC

Since QUIC was designed as an efficient transport replacement to TCP transport in the context of HTTP, it can be applied to CoAP as a replacement to TCP. One of the main advantages of QUIC when compared to TCP transport is that addressed the limitations associated to HOL blocking. To this end, CoAP framing must follow the same header format shown in Fig. 5.

Fig. 7
figure7

Transactions of CoAP over QUIC

Figure 7 shows the CoAP over QUIC transactions associated to a device periodically transmitting messages that are received by an application. This is analogous to the scenario shown in Fig. 6 for CoAP over TCP. One big difference between QUIC and TCP transport is that QUIC is not affected by HOL blocking. HOL is associated with a single stream, however, CoAP is used to transmit sensor readouts and actuator commands that are asynchronous in nature. Specifically, there is no need for data to arrive in any particular order so if the transport layer doesn’t rely on a single stream CoAP will not be affected by HOL issues. Because CoAP is affected by HOL when configured to transmit over a single stream, care must be taken to make sure that multiple streams are used instead. The main difference between Figs. 6 and 7 results from the fact that TCP does not deliver messages to CoAP if the stream is blocked while QUIC does. Because CoAP is asynchronous in nature the only source of blocking is TCP. With this in mind, it is possible to derive the application message loss by first estimating the overall probability of success after \(R = k\) retransmissions of a packet frame follows a geometric distribution with probability mass function (pmf) given by

$$\begin{aligned} P_\mathrm {quic}\left( R = k\right) = P_\mathrm {ack,trans} \left( 1 - P_\mathrm {ack,trans} \right) ^k. \end{aligned}$$
(13)

As for TCP transport, under QUIC, retransmissions are triggered when a connection timeout, estimated from the RTT, expires. Again, considering \(\varLambda\) as maximum latency, the number of retransmissions results \(k \le \frac{\varLambda }{\rm{RTT}}\). The application message loss in this case is therefore given by

$$\begin{aligned} P_\mathrm {quic}\left( \mathrm {loss}\right)&= 1 - \sum _{k=0}^{ \frac{\varLambda }{\rm{RTT}} } P_\mathrm {tcp}\left( R = k\right) \nonumber \\&= \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{ RTT } + 1 } \end{aligned}$$
(14)

where \(P_\mathrm {ack,trans}\) is obtained from Eq. 5.

Analytical Comparison of Transport Mechanisms

Fig. 8
figure8

Theoretical application message loss probability

Figure 8 shows a comparison of the theoretical performance of CoAP under all three transport mechanisms. The curves show the message loss probabilities \(P_\mathrm {udp}\left( \mathrm {loss}\right)\), \(P_\mathrm {tcp}\left( \mathrm {loss}\right)\) and \(P_\mathrm {quic}\left( \mathrm {loss}\right)\), obtained, respectively, from Eqs. 811 and 14, as a function of \(P_\mathrm {ack,trans}\). Note that \(P_\mathrm {ack,trans}\) is obtained from Eq. 5 as a function of the network packet loss p and its burstiness \(\alpha\). The following representative values are used for the computation of these probabilities; \(RTT =0.05\), \(N = 3\), \(\varDelta = 2.5\), \(\varLambda = 0.1\) and \(T = 0.02\). The plot shows that when comparing UDP against TCP transport, UDP performs better for very lossy networks (i.e. \(P_\mathrm {ack,trans} \lessapprox \frac{1}{2}\) in this scenario) while TCP performs better otherwise. However, QUIC performs a lot better than both UDP and TCP.

In fact, from Eqs. 8 and 14, it can be that if \(\varLambda < N {\rm{RTT}}\), that is, the jitter buffer length is smaller that N times the round-tip time, then QUIC always performs better than UDP, as shown by

$$\begin{aligned} \frac{\varLambda }{\rm{RTT}}&< N \nonumber \\ \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{ RTT } + 1 }&< \left( 1 - P_\mathrm {ack,trans} \right) ^{ N + 1 } \nonumber \\ \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{ RTT } + 1 }&< \left( 1 - P_\mathrm {ack,trans} \right) ^{ \varGamma + 1 } \nonumber \\ P_\mathrm {quic}\left( \mathrm {loss}\right)&< P_\mathrm {udp}\left( \mathrm {loss}\right) \end{aligned}$$
(15)

Similarly, from Eqs. 11 and 14, it can be that if \(T < {\rm{RTT}}\), that is, the packet transmission period is smaller than the round-trip time, then QUIC always performs better than TCP, as indicated by

$$\begin{aligned} \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{\rm{RTT}} + 1 }&< \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{\rm{RTT}} + 1 } \varPsi \nonumber \\ \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{\rm{RTT}} + 1 }&< \min \left( 1, \left( 1 - P_\mathrm {ack,trans} \right) ^{ \frac{\varLambda }{\rm{RTT}} + 1 } \varPsi \right) \nonumber \\ P_\mathrm {quic}\left( \mathrm {loss}\right)&< P_\mathrm {tcp}\left( \mathrm {loss}\right) \end{aligned}$$
(16)

since \(\varPsi > 1\) when \(T < {\rm{RTT}}\). This means that the longer the propagation delay, the better the performance of QUIC with respect to both CoAP over UDP and TCP transport.

Since supporting multiple transport mechanisms on an embedded device can be both computationally and resource expensive, it is a good idea to experimentally validate the results shown by the analytical model in other to narrow down CoAP stack requirements. The following Section introduces a scheme that shows for how much the theoretical model deviates from the experimental framework and whether the former can be used to draw conclusions and generalize functionality about the latter.

Experimental Analysis

Fig. 9
figure9

Experimental framework

Fig. 10
figure10

CoAP observation transactions

Fig. 11
figure11

Experimental application message loss probability \(\left( \alpha = 0.1 \right)\)

Fig. 12
figure12

Experimental application message loss probability \(\left( \alpha = 0.5 \right)\)

Fig. 13
figure13

Experimental application message loss probability \(\left( \alpha = 0.9 \right)\)

For most IoT scenarios, RTT can be considered constant for any given session, because devices are wireless but not subjected to mobility. Moreover, the sensors are constrained devices that are observed by an application and periodically transmit readouts. The experimental framework used to validate the analytical model presented in “UDP, TCP and QUIC Transport Analysis” is shown in Fig. 9. The framework includes K independent temperature sensors that transmit readouts at a fixed rate of 50 samples per second. All K sensors are started with a one millisecond staggering delay in order to minimize the chances of traffic bursts. The mechanism relies on IETF RFC 7641 “Observing Resources in the Constrained Application Protocol” [10], that enables CoAP to provide unidirectional sensor observation. The jitter buffer size of the observer is configured to be 100 ms. Each experiment consists of a single 300-s session where application layer packet loss is calculated at the output of the jitter buffer. This is computed for all transmission scenarios analyzed in this paper including confirmable CoAP over UDP, CoAP over TCP and CoAP over QUIC. All network elements in the framework, as well as the network packet loss introduced in this scheme, are emulated by means of VPS+ [21]. This tool provides protocol stack virtualization that enables full IoT network emulation. Specifically, these protocols can be deployed on any hardware including native physical interfaces like IEEE 802.15.4. Figure 10 shows the CoAP transactions between the client, acting as an observer, and the sensors. In all cases, the observer transmits GET requests to start sensor observation. Only under confirmable CoAP over UDP, the requests are acknowledged by means of CoAP ACK messages. When sensor readouts become available, the devices transmit 2.05 Content responses to carry this information. Again, only under confirmable CoAP over UDP, the responses are acknowledged by means of CoAP ACK messages.

Table 1 Application message loss analysis

Figures 11 through 13 show the application layer message loss probability as a function of the network layer packet loss p for three levels of network loss burstiness. Specifically, Figs. 1112 and 13 are associated to three different levels of loss burstiness; low (\(\alpha = 0.1\)), medium (\(\alpha = 0.5\)) and high (\(\alpha = 0.9\)) respectively. The results comply with the theoretical analysis where it can be seen that QUIC transport outperforms both UDP and TCP for all network loss burstiness. For low network loss burstiness, QUIC and TCP perform quite similar while for higher levels, QUIC transport exhibits a lot better performance. These results are numerically shown in Table 1 where the application message loss probability is presented as an average over all values of network packet loss p. The Table shows both experimental and theoretical values of the message loss probability and the percentage error between both values. Numerical values comply with the experimental results shown in Figs. 11 through 13 and the theoretical results shown in Fig. 8. It is important to note that the analytical model is quite efficient at predicting UDP traffic but is less accurate for TCP and QUIC transport. In either case, the Table clearly indicates that QUIC is a better option for CoAP transmission than both TCP and UDP transport. Confirmable CoAP sessions transported by means of UDP exhibit, on average, an application message packet loss of 0.1994, 0.2594 and 0.3789 for low, medium and high loss burstiness. Similarly, CoAP transported by means of TCP shows, on average, an application message packet loss of 0.0053, 0.0165 and 0.1235 for low, medium and high loss burstiness. On the other hand, QUIC transported CoAP exhibits, on average, an application message packet loss of 0.003, 0.0081 and 0.0336 for low, medium and high loss burstiness. As expected for all scenarios, the higher the network loss burstiness is, the worse the performance results are. Calculated values obtained from the analytical model are slightly higher those that result from the experimental framework. The analytical model estimation error corresponding to QUIC transport is larger than that of TCP and, in turns, the error associated to TCP transport is larger than that of UDP. In all cases, the experimental analysis is compatible with the theoretical results by showing that QUIC is a more efficient alternative than UDP and TCP based CoAP transport.

Conclusion and Future Work

In this paper, we propose QUIC as an alternative mechanism to transport of CoAP IoT traffic. Specifically, we introduced an analytical model that provides an estimation of the application layer message loss of CoAP in the context of traditional UDP and TCP transport as well as the proposed QUIC scheme. The model shows that QUIC is less lossy than TCP and UDP transport under the same conditions as long as the application jitter buffer size and the packet transmission period are within certain limits. The experimental framework, that is setup to verify the analytical model, produces results that confirm that QUIC outperforms both TCP and UDP transport. The analytical model estimates an application message loss probability that is, on average, within 1.67, 65.06 and \(79.42\%\) of the experimental results for UDP, TCP and QUIC transport, respectively. The less accuracy for TCP and QUIC is likely to be originated by the fact that the RTT is assumed to be constant over the length of the experiment. The experimental framework also validates that QUIC transport provides an application message loss that is, on average, 5.33 and \(30.76\%\) of that of UDP and TCP transport, respectively. This validates the fact that QUIC transport provides a better alternative to both UDP and TCP transport in the context of CoAP IoT sessions.

There are many more aspects of QUIC transport, derived from this paper, that can serve as subjects of future study. Specifically, one important issue consists of analyzing whether TCP framing, as specified by IETF RFC 8323, is appropriate for QUIC transport or whether it needs to be adapted to comply with specific CoAP requirements. Additionally, the mathematical model can be fine tuned to address some limitations including uplink and downlink effects of network impairments. The experimental framework can be also upgraded to support both the non-periodical transmission of sensor readouts and variable RTTs typically associated with mobile devices. Another important focus of study is extending the analytical model to support not only periodic but also bursty sensor readout transmissions. Moreover, for this latter scenario, the model can be upgraded to estimate session latency in addition to the application message loss probability.

References

  1. 1.

    Betzler A, Gomez C, Demirkol I, Paradells J. Coap congestion control for the internet of things. IEEE Communications Magazine. 2016;54(7):154–60. https://doi.org/10.1109/MCOM.2016.7509394.

    Article  Google Scholar 

  2. 2.

    Bhalerao R, Subramanian SS, Pasquale J. An analysis and improvement of congestion control in the coap internet-of-things protocol. In: 2016 13th IEEE Annual Consumer Communications Networking Conference (CCNC), 2016;889–894. https://doi.org/10.1109/CCNC.2016.7444906

  3. 3.

    Biswal P, Gnawali O. Does quic make the web faster? In: 2016 IEEE Global Communications Conference (GLOBECOM), 2016;1–6

  4. 4.

    Bormann C, Lemay S, Tschofenig H, Hartke K, Silverajan B, Raymor B. CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. RFC 8323, 2018. https://doi.org/10.17487/RFC8323. https://rfc-editor.org/rfc/rfc8323.txt

  5. 5.

    Bujari A, Palazzi CE, Quadrio G, Ronzani D. Emerging interactive applications over quic. In: 2020 IEEE 17th Annual Consumer Communications Networking Conference (CCNC), 2020;1–4

  6. 6.

    Chen Y, Kunz T. Performance evaluation of iot protocols under a constrained wireless access network. In: 2016 International Conference on Selected Topics in Mobile Wireless Networking (MoWNeT), 2016;1–7 . https://doi.org/10.1109/MoWNet.2016.7496622

  7. 7.

    Collina M, Bartolucci M, Vanelli-Coralli A, Corazza GE. Internet of things application layer protocol analysis over error and delay prone links. In: 2014 7th Advanced Satellite Multimedia Systems Conference and the 13th Signal Processing for Space Communications Workshop (ASMS/SPSC), pp. 398–404 (2014). https://doi.org/10.1109/ASMS-SPSC.2014.6934573

  8. 8.

    Elliott EO. Estimates of error rates for codes on burst-noise channels. The Bell System Technical Journal. 1963;42(5):1977–97. https://doi.org/10.1002/j.1538-7305.1963.tb00955.x.

    Article  Google Scholar 

  9. 9.

    Gilbert EN. Capacity of a burst-noise channel. The Bell System Technical Journal. 1960;39(5):1253–65. https://doi.org/10.1002/j.1538-7305.1960.tb03959.x.

    MathSciNet  Article  Google Scholar 

  10. 10.

    Hartke K. Observing Resources in the Constrained Application Protocol (CoAP). RFC 7641 (2015). https://doi.org/10.17487/rfc7641. https://rfc-editor.org/rfc/rfc7641.txt

  11. 11.

    Herrero, R.: Media communications in internet of things wireless sensor networks. Internet Technology Letters 0(0), e46. https://doi.org/10.1002/itl2.46

  12. 12.

    Herrero, R. Dynamic coap mode control in real time wireless iot networks. IEEE Internet of Things Journal, 2018;1–1. https://doi.org/10.1109/JIOT.2018.2857701

  13. 13.

    Herrero R. Encapsulation of real-time iot coap traffic. Trans. Emerging Telecommunications Technologies 2018;29(3). https://doi.org/10.1002/ett.3287.

  14. 14.

    Hohlfeld O, Geib R, Hasslinger G. (2008). Packet loss in real-time services: Markovian models generating qoe impairments. In: 2008 16th Interntional Workshop on Quality of Service, pp. 239–248. https://doi.org/10.1109/IWQOS.2008.33

  15. 15.

    Lee JJ, Chung SM, Lee B, Kim KT, Youn HY. Round trip time based adaptive congestion control with coap for sensor network. In: 2016 International Conference on Distributed Computing in Sensor Systems (DCOSS), pp. 2016;113–115. https://doi.org/10.1109/DCOSS.2016.35

  16. 16.

    Nepomuceno K, d. Oliveira IN, Aschoff RR, Bezerra D, Ito MS, Melo W, Sadok D, Szabo G. Quic and tcp: A performance evaluation. In: 2018 IEEE Symposium on Computers and Communications (ISCC), 2018;00045–00051

  17. 17.

    Oda N, Yamaguchi S. Http/2 performance evaluation with latency and packet losses. In: 2018 15th IEEE Annual Consumer Communications Networking Conference (CCNC), 2018;1–2

  18. 18.

    Seufert M, Schatz R, Wehner N, Casas P. Quicker or not? -an empirical analysis of quic vs tcp for video streaming qoe provisioning. In: 2019 22nd Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), 2019;7–12

  19. 19.

    Slabicki M, Grochla K. Performance evaluation of coap, snmp and netconf protocols in fog computing architecture. In: NOMS 2016 - 2016 IEEE/IFIP Network Operations and Management Symposium, pp. 2016;1315–1319. https://doi.org/10.1109/NOMS.2016.7503010

  20. 20.

    Thombre S, Islam RU, Andersson K, Hossain MS. Performance analysis of an ip based protocol stack for wsns. In: 2016 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2016;360–365. https://doi.org/10.1109/INFCOMW.2016.7562102

  21. 21.

    VPS+: Visual protocol stack emulator. https://www.l7tr.com

Download references

Author information

Affiliations

Authors

Corresponding author

Correspondence to Rolando Herrero.

Ethics declarations

Conflict of interest

The author declares that he has no conflict of interest.

Ethical approval

This article does not contain any studies with human participants or animals performed by any of the authors.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Herrero, R. Analysis of QUIC Transported CoAP. SN COMPUT. SCI. 2, 62 (2021). https://doi.org/10.1007/s42979-021-00468-0

Download citation

Keywords

  • CoAP
  • UDP
  • TCP
  • QUIC
  • QoS