idnits 2.17.1 draft-gomez-lpwan-rto-considerations-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 4, 2019) is 1757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-18 == Outdated reference: A later version (-17) exists of draft-ietf-tcpm-rto-consider-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LPWAN Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Informational J. Crowcroft 5 Expires: January 5, 2020 University of Cambridge 6 July 4, 2019 8 RTO considerations in LPWAN 9 draft-gomez-lpwan-rto-considerations-01 11 Abstract 13 Low-Power Wide Area Network (LPWAN) technologies are characterized by 14 very low physical layer bit and message transmission rates. 15 Moreover, a response to a message sent by an LPWAN device may often 16 only be received after a significant delay. As a result, Round-Trip 17 Time (RTT) values in LPWAN are often (sometimes, significantly) 18 greater than typical default values of Retransmission TimeOut (RTO) 19 algorithms. Furthermore, buffering at network elements such as radio 20 gateways may interact negatively with LPWAN technology transmission 21 mechanisms, potentially exacerbating RTTs by up to several orders of 22 magnitude. This document provides guidance for RTO settings in 23 LPWAN, and describes an experimental dual RTO algorithm for LPWAN. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 5, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Ideal scenario U-RTT . . . . . . . . . . . . . . . . . . . . 3 62 3.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Higher order U-RTT . . . . . . . . . . . . . . . . . . . . . 5 65 5. D-RTT analysis . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Discussion and proposed dual RTO algorithm . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Low-Power Wide Area Network (LPWAN) technologies offer appealing 77 features, such as multikilometer wireless link range, while allowing 78 low energy consumption for Internet of Things (IoT) devices. 79 However, these advantages come at the expense of reduced physical 80 layer (PHY) bit and message rates, which in some regions are further 81 affected by spectrum access regulatory constraints. In some LPWAN 82 scenarios, with flagship LPWAN technologies such as LoRaWAN or 83 Sigfox, PHY bit rates are lower than 1 kbit/s, and uplink message 84 rates are lower than 1 message/minute [RFC8376]. 86 Due to the aforementioned communication constraints, LPWAN 87 technologies often exhibit high or very high Round Trip Times (RTTs). 88 Even with negligible processing delays and in absence of 89 communication errors, RTTs can be in the order of a few seconds or a 90 few tens of seconds. Depending on the approach used to comply with 91 spectrum access regulations, RTTs can grow to several minutes. 92 Finally, when downlink responses are buffered in the radio gateway, 93 RTTs will be in the order of the time between uplink messages (e.g. 94 hours, if that is the time between two consecutive uplink messages). 96 The described RTTs, as well as their potential variability, are 97 significantly greater than typical ones on the Internet. In TCP, the 98 default RTO used to be 3 seconds and was reduced to 1 second 99 [RFC7414]. In a similar order, the Constrained Application Protocol 100 (CoAP), which is the preferred application-layer protocol for 101 IPv6-based LPWAN, has a default RTO randomly chosen between 2 and 3 102 seconds [RFC7252]. At the adaptation layer between IPv6 and the 103 LPWAN technology, some of the Static Context Header Compression 104 (SCHC) fragmentation modes also use RTOs, which need to be defined 105 suitably for each LPWAN technology 106 [I-D.ietf-lpwan-ipv6-static-context-hc]. 108 This document provides guidance for suitable RTO configuration in 109 LPWAN. Both the Uplink RTT (U-RTT) and the Downlink RTT (D-RTT) are 110 considered. The former refers to an RTT where the first message in 111 the RTT is sent in the uplink (and the response is sent in the 112 downlink), whereas the latter refers to the opposite. First, the 113 document characterizes the U-RTT for LoRaWAN and Sigfox in absence of 114 communication errors, buffering delays or processing delays. Second, 115 higher order U-RTTs are described, capturing the impact of message 116 rate limitations due to regulatory constraints and radio gateway 117 buffering delays. Third, D-RTT is analyzed for both LoRaWAN and 118 Sigfox. Finally, the document discusses suitable RTO settings in 119 LPWAN, and describes an experimental LPWAN-specific dual RTO 120 algorithm. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Ideal scenario U-RTT 130 This section provides an analysis of the U-RTT for relevant LPWAN 131 technologies, such as LoRaWAN and Sigfox, assuming ideal conditions 132 (i.e. no losses, as well as negligible buffering and processing 133 delay). For detailed descriptions of LoRaWAN and Sigfox, the reader 134 may refer to the literature [RFC8376][LoRaWAN][Sigfox]. 136 In the analysis, the U-RTT comprises the time since the start of the 137 transmission of an uplink message by an IoT device until a response 138 is completely received by the IoT device. A 4-byte SCHC-compressed 139 IPv6/UDP/CoAP packet is assumed for the downlink response. Of 140 course, larger sized packets will lead to greater RTTs. 142 3.1. LoRaWAN 144 Figure 1 shows the minimum and maximum theoretical U-RTT values for 145 LoRaWAN in the EU band in ideal conditions. For the minimum ones, we 146 assume a 4-byte uplink frame payload, and a downlink response sent in 147 the first receive window. For the maximum ones, we assume the 148 maximum allowed uplink payload size for each Data Rate (DR), and a 149 downlink response sent in the second receive window. Note that there 150 is a 1- or 2-second delay between the uplink transmission and the 151 first or second receive window, respectively. 153 +------------------------+ 154 | Maximum | 155 +----+--------+-------+-------+------+------+ 156 | DR | Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| 157 +----+--------+-------+-------+------+------+ 158 | 0 | 51 | 2.79 | 0.99 | 4.52 | 5.81 | 159 +----+--------+-------+-------+------+------+ 160 | 1 | 51 | 1.56 | 0.58 | 2.99 | 4.15 | 161 +----+--------+-------+-------+------+------+ 162 | 2 | 51 | 0.70 | 0.29 | 1.92 | 3.00 | 163 +----+--------+-------+-------+------+------+ 164 | 3 | 115 | 0.68 | 0.14 | 1.73 | 2.82 | 165 +----+--------+-------+-------+------+------+ 166 | 4 | 242 | 0.70 | 0.07 | 1.66 | 2.78 | 167 +----+--------+-------+-------+------+------+ 168 | 5 | 242 | 0.40 | 0.04 | 1.37 | 2.44 | 169 +----+--------+-------+-------+------+------+ 170 | 6 | 242 | 0.20 | 0.02 | 1.19 | 2.22 | 171 +----+--------+-------+-------+------+------+ 172 | 7 | 242 | 0.04 | 0.003| 1.00 | 2.05 | 173 +----+--------+-------+-------+------+------+ 175 ULpld: uplink frame payload, in bytes 176 TtxUL: uplink frame transmission time, in seconds 177 TtxDL: downlink frame transmission time, in seconds 178 RTTmin: minimum U-RTT, in seconds 179 RTTmax: maximum U-RTT, in seconds 181 Figure 1: Minimum and maximum U-RTT values for LoRaWAN in the EU, 182 without losses, and in absence of buffering delay and processing 183 delay. 185 As shown in Figure 1, and under the conditions assumed, the minimum 186 U-RTT value for DR0 will always (for DR1, will almost always) exceed 187 the default CoAP RTO. The maximum U-RTT will always exceed the 188 default CoAP RTO for DR0-DR2, and will often exceed the default CoAP 189 RTO for DR3-DR7. Note that since DR6 and DR7 are optional, they are 190 not necessarily supported in real deployments. 192 3.2. Sigfox 194 Figure 2 shows the minimum and maximum theoretical U-RTT values for 195 Sigfox in ideal conditions. For the minimum ones, we assume a 4-byte 196 uplink frame payload, and a downlink response sent right at the 197 beginning of the downlink receive window. For the maximum ones, we 198 assume the maximum allowed uplink payload size, and a downlink 199 response sent at the end of the receive window. Note that there is a 200 20-second delay between the frame uplink transmission and the start 201 of the downlink receive window. 203 +------------------------+ 204 | Maximum | 205 +-----+--------+-------+-------+------+------+ 206 |UL BR| Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| 207 +-----+--------+-------+-------+------+------+ 208 | 100 | 12 | 2.08 | 0.39 | 21.8 | 47.1 | 209 +-----+--------+-------+-------+------+------+ 210 | 600 | 12 | 0.35 | 0.39 | 20.6 | 45.4 | 211 +-----+--------+-------+-------+------+------+ 213 UL BR: uplink bit rate, in bit/s 214 ULpld: uplink frame payload, in bytes 215 TtxUL: uplink frame transmission time, in seconds 216 TtxDL: downlink frame transmission time, in seconds 217 RTTmin: minimum U-RTT, in seconds 218 RTTmax: maximum U-RTT, in seconds 220 Figure 2: Minimum and maximum U-RTT values for Sigfox, without 221 losses, and in absence of buffering delay and processing delay. 223 As shown in Figure 2, and under the conditions assumed, the U-RTT in 224 Sigfox is one order of magnitude greater than the default CoAP RTO 225 for all uplink bit rates and uplink frame payload sizes. 227 4. Higher order U-RTT 229 The high U-RTTs found in ideal conditions can be further exacerbated 230 by two further behaviours of LPWAN networks: i) policies for 231 compliance with duty cycle constraints, and ii) radio gateway 232 buffering delays. 234 EU spectrum access regulations for some ISM bands used by LPWAN 235 technologies state that, unless listen-before-talk is used, the duty 236 cycle needs to be lower than some limit (e.g. 1% in some frequency 237 bands). Both LoRaWAN and Sigfox need to comply with such 238 regulations. There may be different applicable policies intended to 239 ensure compliance with the regulations. In one of them, in order to 240 comply with the 1% duty cycle limitation, after sending an uplink 241 frame, an IoT device keeps an idle period equal to 99 times the 242 transmission time of the uplink frame. Such a policy may increase 243 the RTT by up to two orders of magnitude. For example, in LoRaWAN, 244 this policy leads to U-RTTs that will always exceed the default CoAP 245 RTO, leading to a U-RTT of up to 282 seconds in the worst case. 247 Another phenomenon that may happen in LPWAN relates with the fact 248 that in some technologies and scenarios (e.g. the most typical 249 LoRaWAN class, called class A, and in Sigfox), a downlink frame can 250 only be sent during a given time interval (called receive window) 251 after the uplink frame transmission. If a radio gateway misses the 252 opportunity to send a downlink response to an uplink frame (e.g. 253 because the radio gateway is busy sending other downlink messages or 254 because it needs to refrain from transmitting immediately in order to 255 comply with duty cycle regulations), the response to an uplink frame 256 may be queued by the radio gateway until the next opportunity for 257 sending a downlink frame. This problem has already been described in 258 [I-D.toutain-core-time-scale]. If the problem occurs, the U-RTT will 259 be tied to the time between two uplink consecutive frames. Depending 260 on the application and its traffic pattern, such time may take values 261 in the order of seconds, minutes, hours or even days. 263 5. D-RTT analysis 265 D-RTTs may be greater than U-RTTs, due to the feature in some LPWANs 266 that a downlink message can only be sent as a response to an uplink 267 message (as an energy conservation technique for LPWAN devices). A 268 downlink message may need to be buffered at the gateway until the 269 opportunity for downlink transmission occurs. Therefore, a D-RTT 270 comprises two main components: i) the wait time since a message is 271 ready for downlink transmission until the next uplink transmission is 272 complete, denoted T_wait; ii) the time since the uplink transmission 273 is complete, until the D-RTT can be completed, called Basic D-RTT 274 (BD-RTT). 276 T_wait can be characterized as a random variable, which depends on 277 the time between two consecutive uplink messages, and has a 278 distribution that depends on the specific application in use. The 279 message rates at which applications using LPWAN technologies operate 280 may be in the order of seconds, minutes, hours, etc. In some cases, 281 it is possible to program scheduled uplink transmissions, which allow 282 minimizing T_wait, ideally down to zero. 284 Figure 3 and Figure 4 provide the values for BD-RTT for LoRaWAN (in 285 the EU) and Sigfox, respectively. We assume the same packet sizes 286 considered in the ideal scenario U-RTT study. In LoRaWAN, the BD-RTT 287 does not contain the 1- or 2-second delay between the uplink 288 transmission and the downlink response, therefore BD-RTT is smaller 289 than the ideal scenario U-RTT. In Sigfox, the 1.4-second delay 290 between a downlink transmission and its subsequent uplink 291 confirmation is now added, compared to the ideal scenario U-RTT. 293 +-------------+ 294 | BD-RTT | 295 +----+------+------+ 296 | DR | Min | Max | 297 +----+------+------+ 298 | 0 | 3.52 | 3.81 | 299 +----+------+------+ 300 | 1 | 1.99 | 2.15 | 301 +----+------+------+ 302 | 2 | 0.92 | 1.00 | 303 +----+------+------+ 304 | 3 | 0.73 | 0.82 | 305 +----+------+------+ 306 | 4 | 0.66 | 0.78 | 307 +----+------+------+ 308 | 5 | 0.37 | 0.44 | 309 +----+------+------+ 310 | 6 | 0.19 | 0.22 | 311 +----+------+------+ 312 | 7 | 0.01 | 0.05 | 313 +----+------+------+ 315 Figure 3: Minimum and maximum BD-RTT values (in seconds) for LoRaWAN 316 in the EU, without losses, and in absence of buffering delay and 317 processing delay. 319 +-------------+ 320 | BD-RTT | 321 +-----+------+------+ 322 |UL BR| Min | Max | 323 +-----+------+------+ 324 | 100 | 23.6 | 48.1 | 325 +-----+------+------+ 326 | 600 | 22.1 | 46.7 | 327 +-----+------+------+ 329 UL BR: uplink bit rate, in bit/s 331 Figure 4: Minimum and maximum BD-RTT values (in seconds) for Sigfox, 332 without losses, and in absence of buffering delay and processing 333 delay. 335 6. Discussion and proposed dual RTO algorithm 337 The RTO needs to be greater than the RTT in order to avoid spurious 338 timeouts. The latter are particularly expensive in LPWAN due to the 339 message rate constraints in these networks, and also since they 340 consume energy unnecessarily. However, as stated in 341 [I-D.ietf-tcpm-rto-consider], "each implementation of a 342 retransmission timeout mechanism represents a balance between 343 correctness and timeliness and therefore no implementation suits all 344 situations". 346 If delay is not relevant for an application, setting the default RTO 347 to at least the highest frequently expected RTT, denoted HIGH_RTT, 348 may be a suitable approach. 350 The problem arises when delay, even if at LPWAN scales, matters, and 351 higher order RTTs (e.g. see Section 3) are expected in addition to 352 the ideal scenario ones (e.g. see Section 2). At the very least, the 353 default RTO needs to be greater than the corresponding ideal scenario 354 RTT value shown in Section 2. If higher order RTTs are expected, one 355 option is using a simple dual RTO approach as follows. 357 The LPWAN device keeps two RTO instances. One instance (called Low 358 RTO) is initialized to a suitable ideal scenario RTT, denoted 359 LOW_RTT. The other instance (called High RTO) is initialized to a 360 value of at least HIGH_RTT. The dual RTO operates as follows (see 361 Figure 5): 363 o Initially, the LPWAN device uses the High RTO. 365 o When the device uses the High RTO, after N_THRESH_LOW consecutive 366 RTT samples lower than THRESH_LOW_RTT, the device switches to 367 using the Low RTO. 369 o When the device uses the Low RTO, after N_THRESH_HIGH consecutive 370 RTT samples greater than THRESH_HIGH_RTT, the device switches back 371 to using the High RTO. 373 +----------+ 374 +--->| High RTO |----+ 375 | +----------+ | 376 if N_THRESH_HIGH | | if N_THRESH_LOW 377 consecutive RTT samples | | consecutive RTT samples 378 > THRESH_HIGH_RTT | | < THRESH_LOW_RTT 379 | +----------+ | 380 +----| Low RTO |<---+ 381 +----------+ 383 Figure 5: State machine of the dual RTO algorithm. 385 The above described dual RTO algorithm may be applied to different 386 RTO approaches, such as a constant RTO, a constant but dithered RTO 387 (e.g. as in default CoAP), an adaptive RTO algorithm (e.g. as in TCP 388 or CoCoA [I-D.ietf-core-cocoa]), etc. If an adaptive RTO is used, 389 performance will benefit from separating lower RTT and higher RTT 390 regimes, avoiding inaccuracy due to a too high RTT variance. Note 391 that the phenomena described in Section 3 are expected to yield 392 systematically large step function RTT distributions. These deviate 393 significantly from the roughly normal/gaussian RTT statistics assumed 394 by the TCP RTO algorithm. 396 Further refinement of the mechanism, to be discussed. 398 7. Security Considerations 400 TBD 402 8. Acknowledgments 404 Carles Gomez has been funded in part by the Spanish Government 405 (Ministerio de Ciencia, Innovacion y Universidades) through the Jose 406 Castillejo grant CAS18/00170 and by European Regional Development 407 Fund (ERDF) and the Spanish Government through project 408 TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has 409 been carried out during his stay as a visiting scholar at the 410 Computer Laboratory of the University of Cambridge. 412 9. References 414 9.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, 418 DOI 10.17487/RFC2119, March 1997, 419 . 421 9.2. Informative References 423 [I-D.ietf-core-cocoa] 424 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 425 "CoAP Simple Congestion Control/Advanced", draft-ietf- 426 core-cocoa-03 (work in progress), February 2018. 428 [I-D.ietf-lpwan-ipv6-static-context-hc] 429 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 430 Zuniga, "LPWAN Static Context Header Compression (SCHC) 431 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 432 ipv6-static-context-hc-18 (work in progress), December 433 2018. 435 [I-D.ietf-tcpm-rto-consider] 436 Allman, M., "Retransmission Timeout Requirements", draft- 437 ietf-tcpm-rto-consider-08 (work in progress), February 438 2019. 440 [I-D.toutain-core-time-scale] 441 Minaburo, A. and L. Toutain, "CoAP Time Scale Option", 442 draft-toutain-core-time-scale-00 (work in progress), 443 October 2017. 445 [LoRaWAN] L. Casals, B. Mir, R. Vidal, C. Gomez, "Modeling the 446 Energy Performance of LoRaWAN", Sensors, October 2017. 448 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 449 Application Protocol (CoAP)", RFC 7252, 450 DOI 10.17487/RFC7252, June 2014, 451 . 453 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 454 Zimmermann, "A Roadmap for Transmission Control Protocol 455 (TCP) Specification Documents", RFC 7414, 456 DOI 10.17487/RFC7414, February 2015, 457 . 459 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 460 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 461 . 463 [Sigfox] C. Gomez, J.C. Veras, R. Vidal, L. Casals, J. Paradells, 464 "A Sigfox Energy Consumption Model", Sensors, February 465 2019. 467 Authors' Addresses 469 Carles Gomez 470 UPC 471 C/Esteve Terradas, 7 472 Castelldefels 08860 473 Spain 475 Email: carlesgo@entel.upc.edu 477 Jon Crowcroft 478 University of Cambridge 479 JJ Thomson Avenue 480 Cambridge, CB3 0FD 481 United Kingdom 483 Email: jon.crowcroft@cl.cam.ac.uk