idnits 2.17.1 draft-jarvinen-core-fasor-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 (October 22, 2018) is 2007 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group I. Jarvinen 3 Internet-Draft M. Kojo 4 Intended status: Experimental I. Raitahila 5 Expires: April 25, 2019 University of Helsinki 6 Z. Cao 7 Huawei 8 October 22, 2018 10 Fast-Slow Retransmission Timeout and Congestion Control Algorithm for 11 CoAP 12 draft-jarvinen-core-fasor-01 14 Abstract 16 This document specifies an alternative retransmission timeout and 17 congestion control back off algorithm for the CoAP protocol, called 18 Fast-Slow RTO (FASOR). 20 The algorithm specified in this document employs an appropriate and 21 large enough back off of Retransmission Timeout (RTO) as the major 22 congestion control mechanism to allow acquiring unambiguous RTT 23 samples with high probability and to prevent building a persistent 24 queue when retransmitting. The algorithm also aims to retransmit 25 quickly using an accurately managed retransmission timeout when link- 26 errors are occuring, basing RTO calculation on unambiguous round-trip 27 time (RTT) samples. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Problems with Existing CoAP Congestion Control Algorithms . . 3 66 4. FASOR Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Computing Normal RTO (FastRTO) . . . . . . . . . . . . . 4 68 4.2. Slow RTO . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.3. Retransmission Timeout Back Off Logic . . . . . . . . . . 6 70 4.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3.2. Retransmission State Machine . . . . . . . . . . . . 7 72 4.4. Retransmission Count Option . . . . . . . . . . . . . . . 9 73 4.5. Alternatives for Exchanging Retransmission Count 74 Information . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 7.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Pseudocode for Basic FASOR without Dithering . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 CoAP senders use retransmission timeout (RTO) to infer losses that 86 have occurred in the network. For such a heuristic to be correct, 87 the RTT estimate used for calculating the retransmission timeout must 88 match to the real end-to-end path characteristics. Otherwise, 89 unnecessary retransmission may occur. Both default RTO mechanism for 90 CoAP [RFC7252] and CoCoA [I-D.ietf-core-cocoa] have issues in dealing 91 with unnecessary retransmissions and in the worst-case the situation 92 can persist causing congestion collapse [JRCK18a]. 94 This document specifies FASOR retransmission timeout and congestion 95 control algorithm [JRCK18b]. FASOR algorithm ensures unnecessary 96 retransmissions that a sender may have sent due to an inaccurate RTT 97 estimate will not persist avoiding the threat of congestion collapse. 98 FASOR also aims to quickly restore the accuracy of the RTT estimate. 99 Armed with an accurate RTT estimate, FASOR not only handles 100 congestion robustly but also can quickly infer losses due to link 101 errors. 103 2. Conventions 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 BCP 14, RFC 2119 108 [RFC2119]. 110 3. Problems with Existing CoAP Congestion Control Algorithms 112 Correctly inferring losses requires the retransmission timeout (RTO) 113 to be longer than the real RTT in the network. Under certain 114 circumstances the RTO may be incorrectly small. If the real end-to- 115 end RTT is larger than the retransmission timeout, it is impossible 116 for the sender to avoid making unnecessary retransmissions that 117 duplicate data still existing in the network because the sender 118 cannot receive any feedback in time. Unnecessary retransmissions 119 cause two basic problems. First, they increase the perceived end-to- 120 end RTT if the bottleneck has buffering capacity, and second, they 121 prevent getting unambiguous RTT samples. Making unnecessary 122 retransmissions is also a pre-condition for the congestion collapse 123 [RFC0896], which may occur in the worst case if retransmissions are 124 not well controlled [JRCK18a]. Therefore, the sender retransmission 125 timeout algorithm should actively attempt to prevent unnecessary 126 retransmissions from persisting under any circumstance. 128 Karn's algorithm [KP87] has prevented unnecessary retransmission from 129 turning into congestion collapse for decades due to robust RTT 130 estimation and retransmission timeout backoff handling. The recent 131 CoAP congestion control algorithms, however, diverge from the 132 principles of Karn's algorithm in significant ways and may pose a 133 threat to the stability of the Internet due to those differences. 135 The default RTO mechanism for CoAP [RFC7252] uses only an initial RTO 136 dithered between 2 and 3 seconds, while CoCoA [I-D.ietf-core-cocoa] 137 measures RTT both from unambiguous and ambiguous RTT samples and 138 applies a modified version of the TCP RTO algorithm [RFC6298]. The 139 algorithm in RFC 7252 lacks solution to persistent congestion. The 140 binary exponential back off used for the retransmission timeout does 141 not properly address unnecessary retransmissions when RTT is larger 142 than the default RTO (ACK_TIMEOUT). If the CoAP sender performs 143 exchanges over an end-to-end path with such a high RTT, it 144 persistently keeps making unnecessary retransmissions for every 145 exchange wasting some fraction of the used resources (network 146 capacity, battery power). 148 CoCoA [I-D.ietf-core-cocoa] attempts to improve scenarios with link- 149 error related losses and solve persistent congestion by basing its 150 RTO value on an estimated RTT. However, there are couple of 151 exceptions when the RTT estimation is not available: 153 - At the beginning of a flow where initial RTO of 2 seconds is 154 used. 156 - When RTT suddenly jumps high enough to trigger the rule in CoCoA 157 that prevents taking RTT samples when more than two 158 retransmissions are needed. This may also occur when the packet 159 drop rate on the path is high enough. 161 When RTT estimate is too small, unnecessary retransmission will occur 162 also with CoCoA. CoCoA being unable to take RTT samples at all is a 163 particularly problematic phenomenon as it is similarly persisting 164 state as with the algorithm outlined in RFC 7252 and the network 165 remains in a congestion collapsed state due to persisting unnecessary 166 retransmissions. 168 4. FASOR Algorithm 170 FASOR [JRCK18b] is composed of three key components: RTO computation, 171 Slow RTO, and novel retransmission timeout back off logic. 173 4.1. Computing Normal RTO (FastRTO) 175 The FASOR algorithm measures the RTT for an CoAP message exchange 176 over an end-to-end path and computes the RTO value using the TCP RTO 177 algorithm specified in [RFC6298]. We call this normal RTO or 178 FastRTO. In contrast to the TCP RTO mechanism, FASOR SHOULD NOT use 179 1 second lower-bound when setting the RTO because RTO is only a 180 backup mechanisms for loss detection with TCP, whereas with CoAP RTO 181 is the primary and only loss detection mechanism. A lower-bound of 1 182 second would impact timeliness of the loss detection in low RTT 183 environments. The RTO value MAY be upper-bounded by at least 60 184 seconds. A CoAP sender using the FASOR algorithm SHOULD set initial 185 RTO to 2 seconds. The computed RTO value as well as the initial RTO 186 value is subject to dithering; they are dithered between RTO + 1/4 x 187 SRTT and RTO + SRTT. For dithering initial RTO, SRTT is unset; 188 therefore, SRTT is replaced with initial RTO / 3 which is derived 189 from the RTO formula and equals to a hypothetical initial RTT that 190 would yield the initial RTO using the SRTT and RTTVAR initialization 191 rule of RFC 6298. That is, for initial RTO of 2 seconds we use SRTT 192 value of 2/3 seconds. 194 FastRTO is updated only with unambiguous RTT samples. Therefore, it 195 closely tracks the actual RTT of the network and can quickly trigger 196 a retransmission when the network state is not dubious. 197 Retransmitting without extra delay is very useful when the end-to-end 198 path is subject to losses that are unrelated to congestion. When the 199 first unambiguous RTT sample is received, the RTT estimator is 200 initialized with that sample as specified in [RFC6298] except RTTVAR 201 that is set to R/2K. 203 4.2. Slow RTO 205 We introduce Slow RTO as a safe way to ensure that only a unique copy 206 of message is sent before at least one RTT has elapsed. To achieve 207 this the sender must ensure that its retransmission timeout is set to 208 a value that is larger than the path end-to-end RTT that may be 209 inflated by the unnecessary retransmission themselves. Therefore, 210 whenever a message needs to be retransmitted, we measure Slow RTO as 211 the elapsed time required for getting an acknowledgement. That is, 212 Slow RTO is measured starting from the original transmission of the 213 request message until the receipt of the acknowledgement, regardless 214 of the number of retransmissions. In this way, Slow RTO always 215 covers the worst-case RTT during which a number of unnecessary 216 retransmissions were made but the acknowledgement is received for the 217 original transmission. In contrast to computing normal RTO, Slow RTO 218 is not smoothed because it is derived from the sending pattern of the 219 retransmissions (that may turn out unnecessary). In order to drain 220 the potential unnecessary retransmissions successfully from the 221 network, it makes sense to wait for the time used for sending them 222 rather than some smoothed value. However, Slow RTO is multiplied by 223 a factor to allow some growth in load without making Slow RTO too 224 aggressive (by default the factor of 1.5 is used). FASOR then 225 applies Slow RTO as one of the backed off timer values used with the 226 next request message. 228 Slow RTO allows rapidly converging towards stable operating point 229 because 1) it lets the duplicate copies sent earlier to drain from 230 the network reducing the perceived end-to-end RTT, and 2) allows 231 enough time to acquire an unambiguous RTT sample for the RTO 232 computation. Robustly acquiring the RTT sample ensures that the next 233 RTO is set according to the recent measurement and further 234 unnecessary retransmissions are avoided. Slow RTO itself is a form 235 of back off because it includes the accumulated time from the 236 retransmission timeout back off of the previous exchange. FASOR uses 237 this for its advantage as the time included into Slow RTO is what is 238 needed to drain all unnecessary retransmissions possibly made during 239 the previous exchange. Assuming a stable RTT and that all of the 240 retransmissions were unnecessary, the time to drain them is the time 241 elapsed from the original transmission to the sending time of the 242 last retransmission plus one RTT. When the acknowledgement for the 243 original transmission arrives, one RTT has already elapsed, leaving 244 only the sending time difference still unaccounted for which is at 245 minimum the value for Slow RTO (when an RTT sample arrives 246 immediately after the last retransmission). Even if RTT would be 247 increasing, the draining still occurs rapidly due to exponentially 248 backed off frequency in sending the unnecessary retransmissions. 250 4.3. Retransmission Timeout Back Off Logic 252 4.3.1. Overview 254 FASOR uses normal RTO as the base for binary exponential back off 255 when no retransmission were needed for the previous CoAP message 256 exchange. When retransmission were needed for the previous CoAP 257 message exchange, the algorithm rules, however, are more complicated 258 than with the traditional RTO back off because Slow RTO is injected 259 into the back off series to reduce high impact of using Slow RTO. 260 FASOR logic chooses from three possible back off series alternatives: 262 FAST back off: Perform traditional RTO back off with the normal 263 RTO as the base. Applied when the previous message was not 264 retransmitted. 266 FAST_SLOW_FAST back off: First perform a probe using the normal 267 RTO for the original transmission of the request message to 268 improve cases with losses unrelated to congestion. If the probe 269 for the original transmission of the request message is successful 270 without retransmissions, continue with FAST back off for the next 271 message exchange. If the request message needs to be 272 retransmitted, continue by using Slow RTO for the first 273 retransmission in order to respond to congestion and drain the 274 network from the unnecessary retransmissions that were potentially 275 sent for the previous exchange. If still further RTOs are needed, 276 continue by backing off the normal RTO further on each timeout. 277 FAST_SLOW_FAST back off is applied just once when the previous 278 request message using FAST back off required one or more 279 retransmissions. 281 SLOW_FAST back off: Perform Slow RTO first for the original 282 transmisssion to respond to congestion and to acquire an 283 unambiguous RTT sample with high probability. Then, if the 284 original request needs to be retransmitted, continue with the 285 normal RTO-based RTO back off serie by backing off the normal RTO 286 on each timeout. SLOW_FAST back off is applied when the previous 287 request message using FAST_SLOW_FAST or SLOW_FAST back off 288 required one or more retransmissions. Once an acknowledgement for 289 the original transmission with unambigous RTT sample is received, 290 continue with FAST back off for the next message exchange. 292 For the initial message, FAST is used with INITIAL_RTO as the FastRTO 293 value. From there on, state is updated when an acknowledgement 294 arrives. Following unambiguous RTT samples, FASOR always uses FAST. 295 Whenever retransmissions are needed, the back off series selection is 296 first downgraded to FAST_SLOW_FAST back off and then to SLOW_FAST 297 back off if further retransmission are needed in FAST_SLOW_FAST. 299 When Slow RTO is used as the first RTO value, the sender is likely to 300 acquire unambiguous RTT sample even when the network has high delay 301 due to congestion because Slow RTO is based on a very recent 302 measurement of the worst-case RTT. However, using Slow RTO may 303 negatively impact the performance when losses unrelated to congestion 304 are occurring. Due to its potential high cost, FASOR algorithm 305 attempts to avoid using Slow RTO unnecessarily. 307 The CoAP protocol is often used by devices that are connected through 308 a wireless network where non-congestion related losses are much more 309 frequent than in their wired counterparts. This has implications for 310 the retransmission timeout algorithm. While it would be possible to 311 implement FASOR such that it immediately uses Slow RTO when a dubious 312 network state is detected, which would handle congestion very well, 313 it would do significant harm for performance when RTOs occur due to 314 non-congestion related losses. Instead, FASOR uses first normal RTO 315 for one transmission and only responds using Slow RTO if RTO expires 316 also for that request message. Such a pattern quickly probes if the 317 losses were unrelated to congestion and only slightly delays response 318 if real congestion event is taking place. To ensure that an 319 unambiguous RTT sample is also acquired on a congested network path, 320 FASOR then needs to use Slow RTO for the original transmission of the 321 subsequent packet if the probe was not successful. 323 4.3.2. Retransmission State Machine 325 FASOR consists of the three states discussed above while making 326 retranmission decisions, FAST, FAST_SLOW_FAST and SLOW_FAST. The 327 state machine of the FASOR algorithm is depicted in Figure 1. 329 +-------------------b----------------+ 330 | | 331 v | 332 +--FAST--a-->FAST_SLOW_FAST-----a----->SLOW_FAST--+ 333 | ^ ^ | ^ | 334 | | | | | | 335 +-b-+ +------b------+ +-a-+ 337 a: retransmission acknowledged, ambiguous RTT sample acquired; 338 b: no retransmission, umambiguous RTT sample acquired; 340 Figure 1: State Machine of FASOR 342 In the FAST state, if the original transmission of the message has 343 not been acknowledged by the receiver within the time defined by 344 FastRTO, the sender will retransmit it. If there is still no 345 acknowledgement of the retransmitted packet within 2*FastRTO, the 346 sender performs the second retransmission and if necessary, each 347 further retransmission applying binary exponential back off of 348 FastRTO. The retransmission interval in this state is defined as 349 FastRTO, 2^1 * FastRTO, ..., 2^i * FastRTO. 351 When there is an acknowledgement after any retransmission, the sender 352 will calculate SlowRTO value based on the algorithm defined in 353 Section 4.2. 355 When these is an acknowledgement after any retransmission, the sender 356 will also switch to the second state, FAST_FLOW_FAST. In this state, 357 the retransmission interval is defined as FastRTO, Max(SlowRTO, 358 2*FastRTO), FastRTO * 2^1, ..., 2^i * FastRTO. The state will be 359 switched back to the FAST state once an acknowledgement is returned 360 within FastRTO, i.e., no retransmission happens for a message. This 361 is reasonable because it shows the network has recovered from 362 congestion or bloated queue. 364 If some retransmission has been made before the acknowledged arrives 365 in the FAST_SLOW_FAST state, the sender updates the SlowRTO value, 366 and moves to the third state, SLOW_FAST. The retransmission interval 367 in the SLOW_FAST state is defined as SlowRTO, FastRTO, FastRTO * 2^1, 368 ..., 2^i * FastRTO. 370 In SLOW_FAST state, the sender switches back to the FAST state if an 371 unambiguous acknowledgement arrives. Otherwise, the sender stays in 372 the SLOW_FAST state if retransmission happens again. 374 4.4. Retransmission Count Option 376 When retransmissions are needed to deliver a CoAP message, it is not 377 possible to measure RTT for the RTO computation as the RTT sample 378 becomes ambiguous. Therefore, it would be beneficial to be able to 379 distinguish whether an acknowledgement arrives for the original 380 transmission of the message or for a retransmission of it. This 381 would allow reliably acquiring an RTT sample for every CoAP message 382 exchange and thereby compute a more accurate RTO even during periods 383 of congestion and loss. 385 The Retransmission Count Option is used to distinguish whether an 386 Acknowledgement message arrives for the original transmission or one 387 of the retransmissions of a Confirmable message. However, the 388 Retransmission Count Option cannot be used with an Empty 389 Acknowledgement (or Reset) message because the CoAP protocol 390 specification [RFC7252] does not allow adding options to an Empty 391 message. Therefore, Retransmission Count Option is useful only for 392 the common case of Piggybacked Response. In case of Empty 393 Acknowledgements the operation of FASOR is the same as without the 394 option. 396 +-----+---+---+---+---+------------+--------+--------+---------+ 397 | No. | C | U | N | R | Name | Format | Length | Default | 398 +-----+---+---+---+---+------------+--------+--------+---------+ 399 | TBD | | | X | | Rexmit-Cnt | uint | 0-1 | 0 | 400 +-----+---+---+---+---+------------+--------+--------+---------+ 402 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 404 Table 1: Retransmission Count Option 406 Implementation of the Retransmission Count option is optional and it 407 is identified as elective. However, when it is present in a CoAP 408 message and a CoAP endpoint processes it, it MUST be processed as 409 described in this document. The Retransmission Count option MUST NOT 410 occur more than once in a single message. 412 The value of the Retransmission Count option is a variable-size (0 to 413 1 byte) unsigned integer. The default value for the option is the 414 number 0 and it is represented with an empty option value (a zero- 415 length sequence of bytes). However, when a client intents to use 416 Retransmit Count option, it MUST reserve space for it by limiting the 417 request message size also when the value is empty in order to fit the 418 full-sized option into retransmissions. 420 The Retransmission Count option can be present in both the request 421 and response message. When the option is present in a request it 422 indicates the ordinal number of the transmission for the request 423 message. 425 If the server supports (implements) the Retransmission Count option 426 and the option is present in a request, the server MUST echo the 427 option value in its Piggybacked Response unmodified. If the server 428 replies with an Empty Acknowledgement the server MUST silently ignore 429 the option and MUST NOT include it in a later separate response to 430 that request. 432 When Piggybacked Response carrying the Retransmission Count option 433 arrives, the client uses the option to match the response message to 434 the corresponding transmission of the request. In order to measure a 435 correct RTT, the client must store the timestamp for the original 436 transmission of the request as well as the timestamp for each 437 retransmission, if any, of the request. The resulting RTT sample is 438 used for the RTO computation. If the client retransmitted the 439 request without the option but the response includes the option, the 440 client MUST silently ignore the option. 442 The original transmission of a request is indicated with the number 443 0, except when sending the first request to a new destination 444 endpoint. The first original transmission of the request to a new 445 endpoint carries the number 255 (0xFF) and is interpreted the same as 446 an original transmission carrying the number 0. Retransmissions, if 447 any, carry the ordinal number of the retransmission. Once the first 448 Piggybacked Response from the new endpoint arrives the client learns 449 whether or not the other endpoint implements the option. If the 450 first response includes the echoed option, the client learns that the 451 other endpoint supports the option and may continue including the 452 option to each retransmitted request. From this point on the 453 original transmissions of requests implicitly include the option 454 number 0 and a zero-byte integer will be sent according to the CoAP 455 uint-encoding rules. If the first Piggybacked Response does not 456 include the option, the client SHOULD stop including the option into 457 the requests to that endpoint. 459 When the Retransmission Count option is in use, the client bases the 460 retransmission timeout for the normal RTO in the back off series as 461 follows: 463 max(RTO, Previous-RTT-Sample) 465 Previous-RTT-Sample is the RTT sample acquired from the previous 466 message exchange. If no RTT sample was available with the previous 467 message exchange (e.g., the server replied with an Empty 468 Acknowledgement), RTO computed earlier is used like in case the 469 Retransmission Count option is not in use. 471 4.5. Alternatives for Exchanging Retransmission Count Information 473 An alternative way of exchanging the retransmission count information 474 between a client and server is to encode it in the Token. The Token 475 is a client-local identifier and a client solely decides how it 476 generates the Token. Therefore, including a varying Token value to 477 retransmissions of the same request is all possible as long as the 478 client can use the Token to differentiate between requests and match 479 a response to the corresponding request. The server is required to 480 make no assumptions about the content or structure of a Token and 481 always echo the Token unmodified in its response. 483 How exactly a client encodes the retransmission count into a Token is 484 an implementation issue. Note that the original transmission of a 485 request may carry a zero-length Token given that the rules for 486 generating a Token as specified in RFC 7252 [RFC7252] are followed. 487 This allows reducing the overhead of including the Token into the 488 reguests in such cases where Token could otherwise be omitted. 489 However, similar to Retransmit Count option the maximum request 490 message size MUST be limited to accommodate the Token with retransmit 491 count into the retransmissions of the request. 493 5. Security Considerations 495 6. IANA Considerations 497 This memo includes no request to IANA. 499 7. References 501 7.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 509 "Computing TCP's Retransmission Timer", RFC 6298, 510 DOI 10.17487/RFC6298, June 2011, 511 . 513 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 514 Application Protocol (CoAP)", RFC 7252, 515 DOI 10.17487/RFC7252, June 2014, 516 . 518 7.2. Informative References 520 [I-D.ietf-core-cocoa] 521 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 522 "CoAP Simple Congestion Control/Advanced", draft-ietf- 523 core-cocoa-03 (work in progress), February 2018. 525 [JRCK18a] Jarvinen, I., Raitahila, I., Cao, Z., and M. Kojo, "Is 526 CoAP Congestion Safe?", Applied Networking Research 527 Workshop (ANRW'18), July 2018. 529 [JRCK18b] Jarvinen, I., Raitahila, I., Cao, Z., and M. Kojo, "FASOR 530 Retransmission Timeout and Congestion Control Mechanism 531 for CoAP?", Proceedings of IEEE Global Communications 532 Conference (Globecom 2018), to appear, December 2018. 534 [KP87] Karn, P. and C. Partridge, "Improving Round-trip Time 535 Estimates in Reliable Transport Protocols", SIGCOMM'87 536 Proceedings of the ACM Workshop on Frontiers in Computer 537 Communications Technology, August 1987. 539 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 540 RFC 896, DOI 10.17487/RFC0896, January 1984, 541 . 543 Appendix A. Pseudocode for Basic FASOR without Dithering 545 var state = NORMAL_RTO 547 rfc6298_init(var fastrto, 2 secs) 549 var slowrto 550 SLOWRTO_FACTOR = 1.5 552 var original_sendtime 553 var retransmit_count 555 /* 556 * Sending Original Copy and Retransmitting 'req' 557 */ 558 send_request(req) { 559 original_sendtime = time.now 560 retransmit_count = 0 562 arm_rto(calculate_rto()) 563 send(req) 564 } 566 rto_for(req) { 567 retransmit_count += 1 569 arm_rto(calculate_rto()) 570 send(req) 571 } 573 /* 574 * ACK Processings 575 */ 576 ack() { 577 sample = time.now - original_sendtime 578 if (retransmit_count == 0) 579 unambiguous_ack(sample) 580 else 581 ambiguous_ack(sample) 582 } 584 unambiguous_ack(sample) { 585 k = 4 // RFC6298 default K = 4 586 if (rfc6298_is_first_sample(fastrto)) 587 k = 1 588 rfc6298_update(fastrto, k, sample) // Normal RFC6298 processing 589 state = NORMAL_RTO 590 } 591 ambiguous_nextstate = { 592 [NORMAL_RTO] = FAST_SLOW_FAST_RTO, 593 [FAST_SLOW_FAST_RTO] = SLOW_FAST_RTO, 594 [SLOW_FAST_RTO] = SLOW_FAST_RTO 595 } 597 ambiguous_ack(sample) { 598 slowrto = sample * SLOWRTO_FACTOR 599 state = ambiguous_nextstate[state] 600 } 602 /* 603 * RTO Calculations 604 */ 605 calculate_rto() { 606 return _rtoseries() 607 } 609 normal_rtoseries() { 610 switch (retransmit_count) { 611 case 0: return fastrto_series_init() 612 default: return fastrto_series_backoff() 613 } 614 } 616 fastslowfast_rtoseries() { 617 switch (retransmit_count) { 618 case 0: return fastrto_series_init() 619 case 1: return MAX(slowrto, 2*fastrto) 620 default: return fastrto_series_backoff() 621 } 622 } 624 slowfast_rtoseries() { 625 switch (retransmit_count) { 626 case 0: return slowrto 627 case 1: return fastrto_series_init() 628 default: return fastrto_series_backoff() 629 } 630 } 632 var backoff_series_timer 634 fastrto_series_init() { 635 backoff_series_timer = fastrto 636 return backoff_series_timer 637 } 638 fastrto_series_backoff() { 639 backoff_series_timer *= 2 640 return backoff_series_timer 641 } 643 Figure 2 645 Authors' Addresses 647 Ilpo Jarvinen 648 University of Helsinki 649 P.O. Box 68 650 FI-00014 UNIVERSITY OF HELSINKI 651 Finland 653 EMail: ilpo.jarvinen@helsinki.fi 655 Markku Kojo 656 University of Helsinki 657 P.O. Box 68 658 FI-00014 UNIVERSITY OF HELSINKI 659 Finland 661 EMail: markku.kojo@cs.helsinki.fi 663 Iivo Raitahila 664 University of Helsinki 665 P.O. Box 68 666 FI-00014 UNIVERSITY OF HELSINKI 667 Finland 669 EMail: iivo.raitahila@helsinki.fi 671 Zhen Cao 672 Huawei 673 Beijing 674 China 676 EMail: zhencao.ietf@gmail.com