One document matched: draft-eggert-core-congestion-control-00.txt
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)
draft-eggert-core-congestion-control-00
Abstract
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
deployments.
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 http://datatracker.ietf.org/drafts/current/.
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
(http://trustee.ietf.org/license-info) 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
protocol.
[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
equitably.
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
degree.
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
communication)
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
communication
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
overhead.
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
destination.)
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
outstanding.
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
destination.
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
approaches.
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
publication.]
5. Security Considerations
This document has no known security implications.
[Note to the RFC Editor: Please remove this section upon
publication.]
6. Acknowledgments
Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework
Program.
7. References
7.1. Normative References
[I-D.ietf-core-coap]
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", http://www.trilogy-project.org/.
Author's Address
Lars Eggert
Nokia Research Center
P.O. Box 407
Nokia Group 00045
Finland
Phone: +358 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Eggert Expires December 25, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 09:05:46 |