The standardization of the Constrained Application Protocol (CoAP) via Request for Comments (RFC)1 has enabled an efficient representational state transfer Application Program Interface (API)-based interaction between applications and sensors. In this context, the transmission relies on connectionless User Datagram Protocol (UDP) transport that is highly efficient at delivering frames by minimizing the overall end-to-end latency. Restrictive access networks like the public Internet, however, use firewalls that block this type of traffic and only allow the traversal of web-friendly Transmission Control Protocol (TCP) transported frames. Therefore, an alternative to accomplishing a successful transmission of sensor data in an environment where datagrams are dropped is by means of tunneling. Tunneling relies on encapsulating complete sensor data packets, including network layers, on top of a, typically TCP or stream based, firewall-friendly transport that requires no network topology changes. Although it is possible to alternatively use UDP-based encapsulation either by masking UDP as TCP2 or by using well-known Domain Name Server UDP ports,3 recently developed improvements in Deep Packet Inspection implemented at firewalls render these mechanisms useless. As shown in Figure 1, access side traffic is generated by sensors and transmitted on top of CoAP at layer 5 (L5). CoAP is, in turn, transported on top of UDP at layer 4 (L4) and then packetized into IPv6 datagrams that are compressed and fragmented by means of low-power wireless personal area networks (6LoWPAN) at layer 3 (L3). This provides adaptation for transmission over a low-rate wireless IEEE 802.15.4 infrastructure at layers 1 and 2 (L1/2). Access traffic eventually reaches a gateway or cluster head that provides core connectivity to the public Internet. In order to provide firewall traversal capabilities, sensor packets become encapsulated as inner traffic that is streamed at L5 on top of the outer TCP at L4 over IPv6 at L3. These 2 layers, L3 and L4, are removed when the packets arrive at the tunnel server that decapsulates the original L3 and L4 layers and provides routing to the CoAP application that consumes the sensor data. Transporting sensor data over a stream, being TCP a protocol that relies on an Automatic Repeat reQuest (ARQ) mechanism, causes extra latency that is introduced by retransmissions that occur when frames are lost. Since these retransmissions are related to the round-trip time moving average calculated by taking sample estimates, the nature of the latency is random but typically large enough to disrupt functionality. Specifically, in a real-time IoT (RTIoT) environment, servers rely on application-layer jitter buffers that drop any packet that arrives too late to be of significance in the decision-making process. Moreover, the effect of latency is not the same for all applications; an application where unmanned aerial vehicles have their flightpath dynamically computed based on sensed hyperspectral images4 has different latency requirements than an urban agriculture application5 where excess water is dynamically drained based on rain levels. In this paper, we focus on critical applications where the allowable latency is 150 milliseconds at most. In this scenario, if the TCP-induced latency is above the aforementioned threshold, datagrams are dropped by the application layer, and decision making can be compromised, leading to potential physical loss.