Network Working Group                                          L. Eggert
Internet-Draft                                                     Nokia
Intended status: Experimental                              June 23, 2010
Expires: December 25, 2010

   Congestion Control for the Constrained Application Protocol (CoAP)


   The Constrained Application Protocol (CoAP) is a simple, low-
   overhead, UDP-based protocol for use with resource-constrained IP
   networks and nodes.  CoAP defines a simple technique to individually
   retransmit lost messages, but has no other congestion control
   mechanisms.  This document motivates the need for additional
   congestion control mechanisms, and defines some simple strawman
   proposals.  The goal is to encourage experimentation with these and
   other proposals, in order to determine which mechanisms are feasible
   to implement on resource-constrained nodes and are effective real

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 25, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Eggert                  Expires December 25, 2010               [Page 1]

Internet-Draft         Congestion Control for CoAP             June 2010

   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
   simple, low-overhead, UDP-based protocol for use with resource-
   constrained IP networks and nodes.

   CoAP defines two kinds of interactions between end-points:

   1.  a client/server interaction model, where request or notify
       messages initiate a transaction with a server, which may send a
       response to the client with a matching transaction ID

   2.  an asynchronous subscribe/notify interaction model, where a
       server can send notify messages to a client about a resource
       which the client has subscribed to

   CoAP uses the User Datagram Protocol (UDP) [RFC0768] to transmit
   these messages and defines a simple mechanism to individually
   retransmit lost messages using an exponentially backed-off timer.

   This document argues that although this retransmission mechanism is a
   required first step to implement congestion control for CoAP, it
   alone is not sufficient to alleviate network overload in all
   conditions.  Section 2 gives a short summary of Internet congestion
   control principles, and Section 3 presents some simple strawman
   proposals that attempt to complement the current message
   retransmission mechanism in CoAP.

2.  Discussion of Internet Congestion Control Principles

   [RFC2914] describes the best current practices for congestion control
   in the Internet, and requires that Internet communication employ
   congestion control mechanisms.  Because UDP itself provides no
   congestion control mechanisms, it is up to the applications and
   application-layer protocols that use UDP for Internet communication
   to employ suitable mechanisms to prevent congestion collapse and
   establish a degree of fairness.  CoAP is one such application-layer

Eggert                  Expires December 25, 2010               [Page 2]

Internet-Draft         Congestion Control for CoAP             June 2010


   [RFC2914] identifies two major reasons why congestion control
   mechanisms are critical for the stable operation of the Internet:

   1.  The prevention of congestion collapse, i.e., a state where an
       increase in network load results in a decrease in useful work
       done by the network.

   2.  The establishment of a degree of fairness, i.e., allowing
       multiple flows to share the capacity of a path reasonably

   The overwhelming majority of the bytes on the Internet are caused by
   bulk transfers, and the traditional congestion control mechanisms are
   engineered to saturate the network without driving it into congestive
   collapse.  Fairness between flows is an important consideration when
   the network operates around the saturation point, so that new flows
   are not disadvantaged compared to established flows, and can obtain a
   reasonable share of the capacity quickly.

   The environments that CoAP targets are IP networks, although more
   resource-constrained ones than the "big-I" Internet.  This does not
   eliminate the need for end-point-based congestion control.  If
   anything, the environments that CoAP will be deployed in have fewer
   capabilities for network provisioning, traffic engineering and
   capacity allocation, which are among the techniques that can
   sometimes offset the need for end-to-end congestion control to some

   However, the environments that CoAP targets are sufficiently
   different from the "big-I" Internet so that the motivations for
   congestion control from [RFC2914] should probably be weighted
   differently.  CoAP networks will not be used for bulk data transfers
   and CoAP nodes will not need to use a significant fraction of the
   capacity of a path to provide a useful service.  (In fact, they are
   often too resource-constrained to do so in the first place.)  Under
   normal operation, a CoAP network will be mostly idle, which means
   that fairness between the transmissions of different CoAP nodes is
   not a large issue.  A CoAP congestion control mechanism can hence
   focus on preventing congestion collapse, which is a much more
   tractable problem given the specific conditions of CoAP environments.

   The current IETF congestion control mechanisms, such as TCP [RFC5681]
   or TFRC [RFC5348], all focus on determining a "safe" sending rate for
   a bulk transfer, i.e., for a single flow of many packets between a
   sender and destination where many packets are in flight at any given
   time.  They measure the path characteristics, such as round-trip time

Eggert                  Expires December 25, 2010               [Page 3]

