idnits 2.17.1 draft-ietf-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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 618 -- Looks like a reference, but probably isn't: '2' on line 622 -- Looks like a reference, but probably isn't: '3' on line 625 -- Looks like a reference, but probably isn't: '4' on line 629 == Missing Reference: '5-10' is mentioned on line 614, but not defined -- Looks like a reference, but probably isn't: '5' on line 634 -- Looks like a reference, but probably isn't: '6' on line 639 -- Looks like a reference, but probably isn't: '7' on line 644 -- Looks like a reference, but probably isn't: '8' on line 648 -- Looks like a reference, but probably isn't: '9' on line 653 -- Looks like a reference, but probably isn't: '10' on line 658 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). 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: September 14, 2017 Fundacio i2CAT 6 C. Gomez 7 I. Demirkol 8 Universitat Politecnica de Catalunya/Fundacio i2CAT 9 March 13, 2017 11 CoAP Simple Congestion Control/Advanced 12 draft-ietf-core-cocoa-01 14 Abstract 16 The CoAP protocol needs to be implemented in such a way that it does 17 not cause persistent congestion on the network it uses. The CoRE 18 CoAP specification defines basic behavior that exhibits low risk of 19 congestion with minimal implementation requirements. It also leaves 20 room for combining the base specification with advanced congestion 21 control mechanisms with higher performance. 23 This specification defines some simple advanced CoRE Congestion 24 Control mechanisms, Simple CoCoA. It is making use of input from 25 simulations and experiments in real networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Area of Applicability . . . . . . . . . . . . . . . . . . . . 4 65 4. Advanced CoAP Congestion Control: RTO Estimation . . . . . . 4 66 4.1. Blind RTO Estimate . . . . . . . . . . . . . . . . . . . 5 67 4.2. Measured RTO Estimate . . . . . . . . . . . . . . . . . . 5 68 4.2.1. Modifications to the algorithm of RFC 6298 . . . . . 6 69 4.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Lifetime, Aging . . . . . . . . . . . . . . . . . . . . . 7 71 5. Advanced CoAP Congestion Control: Non-Confirmables . . . . . 7 72 5.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Appendix A. Advanced CoAP Congestion Control: Aggregate 79 Congestion Control . . . . . . . . . . . . . . . . . 10 80 A.1. Proposed Algorithm . . . . . . . . . . . . . . . . . . . 10 81 A.2. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 82 A.3. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 11 83 A.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12 84 Appendix B. Supporting evidence . . . . . . . . . . . . . . . . 12 85 B.1. Older versions of the draft and improvement . . . . . . . 13 86 B.2. References . . . . . . . . . . . . . . . . . . . . . . . 13 87 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 (See Abstract.) 94 Extended rationale for this specification can be found in 95 [I-D.bormann-core-congestion-control] and 97 [I-D.eggert-core-congestion-control], as well as in the minutes of 98 the IETF 84 CoRE WG meetings. 100 1.1. Terminology 102 This specification uses terms from [RFC7252]. In addition, it 103 defines the following terminology: 105 Initiator: The endpoint that sends the message that initiates an 106 exchange. E.g., the party that sends a confirmable message, or a 107 non-confirmable message conveying a request. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] when they 112 appear in ALL CAPS. These words may also appear in this document in 113 lower case as plain English words, absent their normative meanings. 115 (Note that this document is itself informational, but it is 116 discussing normative statements.) 118 The term "byte", abbreviated by "B", is used in its now customary 119 sense as a synonym for "octet". 121 2. Context 123 In the Vancouver IETF 84 CoRE meeting, a path forward was defined 124 that includes a very simple basic scheme (lock-step with a number of 125 parallel exchanges of 1) in the base specification together with 126 performance-enhancing advanced mechanisms. 128 The present specification is based on the approved text in the 129 [RFC7252] base specification. It is making use of the text that 130 permits advanced congestion control mechanisms and allows them to 131 change protocol parameters, including NSTART and the binary 132 exponential backoff mechanism. Note that Section 4.8 of [RFC7252] 133 limits the leeway that implementations have in changing the CoRE 134 protocol parameters. 136 The present specification also assumes that, outside of exchanges, 137 non-confirmable messages can only be used at a limited rate without 138 an advanced congestion control mechanism (this is mainly relevant for 139 [RFC7641]). It is also intended to address the [RFC8085] guideline 140 about combining congestion control state for a destination; and to 141 clarify its meaning for CoAP using the definition of an endpoint. 143 The present specification does not address multicast or dithering 144 beyond basic retransmission dithering. 146 3. Area of Applicability 148 The present algorithm is intended to be generally applicable. The 149 objective is to be "better" than default CoAP congestion control in a 150 number of characteristics, including achievable goodput for a given 151 offered load, latency, and recovery from bursts, while providing more 152 predictable stress to the network and the same level of safety from 153 catastrophic congestion. It does require three state variables per 154 scope plus the state needed to do RTT measurements, so it may not be 155 applicable to the most constrained devices (class 1 as per 156 [RFC7228]). 158 The scope of each instance of the algorithm in the current set of 159 evaluations has been the five-tuple, i.e., CoAP + endpoint (transport 160 address) for Initiator and Responder. Potential applicability to 161 larger scopes needs to be examined. 163 Aggregate Congestion Control (Appendix A) is not yet supported by 164 research as well as the other algorithms in this specification. Its 165 use is more interesting on the cloud side, where a single CoAP 166 endpoint may need to talk to thousands of other endpoints and may 167 need to control the burstiness of the resulting aggregate traffic. 169 4. Advanced CoAP Congestion Control: RTO Estimation 171 For an initiator that plans to make multiple requests to one 172 destination endpoint, it may be worthwhile to make RTT measurements 173 in order to obtain a better RTO estimation than that implied by the 174 default initial timeout of 2 to 3 s. This is based on the usual 175 algorithms for RTO estimation [RFC6298], with appropriately extended 176 default/base values, as proposed in Section 4.2.1. Note that such a 177 mechanism must, during idle periods, decay RTO estimates that are 178 shorter or longer than the basic RTO estimate back to the basic RTO 179 estimate, until fresh measurements become available again, as 180 proposed in Section 4.3. 182 One important consideration not relevant for TCP is the fact that a 183 CoAP round-trip may include application processing time, which may be 184 hard to predict, and may differ between different resources available 185 at the same endpoint. Also, for communications with networks of 186 constrained devices that apply radio duty cycling, large and variable 187 round-trip times are likely to be observed. Servers will only 188 trigger their early ACKs (with a non-piggybacked response to be sent 189 later) based on the default timers, e.g. after 1 s. A client that 190 has arrived at a RTO estimate shorter than 1 s SHOULD therefore use a 191 larger backoff factor for retransmissions to avoid expending all of 192 its retransmissions in the default interval of 2 to 3 s. A proposal 193 for a mechanism with variable backoff factors is presented in 194 Section 4.2.1. 196 It may also be worthwhile to do RTT estimates not just based on 197 information measured from a single destination endpoint, but also 198 based on entire hosts (IP addresses) and/or complete prefixes (e.g., 199 maintain an RTT estimate for a whole /64). The exact way this can be 200 used to reduce the amount of state in an initiator is for further 201 study. 203 4.1. Blind RTO Estimate 205 The initial RTO estimate for an endpoint is set to 2 seconds (the 206 initial RTO estimate is used as the initial value for both E_weak_ 207 and E_strong_ below). 209 If only the initial RTO estimate is available, the RTO estimate for 210 each of up to NSTART exchanges started in parallel is set to 2 s 211 times the number of parallel exchanges, e.g. if two exchanges are 212 already running, the initial RTO estimate for an additional exchange 213 is 6 seconds. 215 4.2. Measured RTO Estimate 217 The RTO estimator runs two copies of the algorithm defined in 218 [RFC6298], as modified in Section 4.2.1: One copy for exchanges that 219 complete on initial transmissions (the "strong estimator", 220 E_strong_), and one copy for exchanges that have run into 221 retransmissions, where only the first two retransmissions are 222 considered (the "weak estimator", E_weak_). For the latter, there is 223 some ambiguity whether a response is based on the initial 224 transmission or the retransmissions. For the purposes of the weak 225 estimator, the time from the initial transmission counts. Responses 226 obtained after the third retransmission are not used to update an 227 estimator. 229 The overall RTO estimate is an exponentially weighted moving average 230 (alpha = 0.5 and 0.25, respectively) computed of the strong and the 231 weak estimator, which is evolved after each contribution to the weak 232 estimator (1) or to the strong estimator (2), from the estimator that 233 made the most recent contribution: 235 RTO := 0.25 * E_weak_ + 0.75 * RTO (1) 237 RTO := 0.5 * E_strong_ + 0.5 * RTO (2) 239 (Splitting this update into the two cases avoids making the 240 contribution of the weak estimator too big in naturally lossy 241 networks.) 243 4.2.1. Modifications to the algorithm of RFC 6298 245 This subsection presents three modifications that must be applied to 246 the algorithm of [RFC6298] as per this document. The first two 247 recommend new parameter settings. The third one is the variable 248 backoff factor mechanism. 250 The initial value for each of the two RTO estimators is 2 s. 252 For the weak estimator, the factor K (the RTT variance multiplier) is 253 set to 1 instead of 4. This is necessary to avoid a strong increase 254 of the RTO in the case that the RTTVAR value is very large, which may 255 be the case if a weak RTT measurement is obtained after one or more 256 retransmissions. 258 If an RTO estimation is lower than 1 s or higher than 3 s, instead of 259 applying a binary backoff factor in both cases, a variable backoff 260 factor is used. For RTO estimations below 1 s, the RTO for a 261 retransmission is multiplied by 3, while for estimations above 3 s, 262 the RTO is multiplied only by 1.5 (this updated choice of numbers to 263 be verified by more simulations). This helps to avoid that exchanges 264 with small initial RTOs use up all retransmissions in a short 265 interval of time and exchanges with large initial RTOs may not be 266 able to carry out all retransmissions within MAX_TRANSMIT_WAIT 267 (93 s). 269 The binary exponential backoff is truncated at 32 seconds. Similar 270 to the way retransmissions are handled in the base specification, 271 they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO. 273 4.2.2. Discussion 275 In contrast to [RFC6298], this algorithm attempts to make use of 276 ambiguous information from retransmissions. This is motivated by the 277 high non-congestion loss rates expected in constrained node networks, 278 and the need to update the RTO estimators even in the presence of 279 loss. This approach appears to contravene the mandate in 280 Section 3.1.1 of [RFC8085] that "latency samples MUST NOT be derived 281 from ambiguous transactions". However, those samples are not simply 282 combined into the strong estimator, but are used to correct the 283 limited knowledge that can be gained from the strong RTT measurements 284 by employing an additional weak estimator. Evidence that has been 285 collected from experiments appears to support that the overall effect 286 of using this data in the way described is beneficial (Appendix B). 288 Some evaluation has been done on earlier versions of this 289 specification [Betzler2013]. A more recent (and more comprehensive) 290 reference is [Betzler2015]. 292 4.3. Lifetime, Aging 294 The state of the RTO estimators for an endpoint SHOULD be kept as 295 long as possible. If other state is kept for the endpoint (such as a 296 DTLS connection), it is very strongly RECOMMENDED to keep the RTO 297 state alive at least as long as this other state. It MUST be kept 298 for at least 255 s. 300 If an estimator has a value that is lower than 1 s, and it is left 301 without further update for 16 times its current value, the RTO 302 estimate is doubled. If an estimator has a value that is higher than 303 3 s, and it is left without further update for 4 times its current 304 value, the RTO estimate is set to be 306 RTO := 1 s + (0.5 * RTO) 308 (Note that, instead of running a timer, it is possible to implement 309 these RTO aging calculations cumulatively at the time the estimator 310 is used next.) 312 5. Advanced CoAP Congestion Control: Non-Confirmables 314 A CoAP endpoint MUST NOT send non-confirmables to another CoAP 315 endpoint at a rate higher than defined by this document. Independent 316 of any congestion control mechanisms, a CoAP endpoint can always send 317 non-confirmables if their rate does not exceed 1 B/s. 319 Non-confirmables that form part of exchanges are governed by the 320 rules for exchanges. 322 Non-confirmables outside exchanges (e.g., [RFC7641] notifications 323 sent as non-confirmables) are governed by the following rules: 325 1. Of any 16 consecutive messages towards this endpoint that aren't 326 responses or acknowledgments, at least 2 of the messages must be 327 confirmable. 329 2. The confirmable messages must be sent under an RTO estimator, as 330 specified in Section 4. 332 3. The packet rate of non-confirmable messages cannot exceed 1/RTO, 333 where RTO is the overall RTO estimator value at the time the non- 334 confirmable packet is sent. 336 5.1. Discussion 338 This is relatively conservative. More advanced versions of this 339 algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348] 340 and apply the TCP equation to achieve a higher rate than 1/RTO. 342 [RFC7641], Section 4.5.1, specifies that the rate of NONs SHOULD NOT 343 exceed 1/RTT on average, if the server can maintain an RTT estimate 344 for a client. CoCoA limits the packet rate of NONs in this situation 345 to 1/RTO. Assuming that the RTO estimation in CoCoA works as 346 expected, RTO[k] should be slightly greater than the RTT[k], thus 347 CoCoA would be more conservative. The expectation therefore is that 348 complying with the NON rate set by CoCoA leads to complying with 349 [RFC7641]. 351 6. IANA Considerations 353 This document makes no requirements on IANA. (This section to be 354 removed by RFC editor.) 356 7. Security Considerations 358 (TBD. The security considerations of, e.g., [RFC5681], [RFC2914], 359 and [RFC8085] apply. Some issues are already discussed in the 360 security considerations of [RFC7252].) 362 8. References 364 8.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 372 RFC 2914, DOI 10.17487/RFC2914, September 2000, 373 . 375 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 376 "Computing TCP's Retransmission Timer", RFC 6298, 377 DOI 10.17487/RFC6298, June 2011, 378 . 380 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 381 Application Protocol (CoAP)", RFC 7252, 382 DOI 10.17487/RFC7252, June 2014, 383 . 385 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 386 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 387 March 2017, . 389 8.2. Informative References 391 [Betzler2013] 392 Betzler, A., Gomez, C., Demirkol, I., and J. Paradells, 393 "Congestion control in reliable CoAP communication", 394 ACM MSWIM'13 p. 365-372, DOI 10.1145/2507924.2507954, 395 2013. 397 [Betzler2015] 398 Betzler, A., Gomez, C., Demirkol, I., and J. Paradells, 399 "CoCoA+: an Advanced Congestion Control Mechanism for 400 CoAP", Ad Hoc Networks Vol. 33 pp. 126-139, 401 DOI 10.1016/j.adhoc.2015.04.007, October 2015. 403 [I-D.bormann-core-congestion-control] 404 Bormann, C. and K. Hartke, "Congestion Control Principles 405 for CoAP", draft-bormann-core-congestion-control-02 (work 406 in progress), July 2012. 408 [I-D.eggert-core-congestion-control] 409 Eggert, L., "Congestion Control for the Constrained 410 Application Protocol (CoAP)", draft-eggert-core- 411 congestion-control-01 (work in progress), January 2011. 413 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 414 Friendly Rate Control (TFRC): Protocol Specification", 415 RFC 5348, DOI 10.17487/RFC5348, September 2008, 416 . 418 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 419 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 420 . 422 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 423 Constrained-Node Networks", RFC 7228, 424 DOI 10.17487/RFC7228, May 2014, 425 . 427 [RFC7641] Hartke, K., "Observing Resources in the Constrained 428 Application Protocol (CoAP)", RFC 7641, 429 DOI 10.17487/RFC7641, September 2015, 430 . 432 Appendix A. Advanced CoAP Congestion Control: Aggregate Congestion 433 Control 435 (The mechanism defined in this appendix has received less research 436 than the ones in the main body of this specification.) 438 A.1. Proposed Algorithm 440 To avoid possible congestion when sending many packets to different 441 destination endpoints in parallel, the overall number of outstanding 442 interactions towards different destination endpoints should be 443 limited. An upper limit PLIMIT determines the maximum number of 444 outstanding interactions towards different destination endpoints that 445 are allowed in parallel. When a request is to be sent to a 446 destination endpoint, PLIMIT is determined according to Equation (3) 447 in the case that no RTO information is already available for the 448 destination endpoint, or using Equation (4) in case that valid RTO 449 information is available for the destination endpoint. Both formulas 450 use LAMBDA, as defined in Equation (5). 452 PLIMIT = LAMBDA (3) 454 PLIMIT = max(LAMBDA, LAMBDA*ACK_TIMEOUT/mean(RTO)) (4) 456 LAMBDA = max(4, KNOWN_DEST_ENDPOINTS/4) (5) 458 mean(RTO) is the average value of all valid RTO estimations 459 maintained by the device. LAMBDA is the maximum of a constant value 460 (4 by default) and the rounded up value of KNOWN_DEST_ENDPOINTS/4 , 461 where KNOWN_DEST_ENDPOINTS is the overall number of "known" 462 destination endpoints (i.e. destination endpoints for which an RTO 463 estimate is maintained). 465 A new interaction may only be processed if the current overall number 466 of outstanding interactions is lower than the PLIMIT calculated when 467 the request is initiated. 469 A.2. Example 1 471 In the following we give an example, with LAMBDA = 4 (our proposed 472 default LAMBDA): 474 Assume that a sender has so far obtained RTO estimations for two 475 destination endpoints A (RTO = 0.5 s) and B (RTO = 1.5 s), and 476 currently pcount (a variable which accounts for the number of 477 outstanding interactions towards endpoints) is equal to 0. Now three 478 transactions are initiated consecutively in the following order: one 479 for A, one for B and one for a new destination C. 481 When an interaction with node A is initiated, LAMBDA is calculated 483 LAMBDA = max(4, 3/4) = 4. 485 Then PLIMIT is calculated: 487 PLIMIT = max(4, (4*2 s)/mean(0.5 s, 1.5 s)) = max (4, 8 s/1 s) = 488 max (4, 8) = 8 490 This means that with the current RTO information the sender has 491 obtained about the destination endpoints, up to 8 outstanding 492 interactions to different destination endpoints would be allowed. By 493 initiating an interaction with A, pcount is increased to 1, which is 494 still below PLIMIT. Thus, the interaction may be processed. The 495 same applies to B: pcount increases to 2 after obtaining the same 496 PLIMIT value of 8. 498 Destination C is unknown to CoCoA, therefore the updated PLIMIT 499 before processing the interaction with node C is 4. The CoAP request 500 may be processed (pcount = 3). If two more interactions with 501 different unknown destination endpoints would have been initiated, 502 only the first one would have met the requirements to process it 503 (PLIMIT = 4, pcount = 4). The second interaction would have 504 increased pcount to 5, which is not permitted, since PLIMIT is 4. It 505 may occur that pcount exceeds PLIMIT in particular cases, in this 506 case, the interaction is not permitted as well. If the number of 507 destinations exchanges are initiated with would increase further, 508 eventually LAMBDA could grow beyond 4, allowing for more interactions 509 to be sent in parallel. 511 A.3. Example 2 513 Let us now assume that a sender has so far obtained RTO estimations 514 for 101 destination endpoints, their average RTO is 1 s, and 515 currently pcount is equal to 0. When a new transaction is initiated 516 with a destination endpoint for which an RTO estimate is available, 517 LAMBDA is calculated 519 LAMBDA = max(4, 101/4) = 26 521 Based on this, PLIMIT is calculated as follows: 523 PLIMIT= max(26, (26*2 s)/1 s) = max (26, 52) = 52 525 This means that with the current RTO information that the sender has 526 obtained about the destination endpoints, up to 52 outstanding 527 interactions to known destination endpoints would be allowed. 529 However, if the new exchange is to be initiated with an "unknown" 530 destination endpoint (i.e. an endpoint for which an RTO estimate is 531 not available), then PLIMIT would be 26. 533 A.4. Discussion 535 The idea of the proposal is to allow more parallel transactions to 536 different destination endpoints if we have low RTO estimations for 537 them (which can be interpreted as good connections and low degree of 538 congestion). If the RTO estimations are large or interactions with 539 unknown destinations are initiated, the mechanism behaves more 540 conservatively by reducing the maximum number of parallel 541 interactions towards different destinations, but allowing at least 542 LAMBDA outstanding interactions. The second term of the max() 543 statement used to calculate LAMBDA avoids behaving too restrictively 544 when exchanges with many different destination endpoints are 545 initiated. If no RTO information is available for a destination 546 endpoint, PLIMIT is simply set to be LAMBDA. 548 If at any moment pcount would exceed PLIMIT, CoAP does not 549 immediately perform the transaction. Further, it is important that 550 in parallel, NSTART for each destination endpoint applies (which, for 551 now, we assume to be 1). The default value used for LAMBDA (equal to 552 4 as per this document) determines how aggressive/conservative CoCoA 553 behaves by default for a limited set of destination endpoints and it 554 should be chosen carefully. The term KNOWN_DEST_ENDPOINTS/4 loosens 555 the hard limit of exchanges when large numbers of destination 556 endpoints are addressed. 558 It will be necessary to see whether this approach is effective in the 559 sense that it avoids congestion in use cases where transactions to a 560 multitude of different destination endpoints are initiated. An 561 important aspect of such evaluations would be whether LAMBDA is too 562 conservative when dealing with few destination endpoints and whether 563 it allows for a dynamic adjustment of parallel exchanges with large 564 numbers of destination endpoints. On the other hand, a more safe 565 approach would use max(RTO) instead of mean(RTO). Other concerns 566 include the fact that the congestion degree of the paths to "known" 567 destination endpoints influence whether a new interaction is 568 permitted to some new endpoint which may be in very different 569 conditions in terms of congestion. However, it is desirable to avoid 570 adding a lot of complexity to the current CoCoA mechanisms. 572 Appendix B. Supporting evidence 574 (Editor's note: The WG needs to decide wbether this appendix or 575 something like it should be present in the published version of this 576 specification. If that is deemed desirable, the references local to 577 this appendix need to be merged with those from the specification 578 proper.) 580 CoCoA has been evaluated by means of simulation and experimentation 581 in diverse scenarios comprising different link layer technologies, 582 network topologies, traffic patterns and device classes. The main 583 overall evaluation result is that CoCoA consistently delivers a 584 performance which is better than, or at least similar to, that of 585 default CoAP congestion control. While the latter is insensitive to 586 network conditions, CoCoA is adaptive and makes good use of RTT 587 samples. 589 It has been shown over real GPRS and IEEE 802.15.4 mesh network 590 testebds that in these settings, in comparison to default CoAP, CoCoA 591 increases throughput and reduces the time it takes for a network to 592 process traffic bursts, while not sacrificing fairness. In contrast, 593 other RTT-sensitive approaches such as Linux-RTO or Peak-Hopper-RTO 594 may be too simple or do not adapt well to IoT scenarios, 595 underperforming default CoAP under certain conditions [1]. On the 596 other hand, CoCoA has been found to reduce latency in GPRS and Wi-Fi 597 setups, compared with default CoAP [2]. 599 CoCoA performance has also been evaluated for non-confirmable traffic 600 over emulated GPRS/UMTS links and over a real IEEE 802.15.4 mesh 601 testbed. Results show that since CoCoA is adaptive, it yields better 602 packet delivery ratio than default CoAP (which does not apply 603 congestion control to non-confirmable messages) or Observe (which 604 introduces congestion control that is not adaptive to network 605 conditions) [3, 4]. 607 B.1. Older versions of the draft and improvement 609 CoCoA has evolved since its initial draft version. Its core has 610 remained mostly stable since draft-bormann-core-cocoa-02. The 611 evolution of CoCoA has been driven by research work. This process, 612 including evaluations of early versions of CoCoA, as well as 613 improvement proposals that were finally incorporated in CoCoA, is 614 reflected in published works [5-10]. 616 B.2. References 618 [1] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP 619 congestion control for the Internet of Things", IEEE Communications 620 Magazine, July 2016. 622 [2] F. Zheng, B. Fu, Z. Cao, "CoAP Latency Evaluation", draft- 623 zheng-core-coap-lantency-evaluation-00, 2016 (work in progress). 625 [3] A. Betzler, C. Gomez, I. Demirkol, "Evaluation of Advanced 626 Congestion Control Mechanisms for Unreliable CoAP Communications", 627 PE-WASUN, Cancun, Mexico, 2015. 629 [4] A. Betzler, J. Isern, C. Gomez, I. Demirkol, J. Paradells, 630 "Experimental Evaluation of Congestion Control for CoAP 631 Communications without End-to-End Reliability", Ad Hoc Networks, 632 Volume 52, 1 December 2016, Pages 183-194. 634 [5] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "Congestion 635 Control in Reliable CoAP Communication", 16th ACM International 636 Conference on Modeling, Analysis and Simulation of Wireless and 637 Mobile Systems (MSWIM'13), Barcelona, Spain, Nov. 2013. 639 [6] A. Betzler, C. Gomez, I. Demirkol, M. Kovatsch, "Congestion 640 Control for CoAP cloud services", 8th International Workshop on 641 Service-Oriented Cyber-Physical Systems in Converging Networked 642 Environments (SOCNE) 2014, Barcelona, Spain, Sept. 2014. 644 [7] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoCoA+: an 645 advanced congestion control mechanism for CoAP", Ad Hoc Networks 646 journal, 2015. 648 [8] Bhalerao, Rahul, Sridhar Srinivasa Subramanian, and Joseph 649 Pasquale. "An analysis and improvement of congestion control in the 650 CoAP Internet-of-Things protocol." 2016 13th IEEE Annual Consumer 651 Communications & Networking Conference (CCNC). IEEE, 2016. 653 [9] I Jaervinen, L Daniel, M Kojo, "Experimental evaluation of 654 alternative congestion control algorithms for Constrained Application 655 Protocol (CoAP)", IEEE 2nd World Forum on Internet of Things (WF- 656 IoT), 2015. 658 [10] Balandina, Ekaterina, Yevgeni Koucheryavy, and Andrei Gurtov. 659 "Computing the retransmission timeout in coap." Internet of Things, 660 Smart Spaces, and Next Generation Networking. Springer Berlin 661 Heidelberg, 2013. 352-362. 663 Acknowledgements 665 The first document to examine CoAP congestion control issues in 666 detail was [I-D.eggert-core-congestion-control], to which this draft 667 owes a lot. 669 Michael Scharf did a review of CoAP congestion control issues that 670 asked a lot of good questions. Several Transport Area 671 representatives made further significant inputs this discussion 672 during IETF84, including Lars Eggert, Michael Scharf, and David 673 Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset, 674 Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided 675 very useful additions. 677 Authors from Universitat Politecnica de Catalunya have been supported 678 in part by the Spanish Government's Ministerio de Economia y 679 Competitividad through projects TEC2009-11453 and TEC2012-32531, and 680 FEDER. 682 Carles Gomez has been funded in part by the Spanish Government 683 (Ministerio de Educacion, Cultura y Deporte) through the Jose 684 Castillejo grant CAS15/00336. His contribution to this work has been 685 carried out in part during his stay as a visiting scholar at the 686 Computer Laboratory of the University of Cambridge, in collaboration 687 with Prof. Jon Crowcroft. 689 Authors' Addresses 691 Carsten Bormann 692 Universitaet Bremen TZI 693 Postfach 330440 694 Bremen D-28359 695 Germany 697 Phone: +49-421-218-63921 698 Email: cabo@tzi.org 700 August Betzler 701 Fundacio i2CAT 702 Mobile and Wireless Internet Group 703 C/ del Gran Capita, 2 704 Barcelona 08034 705 Spain 707 Email: august.betzler@entel.upc.edu 709 Carles Gomez 710 Universitat Politecnica de Catalunya/Fundacio i2CAT 711 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 712 de Castelldefels 713 C/Esteve Terradas, 7 714 Castelldefels 08860 715 Spain 717 Phone: +34-93-413-7206 718 Email: carlesgo@entel.upc.edu 719 Ilker Demirkol 720 Universitat Politecnica de Catalunya/Fundacio i2CAT 721 Departament d'Enginyeria Telematica 722 C/Jordi Girona, 1-3 723 Barcelona 08034 724 Spain 726 Email: ilker.demirkol@entel.upc.edu