over default CoAP in such scenarios. Moreover, it can be demonstrated that the con- servative restrictions imposed by the CoAP base specification can be relaxed when using CoCoA, in particular the NSTART limitation. In the second part of this chapter, a set of final performance evaluations of CoCoA for alternative communication tech- nologies, including GPRS and IEEE 802.15.4, and a comparison with other advanced CC mechanisms are presented. The extensive comparisons, involving different com- munication technologies, traffic scenarios, and network setups conclude the work on performance improvements for CoAP, showing that the proposal for an advanced CC mechanism made in this thesis improves performance for CoAP-based IoT communi- cations in many ways.
The remainder of this chapter is structured as follows: Section 6.2 introduces the implementation of CoCoA for Erbium (Er), as well as the Californium (Cf) Java frame- work and optimizations made to this implementation. The evaluations of CoAP for In- ternet cloud services is presented in Section 6.3. In Section 6.4 a comparison of default CoAP and CoCoA with alternative state-of-the-art CC mechanisms is carried out in two testbeds. The conclusions to this chapter are given in Section 6.5.
6.2
CoCoA for Cloud Services: Implementation and Op-
timization
It was shown that CoCoA yields an even higher performance than CoCoA and is capable to overcome the shortcomings identified in Section 5.7.1. As a result, most of the changes proposed in this thesis were adopted in version 2 of the CoCoA draft. Apart from the resulting contributions in conference papers, journal papers, and the CoCoA Internet-draft, the work of CoCoA has also resulted in the publication of source code for two different frameworks.
In the evaluations carried out in the previous chapter, CoCoA, was implemented
for Erbium, the official CoAP implementation for Contiki [116]2. The Erbium imple-
mentation of CoCoA includes all the features as detailed in version 2 of the CoCoA draft [BBGD14]. In this section, the implementation of the CoCoA draft version 2 is presented for the Cf framework, a Java implementation of CoAP for unconstrained devices [117].
In the following, the CoCoA implementation for Er and the CoCoA implementa- tion for Cf is presented for its use on constrained and unconstrained machines that run CoAP-based Internet cloud services. Since the Cf implementation runs on un- constrained devices that are not imposing strong limitations on the available memory (ROM and RAM), two additional improvements for CoCoA are introduced that result in a slightly higher memory consumption of the advanced CC mechanism.
er-coap-transactions.c er-coap-transactions.h Modified Er-CoAP Files
er-cocoa.c Er-CoCoA Functions
Er-CoCoA
Figure 6.1: Er-CoCoA consists of the original Er-CoAP files that have been modified and the additional er-cocoa.c file carrying the methods to manipulate the RTO estimators.
6.2.1 Implementation of CoCoA for Erbium
For the analysis carried out in this chapter, CoCoA was implemented for Er-CoAP. It consists of the slightly modified er-coap-transactions.c and er-coap-transactions.h files from the original Er-CoAP implementation, responsible for managing CoAP transac- tions, and the er-cocoa.c file (see Fig. 6.1).
The er-cocoa.c file provides all the functions necessary to initiate, update, and maintain the RTO estimators for a destination endpoint. For each destination endpoint a coap rtt estimations structure is maintained, that contains all the RTO estimator variables. The Er-CoCoA implementation [Bet15] is optional and can be activated by setting the COCOA flag at compile time. It is compatible with the newest version of Er-CoAP available at the time of writing this thesis (implementing the CoAP RFC) and is to be included in the official Git repository for Er-CoAP.
6.2.2 CoCoA Californium Implementation (pre-Git version)
CoCoA is implemented as an optional CC layer for the Cf CoAP framework that has been released in the official Git repository of Cf CoAP under an Eclipse Foundation license [Bet14]. The implementation provides all necessary data structures and methods to carry out the mechanisms as defined in the draft version 2. A RemoteEndpoint object stores the information needed by the CC layer, such as the RTT and the current state of the RTO estimators (see Fig. 6.2).
Since Californium is designed for unconstrained environments, each remote endpoint is identified at the highest granularity, that is, by its unique IP address and port number. This allows to even react to congestion at specific services, which are provided at different UDP ports of a host.
Whenever a new request-response exchange is created, it is associated to its remote endpoint. After performing this association, it is possible to access the state information of the remote endpoint from all layers of the CoAP stack, as the Exchange object is
6.2 CoCoA for Cloud Services: Implementation and Optimization CC Layer Remote Endpoint CoCoA Exch an ge St ore Blockwise Layer Observe Layer Token Layer Reliability Layer Matching & Deduplication
Message Serialization Connector (UDP/DTLS/…) St ag e 1 St ag e 2: Pro to co l (C oAP) St ag e 3: Se rve r Network B2 B1 A2 A Root St ag e 3: C lie nt Client for Y Client for X Async.Handler ma i n B A1 CoCoA • Adds RemoteEndpoint • Adds optional CC Layer
Figure 6.2: Simplified overview of the Californium CoAP stack [4] with the optional CoCoA layer in the pre-Git version.
passed around. The CC layer first determines whether the transmission is a CON or a NON, as each type is processed differently.
When an exchange with a CON message reaches the CC layer, the NSTART limit for open interactions with the corresponding remote endpoint is checked. If less than NSTART exchanges are active to that remote endpoint, the request can be processed and it is forwarded to the reliability layer. In this context, observing does not count as active exchange. If the limit of NSTART is already reached, the new request is added to a queue that is bounded through a maximal lifetime for stored exchanges. As soon as an incoming reply is handed up from the reliability layer, the CC layer updates the RTO estimators of the associated endpoint. After updating the state information of the remote endpoint, the outstanding interaction is closed and the next CON exchange can be pulled from the queue.
When a NON exchange is handed over to the CC layer, it is stored in a queue, which implements a leaky bucket traffic shaper [118] for the associated remote endpoint. With a rate of 1/RT Ooverall, NONs are pulled from the queue and handed down to the lower layers in the stack. Following the guidelines of the CoCoA draft, every eighth NON is converted to a CON in order to obtain a RTT measurement to assure that the RTO value gets updated from time to time. The evaluation of this mechanism is out of scope of this chapter, though, as the focus lies on the adaptation of the RTO value for CON requests.
6.2.3 CoCoA Californium: Optimizations over the Draft
For the evaluations carried out in the following section and in line with the ongoing optimization of the CoCoA draft, some of CoCoA’s mechanisms are modified and new
ones are added. The aging mechanism for RTO estimators with large RTOs is modified experimentally. If an RTO estimator was not updated for at least one minute and its RTO value is larger than the default of two seconds, the RTT and RTTVAR of the estimators are adjusted to be reduced:
RTTX = (2 + RTTX)/2; RTTVARX = RTTVARX/2. (6.1)
The reasoning for this mechanism is that RTT information may become obsolete after some time and may no longer reflect the current network state, in particular when low-power wireless links are involved.
Another improvement to avoid strong fluctuations of the RTO is the use of a history with configurable size for implementations of CoCoA for unconstrained devices, where the last calculated values for RTOoverall are used to calculate an averaged RTO value. Alternatively, this behavior can be approximated by adjusting the weights used in the calculation of the estimator. However, it is easier to implement in form of a RTO history, given the higher amount of RAM available to the unconstrained devices.