idnits 2.17.1 draft-bormann-core-congestion-control-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 31, 2012) is 4288 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 (-21) exists of draft-ietf-core-block-08 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-11 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-20 == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-initcwnd-04 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft K. Hartke 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: February 1, 2013 July 31, 2012 7 Congestion Control Principles for CoAP 8 draft-bormann-core-congestion-control-02 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. Congestion 14 control is a complex issue -- the proper rationale for the congestion 15 control mechanisms chosen in CoAP is probably more material than the 16 CoAP protocol specification itself. This informational document 17 attempts to pull out the background material and more extensive 18 considerations behind the CoAP congestion control mechanisms, while 19 leaving the basic MUSTs and MUST NOTs in the main spec. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 1, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2.1. TCP-Friendliness . . . . . . . . . . . . . . . . . . . 4 59 1.2.2. Actually working well . . . . . . . . . . . . . . . . 4 60 1.2.3. Getting actual implementation . . . . . . . . . . . . 5 61 2. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. RFC 2914 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. RFC 5405 . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. draft-eggert-core-congestion-control . . . . . . . . . . . 7 65 3. coap-11 Congestion Control Principles . . . . . . . . . . . . 8 66 4. How do other protocols do it . . . . . . . . . . . . . . . . . 11 67 4.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Advanced CoAP Congestion Control . . . . . . . . . . . . . . . 14 72 5.1. RTT Measurement . . . . . . . . . . . . . . . . . . . . . 14 73 5.2. Block Slow-Start . . . . . . . . . . . . . . . . . . . . . 14 74 6. Changes Planned for Base Specifications . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 With few exceptions, it is simply incompetent to build an 86 implementation of a packet-based protocol without considering 87 congestion control. Unfortunately, detailed, evidence-based 88 knowledge about congestion control is limited to a small group of 89 people. It has become customary for these to try to encode their 90 knowledge into the protocol definitions, in an attempt to replace 91 competence by conformance. 93 This has worked relatively well for TCP, not the least because the 94 art of TCP implementation is itself limited to a rather small group 95 of experts, which over the years often have acquired some knowledge 96 of congestion control principles, complementing the desire for 97 conformance by substantial competence again. Conversely, application 98 developers are a much larger, much more diverse group. Worse, 99 protocol complexity for which the rationale is not apparent to the 100 developers might simply not be implemented. Giving congestion- 101 unaware developers UDP sockets that are not protected by TCP's 102 congestion control may lead to disasters. 104 With this background, an application protocol that is threatening to 105 be widely deployed and does not rely on the built-in congestion 106 control properties of TCP presents a serious worry. 108 This document attempts to present a more extensive rationale for 109 CoAP's minimal, but effective congestion control design, as well as 110 some updates to it. This rationale is not included in 111 [I-D.ietf-core-coap] or [I-D.ietf-core-observe] as the specification 112 is threatening to become too long with all the rationale and 113 implementation considerations discussion already included. While the 114 present document discusses normative statements, it is not intended 115 to supplement or replace the normative statements in 116 [I-D.ietf-core-coap] and [I-D.ietf-core-observe], but just to provide 117 additional explanation. 119 ((Editorial note: the updates to the mandates discussed here 120 partially still need to make it into the next version of 121 [I-D.ietf-core-coap]. A summary of the updates needed is in 122 Section 6.)) 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119] when they 129 appear in ALL CAPS. These words may also appear in this document in 130 lower case as plain English words, absent their normative meanings. 132 (Note that this document is itself informational, but it is 133 discussing normative statements.) 135 The term "byte" is used in its now customary sense as a synonym for 136 "octet". 138 1.2. Objectives 140 The objectives of adding congestion control to the CoAP protocol 141 specification can be on two different levels, with one additional 142 (third) consideration. 144 1.2.1. TCP-Friendliness 146 Much of the knowledge that the IETF has accumulated on congestion 147 control focuses on not being worse than its flagship transport 148 protocol, TCP, and being "fair" to instances of TCP competing for 149 capacity. Since fairness is not really a well-defined term, we 150 reduce it to "friendliness". 152 One objective of this document is to discuss how CoAP can be employed 153 in a TCP-friendly way, and what are the minimum mandates the protocol 154 needs to make in order to ensure this for reasonable applications. 156 (Note that TCP itself is not TCP-friendly when abused, e.g., when 157 opening 10000 connections in close succession; so there will be no 158 attempt to stay TCP-friendly when CoAP is abused, either.) 160 Conclusion: CoAP needs to be TCP-friendly, but probably not more so 161 than TCP itself. 163 1.2.2. Actually working well 165 Making sure that the network continues to work well in the presence 166 of a strong deployment of active CoAP endpoints is a much harder 167 objective to achieve. There is only limited knowledge about the 168 characteristics of the constrained node/networks CoAP will be used 169 in. They might exhibit congestion in surprising ways. 171 It may turn out the collected wisdom that has been derived from TCP 172 deployment experience in the mostly browser-oriented Internet does 173 not transfer to the Internet of Things, and that we need to invent 174 new mechanisms for the latter. 176 But this is research. 178 Imposing the need for a completed solution that meets requirements 179 entirely unknown at this time would be an instance of the Fallacy of 180 Perfection [GF]. 182 We will need to accumulate additional knowledge, on a research basis, 183 and with experience coming in from larger CoAP deployments. One 184 likely outcome is that constrained node/networks will simply continue 185 to evolve to be able to cope with TCP and CoAP. 187 Conclusion: For now, we will focus on staying safe where TCP would 188 have stayed safe. 190 1.2.3. Getting actual implementation 192 The protocol specification may specify whatever it wants; if there is 193 significant complexity in implementing a mandate and the rationale is 194 not apparent for implementers, compliance will be but a lucky 195 coincidence - even more so in implementations for highly constrained 196 systems. A design that achieves stable operation outside 197 pathological situations and is implemented is preferable to a 198 picture-perfect design that is a beautiful part of the specification 199 and then ignored. 201 Binding the inevitable complexity of a congestion control scheme to 202 mechanisms that already have to be implemented for other functional 203 reasons seems the most fruitful approach for obtaining compliance. 204 This consideration, together with the main design objective of CoAP - 205 being implementable on constrained nodes and networks - has been the 206 overriding design objective. 208 2. Input 210 The word "congestion" occurs more than a hundred times in 1id- 211 abstracts.txt, indicating that there is a lot of documents under 212 construction that might become relevant to this document. We select 213 a few existing documents here and pick up a few salient points. 215 2.1. RFC 2914 217 [RFC2914], "Congestion Control Principles", is the BCP that lays out 218 the basic principles for congestion control in the Internet. While 219 it does allude to non-TCP protocols, it mainly focuses on TCP and 220 TCP-like behavior. 222 2.2. RFC 5405 224 [RFC5405], "Unicast UDP Usage Guidelines for Application Designers", 225 makes additional points for the usage of UDP. It is also a BCP 226 document. Its considerations have mostly been made without looking 227 at specific application protocols, and with a view to guiding 228 application protocol developers towards congestion-controlled 229 transport protocols (which is unfortunately not an appropriate choice 230 for CoAP). It does consider the case of low data-volume applications 231 (section 3.1.2 is therefore the most relevant section for this 232 document). It clearly needs to be interpreted intelligently in order 233 to arrive at congestion control guidelines for a new application 234 protocol. E.g., it recommends: 236 Applications that at any time exchange only a small number of UDP 237 datagrams with a destination SHOULD still control their 238 transmission behavior by not sending on average more than one UDP 239 datagram per round-trip time (RTT) to a destination. 241 Instead, a CoAP client that does receive a response without the need 242 for a retransmission should be able to send an ensuing request right 243 away, without the need to do any such rate control -- this keeps the 244 spirit, but not the letter of that requirement. 246 While [RFC5405] does provide a good set of "don't forget" points, 247 some of its requirements appear to attempt to err on the side of 248 caution, without regards to the specific characteristics of an 249 application. Fortunately, these requirements are often phrased as a 250 SHOULD, so it is possible to explain when and why they should not be 251 heeded. 253 2.3. draft-eggert-core-congestion-control 255 [I-D.eggert-core-congestion-control], "Congestion Control for the 256 Constrained Application Protocol (CoAP)", was the original document 257 that led to CoAP's congestion control design. This document provides 258 good historical context and should be read in conjunction with the 259 present document. However, the "credit-based" mechanism proposed in 260 its section 3.2 is probably too complicated to be implemented in 261 constrained nodes; CoAP now uses a simpler algorithm that uses the 262 information the implementation already has to keep (i.e., it is based 263 on limiting the outstanding exchanges). 265 3. coap-11 Congestion Control Principles 267 CoAP is a protocol that attempts to minimize the complexity of its 268 implementation. It is mainly intended for interactions that are not 269 really flow-shaped, so traditional congestion control mechanisms 270 simply do not have useful information to work on. 272 Basic CoAP [I-D.ietf-core-coap] uses a strict lock-step protocol for 273 its requests and responses (both on the reliability layer with CON/ 274 ACK and one level higher with requests and responses), with 275 exponential back-off in case of non-delivery. The initial timeout is 276 dithered between 2 and 3 seconds and grows up to between 32 and 48 277 seconds. 279 This is inherently TCP-friendly, similar to the way protocols like 280 DNS operate. 282 [I-D.ietf-core-coap] goes on to require: 284 In order not to cause congestion, Clients (including proxies) 285 SHOULD strictly limit the number of simultaneous outstanding 286 interactions that they maintain to a given server (including 287 proxies). An outstanding interaction is either a CON for which an 288 ACK has not yet been received but is still expected (message 289 layer) or a request for which a response has not yet been received 290 but is still expected (which may both occur at the same time, 291 counting as one outstanding interaction). A good value for this 292 limit is the number 1. (Note that [RFC2616], in trying to achieve 293 a similar objective, did specify a specific number of simultaneous 294 connections as a ceiling. While revising [RFC2616], this was 295 found to be impractical for many applications 296 [I-D.ietf-httpbis-p1-messaging]. For the same considerations, 297 this specification does not mandate a particular maximum number of 298 outstanding interactions, but instead encourages clients to be 299 conservative when initiating interactions.) 301 The rationale for this design is that it is very easy to implement 302 for a constrained device: a constrained device will already have a 303 hard limit on the number of slots available for initiating 304 transactions. Similarly, even back-end systems already need to bind 305 state to outstanding transactions; adding some form of congestion 306 control state to these does not require maintaining new objects, just 307 new fields. In any case, having some form of limit is not elective: 308 in the text the SHOULD needs to be changed into a MUST, even though 309 it may not be easy to pinpoint the exact criterion for compliance. 311 In the following, we refer to the initiator parameter that limits the 312 number of outstanding interactions as NSTART. 314 Clients SHOULD also heed this [RFC5405] guideline: 316 an application SHOULD perform congestion control over all UDP 317 traffic it sends to a destination, independently from how it 318 generates this traffic. For example, an application that forks 319 multiple worker processes or otherwise uses multiple sockets to 320 generate UDP datagrams SHOULD perform congestion control over the 321 aggregate traffic. 323 Note that [RFC5405] is not explicit here with respect to what it 324 considers to be a "destination"; it also uses the term "destination 325 host" when it appears to provide specific discussion about all 326 protocol entities at an IP address. [RFC5405] duly notes the failure 327 of the congestion manager approach [RFC3124], but appears to wish it 328 back into existence. For the purposes of CoAP, probably 329 "destination" here should be used as with the CoAP term destination 330 endpoint (i.e., including the UDP port number). Still, an 331 implementation that e.g. uses a new source port per request (i.e. a 332 new source endpoint, which is a valid strategy) probably needs to 333 heed this SHOULD for the entirety of the combination of its own 334 endpoint abstractions. 336 For certain exchanges in CoAP, there is a chance that a request would 337 never elicit a response (e.g., due to a crashed server) but there is 338 also no (protocol) timeout governing this exchange. Therefore, the 339 count of outstanding interactions needs to decay at some rate; a 340 decay rate below that at which TCP sends to a very lossy channel 341 (e.g., 7 B/s) should be safe. 343 There are also some special congestion control considerations with 344 responses to multicast requests, see [I-D.ietf-core-coap] section 345 4.5; servers are expected to provide estimates for group size and a 346 target rate as well as a response size. Where those estimates are 347 hard to come up with, a default response dithering window of 10 348 seconds should be added to [I-D.ietf-core-coap], as well an 349 admonition for a client not to use multicast requests when such a 350 default window would be way off. Finally, a server that receives 351 another multicast request within the dithering window for a request 352 that it already is answering SHOULD move the dithering window for its 353 next response to after the first dithering window. 355 Finally, the text in [I-D.ietf-core-coap] needs to be reviewed 356 whether it always clearly separates the discussion for avoiding 357 network congestion from any mechanisms for avoiding server 358 overloading. 360 [I-D.ietf-core-observe] adds one additional behavior: servers may 361 send NON messages as notifications for state changes, which is 362 outside of exchanges that would be governed by NSTART. This 363 functionality needs to be supported with some discussion of 364 congestion control. Generally, servers SHOULD NOT send more than one 365 NON message every 3 seconds on average ([RFC5405] section 3.1.2), and 366 they SHOULD NOT send NON messages while waiting for CON messages to 367 be acknowledged (however, CON retransmissions should send the new 368 resource state if it has changed since, see [I-D.ietf-core-observe] 369 section 4.5). There already was a decision to add a requirement to 370 require sending a CON message at least every 24 hours before 371 continuing with NON messages; probably the parameter of no more than 372 a NON per 3 seconds should be increased for servers that check the 373 client that rarely (e.g., to the rate at which TCP sends into a very 374 lossy channel, e.g., 7 B/s). 376 4. How do other protocols do it 378 While CoAP congestion control could be designed from first 379 principles, it is maybe more realistic to have a look at how other 380 protocols address its respective version of the problem. 382 4.1. DNS 384 The DNS protocol, which in many characteristics is quite close to 385 CoAP, does not have any explicit mechanisms for congestion control at 386 all. Many documents consider DNS to be "sporadic messages", not 387 worth of congestion control. 389 [RFC4336] says: 391 (The short flows generated by request-response applications, such 392 as DNS and SNMP, don't cause congestion in practice, and any 393 congestion control mechanism would take effect between flows, not 394 within a single end- to-end transfer of information.) 396 (This simple packet-for-packet request-response nature is now 397 changing a bit with DNS being used for voluminous keying information 398 and growing TXT records.) 400 4.2. SIP 402 SIP uses a 0.5 s initial timeout (T1 "RTT Estimate"), and uses binary 403 exponential increase after that. That is similar to CoAP, but starts 404 from a smaller initial estimate. CoAP is more conservative (initial 405 RESPONSE_TIMEOUT is 2 s to 3 s) as we expect latencies in constrained 406 networks to be higher than in the networks used for telephony. 408 4.3. TCP 410 A well-known problem with relying on TCP's built-in congestion 411 control is that, even with all congestion-control mechanisms in 412 place, simply multiplying the number of instances may lead to 413 eventual congestion. 415 About a decade ago, TCP has increased its initial congestion window 416 (IW) to about 3 full-size packets, or up to 4 packets with MSS <= 417 1095 bytes (which is comparable to CoAP's maximum packet sizes) 418 [RFC3390]. As an Experimental specification, moving to an IW of 10 419 packets (IW10) is being examined [I-D.ietf-tcpm-initcwnd]. A related 420 change is also planned in that document that will avoid resetting 421 this initial window when the SYN or SYN/ACK is lost. This would mean 422 that it is considered appropriate to send about 15 kB of data on a 423 single connection without any congestion control feedback whatsoever, 424 except that some SYN+SYN/ACK exchange made it through. While 425 [I-D.ietf-tcpm-initcwnd] is not yet approved, it is a WG document and 426 there is widespread feeling of its inevitability even beyond the 427 experimental status that is being planned now. 429 The numbers 3, 4, and 10 clearly provide some additional context for 430 the selection of appropriate values of NSTART. 432 Conclusion: For now, it is probably appropriate to RECOMMEND keeping 433 NSTART at or below a value chosen from the space between 3 and 10. 435 4.4. HTTP 437 HTTP is running on top of TCP, so it is TCP-friendly by definition. 438 However, as HTTP 1.0 was using one TCP connection per request, and it 439 became clear that browser usage would entail fetching many objects in 440 parallel, congestion was still observed, and client implementations 441 started to limit the number of simultaneously active connections to 442 one server. Even when persistent connections were added (and later 443 codified in HTTP 1.1) this remained a concern. Under 8.1.4 444 "Practical considerations", [RFC2616] defines a limit on the number 445 of simultaneous connections from one client to one server. 447 Clients that use persistent connections SHOULD limit the number of 448 simultaneous connections that they maintain to a given server. A 449 single-user client SHOULD NOT maintain more than 2 connections 450 with any server or proxy. A proxy SHOULD use up to 2*N 451 connections to another server or proxy, where N is the number of 452 simultaneously active users. These guidelines are intended to 453 improve HTTP response times and avoid congestion. 455 Intended as a guideline, this has been implemented to the letter in 456 browser clients for a decade. However, using this as a hard limit is 457 simply not appropriate for all environments. This led server 458 implementers to widely deploy workarounds, such as splitting up a 459 website between multiple servers ("domain sharding") in order to 460 increase the connection concurrency. 462 From this historical evidence we can learn that well-meaning 463 limitations can cause a lot of pain when implemented slavishly. The 464 httpbis effort has learned this lesson and removed the suggestion for 465 a hard limit (see [HTTPBISt131], [HTTPBISc715]). Note that it now 466 says: 468 Clients (including proxies) SHOULD limit the number of 469 simultaneous connections that they maintain to a given server 470 (including proxies). 472 Previous revisions of HTTP gave a specific number of connections 473 as a ceiling, but this was found to be impractical for many 474 applications. As a result, this specification does not mandate a 475 particular maximum number of connections, but instead encourages 476 clients to be conservative when opening multiple connections. 478 In particular, while using multiple connections avoids the 479 "head-of- line blocking" problem (whereby a request that takes 480 significant server-side processing and/or has a large payload can 481 block subsequent requests on the same connection), each connection 482 used consumes server resources (sometimes significantly), and 483 furthermore using multiple connections can cause undesirable side 484 effects in congested networks. 486 Note that servers might reject traffic that they deem abusive, 487 including an excessive number of connections from a client. 489 Conclusion: There is no doubt that CoAP should follow this hard- 490 learned expertise. 492 5. Advanced CoAP Congestion Control 494 5.1. RTT Measurement 496 For an initiator that plans to make multiple requests to one 497 destination end-point, it may be worthwhile to make RTT measurements 498 in order to obtain a better RTT estimation than that implied by the 499 default initial timeout of 2 to 3 s. The usual algorithms for RTT 500 estimation can be used [RFC6298], with appropriately extended 501 default/base values. Note that such a mechanism MUST, during idle 502 periods, decay RTT estimates that are shorter than the basic RTT 503 estimate back to the basic RTT estimate, until fresh measurements 504 become available again. 506 One important consideration not relevant for TCP is the fact that a 507 CoAP round-trip may include application processing time, which may be 508 hard to predict, and may differ between different resources available 509 at the same endpoint. Servers will only trigger early ACKs (with a 510 non-piggybacked response to be sent later) based on the default 511 timers, e.g. after 1 s. A client that has arrived at a RTT estimate 512 much shorter than the 2 to 3 s used as a default SHOULD therefore not 513 expend all of its retransmissions in the shorter estimated timescale. 515 It may also be worthwhile to do RTT estimates not just based on 516 information measured from a single destination endpoint, but also 517 based on entire hosts (IP addresses) and/or complete prefixes (e.g., 518 maintain an RTT estimate for a whole /64). The exact way this can be 519 used to reduce the amount of state in an initiator is for further 520 study. 522 5.2. Block Slow-Start 524 The CoAP protocol is not optimized for making good use of available 525 network capacity; given a good offered load, a lightly-loaded network 526 and some time, a TCP connection will always overtake a series of CoAP 527 requests. 529 However, the [I-D.ietf-core-block] protocol can be used by inventive 530 clients to emulate TCP slow start. E.g., a client can do a request 531 for block 0, and, if a response comes back without a loss, it can 532 fire off the requests for block 1 and block 2 at the same time, etc., 533 using each response in a similar way that TCP would clock its data 534 segments based on ACKs, waiving NSTART. Similar approaches may work 535 to increase channel utilization for any other REST usage that 536 requires multiple requests. 538 Clearly, the slow start period MUST terminate on the first loss/ 539 retransmission. How exactly the congestion window is to be 540 maintained after that (a "congestion avoidance period" for CoAP) is a 541 subject for further study. See also [I-D.mathis-tcpm-tcp-laminar] 542 for fresh approaches to maintaining the necessary variables in TCP. 543 Another alternative would be an implementation that emulates 544 [RFC5348]. 546 6. Changes Planned for Base Specifications 548 [I-D.ietf-core-coap]: 550 1. Change SHOULD in second paragraph of [I-D.ietf-core-coap] 4.7 to 551 MUST; define protocol parameter NSTART. 553 2. Add reference to (and/or cite) [RFC5405] guideline about 554 combining congestion control state for a destination; clarify its 555 meaning for CoAP using the definition of an endpoint. 557 3. Add a mechanism of decaying outstanding transactions at a rate of 558 about 7 B/s. 560 4. Add default "Leisure" (response dithering windows) of 10 seconds 561 to [I-D.ietf-core-coap] 8.2, as well as n admonition for a client 562 not to use multicast requests when such a default window would be 563 way off. 565 [I-D.ietf-core-observe]: 567 1. servers SHOULD NOT send more than one NON notification every 3 568 seconds to an endpoint on average ([RFC5405] section 3.1.2); 569 define protocol parameter MAXNONRATE. 571 2. servers SHOULD NOT send NON messages while waiting for CON 572 messages to be acknowledged (however, CON retransmissions should 573 send the new resource state if it has changed since, see 574 [I-D.ietf-core-observe] section 4.5). 576 3. require sending a CON message at least every 24 hours before 577 continuing with NON messages. 579 4. consider increasing MAXNONRATE for servers that check the client 580 that rarely (e.g., to the rate at which TCP sends into a very 581 lossy channel, e.g., 7 B/s). 583 Additional changes have been made to limit the leeway that 584 implementations have in changing the CoRE protocol parameters; these 585 changes are already gathered in Section 4.8 of [I-D.ietf-core-coap] 586 and will not be repeated here. 588 7. IANA Considerations 590 This document makes no requirements on IANA. (This section to be 591 removed by RFC editor.) 593 8. Security Considerations 595 (TBD. The security considerations of, e.g., [RFC2581], [RFC2914], 596 and [RFC5405] apply. Some issues are already discussed in the 597 security considerations of [I-D.ietf-core-coap].) 599 9. Acknowledgements 601 The first document to examine CoAP congestion control issues in 602 detail was [I-D.eggert-core-congestion-control], to which this draft 603 owes a lot. 605 Michael Scharf did a review of CoAP congestion control issues that 606 asked a lot of good questions that this draft attempts to answer. 608 10. References 610 10.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 616 RFC 2914, September 2000. 618 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 619 for Application Designers", BCP 145, RFC 5405, 620 November 2008. 622 10.2. Informative References 624 [GF] Bormann, C., "Garrulity and Fluff", IAB Smart Object 625 Workshop, 2011, . 628 [HTTPBISc715] 629 "Changeset 715", October 2009, 630 . 633 [HTTPBISt131] 634 "increase connection limit", HTTPBIS ticket #131, closed 635 2009-12-02, September 2008, 636 . 638 [I-D.eggert-core-congestion-control] 639 Eggert, L., "Congestion Control for the Constrained 640 Application Protocol (CoAP)", 641 draft-eggert-core-congestion-control-01 (work in 642 progress), January 2011. 644 [I-D.ietf-core-block] 645 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 646 draft-ietf-core-block-08 (work in progress), 647 February 2012. 649 [I-D.ietf-core-coap] 650 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 651 "Constrained Application Protocol (CoAP)", 652 draft-ietf-core-coap-11 (work in progress), July 2012. 654 [I-D.ietf-core-observe] 655 Hartke, K., "Observing Resources in CoAP", 656 draft-ietf-core-observe-05 (work in progress), March 2012. 658 [I-D.ietf-httpbis-p1-messaging] 659 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 660 1: Message Routing and Syntax"", 661 draft-ietf-httpbis-p1-messaging-20 (work in progress), 662 July 2012. 664 [I-D.ietf-tcpm-initcwnd] 665 Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 666 "Increasing TCP's Initial Window", 667 draft-ietf-tcpm-initcwnd-04 (work in progress), June 2012. 669 [I-D.mathis-tcpm-tcp-laminar] 670 Mathis, M., "Laminar TCP and the case for refactoring TCP 671 congestion control", draft-mathis-tcpm-tcp-laminar-01 672 (work in progress), July 2012. 674 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 675 Control", RFC 2581, April 1999. 677 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 678 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 679 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 681 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 682 RFC 3124, June 2001. 684 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 685 Initial Window", RFC 3390, October 2002. 687 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 688 for the Datagram Congestion Control Protocol (DCCP)", 689 RFC 4336, March 2006. 691 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 692 Friendly Rate Control (TFRC): Protocol Specification", 693 RFC 5348, September 2008. 695 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 696 "Computing TCP's Retransmission Timer", RFC 6298, 697 June 2011. 699 Authors' Addresses 701 Carsten Bormann 702 Universitaet Bremen TZI 703 Postfach 330440 704 Bremen D-28359 705 Germany 707 Phone: +49-421-218-63921 708 Email: cabo@tzi.org 710 Klaus Hartke 711 Universitaet Bremen TZI 712 Postfach 330440 713 Bremen D-28359 714 Germany 716 Phone: +49-421-218-63905 717 Email: hartke@tzi.org