Internet-Draft         Congestion Control for CoAP             June 2010

   (RTT) and packet loss rate, by monitoring the ongoing transfer and
   use this information to adjust the sending rate of the flow during
   the transmission.

   This approach is not feasible for CoAP.  The infrequent request/
   response interaction that CoAP supports does not generate sufficient
   data about the path characteristics to drive a traditional congestion
   control loop, even if the notion of "a flow" to a destination is
   extended from "one CoAP transaction" to "a sequence of CoAP
   transactions".  This approach is also not applicable to multicast
   transmissions, which CoAP offers.

   [RFC5405] documents the IETF's current best practices for using UDP
   for unicast communication in the Internet.  It provides guidance on
   topics such as message sizes, reliability, checksums, middlebox
   traversal and congestion control.  Section 3.1.2 of [RFC5405], which
   focuses on congestion control for low data-volume applications, is
   especially relevant to CoAP.

   Section 3.1.2 of [RFC5405] acknowledges that the traditional IETF
   congestion control mechanisms are not applicable for low data-volume
   application protocols such as CoAP.  Instead, it recommends that such
   application protocols:

   o  maintain an estimate of the RTT for any destination with which
      they communicate, or assume a conservative fixed value of 3
      seconds when no RTT estimate can be obtained (e.g., unidirectional

   o  control their transmission behavior by not sending on average more
      than one UDP datagram per RTT to a destination

   o  detect packet loss and exponentially back their retransmission
      timer off when a loss event occurs

   o  employ congestion control for both directions of a bi-directional

   CoAP follows some of these guidelines already.  It uses a fixed value
   of 1 second for its retransmission timer for both requests and
   responses, which although shorter than the recommended value in
   [RFC5405] is likely appropriate for many of its deployment scenarios.
   CoAP also uses exponential back-off for its retransmission timer.

   This alone, however, does not result in a complete congestion control
   mechanism for CoAP.  Section 3 defines an experimental complement to
   the current CoAP mechanism described in [I-D.ietf-core-coap].

Eggert                  Expires December 25, 2010               [Page 4]

Internet-Draft         Congestion Control for CoAP             June 2010

3.  CoAP Congestion Control

   This section proposes several congestion control techniques for CoAP
   that are intended to improve its ability to prevent congestion
   collapse.  At the moment, these techniques are described with the
   intent of encouraging experimentation with such proposals in CoAP
   simulations and testbed deployments.  Of particular interest are
   mechanism requiring little computation and state, i.e., mechanisms
   that can be implemented in resource-constrained nodes without much

3.1.  Retransmissions

   CoAP already defines a simple retransmission scheme with exponential
   back-off, where messages that have not been responded to in
   RESPONSE_TIMEOUT are retransmitted, followed by doubling
   RESPONSE_TIMEOUT.  Up to MAX_RETRANSMIT retransmission attempts are
   made.  (At the moment, [I-D.ietf-core-coap] defines RESPONSE_TIMEOUT
   to be 1 second and MAX_RETRANSMIT to be five attempts.)  As stated
   above, although RESPONSE_TIMEOUT is shorter than what [RFC5405]
   recommends, the shorter value is likely to not cause large issues in
   many deployments that CoAP targets.

   However, using a fixed value for RESPONSE_TIMEOUT instead of basing
   it on the measured RTT to a destination has some minor drawbacks.
   CoAP may be used in deployments where the path RTTs can approach the
   currently defined RESPONSE_TIMEOUT of 1 second, such as Internet
   deployments involving GSM or 3G links, or cases where preparing a
   response can involve significant computation or where it otherwise
   incurs delays, such as long sleep cycles at the receiver.  Fixed
   timeouts that are too short can cause spurious retransmissions, i.e.,
   unnecessary retransmissions in cases where either the request or the
   response are still in transit.  Spurious retransmissions, especially
   persistent ones, waste resources.

   This section therefore proposes that CoAP deployments experiment with
   maintaining an estimate of the RTT for any destination with which
   they communicate.  Specifically, it is suggested that deployments
   experiment with the algorithm specified in [RFC2988] to compute a
   smoothed RTT (SRTT) estimate, and compute RESPONSE_TIMEOUT in the
   same way [RFC2988] computes RTO.

   A second suggestion is to experiment with a longer RESPONSE_TIMEOUT,
   such as 3 seconds, which is what [RFC5405] recommends, in order to
   determine if there are significant drawbacks or whether this value
   could be lengthened.

Eggert                  Expires December 25, 2010               [Page 5]

Internet-Draft         Congestion Control for CoAP             June 2010

3.2.  Aggregate Congestion Control

   Traditional Internet congestion control algorithms control the
   sending rate of a single flow.  When a node establishes multiple,
   parallel flows, their congestion control loops run (mostly)
   independently of one another.  Interactions between the control loops
   of parallel flows is (mostly) indirect, e.g., a rate increase of one
   flow may cause packet loss and a rate decrease to another.

   CoAP "flows", i.e., sequences of infrequent CoAP transactions between
   the same two nodes, do not require much more per-flow congestion
   control than a retransmission scheme that reduces the rate (increases
   the back-off) of a flow under loss, and a (low) cap on the number of
   allowed outstanding requests to a destination.  ([RFC5405] recommends
   "on average not more than one" outstanding transaction to a given

   On the other hand, CoAP applications may potentially want to initiate
   many transactions with different nodes at the same time.  Allowing
   CoAP applications to initiate an unlimited number of parallel
   transactions gives them the means for causing overload, and depends
   on application-level measures to detect and correctly mitigate this
   failure.  Because each transaction only consumes a very limited
   amount of resources, it is arguably more important to control the
   total outstanding number of transactions, compared to controlling the
   rate at which each individual one is being (re)transmitted.  The CoAP
   spec [I-D.ietf-core-coap] does currently not impose any limit on how
   many parallel transactions to different nodes an end-point may have

   Given the importance of preventing congestion collapse, this document
   argues that the CoAP protocol should specify a common mechanism for
   congestion controlling the aggregate traffic a CoAP node sends into
   the network.  In other words, the CoAP stack should locally drop
   application-generated messages under overload situations, rather than
   attempting to send them into the network, irrespective of the

   One proposal is to implement a simple windowing algorithm.  In this
   mechanism, a CoAP node has a certain number of "transmission credits"
   available during a time interval.  Sending one CoAP message consumes
   one transmission credit, independent of which destination it is being
   sent to.  If all transmission credits have been used up during a time
   interval, the CoAP node drops any additional messages that the
   applications attempt to send during the remainder of the time
   interval.  At the end of a time interval, the CoAP node determines
   whether responses have been received for all requests it has issued
   within the time interval.  If this is the case, the CoAP node

Eggert                  Expires December 25, 2010               [Page 6]

Internet-Draft         Congestion Control for CoAP             June 2010

   increases the number of send credits by one for the following time
   interval.  If responses fail to arrive for some of the requests
   issued during the time interval, the number of permitted CoAP
   requests is cut in half for the next interval.

   The description above leaves several questions unanswered.  These
   include the length of the time interval and whether it is fixed or
   adapted over time, whether an increase by one and a reduction by half
   are the correct parameters for the proposed AIMD (additive increase,
   multiplicative decrease) scheme, whether the decrease should be
   proportional to the loss rate, and others.

   This document does at the moment not attempt to answer these
   questions.  Instead, it encourages simulations and implementations to
   explore the design space, and also consider other non-windowing

3.3.  Explicit Congestion Notification

   Explicit Congestion Notification (ECN) [RFC3168] is an extension to
   IP that allows routers to inform end nodes when they approach
   congestion by setting a bit in the IP header.  The receiver of a
   message echoes this bit to the sender, which reacts as if a packet
   loss had occurred for the flow.

   Deployment of ECN can reduce overall packet loss, because senders can
   react to congestion early, i.e., before packet loss occurs.  This is
   especially attractive in resource-constrained environments, because
   retransmissions can be avoided.

   If CoAP uses an aggregate congestion control mechanism such as
   described in Section Section 3.2, it will reduce the amount of
   transmission credits for the next time interval when some of the
   responses received had the ECN bit set.  (Other reactions to ECN
   markings may be possible.)

   Whether ECN support is possible in CoAP deployments remains to be
   investigated, because ECN usage requires a negotiation handshake (can
   potentially be avoided if support is made mandatory for CoAP
   deployments) and because routers need to support ECN marking.  At
   this point, simulations attempting to quantify the benefits may
   therefore be easiest to obtain.

3.4.  Multicast Considerations

   CoAP requests may be multicast, and result in several replies from
   different end-points, potentially consuming much more resource
   capacity for the request and response transmissions than a single

Eggert                  Expires December 25, 2010               [Page 7]

Internet-Draft         Congestion Control for CoAP             June 2010

   unicast transaction.  It can therefore be argued that sending
   multicast requests should be more conservatively controlled than the
   sending of unicast requests.

   CoAP already acknowledges this to some degree by not retransmitting
   multicast requests at the CoAP-level.  Unfortunately, CoAP currently
   has no means for preventing an application from doing application-
   level retransmissions of multicast requests.  Given that the
   prevention of congestion collapse is important, such a mechanism
   should be added.

   The aggregate congestion control proposal in Section Section 3.2 puts
   a cap on the number of transmissions allowed during a time interval,
   including multicast requests.  It is currently unclear whether
   additional means are required for CoAP deployments that make heavy
   use of multicast.  As before, experimentation is encouraged to
   understand the problem space.

4.  IANA Considerations

   This document requests no actions from IANA.

   [Note to the RFC Editor: Please remove this section upon

5.  Security Considerations

   This document has no known security implications.

   [Note to the RFC Editor: Please remove this section upon

6.  Acknowledgments

   Lars Eggert is partly funded by [TRILOGY], a research project
   supported by the European Commission under its Seventh Framework

7.  References

7.1.  Normative References

              Shelby, Z., Frank, B., and D. Sturek, "Constrained

Eggert                  Expires December 25, 2010               [Page 8]

Internet-Draft         Congestion Control for CoAP             June 2010

              Application Protocol (CoAP)", draft-ietf-core-coap-00
              (work in progress), June 2010.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

7.2.  Informative References

   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 5348, September 2008.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

   [TRILOGY]  "Trilogy Project",

Author's Address

   Lars Eggert
   Nokia Research Center
   P.O. Box 407
   Nokia Group  00045

   Phone: +358 50 48 24461

Eggert                  Expires December 25, 2010               [Page 9]