[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-gomez-rto-considerations-lpwan) 00 01

Network 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-00

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 RTT  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Sigfox  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Higher order RTT  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Discussion and proposed dual RTO algorithm  . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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).

   The described RTTs, as well as their potential variability, are
   significantly greater than typical ones on the Internet.  In TCP, the



Gomez & Crowcroft        Expires January 5, 2020                [Page 2]


Internet-Draft                RTO in LPWAN                     July 2019


   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 and/or
   usage in LPWAN.  First, the document characterizes the RTT for
   LoRaWAN and Sigfox in absence of communication errors, buffering
   delays or processing delays.  Second, higher order RTTs are
   described, capturing the impact of message rate limitations due to
   regulatory constraints and radio gateway buffering delays.  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 RTT

   This section provides an analysis of the 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 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.

3.1.  LoRaWAN

   Figure 1 shows the minimum and maximum theoretical 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




Gomez & Crowcroft        Expires January 5, 2020                [Page 3]


Internet-Draft                RTO in LPWAN                     July 2019


   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 RTT, in seconds
        RTTmax:   maximum RTT, in seconds


      Figure 1: Minimum and maximum 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
   RTT value for DR0 will always (for DR1, will almost always) exceed
   the default CoAP RTO.  The maximum RTT will always exceed the default
   CoAP RTO for DR0-DR2, and will often exceed the default CoAP 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 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



Gomez & Crowcroft        Expires January 5, 2020                [Page 4]


Internet-Draft                RTO in LPWAN                     July 2019


   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 RTT, in seconds
        RTTmax:   maximum RTT, in seconds


   Figure 2: Minimum and maximum 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 RTT in
   Sigfox will be one order of magnitude greater than the default CoAP
   RTO for all uplink bit rates and uplink frame payload sizes.

4.  Higher order RTT

   The high 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
   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,




Gomez & Crowcroft        Expires January 5, 2020                [Page 5]


Internet-Draft                RTO in LPWAN                     July 2019


   this policy leads to RTTs that will always exceed the default CoAP
   RTO, leading to an 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 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.  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 (Section 3) are expected in addition to the ideal
   scenario ones (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 3):

   o  Initially, the LPWAN device uses the High RTO.



Gomez & Crowcroft        Expires January 5, 2020                [Page 6]


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 3: 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.

6.  Security Considerations

   TBD

7.  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 7]


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.

8.  References

8.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,
              <https://www.rfc-editor.org/info/rfc2119>.

8.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,
              <https://www.rfc-editor.org/info/rfc7252>.








Gomez & Crowcroft        Expires January 5, 2020                [Page 8]


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,
              <https://www.rfc-editor.org/info/rfc7414>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [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 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/