The CoAP specification [15] introduces CC in several ways for confirmable messages (CONs) and non-confirmable messages (NONs). CONs require an ACK from the des- tination endpoint to which the message is directed to. Up to four retransmission are allowed by default. As already explained in the introduction to CoAP (Section 2.7.3), CoAP communications are based on the exchange of UDP messages between two or more endpoints. The basic CC mechanism of CoAP imposes several rather conservative restrictions on the rate of outgoing messages and on the amount of exchanges that are allowed in parallel.
For the transmission of the original message the RTO value is randomly picked from the interval [2 s, 3 s]. As in TCP, a binary exponential backoff (BEB) is applied to the RTO value for the retransmission, i.e., its value is doubled. If all retransmissions are used and no ACK was received, the message is dropped. Above that, the number of allowed outstanding interactions towards a destination endpoint by default is limited to 1. An outstanding interaction can be a CON request for which no ACK has been received yet or a NON request for which no reply has been received yet. This conserva- tive approach is meant to ensure a safe and stable operation of the network, avoiding fast retransmissions or the start of multiple parallel interactions that could overload the network. Apart from that, the simplicity of the algorithm results in a small memory footprint.
Traffic loads that can cause such congestion are likely to happen in CoAP commu- nications, where messages between large numbers of devices are exchanged. However, the basic CC mechanisms offered by the CoAP specification is insensitive to network conditions. Therefore, default CoAP CC may significantly underperform, often being too conservative or too aggressive, instead of adapting its behavior on the basis of network status information actually available to CoAP.
Advanced CC mechanisms for CoAP should resolve aforementioned issues, as long as these methods do assure a behavior that is safe in the Internet. They should also consider the three following basic aspects of CC mechanisms that have been identified based on the base specification of CoAP:
1. The RTO calculation for the initial transmission of a confirmable CoAP message. 2. The backoff behavior applied to the RTO before retransmission of a confirmable
5.4 Related Work
3. The state information stored about destinations of confirmable CoAP messages. Currently there exist two drafts with proposals for advanced CC mechanisms for CoAP. Apart from the CoCoA-draft, which is evaluated in this chapter, another Internet- Draft with several proposals for such advanced CC mechanisms entitled ‘Congestion Control for the Constrained Application Protocol (CoAP)’ has been submitted to the IETF by Lars Eggert. The content of this draft is introduced in the following.
5.4
Related Work
A first proposal for an advanced CC mechanisms for CoAP has been written in the Internet-Draft ‘Congestion Control for the Constrained Application Protocol (CoAP)’ [111] by Lars Eggert. Several mechanisms to extend CoAP’s CC mechanisms are pro- posed in this document with the intention to make the community experiment with these proposals. In the following the main ideas that are raised in the draft are gath- ered.
The author states that if the response times for CoAP messages exceed the default range of RTO values (2 s to 3 s) the protocol may retransmit unnecessary messages that are still on the path between the two endpoints or being processed at the destination. This leads to the first addition for CoAP: it should include an RTO estimator that operates similarly to the one defined in RFC 2988 for TCP to adapt the RTOs to the real durations of transactions. As an alternative to this RTO estimator, a larger initial RTO is proposed.
In addition to the RTO estimator, a solution for aggregated traffic control is pro- posed. The draft points out that this is a required mechanism if several transactions to different destinations are initiated in parallel. It addresses the limitation introduced by NSTART, that limits the amount of open transactions to a destination endpoint to one but does not limit the number of destination endpoints to which open transactions are allowed. A regulation mechanism proposed by Eggert is based on keeping a global pool of transaction tokens and applying a windowing algorithm to determine how many transactions are allowed in parallel. For each exchange one of the available tokens is used. When no more tokens are available, no further transactions may be initiated to any destination endpoint. The successful completion of transactions returns tokens to the pool. The subsequent successful completion of transactions during a certain time interval leads to an increase of available tokens. On the other hand, failed transmissions lead to a reduction of the token pool size.
The proposal of aggregated traffic control is extended by the use of ECN at the IP layer. When congestion is detected by a router, it may inform end nodes to reduce the outgoing message rate, which in this case would be achieved by reducing the window size.
The last addition to the set of mechanisms to provide an advanced CC for CoAP is the regulation of multicast message retransmissions. Since CoAP does not apply
retransmissions to multicast messages, the retransmission of multicast messages is left to the user application. However, CoAP does not prevent the user application from retransmitting multicast messages. Multicast messages can generate a flood of replies from all destination endpoints to which the multicast message is directed to. Hence, the subsequent transmission of a multicast message and the replies it generates may cause congestion collapse. The author states that his proposal for the aggregate CC already helps to avoid an abusive use of multicast retransmissions. Still, he incites the reader to find and experiment with additional means to regulate these retransmissions. The draft does not provide any details about the parameter settings used for RTO calculations or a specific proposal for the behavior of the windowing algorithm for the transaction tokens. Yet, the different proposals try to address several of the limitations of the default CC mechanisms. In the following, the proposals made in the draft are analyzed and it is discussed if they are apt for the design of an advanced CC mechanism for CoAP.
As shown in the evaluations for the ZigBee WHAN scenario in Chapter 4, the esti- mation of the expected transaction duration for an endpoint using a RTO estimator can lead to an increase of the performance when compared to the static approach followed by the CoAP base specification. The use of an RTO estimator for CoAP is a valuable addition to CC if the expected transactions durations are either longer or shorter than determined by the default RTO value of 2 s to 3 s. If the duration of transactions tends to vary over time, an adaptive RTO algorithm can improve performance too. However, the performance of a TCP estimator in WSN communications is unclear. The premiss for updating and adjusting the RTO estimator is the measurement of RTT values. Ac- cording to RFC 6298 [52], RTT values can only be calculated from messages that have not been retransmitted. Since the natural packet loss rate in constrained networks is higher than in non-constrained networks, the chances of updating the RTO estimators are expected to be significantly fewer when used in CoAP. If on top of the natural losses caused by the channel qualities, losses are added as a result of network congestion, the probabilities of measuring valid RTTs is further reduced. This signifies a pending issue that is not addressed in the draft.
The aggregated traffic mechanism intends to manage the amount of open transac- tions towards endpoints using a pool of tokens. An upper limit of open transactions is controlled by requiring each new transaction to use a token from the pool. Yet, this particular proposal for a global pool of transaction tokens leaves important questions unanswered.
For example, the draft does not point out how in the context of a global pool of tokens NSTART is adjusted for each destination endpoint, depending on the currently available tokens. NSTART defines how many transactions can be open in parallel to- wards one destination endpoint. The windowing algorithms described in Eggert’s draft suggests that NSTART is dynamic and has the same value for every destination end- point. However, different destination endpoints may show a different behavior in terms of losses and delays and using the same NSTART value for all destination endpoints