idnits 2.17.1 draft-bormann-core-cocoa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational February 14, 2014 5 Expires: August 18, 2014 7 CoAP Simple Congestion Control/Advanced 8 draft-bormann-core-cocoa-01 10 Abstract 12 The CoAP protocol needs to be implemented in such a way that it does 13 not cause persistent congestion on the network it uses. The CoRE 14 CoAP specification defines basic behavior that exhibits low risk of 15 congestion with minimal implementation requirements. It also leaves 16 room for combining the base specification with advanced congestion 17 control mechanisms with higher performance. 19 This specification defines some simple advanced CoRE Congestion 20 Control mechanisms, Simple CoCoA. In the present version -01, it is 21 already making use of some input from simulations, but might still 22 benefit from simplifying it further. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Advanced CoAP Congestion Control: RTO Estimation . . . . . . 3 62 3.1. Blind RTO Estimate . . . . . . . . . . . . . . . . . . . 4 63 3.2. Measured RTO Estimate . . . . . . . . . . . . . . . . . . 4 64 3.2.1. Modifications to the algorithm of RFC 6298 . . . . . 5 65 3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Lifetime, Aging . . . . . . . . . . . . . . . . . . . . . 5 67 4. Advanced CoAP Congestion Control: Non-Confirmables . . . . . 6 68 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 (See Abstract.) 81 Extended rationale for this specification can be found in 82 [I-D.bormann-core-congestion-control] and 83 [I-D.eggert-core-congestion-control], as well as in the minutes of 84 the IETF 84 CoRE WG meetings. 86 1.1. Terminology 88 This specification uses terms from [I-D.ietf-core-coap]. In 89 addition, it defines the following terminology: 91 Initiator: The endpoint that sends the message that initiates an 92 exchange. E.g., the party that sends a confirmable message, or a 93 non-confirmable message conveying a request. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119] when they 98 appear in ALL CAPS. These words may also appear in this document in 99 lower case as plain English words, absent their normative meanings. 101 (Note that this document is itself informational, but it is 102 discussing normative statements.) 104 The term "byte", abbreviated by "B", is used in its now customary 105 sense as a synonym for "octet". 107 2. Context 109 In the Vancouver IETF 84 CoRE meeting, a path forward was defined 110 that includes a very simple basic scheme (lock-step with a number of 111 parallel exchanges of 1) in the base specification together with 112 performance-enhancing advanced mechanisms. 114 The present specification is based on the approved text in the 115 [I-D.ietf-core-coap] base specification. It is making use of the 116 text that permits advanced congestion control mechanisms and allows 117 them to change protocol parameters, including NSTART and the binary 118 exponential backoff mechanism. Note that Section 4.8 of 119 [I-D.ietf-core-coap] limits the leeway that implementations have in 120 changing the CoRE protocol parameters. 122 The present specification also assumes that, outside of exchanges, 123 non-confirmable messages can only be used at a limited rate without 124 an advanced congestion control mechanism (this is mainly relevant for 125 -observe). It is also intended to address the [RFC5405] guideline 126 about combining congestion control state for a destination; and to 127 clarify its meaning for CoAP using the definition of an endpoint. 129 The present specification does not address multicast or dithering 130 beyond basic retransmission dithering. 132 3. Advanced CoAP Congestion Control: RTO Estimation 134 For an initiator that plans to make multiple requests to one 135 destination endpoint, it may be worthwhile to make RTT measurements 136 in order to obtain a better RTO estimation than that implied by the 137 default initial timeout of 2 to 3 s. This is based on the usual 138 algorithms for RTO estimation [RFC6298], with appropriately extended 139 default/base values, as proposed in Section 3.2.1. Note that such a 140 mechanism must, during idle periods, decay RTT estimates that are 141 shorter than the basic RTT estimate back to the basic RTT estimate, 142 until fresh measurements become available again, as proposed in 143 Section 3.3. 145 One important consideration not relevant for TCP is the fact that a 146 CoAP round-trip may include application processing time, which may be 147 hard to predict, and may differ between different resources available 148 at the same endpoint. Servers will only trigger their early ACKs 149 (with a non-piggybacked response to be sent later) based on the 150 default timers, e.g. after 1 s. A client that has arrived at a RTO 151 estimate shorter than 1 s SHOULD therefore use a larger backoff 152 factor for retransmissions to avoid expending all of its 153 retransmissions in the default interval of 2 to 3 s. A proposal for 154 a mechanism with variable backoff factors is presented in 155 Section 3.2.1. 157 It may also be worthwhile to do RTT estimates not just based on 158 information measured from a single destination endpoint, but also 159 based on entire hosts (IP addresses) and/or complete prefixes (e.g., 160 maintain an RTT estimate for a whole /64). The exact way this can be 161 used to reduce the amount of state in an initiator is for further 162 study. 164 3.1. Blind RTO Estimate 166 The initial RTO estimate for an endpoint is set to 2 seconds. 168 If only the initial RTO estimate is available, the RTO estimate for 169 each of up to NSTART exchanges started in parallel is set to 1 s 170 times 2 to the power of the number of parallel exchanges, e.g. if two 171 exchanges are already running, the initial RTO estimate for an 172 additional exchange is 8 seconds. 174 The binary exponential backoff is truncated at 32 seconds. Similar 175 to the way retransmissions are handled in the base specification, 176 they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO. 178 3.2. Measured RTO Estimate 180 The RTO estimator runs two copies of the algorithm defined in 181 [RFC6298], as modified in Section 3.2.1: One copy for exchanges that 182 complete on initial transmissions (the "strong estimator"), and one 183 copy for exchanges that have run into retransmissions (the "weak 184 estimator"). For the latter, there is some ambiguity whether a 185 response is based on the initial transmission or any retransmission. 186 For the purposes of the weak estimator, the time from the initial 187 transmission counts. 189 The overall RTO estimate is a exponentially weighted moving average 190 (alpha = 0.5) computed of the strong and the weak estimator, which is 191 evolved after each contribution to the weak estimator or to the 192 strong estimator, from the estimator that made the most recent 193 contribution: 195 RTO_overall_ := 0.5 * RTO_recent_ + 0.5 * RTO_overall_ 197 (Note that the contributionof the weak estimator may be too big in 198 naturally lossy networks. TBD.) 200 3.2.1. Modifications to the algorithm of RFC 6298 202 This subsection presents three modifications that must be applied to 203 the algorithm of [RFC6298] as per this document. The first two 204 recommend new parameter settings. The third one is the variable 205 backoff factor mechanism. 207 The initial value for each of the two RTO estimators is 2 s. 209 For the weak estimator, the factor K (the RTT variance multiplier) is 210 set to 1 instead of 4. This is necessary to avoid a strong increase 211 of the RTO in the case that the RTTVAR value is very large, which may 212 be the case if a weak RTT measurement is obtained after one or more 213 retransmissions. 215 If an RTO estimation is lower than 1 s or higher than 8 s, instead of 216 applying a binary backoff factor in both cases, a variable backoff 217 factor is used. For RTO estimations below 1 s, the RTO for a 218 retransmission is multiplied by 3, while for estimations above 8 s, 219 the RTO is multiplied only by 1.3 (this initial choice of numbers to 220 be verified by more simulations). This helps to avoid that exchanges 221 with small initial RTOs use up all retransmissions in a short 222 interval of time and exchanges with large initial RTOs may not be 223 able to carry out all retransmissions within MAX_TRANSMIT_WAIT 224 (93 s). 226 3.2.2. Discussion 228 In contrast to [RFC6298], this algorithm attempts to make use of 229 ambiguous information from retransmissions. This is motivated by the 230 high non-congestion loss rates expected in constrained node networks, 231 and the need to update the RTO estimators even in the presence of 232 loss. Additional investigation is required to determine whether this 233 is indeed justified. 235 3.3. Lifetime, Aging 236 The state of the RTO estimators for an endpoint SHOULD be kept as 237 long as possible. If other state is kept for the endpoint (such as a 238 DTLS connection), it is very strongly RECOMMENDED to keep the RTO 239 state alive at least as long as this other state. It MUST be kept 240 for at least 255 s. 242 If an estimator has a value that is lower than 1 s, and it is left 243 without further update for a time that is more than 16 times its 244 current value, its value is doubled. 246 (It is allowed to implement this cumulatively at the time it is used 247 next, possibly approximating multiple doublings by replacing the 248 value with 1/8th of the time that has elapsed since the last update. 249 Alternatively, simple estimators can be simply updated to 1 s after 250 being without update for a time that is more than 16 times its value, 251 or, even simpler, be clamped at 1 s or above.) 253 4. Advanced CoAP Congestion Control: Non-Confirmables 255 (TO DO: Align this with final consensus on -observe!) 257 A CoAP endpoint MUST NOT send non-confirmables to another CoAP 258 endpoint at a rate higher than defined by this document. Independent 259 of any congestion control mechanisms, a CoAP endpoint can always send 260 non-confirmables if their rate does not exceed 1 B/s. 262 Non-confirmables that form part of exchanges are governed by the 263 rules for exchanges. 265 Non-confirmables outside exchanges (e.g., [I-D.ietf-core-observe] 266 notifications sent as non-confirmables) are governed by the following 267 rules: 269 1. Of any 16 consecutive messages towards this endpoint that aren't 270 responses or acknowledgments, at least 2 of the messages must be 271 confirmable. 273 2. The confirmable messages must be sent under an RTO estimator, as 274 specified in Section 3. 276 3. The packet rate of non-confirmable messages cannot exceed 1/RTO, 277 where RTO is the overall RTO estimator value at the time the non- 278 confirmable packet is sent. 280 4.1. Discussion 281 This is relatively conservative. More advanced versions of this 282 algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348] 283 and apply the TCP equation to achieve a higher rate than 1/RTO. 285 5. IANA Considerations 287 This document makes no requirements on IANA. (This section to be 288 removed by RFC editor.) 290 6. Security Considerations 292 (TBD. The security considerations of, e.g., [RFC5681], [RFC2914], 293 and [RFC5405] apply. Some issues are already discussed in the 294 security considerations of [I-D.ietf-core-coap].) 296 7. Acknowledgements 298 The first document to examine CoAP congestion control issues in 299 detail was [I-D.eggert-core-congestion-control], to which this draft 300 owes a lot. 302 Michael Scharf did a review of CoAP congestion control issues that 303 asked a lot of good questions. Several Transport Area 304 representatives made further significant inputs this discussion 305 during IETF84, including Lars Eggert, Michael Scharf, and David 306 Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset, 307 Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided 308 very useful additions. Carles Gomez, August Betzler and Ilker 309 Demirkol provided a first detailed review of the present document; 310 August provided simulation results that shaped some of the 311 recommendations here but also indicate a need for further effort. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 321 2914, September 2000. 323 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 324 for Application Designers", BCP 145, RFC 5405, November 325 2008. 327 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 328 "Computing TCP's Retransmission Timer", RFC 6298, June 329 2011. 331 8.2. Informative References 333 [I-D.bormann-core-congestion-control] 334 Bormann, C. and K. Hartke, "Congestion Control Principles 335 for CoAP", draft-bormann-core-congestion-control-02 (work 336 in progress), July 2012. 338 [I-D.eggert-core-congestion-control] 339 Eggert, L., "Congestion Control for the Constrained 340 Application Protocol (CoAP)", draft-eggert-core- 341 congestion-control-01 (work in progress), January 2011. 343 [I-D.ietf-core-coap] 344 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 345 Application Protocol (CoAP)", draft-ietf-core-coap-18 346 (work in progress), June 2013. 348 [I-D.ietf-core-observe] 349 Hartke, K., "Observing Resources in CoAP", draft-ietf- 350 core-observe-11 (work in progress), October 2013. 352 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 353 Friendly Rate Control (TFRC): Protocol Specification", RFC 354 5348, September 2008. 356 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 357 Control", RFC 5681, September 2009. 359 Author's Address 361 Carsten Bormann 362 Universitaet Bremen TZI 363 Postfach 330440 364 Bremen D-28359 365 Germany 367 Phone: +49-421-218-63921 368 Email: cabo@tzi.org