idnits 2.17.1 draft-ietf-core-cocoa-00.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 (October 20, 2016) is 2743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: April 23, 2017 Fundacio i2CAT 6 C. Gomez 7 I. Demirkol 8 Universitat Politecnica de Catalunya/Fundacio i2CAT 9 October 20, 2016 11 CoAP Simple Congestion Control/Advanced 12 draft-ietf-core-cocoa-00 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 April 23, 2017. 44 Copyright Notice 46 Copyright (c) 2016 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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 (See Abstract.) 91 Extended rationale for this specification can be found in 92 [I-D.bormann-core-congestion-control] and 93 [I-D.eggert-core-congestion-control], as well as in the minutes of 94 the IETF 84 CoRE WG meetings. 96 1.1. Terminology 98 This specification uses terms from [RFC7252]. In addition, it 99 defines the following terminology: 101 Initiator: The endpoint that sends the message that initiates an 102 exchange. E.g., the party that sends a confirmable message, or a 103 non-confirmable message conveying a request. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119] when they 108 appear in ALL CAPS. These words may also appear in this document in 109 lower case as plain English words, absent their normative meanings. 111 (Note that this document is itself informational, but it is 112 discussing normative statements.) 114 The term "byte", abbreviated by "B", is used in its now customary 115 sense as a synonym for "octet". 117 2. Context 119 In the Vancouver IETF 84 CoRE meeting, a path forward was defined 120 that includes a very simple basic scheme (lock-step with a number of 121 parallel exchanges of 1) in the base specification together with 122 performance-enhancing advanced mechanisms. 124 The present specification is based on the approved text in the 125 [RFC7252] base specification. It is making use of the text that 126 permits advanced congestion control mechanisms and allows them to 127 change protocol parameters, including NSTART and the binary 128 exponential backoff mechanism. Note that Section 4.8 of [RFC7252] 129 limits the leeway that implementations have in changing the CoRE 130 protocol parameters. 132 The present specification also assumes that, outside of exchanges, 133 non-confirmable messages can only be used at a limited rate without 134 an advanced congestion control mechanism (this is mainly relevant for 135 [RFC7641]). It is also intended to address the [RFC5405] guideline 136 about combining congestion control state for a destination; and to 137 clarify its meaning for CoAP using the definition of an endpoint. 139 The present specification does not address multicast or dithering 140 beyond basic retransmission dithering. 142 3. Area of Applicability 144 The present algorithm is intended to be generally applicable. The 145 objective is to be "better" than default CoAP congestion control in a 146 number of characteristics, including achievable goodput for a given 147 offered load, latency, and recovery from bursts, while providing more 148 predictable stress to the network and the same level of safety from 149 catastrophic congestion. It does require three state variables per 150 scope plus the state needed to do RTT measurements, so it may not be 151 applicable to the most constrained devices (class 1 as per 152 [RFC7228]). 154 The scope of each instance of the algorithm in the current set of 155 evaluations has been the five-tuple, i.e., CoAP + endpoint (transport 156 address) for Initiator and Responder. Potential applicability to 157 larger scopes needs to be examined. 159 Aggregate Congestion Control (Appendix A) is not yet supported by 160 research as well as the other algorithms in this specification. Its 161 use is more interesting on the cloud side, where a single CoAP 162 endpoint may need to talk to thousands of other endpoints and may 163 need to control the burstiness of the resulting aggregate traffic. 165 4. Advanced CoAP Congestion Control: RTO Estimation 167 For an initiator that plans to make multiple requests to one 168 destination endpoint, it may be worthwhile to make RTT measurements 169 in order to obtain a better RTO estimation than that implied by the 170 default initial timeout of 2 to 3 s. This is based on the usual 171 algorithms for RTO estimation [RFC6298], with appropriately extended 172 default/base values, as proposed in Section 4.2.1. Note that such a 173 mechanism must, during idle periods, decay RTO estimates that are 174 shorter or longer than the basic RTO estimate back to the basic RTO 175 estimate, until fresh measurements become available again, as 176 proposed in Section 4.3. 178 One important consideration not relevant for TCP is the fact that a 179 CoAP round-trip may include application processing time, which may be 180 hard to predict, and may differ between different resources available 181 at the same endpoint. Also, for communications with networks of 182 constrained devices that apply radio duty cycling, large and variable 183 round-trip times are likely to be observed. Servers will only 184 trigger their early ACKs (with a non-piggybacked response to be sent 185 later) based on the default timers, e.g. after 1 s. A client that 186 has arrived at a RTO estimate shorter than 1 s SHOULD therefore use a 187 larger backoff factor for retransmissions to avoid expending all of 188 its retransmissions in the default interval of 2 to 3 s. A proposal 189 for a mechanism with variable backoff factors is presented in 190 Section 4.2.1. 192 It may also be worthwhile to do RTT estimates not just based on 193 information measured from a single destination endpoint, but also 194 based on entire hosts (IP addresses) and/or complete prefixes (e.g., 195 maintain an RTT estimate for a whole /64). The exact way this can be 196 used to reduce the amount of state in an initiator is for further 197 study. 199 4.1. Blind RTO Estimate 201 The initial RTO estimate for an endpoint is set to 2 seconds (the 202 initial RTO estimate is used as the initial value for both E_weak_ 203 and E_strong_ below). 205 If only the initial RTO estimate is available, the RTO estimate for 206 each of up to NSTART exchanges started in parallel is set to 2 s 207 times the number of parallel exchanges, e.g. if two exchanges are 208 already running, the initial RTO estimate for an additional exchange 209 is 6 seconds. 211 4.2. Measured RTO Estimate 213 The RTO estimator runs two copies of the algorithm defined in 214 [RFC6298], as modified in Section 4.2.1: One copy for exchanges that 215 complete on initial transmissions (the "strong estimator", 216 E_strong_), and one copy for exchanges that have run into 217 retransmissions, where only the first two retransmissions are 218 considered (the "weak estimator", E_weak_). For the latter, there is 219 some ambiguity whether a response is based on the initial 220 transmission or the retransmissions. For the purposes of the weak 221 estimator, the time from the initial transmission counts. Responses 222 obtained after the third retransmission are not used to update an 223 estimator. 225 The overall RTO estimate is an exponentially weighted moving average 226 (alpha = 0.5 and 0.25, respectively) computed of the strong and the 227 weak estimator, which is evolved after each contribution to the weak 228 estimator (1) or to the strong estimator (2), from the estimator that 229 made the most recent contribution: 231 RTO := 0.25 * E_weak_ + 0.75 * RTO (1) 233 RTO := 0.5 * E_strong_ + 0.5 * RTO (2) 235 (Splitting this update into the two cases avoids making the 236 contribution of the weak estimator too big in naturally lossy 237 networks.) 239 4.2.1. Modifications to the algorithm of RFC 6298 241 This subsection presents three modifications that must be applied to 242 the algorithm of [RFC6298] as per this document. The first two 243 recommend new parameter settings. The third one is the variable 244 backoff factor mechanism. 246 The initial value for each of the two RTO estimators is 2 s. 248 For the weak estimator, the factor K (the RTT variance multiplier) is 249 set to 1 instead of 4. This is necessary to avoid a strong increase 250 of the RTO in the case that the RTTVAR value is very large, which may 251 be the case if a weak RTT measurement is obtained after one or more 252 retransmissions. 254 If an RTO estimation is lower than 1 s or higher than 3 s, instead of 255 applying a binary backoff factor in both cases, a variable backoff 256 factor is used. For RTO estimations below 1 s, the RTO for a 257 retransmission is multiplied by 3, while for estimations above 3 s, 258 the RTO is multiplied only by 1.5 (this updated choice of numbers to 259 be verified by more simulations). This helps to avoid that exchanges 260 with small initial RTOs use up all retransmissions in a short 261 interval of time and exchanges with large initial RTOs may not be 262 able to carry out all retransmissions within MAX_TRANSMIT_WAIT 263 (93 s). 265 The binary exponential backoff is truncated at 32 seconds. Similar 266 to the way retransmissions are handled in the base specification, 267 they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO. 269 4.2.2. Discussion 271 In contrast to [RFC6298], this algorithm attempts to make use of 272 ambiguous information from retransmissions. This is motivated by the 273 high non-congestion loss rates expected in constrained node networks, 274 and the need to update the RTO estimators even in the presence of 275 loss. Additional investigation is required to determine whether this 276 is indeed justified. 278 Some evaluation has been done on earlier versions of this 279 specification [Betzler2013]. A more recent (and more comprehensive) 280 reference is [Betzler2015]. Additional investigation is required. 282 4.3. Lifetime, Aging 284 The state of the RTO estimators for an endpoint SHOULD be kept as 285 long as possible. If other state is kept for the endpoint (such as a 286 DTLS connection), it is very strongly RECOMMENDED to keep the RTO 287 state alive at least as long as this other state. It MUST be kept 288 for at least 255 s. 290 If an estimator has a value that is lower than 1 s, and it is left 291 without further update for 16 times its current value, the RTO 292 estimate is doubled. If an estimator has a value that is higher than 293 3 s, and it is left without further update for 4 times its current 294 value, the RTO estimate is set to be 296 RTO := 1 s + (0.5 * RTO) 298 (Note that, instead of running a timer, it is possible to implement 299 these RTO aging calculations cumulatively at the time the estimator 300 is used next.) 302 5. Advanced CoAP Congestion Control: Non-Confirmables 304 A CoAP endpoint MUST NOT send non-confirmables to another CoAP 305 endpoint at a rate higher than defined by this document. Independent 306 of any congestion control mechanisms, a CoAP endpoint can always send 307 non-confirmables if their rate does not exceed 1 B/s. 309 Non-confirmables that form part of exchanges are governed by the 310 rules for exchanges. 312 Non-confirmables outside exchanges (e.g., [RFC7641] notifications 313 sent as non-confirmables) are governed by the following rules: 315 1. Of any 16 consecutive messages towards this endpoint that aren't 316 responses or acknowledgments, at least 2 of the messages must be 317 confirmable. 319 2. The confirmable messages must be sent under an RTO estimator, as 320 specified in Section 4. 322 3. The packet rate of non-confirmable messages cannot exceed 1/RTO, 323 where RTO is the overall RTO estimator value at the time the non- 324 confirmable packet is sent. 326 5.1. Discussion 328 This is relatively conservative. More advanced versions of this 329 algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348] 330 and apply the TCP equation to achieve a higher rate than 1/RTO. 332 [RFC7641], Section 4.5.1, specifies that the rate of NONs SHOULD NOT 333 exceed 1/RTT on average, if the server can maintain an RTT estimate 334 for a client. CoCoA limits the packet rate of NONs in this situation 335 to 1/RTO. Assuming that the RTO estimation in CoCoA works as 336 expected, RTO[k] should be slightly greater than the RTT[k], thus 337 CoCoA would be more conservative. The expectation therefore is that 338 complying with the NON rate set by CoCoA leads to complying with 339 [RFC7641]. 341 6. IANA Considerations 343 This document makes no requirements on IANA. (This section to be 344 removed by RFC editor.) 346 7. Security Considerations 348 (TBD. The security considerations of, e.g., [RFC5681], [RFC2914], 349 and [RFC5405] apply. Some issues are already discussed in the 350 security considerations of [RFC7252].) 352 8. References 354 8.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 362 RFC 2914, DOI 10.17487/RFC2914, September 2000, 363 . 365 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 366 for Application Designers", BCP 145, RFC 5405, 367 DOI 10.17487/RFC5405, November 2008, 368 . 370 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 371 "Computing TCP's Retransmission Timer", RFC 6298, 372 DOI 10.17487/RFC6298, June 2011, 373 . 375 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 376 Application Protocol (CoAP)", RFC 7252, 377 DOI 10.17487/RFC7252, June 2014, 378 . 380 8.2. Informative References 382 [Betzler2013] 383 Betzler, A., Gomez, C., Demirkol, I., and J. Paradells, 384 "Congestion control in reliable CoAP communication", 385 ACM MSWIM'13 p. 365-372, DOI 10.1145/2507924.2507954, 386 2013. 388 [Betzler2015] 389 Betzler, A., Gomez, C., Demirkol, I., and J. Paradells, 390 "CoCoA+: an Advanced Congestion Control Mechanism for 391 CoAP", Ad Hoc Networks Vol. 33 pp. 126-139, 392 DOI 10.1016/j.adhoc.2015.04.007, October 2015. 394 [I-D.bormann-core-congestion-control] 395 Bormann, C. and K. Hartke, "Congestion Control Principles 396 for CoAP", draft-bormann-core-congestion-control-02 (work 397 in progress), July 2012. 399 [I-D.eggert-core-congestion-control] 400 Eggert, L., "Congestion Control for the Constrained 401 Application Protocol (CoAP)", draft-eggert-core- 402 congestion-control-01 (work in progress), January 2011. 404 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 405 Friendly Rate Control (TFRC): Protocol Specification", 406 RFC 5348, DOI 10.17487/RFC5348, September 2008, 407 . 409 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 410 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 411 . 413 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 414 Constrained-Node Networks", RFC 7228, 415 DOI 10.17487/RFC7228, May 2014, 416 . 418 [RFC7641] Hartke, K., "Observing Resources in the Constrained 419 Application Protocol (CoAP)", RFC 7641, 420 DOI 10.17487/RFC7641, September 2015, 421 . 423 Appendix A. Advanced CoAP Congestion Control: Aggregate Congestion 424 Control 426 (The mechanism defined in this appendix has received less research 427 than the ones in the main body of this specification.) 429 A.1. Proposed Algorithm 431 To avoid possible congestion when sending many packets to different 432 destination endpoints in parallel, the overall number of outstanding 433 interactions towards different destination endpoints should be 434 limited. An upper limit PLIMIT determines the maximum number of 435 outstanding interactions towards different destination endpoints that 436 are allowed in parallel. When a request is to be sent to a 437 destination endpoint, PLIMIT is determined according to Equation (3) 438 in the case that no RTO information is already available for the 439 destination endpoint, or using Equation (4) in case that valid RTO 440 information is available for the destination endpoint. Both formulas 441 use LAMBDA, as defined in Equation (5). 443 PLIMIT = LAMBDA (3) 445 PLIMIT = max(LAMBDA, LAMBDA*ACK_TIMEOUT/mean(RTO)) (4) 447 LAMBDA = max(4, KNOWN_DEST_ENDPOINTS/4) (5) 449 mean(RTO) is the average value of all valid RTO estimations 450 maintained by the device. LAMBDA is the maximum of a constant value 451 (4 by default) and the rounded up value of KNOWN_DEST_ENDPOINTS/4 , 452 where KNOWN_DEST_ENDPOINTS is the overall number of "known" 453 destination endpoints (i.e. destination endpoints for which an RTO 454 estimate is maintained). 456 A new interaction may only be processed if the current overall number 457 of outstanding interactions is lower than the PLIMIT calculated when 458 the request is initiated. 460 A.2. Example 1 462 In the following we give an example, with LAMBDA = 4 (our proposed 463 default LAMBDA): 465 Assume that a sender has so far obtained RTO estimations for two 466 destination endpoints A (RTO = 0.5 s) and B (RTO = 1.5 s), and 467 currently pcount (a variable which accounts for the number of 468 outstanding interactions towards endpoints) is equal to 0. Now three 469 transactions are initiated consecutively in the following order: one 470 for A, one for B and one for a new destination C. 472 When an interaction with node A is initiated, LAMBDA is calculated 474 LAMBDA = max(4, 3/4) = 4. 476 Then PLIMIT is calculated: 478 PLIMIT = max(4, (4*2 s)/mean(0.5 s, 1.5 s)) = max (4, 8 s/1 s) = 479 max (4, 8) = 8 481 This means that with the current RTO information the sender has 482 obtained about the destination endpoints, up to 8 outstanding 483 interactions to different destination endpoints would be allowed. By 484 initiating an interaction with A, pcount is increased to 1, which is 485 still below PLIMIT. Thus, the interaction may be processed. The 486 same applies to B: pcount increases to 2 after obtaining the same 487 PLIMIT value of 8. 489 Destination C is unknown to CoCoA, therefore the updated PLIMIT 490 before processing the interaction with node C is 4. The CoAP request 491 may be processed (pcount = 3). If two more interactions with 492 different unknown destination endpoints would have been initiated, 493 only the first one would have met the requirements to process it 494 (PLIMIT = 4, pcount = 4). The second interaction would have 495 increased pcount to 5, which is not permitted, since PLIMIT is 4. It 496 may occur that pcount exceeds PLIMIT in particular cases, in this 497 case, the interaction is not permitted as well. If the number of 498 destinations exchanges are initiated with would increase further, 499 eventually LAMBDA could grow beyond 4, allowing for more interactions 500 to be sent in parallel. 502 A.3. Example 2 504 Let us now assume that a sender has so far obtained RTO estimations 505 for 101 destination endpoints, their average RTO is 1 s, and 506 currently pcount is equal to 0. When a new transaction is initiated 507 with a destination endpoint for which an RTO estimate is available, 508 LAMBDA is calculated 510 LAMBDA = max(4, 101/4) = 26 512 Based on this, PLIMIT is calculated as follows: 514 PLIMIT= max(26, (26*2 s)/1 s) = max (26, 52) = 52 516 This means that with the current RTO information that the sender has 517 obtained about the destination endpoints, up to 52 outstanding 518 interactions to known destination endpoints would be allowed. 520 However, if the new exchange is to be initiated with an "unknown" 521 destination endpoint (i.e. an endpoint for which an RTO estimate is 522 not available), then PLIMIT would be 26. 524 A.4. Discussion 526 The idea of the proposal is to allow more parallel transactions to 527 different destination endpoints if we have low RTO estimations for 528 them (which can be interpreted as good connections and low degree of 529 congestion). If the RTO estimations are large or interactions with 530 unknown destinations are initiated, the mechanism behaves more 531 conservatively by reducing the maximum number of parallel 532 interactions towards different destinations, but allowing at least 533 LAMBDA outstanding interactions. The second term of the max() 534 statement used to calculate LAMBDA avoids behaving too restrictively 535 when exchanges with many different destination endpoints are 536 initiated. If no RTO information is available for a destination 537 endpoint, PLIMIT is simply set to be LAMBDA. 539 If at any moment pcount would exceed PLIMIT, CoAP does not 540 immediately perform the transaction. Further, it is important that 541 in parallel, NSTART for each destination endpoint applies (which, for 542 now, we assume to be 1). The default value used for LAMBDA (equal to 543 4 as per this document) determines how aggressive/conservative CoCoA 544 behaves by default for a limited set of destination endpoints and it 545 should be chosen carefully. The term KNOWN_DEST_ENDPOINTS/4 loosens 546 the hard limit of exchanges when large numbers of destination 547 endpoints are addressed. 549 It will be necessary to see whether this approach is effective in the 550 sense that it avoids congestion in use cases where transactions to a 551 multitude of different destination endpoints are initiated. An 552 important aspect of such evaluations would be whether LAMBDA is too 553 conservative when dealing with few destination endpoints and whether 554 it allows for a dynamic adjustment of parallel exchanges with large 555 numbers of destination endpoints. On the other hand, a more safe 556 approach would use max(RTO) instead of mean(RTO). Other concerns 557 include the fact that the congestion degree of the paths to "known" 558 destination endpoints influence whether a new interaction is 559 permitted to some new endpoint which may be in very different 560 conditions in terms of congestion. However, it is desirable to avoid 561 adding a lot of complexity to the current CoCoA mechanisms. 563 Acknowledgements 565 The first document to examine CoAP congestion control issues in 566 detail was [I-D.eggert-core-congestion-control], to which this draft 567 owes a lot. 569 Michael Scharf did a review of CoAP congestion control issues that 570 asked a lot of good questions. Several Transport Area 571 representatives made further significant inputs this discussion 572 during IETF84, including Lars Eggert, Michael Scharf, and David 573 Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset, 574 Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided 575 very useful additions. 577 Authors from Universitat Politecnica de Catalunya have been supported 578 in part by the Spanish Government's Ministerio de Economia y 579 Competitividad through projects TEC2009-11453 and TEC2012-32531, and 580 FEDER. 582 Carles Gomez has been funded in part by the Spanish Government 583 (Ministerio de Educacion, Cultura y Deporte) through the Jose 584 Castillejo grant CAS15/00336. His contribution to this work has been 585 carried out in part during his stay as a visiting scholar at the 586 Computer Laboratory of the University of Cambridge, in collaboration 587 with Prof. Jon Crowcroft. 589 Authors' Addresses 591 Carsten Bormann 592 Universitaet Bremen TZI 593 Postfach 330440 594 Bremen D-28359 595 Germany 597 Phone: +49-421-218-63921 598 Email: cabo@tzi.org 600 August Betzler 601 Fundacio i2CAT 602 Mobile and Wireless Internet Group 603 C/ del Gran Capita, 2 604 Barcelona 08034 605 Spain 607 Email: august.betzler@entel.upc.edu 608 Carles Gomez 609 Universitat Politecnica de Catalunya/Fundacio i2CAT 610 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 611 de Castelldefels 612 C/Esteve Terradas, 7 613 Castelldefels 08860 614 Spain 616 Phone: +34-93-413-7206 617 Email: carlesgo@entel.upc.edu 619 Ilker Demirkol 620 Universitat Politecnica de Catalunya/Fundacio i2CAT 621 Departament d'Enginyeria Telematica 622 C/Jordi Girona, 1-3 623 Barcelona 08034 624 Spain 626 Email: ilker.demirkol@entel.upc.edu