idnits 2.17.1 draft-gomez-lpwan-rto-considerations-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 : ---------------------------------------------------------------------------- ** 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 Network 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-00 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 RTT . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Higher order RTT . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Discussion and proposed dual RTO algorithm . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Low-Power Wide Area Network (LPWAN) technologies offer appealing 76 features, such as multikilometer wireless link range, while allowing 77 low energy consumption for Internet of Things (IoT) devices. 78 However, these advantages come at the expense of reduced physical 79 layer (PHY) bit and message rates, which in some regions are further 80 affected by spectrum access regulatory constraints. In some LPWAN 81 scenarios, with flagship LPWAN technologies such as LoRaWAN or 82 Sigfox, PHY bit rates are lower than 1 kbit/s, and uplink message 83 rates are lower than 1 message/minute [RFC8376]. 85 Due to the aforementioned communication constraints, LPWAN 86 technologies often exhibit high or very high Round Trip Times (RTTs). 87 Even with negligible processing delays and in absence of 88 communication errors, RTTs can be in the order of a few seconds or a 89 few tens of seconds. Depending on the approach used to comply with 90 spectrum access regulations, RTTs can grow to several minutes. 91 Finally, when downlink responses are buffered in the radio gateway, 92 RTTs will be in the order of the time between uplink messages (e.g. 93 hours, if that is the time between two consecutive uplink messages). 95 The described RTTs, as well as their potential variability, are 96 significantly greater than typical ones on the Internet. In TCP, the 97 default RTO used to be 3 seconds and was reduced to 1 second 98 [RFC7414]. In a similar order, the Constrained Application Protocol 99 (CoAP), which is the preferred application-layer protocol for 100 IPv6-based LPWAN, has a default RTO randomly chosen between 2 and 3 101 seconds [RFC7252]. At the adaptation layer between IPv6 and the 102 LPWAN technology, some of the Static Context Header Compression 103 (SCHC) fragmentation modes also use RTOs, which need to be defined 104 suitably for each LPWAN technology 105 [I-D.ietf-lpwan-ipv6-static-context-hc]. 107 This document provides guidance for suitable RTO configuration and/or 108 usage in LPWAN. First, the document characterizes the RTT for 109 LoRaWAN and Sigfox in absence of communication errors, buffering 110 delays or processing delays. Second, higher order RTTs are 111 described, capturing the impact of message rate limitations due to 112 regulatory constraints and radio gateway buffering delays. Finally, 113 the document discusses suitable RTO settings in LPWAN, and describes 114 an experimental LPWAN-specific dual RTO algorithm. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Ideal scenario RTT 124 This section provides an analysis of the RTT for relevant LPWAN 125 technologies, such as LoRaWAN and Sigfox, assuming ideal conditions 126 (i.e. no losses, as well as negligible buffering and processing 127 delay). For detailed descriptions of LoRaWAN and Sigfox, the reader 128 may refer to the literature [RFC8376][LoRaWAN][Sigfox]. 130 In the analysis, the RTT comprises the time since the start of the 131 transmission of an uplink message by an IoT device until a response 132 is completely received by the IoT device. A 4-byte SCHC-compressed 133 IPv6/UDP/CoAP packet is assumed for the downlink response. Of 134 course, larger sized packets will lead to greater RTTs. 136 3.1. LoRaWAN 138 Figure 1 shows the minimum and maximum theoretical RTT values for 139 LoRaWAN in the EU band in ideal conditions. For the minimum ones, we 140 assume a 4-byte uplink frame payload, and a downlink response sent in 141 the first receive window. For the maximum ones, we assume the 142 maximum allowed uplink payload size for each Data Rate (DR), and a 143 downlink response sent in the second receive window. Note that there 144 is a 1- or 2-second delay between the uplink transmission and the 145 first or second receive window, respectively. 147 +------------------------+ 148 | Maximum | 149 +----+--------+-------+-------+------+------+ 150 | DR | Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| 151 +----+--------+-------+-------+------+------+ 152 | 0 | 51 | 2.79 | 0.99 | 4.52 | 5.81 | 153 +----+--------+-------+-------+------+------+ 154 | 1 | 51 | 1.56 | 0.58 | 2.99 | 4.15 | 155 +----+--------+-------+-------+------+------+ 156 | 2 | 51 | 0.70 | 0.29 | 1.92 | 3.00 | 157 +----+--------+-------+-------+------+------+ 158 | 3 | 115 | 0.68 | 0.14 | 1.73 | 2.82 | 159 +----+--------+-------+-------+------+------+ 160 | 4 | 242 | 0.70 | 0.07 | 1.66 | 2.78 | 161 +----+--------+-------+-------+------+------+ 162 | 5 | 242 | 0.40 | 0.04 | 1.37 | 2.44 | 163 +----+--------+-------+-------+------+------+ 164 | 6 | 242 | 0.20 | 0.02 | 1.19 | 2.22 | 165 +----+--------+-------+-------+------+------+ 166 | 7 | 242 | 0.04 | 0.003| 1.00 | 2.05 | 167 +----+--------+-------+-------+------+------+ 169 ULpld: uplink frame payload, in bytes 170 TtxUL: uplink frame transmission time, in seconds 171 TtxDL: downlink frame transmission time, in seconds 172 RTTmin: minimum RTT, in seconds 173 RTTmax: maximum RTT, in seconds 175 Figure 1: Minimum and maximum RTT values for LoRaWAN in the EU, 176 without losses, and in absence of buffering delay and processing 177 delay. 179 As shown in Figure 1, and under the conditions assumed, the minimum 180 RTT value for DR0 will always (for DR1, will almost always) exceed 181 the default CoAP RTO. The maximum RTT will always exceed the default 182 CoAP RTO for DR0-DR2, and will often exceed the default CoAP RTO for 183 DR3-DR7. Note that since DR6 and DR7 are optional, they are not 184 necessarily supported in real deployments. 186 3.2. Sigfox 188 Figure 2 shows the minimum and maximum theoretical RTT values for 189 Sigfox in ideal conditions. For the minimum ones, we assume a 4-byte 190 uplink frame payload, and a downlink response sent right at the 191 beginning of the downlink receive window. For the maximum ones, we 192 assume the maximum allowed uplink payload size, and a downlink 193 response sent at the end of the receive window. Note that there is a 194 20-second delay between the frame uplink transmission and the start 195 of the downlink receive window. 197 +------------------------+ 198 | Maximum | 199 +-----+--------+-------+-------+------+------+ 200 |UL BR| Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| 201 +-----+--------+-------+-------+------+------+ 202 | 100 | 12 | 2.08 | 0.39 | 21.8 | 47.1 | 203 +-----+--------+-------+-------+------+------+ 204 | 600 | 12 | 0.35 | 0.39 | 20.6 | 45.4 | 205 +-----+--------+-------+-------+------+------+ 207 UL BR: uplink bit rate, in bit/s 208 ULpld: uplink frame payload, in bytes 209 TtxUL: uplink frame transmission time, in seconds 210 TtxDL: downlink frame transmission time, in seconds 211 RTTmin: minimum RTT, in seconds 212 RTTmax: maximum RTT, in seconds 214 Figure 2: Minimum and maximum RTT values for Sigfox, without losses, 215 and in absence of buffering delay and processing delay. 217 As shown in Figure 2, and under the conditions assumed, the RTT in 218 Sigfox will be one order of magnitude greater than the default CoAP 219 RTO for all uplink bit rates and uplink frame payload sizes. 221 4. Higher order RTT 223 The high RTTs found in ideal conditions can be further exacerbated by 224 two further behaviours of LPWAN networks: i) policies for compliance 225 with duty cycle constraints, and ii) radio gateway buffering delays. 227 EU spectrum access regulations for some ISM bands used by LPWAN 228 technologies state that, unless listen-before-talk is used, the duty 229 cycle needs to be lower than some limit (e.g. 1% in some frequency 230 bands). Both LoRaWAN and Sigfox need to comply with such 231 regulations. There may be different applicable policies intended to 232 ensure compliance with the regulations. In one of them, in order to 233 comply with the 1% duty cycle limitation, after sending an uplink 234 frame, an IoT device keeps an idle period equal to 99 times the 235 transmission time of the uplink frame. Such a policy may increase 236 the RTT by up to two orders of magnitude. For example, in LoRaWAN, 237 this policy leads to RTTs that will always exceed the default CoAP 238 RTO, leading to an RTT of up to 282 seconds in the worst case. 240 Another phenomenon that may happen in LPWAN relates with the fact 241 that in some technologies and scenarios (e.g. the most typical 242 LoRaWAN class, called class A, and in Sigfox), a downlink frame can 243 only be sent during a given time interval (called receive window) 244 after the uplink frame transmission. If a radio gateway misses the 245 opportunity to send a downlink response to an uplink frame (e.g. 246 because the radio gateway is busy sending other downlink messages or 247 because it needs to refrain from transmitting immediately in order to 248 comply with duty cycle regulations), the response to an uplink frame 249 may be queued by the radio gateway until the next opportunity for 250 sending a downlink frame. This problem has already been described in 251 [I-D.toutain-core-time-scale]. If the problem occurs, the RTT will 252 be tied to the time between two uplink consecutive frames. Depending 253 on the application and its traffic pattern, such time may take values 254 in the order of seconds, minutes, hours or even days. 256 5. Discussion and proposed dual RTO algorithm 258 The RTO needs to be greater than the RTT in order to avoid spurious 259 timeouts. The latter are particularly expensive in LPWAN due to the 260 message rate constraints in these networks, and also since they 261 consume energy unnecessarily. However, as stated in 262 [I-D.ietf-tcpm-rto-consider], "each implementation of a 263 retransmission timeout mechanism represents a balance between 264 correctness and timeliness and therefore no implementation suits all 265 situations". 267 If delay is not relevant for an application, setting the default RTO 268 to at least the highest frequently expected RTT, denoted HIGH_RTT, 269 may be a suitable approach. 271 The problem arises when delay, even if at LPWAN scales, matters, and 272 higher order RTTs (Section 3) are expected in addition to the ideal 273 scenario ones (Section 2). At the very least, the default RTO needs 274 to be greater than the corresponding ideal scenario RTT value shown 275 in Section 2. If higher order RTTs are expected, one option is using 276 a simple dual RTO approach as follows. 278 The LPWAN device keeps two RTO instances. One instance (called Low 279 RTO) is initialized to a suitable ideal scenario RTT, denoted 280 LOW_RTT. The other instance (called High RTO) is initialized to a 281 value of at least HIGH_RTT. The dual RTO operates as follows (see 282 Figure 3): 284 o Initially, the LPWAN device uses the High RTO. 286 o When the device uses the High RTO, after N_THRESH_LOW consecutive 287 RTT samples lower than THRESH_LOW_RTT, the device switches to 288 using the Low RTO. 290 o When the device uses the Low RTO, after N_THRESH_HIGH consecutive 291 RTT samples greater than THRESH_HIGH_RTT, the device switches back 292 to using the High RTO. 294 +----------+ 295 +--->| High RTO |----+ 296 | +----------+ | 297 if N_THRESH_HIGH | | if N_THRESH_LOW 298 consecutive RTT samples | | consecutive RTT samples 299 > THRESH_HIGH_RTT | | < THRESH_LOW_RTT 300 | +----------+ | 301 +----| Low RTO |<---+ 302 +----------+ 304 Figure 3: State machine of the dual RTO algorithm. 306 The above described dual RTO algorithm may be applied to different 307 RTO approaches, such as a constant RTO, a constant but dithered RTO 308 (e.g. as in default CoAP), an adaptive RTO algorithm (e.g. as in TCP 309 or CoCoA [I-D.ietf-core-cocoa]), etc. If an adaptive RTO is used, 310 performance will benefit from separating lower RTT and higher RTT 311 regimes, avoiding inaccuracy due to a too high RTT variance. Note 312 that the phenomena described in Section 3 are expected to yield 313 systematically large step function RTT distributions. These deviate 314 significantly from the roughly normal/gaussian RTT statistics assumed 315 by the TCP RTO algorithm. 317 Further refinement of the mechanism, to be discussed. 319 6. Security Considerations 321 TBD 323 7. Acknowledgments 325 Carles Gomez has been funded in part by the Spanish Government 326 (Ministerio de Ciencia, Innovacion y Universidades) through the Jose 327 Castillejo grant CAS18/00170 and by European Regional Development 328 Fund (ERDF) and the Spanish Government through project 329 TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has 330 been carried out during his stay as a visiting scholar at the 331 Computer Laboratory of the University of Cambridge. 333 8. References 335 8.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 8.2. Informative References 344 [I-D.ietf-core-cocoa] 345 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 346 "CoAP Simple Congestion Control/Advanced", draft-ietf- 347 core-cocoa-03 (work in progress), February 2018. 349 [I-D.ietf-lpwan-ipv6-static-context-hc] 350 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 351 Zuniga, "LPWAN Static Context Header Compression (SCHC) 352 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 353 ipv6-static-context-hc-18 (work in progress), December 354 2018. 356 [I-D.ietf-tcpm-rto-consider] 357 Allman, M., "Retransmission Timeout Requirements", draft- 358 ietf-tcpm-rto-consider-08 (work in progress), February 359 2019. 361 [I-D.toutain-core-time-scale] 362 Minaburo, A. and L. Toutain, "CoAP Time Scale Option", 363 draft-toutain-core-time-scale-00 (work in progress), 364 October 2017. 366 [LoRaWAN] L. Casals, B. Mir, R. Vidal, C. Gomez, "Modeling the 367 Energy Performance of LoRaWAN", Sensors, October 2017. 369 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 370 Application Protocol (CoAP)", RFC 7252, 371 DOI 10.17487/RFC7252, June 2014, 372 . 374 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 375 Zimmermann, "A Roadmap for Transmission Control Protocol 376 (TCP) Specification Documents", RFC 7414, 377 DOI 10.17487/RFC7414, February 2015, 378 . 380 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 381 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 382 . 384 [Sigfox] C. Gomez, J.C. Veras, R. Vidal, L. Casals, J. Paradells, 385 "A Sigfox Energy Consumption Model", Sensors, February 386 2019. 388 Authors' Addresses 390 Carles Gomez 391 UPC 392 C/Esteve Terradas, 7 393 Castelldefels 08860 394 Spain 396 Email: carlesgo@entel.upc.edu 398 Jon Crowcroft 399 University of Cambridge 400 JJ Thomson Avenue 401 Cambridge, CB3 0FD 402 United Kingdom 404 Email: jon.crowcroft@cl.cam.ac.uk