Optimization for Unconstrained Networks

One one the most popular application layer protocols for IoTs, CoAP, uses UDP as the underlying transport protocol. Moreover, UDP is also used by more complex M2M engines such as UPnP. It makes sense, in order to reduce the amount of protocol overhead that has to be carried over the constrained network, to compress the UDP header so that less data has to be transmitted by IoT constrained devices.

UDP is a transport service that only offersport multiplexingandchecksumming. In a number of cases, however, these are not useful services for constrained objects. As an example, for sleepy sensors running a single application, port multiplexing turns out to be useless as

there is no need to discriminate among different applications at the constrained node. An UDP header is composed of 64 bits, 16 bits are used for the source port, 16 bits for the destination port, 16 bits for the UDP datagram length (UDP header and payload) and finally 16 bits for the checksum. The UDP datagram length can be safely neglected, as the UDP datagram length can be inferred from the IP packet carrying the datagram. RFC6282 [40] defines an UDP header compression format allowing to either elide the first 8 bits or the first 12 bits of both source and destination ports. Our intention is to work toward an amendment to [40] allowing to cut all 16 bits of both source and destination ports through a suitable “implicit” port multiplexing. The main characteristic of this implicit port multiplexing is to have no ports at all for sending and no ports at all for receiving (if appropriate). This will be implemented into a dedicated stack working on the IoT devices as well as on a node in the NTU (which could be a proxy), that will map the incoming IoT flow accounting for predefined (and fixed) ports for source and destination.

Regarding the UDP Checksum, the discussion is more delicate as in IPv6 according to RFC2460 [41] UDP Checksum is mandatory. RFC6282 only considers two cases for which eliding the UDP Checksum is allowed:

• Tunneling: e.g., IPsec Encapsulating Security Payload tunnel mode, as defined in RFC4303 [42], or L2TP Session Header Over UDP, as per RFC3931 [43]. The tun- neling mechanism MAY authorize eliding the UDP checksum in order to save on the encapsulation overhead.

• Other Message Integrity Check: IPsec Authentication Header, as per RFC4302 [44], or some other type of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength.

[40] also introduces the further requirement of having an additional Layer 2 message in- tegrity check in order to preserve the packet being delivered to a wrong destination due to a corruption of the IP header, when eliding the UDP checksum. When the constrained proto- col stacks features an Identity Layer and performs message integrity check at layer 2 (MAC) the UDP header may be entirely omitted.

In WP3 we will investigate suitable UDP compression schemes especially tailed for IoTs, varying their effectiveness in terms of overhead reduction and the corresponding perfor- mance improvement in terms of communication speed and energy consumption.

7.6.2.2 Bridging a Constrained Network to the Internet

In this subsection we will analyze how to complement the work presented in the previous one in order to ensure a smooth cooperation between Constrained Networks and Internet Cloud services. Our discussion will be articulated along two main axes:

• exploiting the catalyzing effect of the Cloud in order to offer packet aggregation from Constrained Networks to the Cloud, and

• gain insight on the network packets created by the IoT nodes and exploit or craft new algorithms for queue management.

7.6.2.3 Bridge a Constrained Network to the Cloud

In this paragraph we will address how to handle the wired portion of communication between constrained networks and the Cloud, mainly throughflow aggregation. Referring to Sce- nario S2, see also Fig.18, aggregation will occur between the Gateway and a server in the unconstrained domain. For illustration, consider the case where multiple IoT nodes within the NTC communicate with the same server in the Internet Cloud. In this case, aggregating the respective transport flows will improve the communication performance (and the asso- ciated overhead) within the NTU (Internet network). The work needed to accomplish this objective requires to:

• characterize Cloud services;

• characterize communication modes.

Additionally, depending on the previous items, we have to:

• outline possible transport protocols for the aggregation of data flows; • describe how aggregation is carried out;

• identify aggregation points.

A substantial part of the Internet traffic in the future will be generated by constrained IoT ob- jects and this traffic is expected to lead to massive communication between the constrained network domains and the Internet cloud. As of November 2011, a number of Internet of Things startup companies has been established; most of those companies propose prod- ucts enabling publication on centralized private platforms, such as twitter or public Internet Clouds. By refereeing to “Cloud” as a remote datacenter, we can outline a number of Cloud services which are critical to constrained networks:

