idnits 2.17.1 draft-bormann-core-cocoa-02.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 (July 03, 2014) is 3582 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-14 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 A. Betzler 5 Expires: January 4, 2015 C. Gomez 6 I. Demirkol 7 Universitat Politecnica de Catalunya/Fundacio i2CAT 8 July 03, 2014 10 CoAP Simple Congestion Control/Advanced 11 draft-bormann-core-cocoa-02 13 Abstract 15 The CoAP protocol needs to be implemented in such a way that it does 16 not cause persistent congestion on the network it uses. The CoRE 17 CoAP specification defines basic behavior that exhibits low risk of 18 congestion with minimal implementation requirements. It also leaves 19 room for combining the base specification with advanced congestion 20 control mechanisms with higher performance. 22 This specification defines some simple advanced CoRE Congestion 23 Control mechanisms, Simple CoCoA. In the present version -02, it is 24 making use of input from simulations and experiments in real 25 networks. The specification might still benefit from simplifying it 26 further. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 4, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Advanced CoAP Congestion Control: RTO Estimation . . . . . . 4 66 3.1. Blind RTO Estimate . . . . . . . . . . . . . . . . . . . 4 67 3.2. Measured RTO Estimate . . . . . . . . . . . . . . . . . . 5 68 3.2.1. Modifications to the algorithm of RFC 6298 . . . . . 5 69 3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Lifetime, Aging . . . . . . . . . . . . . . . . . . . . . 6 71 4. Advanced CoAP Congestion Control: Non-Confirmables . . . . . 6 72 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 (See Abstract.) 85 Extended rationale for this specification can be found in 86 [I-D.bormann-core-congestion-control] and 87 [I-D.eggert-core-congestion-control], as well as in the minutes of 88 the IETF 84 CoRE WG meetings. 90 1.1. Terminology 92 This specification uses terms from [RFC7252]. In addition, it 93 defines the following terminology: 95 Initiator: The endpoint that sends the message that initiates an 96 exchange. E.g., the party that sends a confirmable message, or a 97 non-confirmable message conveying a request. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119] when they 102 appear in ALL CAPS. These words may also appear in this document in 103 lower case as plain English words, absent their normative meanings. 105 (Note that this document is itself informational, but it is 106 discussing normative statements.) 108 The term "byte", abbreviated by "B", is used in its now customary 109 sense as a synonym for "octet". 111 2. Context 113 In the Vancouver IETF 84 CoRE meeting, a path forward was defined 114 that includes a very simple basic scheme (lock-step with a number of 115 parallel exchanges of 1) in the base specification together with 116 performance-enhancing advanced mechanisms. 118 The present specification is based on the approved text in the 119 [RFC7252] base specification. It is making use of the text that 120 permits advanced congestion control mechanisms and allows them to 121 change protocol parameters, including NSTART and the binary 122 exponential backoff mechanism. Note that Section 4.8 of [RFC7252] 123 limits the leeway that implementations have in changing the CoRE 124 protocol parameters. 126 The present specification also assumes that, outside of exchanges, 127 non-confirmable messages can only be used at a limited rate without 128 an advanced congestion control mechanism (this is mainly relevant for 129 -observe). It is also intended to address the [RFC5405] guideline 130 about combining congestion control state for a destination; and to 131 clarify its meaning for CoAP using the definition of an endpoint. 133 The present specification does not address multicast or dithering 134 beyond basic retransmission dithering. 136 3. Advanced CoAP Congestion Control: RTO Estimation 138 For an initiator that plans to make multiple requests to one 139 destination endpoint, it may be worthwhile to make RTT measurements 140 in order to obtain a better RTO estimation than that implied by the 141 default initial timeout of 2 to 3 s. This is based on the usual 142 algorithms for RTO estimation [RFC6298], with appropriately extended 143 default/base values, as proposed in Section 3.2.1. Note that such a 144 mechanism must, during idle periods, decay RTO estimates that are 145 shorter or longer than the basic RTO estimate back to the basic RTO 146 estimate, until fresh measurements become available again, as 147 proposed in Section 3.3. 149 One important consideration not relevant for TCP is the fact that a 150 CoAP round-trip may include application processing time, which may be 151 hard to predict, and may differ between different resources available 152 at the same endpoint. Also, for communications with networks of 153 constrained devices that apply radio duty cycling, large and variable 154 round-trip times are likely to be observed. Servers will only 155 trigger their early ACKs (with a non-piggybacked response to be sent 156 later) based on the default timers, e.g. after 1 s. A client that 157 has arrived at a RTO estimate shorter than 1 s SHOULD therefore use a 158 larger backoff factor for retransmissions to avoid expending all of 159 its retransmissions in the default interval of 2 to 3 s. A proposal 160 for a mechanism with variable backoff factors is presented in 161 Section 3.2.1. 163 It may also be worthwhile to do RTT estimates not just based on 164 information measured from a single destination endpoint, but also 165 based on entire hosts (IP addresses) and/or complete prefixes (e.g., 166 maintain an RTT estimate for a whole /64). The exact way this can be 167 used to reduce the amount of state in an initiator is for further 168 study. 170 3.1. Blind RTO Estimate 172 The initial RTO estimate for an endpoint is set to 2 seconds. 174 If only the initial RTO estimate is available, the RTO estimate for 175 each of up to NSTART exchanges started in parallel is set to 2 s 176 times the number of parallel exchanges, e.g. if two exchanges are 177 already running, the initial RTO estimate for an additional exchange 178 is 6 seconds. 180 3.2. Measured RTO Estimate 182 The RTO estimator runs two copies of the algorithm defined in 183 [RFC6298], as modified in Section 3.2.1: One copy for exchanges that 184 complete on initial transmissions (the "strong estimator"), and one 185 copy for exchanges that have run into retransmissions, where only the 186 first two retransmissions are considered (the "weak estimator"). For 187 the latter, there is some ambiguity whether a response is based on 188 the initial transmission or the retransmissions. For the purposes of 189 the weak estimator, the time from the initial transmission counts. 190 Responses obtained after the third retransmission are not used to 191 update an estimator. 193 The overall RTO estimate is an exponentially weighted moving average 194 (alpha = 0.5) computed of the strong and the weak estimator, which is 195 evolved after each contribution to the weak estimator (1) or to the 196 strong estimator (2), from the estimator that made the most recent 197 contribution: 199 RTO_overall_ := 0.25 * RTO_weak_ + 0.75 * RTO_overall_ (1) 201 RTO_overall_ := 0.5 * RTO_strong_ + 0.5 * RTO_overall_ (2) 203 (Splitting this update into the two cases avoids making the 204 contribution of the weak estimator too big in naturally lossy 205 networks.) 207 3.2.1. Modifications to the algorithm of RFC 6298 209 This subsection presents three modifications that must be applied to 210 the algorithm of [RFC6298] as per this document. The first two 211 recommend new parameter settings. The third one is the variable 212 backoff factor mechanism. 214 The initial value for each of the two RTO estimators is 2 s. 216 For the weak estimator, the factor K (the RTT variance multiplier) is 217 set to 1 instead of 4. This is necessary to avoid a strong increase 218 of the RTO in the case that the RTTVAR value is very large, which may 219 be the case if a weak RTT measurement is obtained after one or more 220 retransmissions. 222 If an RTO estimation is lower than 1 s or higher than 3 s, instead of 223 applying a binary backoff factor in both cases, a variable backoff 224 factor is used. For RTO estimations below 1 s, the RTO for a 225 retransmission is multiplied by 3, while for estimations above 3 s, 226 the RTO is multiplied only by 1.5 (this updated choice of numbers to 227 be verified by more simulations). This helps to avoid that exchanges 228 with small initial RTOs use up all retransmissions in a short 229 interval of time and exchanges with large initial RTOs may not be 230 able to carry out all retransmissions within MAX_TRANSMIT_WAIT 231 (93 s). 233 The binary exponential backoff is truncated at 32 seconds. Similar 234 to the way retransmissions are handled in the base specification, 235 they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO. 237 3.2.2. Discussion 239 In contrast to [RFC6298], this algorithm attempts to make use of 240 ambiguous information from retransmissions. This is motivated by the 241 high non-congestion loss rates expected in constrained node networks, 242 and the need to update the RTO estimators even in the presence of 243 loss. Additional investigation is required to determine whether this 244 is indeed justified. 246 3.3. Lifetime, Aging 248 The state of the RTO estimators for an endpoint SHOULD be kept as 249 long as possible. If other state is kept for the endpoint (such as a 250 DTLS connection), it is very strongly RECOMMENDED to keep the RTO 251 state alive at least as long as this other state. It MUST be kept 252 for at least 255 s. 254 If an estimator has a value that is lower than 1 s, and it is left 255 without further update for 16 times its current value, the RTO 256 estimate is doubled. If an estimator has a value that is higher than 257 3 s, and it is left without further update for 4 times its current 258 value, the RTO estimate is set to be 260 RTO_overall_ := 1 s + (0.5 * RTO_overall_) 262 (Note that, instead of running a timer, it is possible to implement 263 these RTO aging calculations cumulatively at the time the estimator 264 is used next.) 266 4. Advanced CoAP Congestion Control: Non-Confirmables 268 (TO DO: Align this with final consensus on -observe!) 270 A CoAP endpoint MUST NOT send non-confirmables to another CoAP 271 endpoint at a rate higher than defined by this document. Independent 272 of any congestion control mechanisms, a CoAP endpoint can always send 273 non-confirmables if their rate does not exceed 1 B/s. 275 Non-confirmables that form part of exchanges are governed by the 276 rules for exchanges. 278 Non-confirmables outside exchanges (e.g., [I-D.ietf-core-observe] 279 notifications sent as non-confirmables) are governed by the following 280 rules: 282 1. Of any 16 consecutive messages towards this endpoint that aren't 283 responses or acknowledgments, at least 2 of the messages must be 284 confirmable. 286 2. The confirmable messages must be sent under an RTO estimator, as 287 specified in Section 3. 289 3. The packet rate of non-confirmable messages cannot exceed 1/RTO, 290 where RTO is the overall RTO estimator value at the time the non- 291 confirmable packet is sent. 293 4.1. Discussion 295 This is relatively conservative. More advanced versions of this 296 algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348] 297 and apply the TCP equation to achieve a higher rate than 1/RTO. 299 5. IANA Considerations 301 This document makes no requirements on IANA. (This section to be 302 removed by RFC editor.) 304 6. Security Considerations 306 (TBD. The security considerations of, e.g., [RFC5681], [RFC2914], 307 and [RFC5405] apply. Some issues are already discussed in the 308 security considerations of [RFC7252].) 310 7. Acknowledgements 312 The first document to examine CoAP congestion control issues in 313 detail was [I-D.eggert-core-congestion-control], to which this draft 314 owes a lot. 316 Michael Scharf did a review of CoAP congestion control issues that 317 asked a lot of good questions. Several Transport Area 318 representatives made further significant inputs this discussion 319 during IETF84, including Lars Eggert, Michael Scharf, and David 320 Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset, 321 Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided 322 very useful additions. 324 Authors from Universitat Politecnica de Catalunya have been supported 325 in part by the Spanish Government's Ministerio de Economia y 326 Competitividad through projects TEC2009-11453 and TEC2012-32531, and 327 FEDER. 329 8. References 331 8.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 337 2914, September 2000. 339 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 340 for Application Designers", BCP 145, RFC 5405, November 341 2008. 343 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 344 "Computing TCP's Retransmission Timer", RFC 6298, June 345 2011. 347 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 348 Application Protocol (CoAP)", RFC 7252, June 2014. 350 8.2. Informative References 352 [I-D.bormann-core-congestion-control] 353 Bormann, C. and K. Hartke, "Congestion Control Principles 354 for CoAP", draft-bormann-core-congestion-control-02 (work 355 in progress), July 2012. 357 [I-D.eggert-core-congestion-control] 358 Eggert, L., "Congestion Control for the Constrained 359 Application Protocol (CoAP)", draft-eggert-core- 360 congestion-control-01 (work in progress), January 2011. 362 [I-D.ietf-core-observe] 363 Hartke, K., "Observing Resources in CoAP", draft-ietf- 364 core-observe-14 (work in progress), June 2014. 366 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 367 Friendly Rate Control (TFRC): Protocol Specification", RFC 368 5348, September 2008. 370 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 371 Control", RFC 5681, September 2009. 373 Authors' Addresses 375 Carsten Bormann 376 Universitaet Bremen TZI 377 Postfach 330440 378 Bremen D-28359 379 Germany 381 Phone: +49-421-218-63921 382 Email: cabo@tzi.org 384 August Betzler 385 Universitat Politecnica de Catalunya/Fundacio i2CAT 386 Departament d'Enginyeria Telematica 387 C/Jordi Girona, 1-3 388 Barcelona 08034 389 Spain 391 Email: august.betzler@entel.upc.edu 393 Carles Gomez 394 Universitat Politecnica de Catalunya/Fundacio i2CAT 395 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 396 de Castelldefels 397 C/Esteve Terradas, 7 398 Castelldefels 08860 399 Spain 401 Phone: +34-93-413-7206 402 Email: carlesgo@entel.upc.edu 404 Ilker Demirkol 405 Universitat Politecnica de Catalunya/Fundacio i2CAT 406 Departament d'Enginyeria Telematica 407 C/Jordi Girona, 1-3 408 Barcelona 08034 409 Spain 411 Email: ilker.demirkol@entel.upc.edu