Optimization for Constrained Networks

In the context of IoT communication over constrained networks (NTC), where potentially a high number of devices will access resource constrained networking resources, specific measures to control network load are required. In fact, using congestion control techniques as they are currently deployed on the unconstrained Internet (NTU), would likely cause net- work congestion inside the NTC, which would hamper the communication within such net- work. Transmission Control Protocol (TCP), i.e., the transport protocol technique that is used for the Internet was designed for relatively fast links and capable devices. As a conse- quence, this technique is not adequate for NTC as it would generate an excessive amount of control traffic.

TCP is in charge of reliably transmitting data in an end-to-end (E2E) fashion, exploiting E2E acknowledgments and packet retransmissions. If either a data packet or the corresponding acknowledgment is lost due to network congestion, its data retransmissions will further con- tribute to the congestion, leading to an even more congested network. In turn, additional losses and retransmissions [36] are expected.

In TCP, this problem was solved by probing the network capacity through the so called “slow start” algorithm and throttling down the transmission rate at the senders whenever a conges- tion is detected. This is achieved through a continuous use of E2E acknowledgments, which are sent from every receiver to the corresponding transmitter so that the latter can monitor 1) the number of packets that are reliably received (i.e., reliability) and 2) the connection round trip time (RTT). Acknowledgements make it possible to detect the loss of a small number of packets at the sender after a usually short delay. After that, the sender slows down its transmission rate to relieve the congestion event and retransmits the losses. In the standard

TCP case, each sender and receiver pair define a data flow, where the sender adapts its transmission rate (through a sliding window approach) according to the feedback from the receiver. Intermediate nodes just forward the packets belonging to this flow, without taking any congestion control action.

We note that the TCP mechanism is unsuitable for constrained networks. In fact, the queue length of the routers within NTC is usually small and, in turn, senders cannot buffer multiple datagrams. This implies that congestion events are likely to occur (in just a fraction of the connection round trip time) when multiple nodes transmit. Moreover, the distributed buffering space is so constrained that evenmicro-flows(e.g., a single message per round trip time per sender) could exhaust the available capacity and cause congestion.

In practical implementations over widely adopted sensor network hardware, i.e., TT2 devices (e.g. telosb motes, etc.), buffer space for IP forwarding is reserved in RAM and the available forwarding queue length is typically bounded to tens of IP datagrams. In these settings, the number of devices served by a router node and its queue length are comparable (ratio ' 1). Thus, TCP’s three-way handshakes and tree-way closures in constrained networks should be as much as possible avoided. Additionally, the usually small transmission rate of constrained devices along with the possibly multiple hops that a datagram has to travel to reach the unconstrained network can easily lead to long RTTs, which greatly impact the service delay when handshake-based protocols are in use.

Due to the above reasons, TCP is deemed to be unsuitable for use in constrained net- works, especially in low-power lossy network (LLN) environments such as wireless sensor networks, that also adds to the previous issues the fact that radio channels are lossy and, as such, further impact the reliability performance. Instead, TCP could still be used in the unconstrained portion of the network (NTU), possibly exploiting aTCP-splitapproach. More than that, handling the congestion solely at layer 4 is also unlikely to be effective. In fact, as even micro-flows are likely to create congestion, we may get some benefits from additionally implementing some congestion control features at layer 3, as we now explain. Enabling congestion control actions at lower layers (3 and 2) received considerable attention in recent research work on transport protocol for sensor networks and from standardization bodies such as IETF, as testified by a recent document draft of the IETF CoRE Working Group (WG). The main benefit from handling congestion control at lower layers is due to the fact that at such layers congestion control can be applied onaggregate network flows of IP packets, as outlined in [37].

[37] defines “CoAP aggregate congestion control” by limiting to a value N the number of aggregate outstanding unacknowledged CoAP messages that can be sent from a single node (N would act as a sort of “aggregate congestion window”). Note that these packets may belong to different (sender,receiver) pairs, which implies a re-definition of the concept of “flow”. This paper defines that every node cannot transmit, in a given timeslot, more than N CoAP messages; N is increased by one unit when all CoAP messages sent in the previous timeslot have been correctly acknowledged, otherwise it is halved. As can be noted, this congestion window update is reminiscent of the well known TCP Reno congestion control algorithm. Some open issues of [37] are: 1) multicast transmissions (as well as any other unacknowledged transmission mode) is not supported, 2) no evaluation of this method has been provided, 3) N can only be updated in the presence of data traffic and 4) E2E

aggregative congestion control techniques alone cannot fully avoid congestion when the number of nodes that concurrently generate traffic in the network is higher than the queue length at the bottleneck router.

As a remedy to the problem highlighted in point 4) above, researchers have proposed further enhancements which entail the collaborative action of intermediate nodes (located along the path connecting the sender and the NTC border router). In particular, these nodes could selectively slow down packet forwarding to relieve the congestion, also introducing back- pressure notifications to alert all the nodes upstream about any detected congestion event. This technique generalizes the aggregative congestion control described above through the distributed cooperation of potentially every node in the constrained network.

A simple but efficient proposal implementing this approach in wireless sensor networks has been proposed in [38], which introduces COngestion Detection and Avoidance (CODA). The novelty of CODA resides in the application of explicit back-pressure messages to maintain the level of traffic in the network at an acceptable level. Upon the reception of a back- pressure message, a node reduces its packet output rate for its own as well as for exoge- nous traffic. Simulation results for a simple topology provide encouraging results: conges- tion losses are substantially reduced, the rate of E2E retransmissions is kept low and as a byproduct of that, energy is saved.

Given the above discussion, a layer 3/4 combined design for constrained transport layer is expected to produce good results. In particular:

• E2E reliability (i.e., retransmission of TPC/IP packets) should be handled at layer 4 with the following characteristics, 1) simple format and protocol, 2) re-definition of flows, 3) no handshakes should be implemented. Candidate existing protocols that could be used for the implementation of such a transport layer are the CoAP message-layer [26] and in particular its transport subset of features, which have been stripped off from [26] document and extended in CMP [39];

• Besides, the congestion control algorithm should work on traffic aggregates, by im- plementing an hop-by-hop congestion control technique at layer 3 and exploring the benefits of back-pressure in effectively reducing the E2E loss rate, the delay and the energy consumption.

7.6.2 Optimization for Unconstrained Networks