• Archiving has his focus on the reliability of the transfer, as opposed to latency and responsiveness; due to the minor importance of latency for this service. For this class of applications there are ongoing efforts (LEDBAT [45]) that are worth being considered for IoTs;

• Storageis quite a peculiar service, having a multiplicity of possible focuses, if consid- ered as archiving his focus will be on reliability of the transfer, as opposed to latency and responsiveness;

• Backupis mainly a legacy notion, but it still finds its place in the Cloud due to several legacy architectures that have been ported to it, it shares some features withArchiving but it additionally presents exploitable time patterns;

• Real-time processingfocuses on minimizing the latencies under a given hard thresh- old;

• OLT processingfocuses on minimizing latencies as well, but with “softer” thresholds. Moreover, it could leverage on transactions;

• Transactionsseems harder than other services to batch, as their functioning could be endangered by message duplication and excessive latency;

• Datawarehouse processingthis service presents the same characteristics ofArchiv- ing.

Also, different Cloud services, presents different requirements, in terms of communication modes:

• NTC Unicast/Anycast to Cloud (NTU) Unicast/Anycast; • Cloud (NTU) Unicast/Anycast to NTC Unicast/Anycast; • Cloud (NTU) to NTC Multicast.

Moreover, different Cloud services feature different requirements in terms of bandwidth and latency. The required communication mode will lead to specific modifications on the original packet, while the previous requirements could lead to different choices in terms of con- gestion control mechanism. For archiving/backup purposes Low Extra Delay Background Transport [45] seems to be a good candidate.

Considering IEEE 802.15.4 as the physical layer technology, at the MAC layer the packet size limit is 102 bytes, and the majority of broadband connections offer an MTU of at least 1492 bytes. Thus, we consider as an option that of reducing the number of packets emitted to the Internet aggregation. This is viable because in case of a congestion control-less transport protocol inside the constrained network latency would not affect the traffic, and in case of congestion control we can apply back-pressure. One of the main challenges is the choice of timeout conditions for transmitting and more generally the adopted aggregation algorithm. In terms of network elements, good candidates to perform this aggregation seem to be Gateways or NTU proxies, that are both unconstrained devices.

Concluding, we will implement the just discussed aggregation, exploring its pros and cons, how it interoperates with other layers, and its effect on the overall end-to-end communication performance.

7.6.2.4 Packet classification and Queues Mangling “Avoiding the Bufferbloat”

Bufferbloat identifies the excess of buffering which generates increased latency and jit- ter. This problem heavily affects home IEEE 802.11 access points and routers, and it is mainly linked to buffering TCP packets for too a long time. In Constrained Networks it is of paramount importance to define proper queue handling in both gateways and core routers. The latter is out of scope, but we will analyze the behavior of queues on gateways for con- strained networks in order to avoid such a phenomenon.

Blue, an in particular its Stochastic Fair Blue [46] variant, and Random Early Detections (RED) are considered the most promising Active Queue Management algorithms. Both algo- rithms work on random drops, or Explicit Congestion Notification (ECN) marks on packets in order to prevent router queues to overflow. The Blue class of algorithms requires less tuning on the network infrastructure than RED (having its advantages and drawbacks). Nonethe- less, we still need to verify the impact of such buffer management policies on the constrained

network traffic, and vice-versa, the impact of the latter on these algorithms. Further, we need to assess the ECN compatibility, the interaction of buffering policies with the MAC layer and all possible interactions with specific constraints, such as energy or bandwidth.

Moreover, given new routing protocols, new network configuration protocols, and header compression schemes, we expect that in the IoT we will face an increased complexity and packet diversity, so we need to outline which new packets will be produced, their per hop be- havior, their impact and the compatibility with differentiated services [47] and understanding which packets are good candidates for a specific per hop behavior.

In conclusion, it seems reasonable to perform this study on the queues before even consid- ering packet aggregation, using the insight gained to propose a more accurate design, and to enhance the study afterwards to include the aggregation in the big picture.