LPWAN Working Group C. Gomez Internet-Draft UPC Intended status: Informational J. Crowcroft Expires: January 5, 2020 University of Cambridge July 4, 2019 RTO considerations in LPWAN draft-gomez-lpwan-rto-considerations-01 Abstract Low-Power Wide Area Network (LPWAN) technologies are characterized by very low physical layer bit and message transmission rates. Moreover, a response to a message sent by an LPWAN device may often only be received after a significant delay. As a result, Round-Trip Time (RTT) values in LPWAN are often (sometimes, significantly) greater than typical default values of Retransmission TimeOut (RTO) algorithms. Furthermore, buffering at network elements such as radio gateways may interact negatively with LPWAN technology transmission mechanisms, potentially exacerbating RTTs by up to several orders of magnitude. This document provides guidance for RTO settings in LPWAN, and describes an experimental dual RTO algorithm for LPWAN. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Gomez & Crowcroft Expires January 5, 2020 [Page 1] Internet-Draft RTO in LPWAN July 2019 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Ideal scenario U-RTT . . . . . . . . . . . . . . . . . . . . 3 3.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Higher order U-RTT . . . . . . . . . . . . . . . . . . . . . 5 5. D-RTT analysis . . . . . . . . . . . . . . . . . . . . . . . 6 6. Discussion and proposed dual RTO algorithm . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Low-Power Wide Area Network (LPWAN) technologies offer appealing features, such as multikilometer wireless link range, while allowing low energy consumption for Internet of Things (IoT) devices. However, these advantages come at the expense of reduced physical layer (PHY) bit and message rates, which in some regions are further affected by spectrum access regulatory constraints. In some LPWAN scenarios, with flagship LPWAN technologies such as LoRaWAN or Sigfox, PHY bit rates are lower than 1 kbit/s, and uplink message rates are lower than 1 message/minute [RFC8376]. Due to the aforementioned communication constraints, LPWAN technologies often exhibit high or very high Round Trip Times (RTTs). Even with negligible processing delays and in absence of communication errors, RTTs can be in the order of a few seconds or a few tens of seconds. Depending on the approach used to comply with spectrum access regulations, RTTs can grow to several minutes. Finally, when downlink responses are buffered in the radio gateway, RTTs will be in the order of the time between uplink messages (e.g. hours, if that is the time between two consecutive uplink messages). Gomez & Crowcroft Expires January 5, 2020 [Page 2] Internet-Draft RTO in LPWAN July 2019 The described RTTs, as well as their potential variability, are significantly greater than typical ones on the Internet. In TCP, the default RTO used to be 3 seconds and was reduced to 1 second [RFC7414]. In a similar order, the Constrained Application Protocol (CoAP), which is the preferred application-layer protocol for IPv6-based LPWAN, has a default RTO randomly chosen between 2 and 3 seconds [RFC7252]. At the adaptation layer between IPv6 and the LPWAN technology, some of the Static Context Header Compression (SCHC) fragmentation modes also use RTOs, which need to be defined suitably for each LPWAN technology [I-D.ietf-lpwan-ipv6-static-context-hc]. This document provides guidance for suitable RTO configuration in LPWAN. Both the Uplink RTT (U-RTT) and the Downlink RTT (D-RTT) are considered. The former refers to an RTT where the first message in the RTT is sent in the uplink (and the response is sent in the downlink), whereas the latter refers to the opposite. First, the document characterizes the U-RTT for LoRaWAN and Sigfox in absence of communication errors, buffering delays or processing delays. Second, higher order U-RTTs are described, capturing the impact of message rate limitations due to regulatory constraints and radio gateway buffering delays. Third, D-RTT is analyzed for both LoRaWAN and Sigfox. Finally, the document discusses suitable RTO settings in LPWAN, and describes an experimental LPWAN-specific dual RTO algorithm. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Ideal scenario U-RTT This section provides an analysis of the U-RTT for relevant LPWAN technologies, such as LoRaWAN and Sigfox, assuming ideal conditions (i.e. no losses, as well as negligible buffering and processing delay). For detailed descriptions of LoRaWAN and Sigfox, the reader may refer to the literature [RFC8376][LoRaWAN][Sigfox]. In the analysis, the U-RTT comprises the time since the start of the transmission of an uplink message by an IoT device until a response is completely received by the IoT device. A 4-byte SCHC-compressed IPv6/UDP/CoAP packet is assumed for the downlink response. Of course, larger sized packets will lead to greater RTTs. Gomez & Crowcroft Expires January 5, 2020 [Page 3] Internet-Draft RTO in LPWAN July 2019 3.1. LoRaWAN Figure 1 shows the minimum and maximum theoretical U-RTT values for LoRaWAN in the EU band in ideal conditions. For the minimum ones, we assume a 4-byte uplink frame payload, and a downlink response sent in the first receive window. For the maximum ones, we assume the maximum allowed uplink payload size for each Data Rate (DR), and a downlink response sent in the second receive window. Note that there is a 1- or 2-second delay between the uplink transmission and the first or second receive window, respectively. +------------------------+ | Maximum | +----+--------+-------+-------+------+------+ | DR | Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| +----+--------+-------+-------+------+------+ | 0 | 51 | 2.79 | 0.99 | 4.52 | 5.81 | +----+--------+-------+-------+------+------+ | 1 | 51 | 1.56 | 0.58 | 2.99 | 4.15 | +----+--------+-------+-------+------+------+ | 2 | 51 | 0.70 | 0.29 | 1.92 | 3.00 | +----+--------+-------+-------+------+------+ | 3 | 115 | 0.68 | 0.14 | 1.73 | 2.82 | +----+--------+-------+-------+------+------+ | 4 | 242 | 0.70 | 0.07 | 1.66 | 2.78 | +----+--------+-------+-------+------+------+ | 5 | 242 | 0.40 | 0.04 | 1.37 | 2.44 | +----+--------+-------+-------+------+------+ | 6 | 242 | 0.20 | 0.02 | 1.19 | 2.22 | +----+--------+-------+-------+------+------+ | 7 | 242 | 0.04 | 0.003| 1.00 | 2.05 | +----+--------+-------+-------+------+------+ ULpld: uplink frame payload, in bytes TtxUL: uplink frame transmission time, in seconds TtxDL: downlink frame transmission time, in seconds RTTmin: minimum U-RTT, in seconds RTTmax: maximum U-RTT, in seconds Figure 1: Minimum and maximum U-RTT values for LoRaWAN in the EU, without losses, and in absence of buffering delay and processing delay. As shown in Figure 1, and under the conditions assumed, the minimum U-RTT value for DR0 will always (for DR1, will almost always) exceed the default CoAP RTO. The maximum U-RTT will always exceed the default CoAP RTO for DR0-DR2, and will often exceed the default CoAP Gomez & Crowcroft Expires January 5, 2020 [Page 4] Internet-Draft RTO in LPWAN July 2019 RTO for DR3-DR7. Note that since DR6 and DR7 are optional, they are not necessarily supported in real deployments. 3.2. Sigfox Figure 2 shows the minimum and maximum theoretical U-RTT values for Sigfox in ideal conditions. For the minimum ones, we assume a 4-byte uplink frame payload, and a downlink response sent right at the beginning of the downlink receive window. For the maximum ones, we assume the maximum allowed uplink payload size, and a downlink response sent at the end of the receive window. Note that there is a 20-second delay between the frame uplink transmission and the start of the downlink receive window. +------------------------+ | Maximum | +-----+--------+-------+-------+------+------+ |UL BR| Ulpld | TtxUL | TtxDL |RTTmin|RTTmax| +-----+--------+-------+-------+------+------+ | 100 | 12 | 2.08 | 0.39 | 21.8 | 47.1 | +-----+--------+-------+-------+------+------+ | 600 | 12 | 0.35 | 0.39 | 20.6 | 45.4 | +-----+--------+-------+-------+------+------+ UL BR: uplink bit rate, in bit/s ULpld: uplink frame payload, in bytes TtxUL: uplink frame transmission time, in seconds TtxDL: downlink frame transmission time, in seconds RTTmin: minimum U-RTT, in seconds RTTmax: maximum U-RTT, in seconds Figure 2: Minimum and maximum U-RTT values for Sigfox, without losses, and in absence of buffering delay and processing delay. As shown in Figure 2, and under the conditions assumed, the U-RTT in Sigfox is one order of magnitude greater than the default CoAP RTO for all uplink bit rates and uplink frame payload sizes. 4. Higher order U-RTT The high U-RTTs found in ideal conditions can be further exacerbated by two further behaviours of LPWAN networks: i) policies for compliance with duty cycle constraints, and ii) radio gateway buffering delays. EU spectrum access regulations for some ISM bands used by LPWAN technologies state that, unless listen-before-talk is used, the duty Gomez & Crowcroft Expires January 5, 2020 [Page 5] Internet-Draft RTO in LPWAN July 2019 cycle needs to be lower than some limit (e.g. 1% in some frequency bands). Both LoRaWAN and Sigfox need to comply with such regulations. There may be different applicable policies intended to ensure compliance with the regulations. In one of them, in order to comply with the 1% duty cycle limitation, after sending an uplink frame, an IoT device keeps an idle period equal to 99 times the transmission time of the uplink frame. Such a policy may increase the RTT by up to two orders of magnitude. For example, in LoRaWAN, this policy leads to U-RTTs that will always exceed the default CoAP RTO, leading to a U-RTT of up to 282 seconds in the worst case. Another phenomenon that may happen in LPWAN relates with the fact that in some technologies and scenarios (e.g. the most typical LoRaWAN class, called class A, and in Sigfox), a downlink frame can only be sent during a given time interval (called receive window) after the uplink frame transmission. If a radio gateway misses the opportunity to send a downlink response to an uplink frame (e.g. because the radio gateway is busy sending other downlink messages or because it needs to refrain from transmitting immediately in order to comply with duty cycle regulations), the response to an uplink frame may be queued by the radio gateway until the next opportunity for sending a downlink frame. This problem has already been described in [I-D.toutain-core-time-scale]. If the problem occurs, the U-RTT will be tied to the time between two uplink consecutive frames. Depending on the application and its traffic pattern, such time may take values in the order of seconds, minutes, hours or even days. 5. D-RTT analysis D-RTTs may be greater than U-RTTs, due to the feature in some LPWANs that a downlink message can only be sent as a response to an uplink message (as an energy conservation technique for LPWAN devices). A downlink message may need to be buffered at the gateway until the opportunity for downlink transmission occurs. Therefore, a D-RTT comprises two main components: i) the wait time since a message is ready for downlink transmission until the next uplink transmission is complete, denoted T_wait; ii) the time since the uplink transmission is complete, until the D-RTT can be completed, called Basic D-RTT (BD-RTT). T_wait can be characterized as a random variable, which depends on the time between two consecutive uplink messages, and has a distribution that depends on the specific application in use. The message rates at which applications using LPWAN technologies operate may be in the order of seconds, minutes, hours, etc. In some cases, it is possible to program scheduled uplink transmissions, which allow minimizing T_wait, ideally down to zero. Gomez & Crowcroft Expires January 5, 2020 [Page 6] Internet-Draft RTO in LPWAN July 2019 Figure 3 and Figure 4 provide the values for BD-RTT for LoRaWAN (in the EU) and Sigfox, respectively. We assume the same packet sizes considered in the ideal scenario U-RTT study. In LoRaWAN, the BD-RTT does not contain the 1- or 2-second delay between the uplink transmission and the downlink response, therefore BD-RTT is smaller than the ideal scenario U-RTT. In Sigfox, the 1.4-second delay between a downlink transmission and its subsequent uplink confirmation is now added, compared to the ideal scenario U-RTT. +-------------+ | BD-RTT | +----+------+------+ | DR | Min | Max | +----+------+------+ | 0 | 3.52 | 3.81 | +----+------+------+ | 1 | 1.99 | 2.15 | +----+------+------+ | 2 | 0.92 | 1.00 | +----+------+------+ | 3 | 0.73 | 0.82 | +----+------+------+ | 4 | 0.66 | 0.78 | +----+------+------+ | 5 | 0.37 | 0.44 | +----+------+------+ | 6 | 0.19 | 0.22 | +----+------+------+ | 7 | 0.01 | 0.05 | +----+------+------+ Figure 3: Minimum and maximum BD-RTT values (in seconds) for LoRaWAN in the EU, without losses, and in absence of buffering delay and processing delay. Gomez & Crowcroft Expires January 5, 2020 [Page 7] Internet-Draft RTO in LPWAN July 2019 +-------------+ | BD-RTT | +-----+------+------+ |UL BR| Min | Max | +-----+------+------+ | 100 | 23.6 | 48.1 | +-----+------+------+ | 600 | 22.1 | 46.7 | +-----+------+------+ UL BR: uplink bit rate, in bit/s Figure 4: Minimum and maximum BD-RTT values (in seconds) for Sigfox, without losses, and in absence of buffering delay and processing delay. 6. Discussion and proposed dual RTO algorithm The RTO needs to be greater than the RTT in order to avoid spurious timeouts. The latter are particularly expensive in LPWAN due to the message rate constraints in these networks, and also since they consume energy unnecessarily. However, as stated in [I-D.ietf-tcpm-rto-consider], "each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations". If delay is not relevant for an application, setting the default RTO to at least the highest frequently expected RTT, denoted HIGH_RTT, may be a suitable approach. The problem arises when delay, even if at LPWAN scales, matters, and higher order RTTs (e.g. see Section 3) are expected in addition to the ideal scenario ones (e.g. see Section 2). At the very least, the default RTO needs to be greater than the corresponding ideal scenario RTT value shown in Section 2. If higher order RTTs are expected, one option is using a simple dual RTO approach as follows. The LPWAN device keeps two RTO instances. One instance (called Low RTO) is initialized to a suitable ideal scenario RTT, denoted LOW_RTT. The other instance (called High RTO) is initialized to a value of at least HIGH_RTT. The dual RTO operates as follows (see Figure 5): o Initially, the LPWAN device uses the High RTO. Gomez & Crowcroft Expires January 5, 2020 [Page 8] Internet-Draft RTO in LPWAN July 2019 o When the device uses the High RTO, after N_THRESH_LOW consecutive RTT samples lower than THRESH_LOW_RTT, the device switches to using the Low RTO. o When the device uses the Low RTO, after N_THRESH_HIGH consecutive RTT samples greater than THRESH_HIGH_RTT, the device switches back to using the High RTO. +----------+ +--->| High RTO |----+ | +----------+ | if N_THRESH_HIGH | | if N_THRESH_LOW consecutive RTT samples | | consecutive RTT samples > THRESH_HIGH_RTT | | < THRESH_LOW_RTT | +----------+ | +----| Low RTO |<---+ +----------+ Figure 5: State machine of the dual RTO algorithm. The above described dual RTO algorithm may be applied to different RTO approaches, such as a constant RTO, a constant but dithered RTO (e.g. as in default CoAP), an adaptive RTO algorithm (e.g. as in TCP or CoCoA [I-D.ietf-core-cocoa]), etc. If an adaptive RTO is used, performance will benefit from separating lower RTT and higher RTT regimes, avoiding inaccuracy due to a too high RTT variance. Note that the phenomena described in Section 3 are expected to yield systematically large step function RTT distributions. These deviate significantly from the roughly normal/gaussian RTT statistics assumed by the TCP RTO algorithm. Further refinement of the mechanism, to be discussed. 7. Security Considerations TBD 8. Acknowledgments Carles Gomez has been funded in part by the Spanish Government (Ministerio de Ciencia, Innovacion y Universidades) through the Jose Castillejo grant CAS18/00170 and by European Regional Development Fund (ERDF) and the Spanish Government through project TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has Gomez & Crowcroft Expires January 5, 2020 [Page 9] Internet-Draft RTO in LPWAN July 2019 been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [I-D.ietf-core-cocoa] Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, "CoAP Simple Congestion Control/Advanced", draft-ietf- core-cocoa-03 (work in progress), February 2018. [I-D.ietf-lpwan-ipv6-static-context-hc] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. Zuniga, "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP", draft-ietf-lpwan- ipv6-static-context-hc-18 (work in progress), December 2018. [I-D.ietf-tcpm-rto-consider] Allman, M., "Retransmission Timeout Requirements", draft- ietf-tcpm-rto-consider-08 (work in progress), February 2019. [I-D.toutain-core-time-scale] Minaburo, A. and L. Toutain, "CoAP Time Scale Option", draft-toutain-core-time-scale-00 (work in progress), October 2017. [LoRaWAN] L. Casals, B. Mir, R. Vidal, C. Gomez, "Modeling the Energy Performance of LoRaWAN", Sensors, October 2017. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Gomez & Crowcroft Expires January 5, 2020 [Page 10] Internet-Draft RTO in LPWAN July 2019 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, . [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . [Sigfox] C. Gomez, J.C. Veras, R. Vidal, L. Casals, J. Paradells, "A Sigfox Energy Consumption Model", Sensors, February 2019. Authors' Addresses Carles Gomez UPC C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu Jon Crowcroft University of Cambridge JJ Thomson Avenue Cambridge, CB3 0FD United Kingdom Email: jon.crowcroft@cl.cam.ac.uk Gomez & Crowcroft Expires January 5, 2020 [Page 11]