< draft-gomez-lpwan-rto-considerations-00.txt   draft-gomez-lpwan-rto-considerations-01.txt >
Network Working Group C. Gomez LPWAN Working Group C. Gomez
Internet-Draft UPC Internet-Draft UPC
Intended status: Informational J. Crowcroft Intended status: Informational J. Crowcroft
Expires: January 5, 2020 University of Cambridge Expires: January 5, 2020 University of Cambridge
July 4, 2019 July 4, 2019
RTO considerations in LPWAN RTO considerations in LPWAN
draft-gomez-lpwan-rto-considerations-00 draft-gomez-lpwan-rto-considerations-01
Abstract Abstract
Low-Power Wide Area Network (LPWAN) technologies are characterized by Low-Power Wide Area Network (LPWAN) technologies are characterized by
very low physical layer bit and message transmission rates. very low physical layer bit and message transmission rates.
Moreover, a response to a message sent by an LPWAN device may often 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 only be received after a significant delay. As a result, Round-Trip
Time (RTT) values in LPWAN are often (sometimes, significantly) Time (RTT) values in LPWAN are often (sometimes, significantly)
greater than typical default values of Retransmission TimeOut (RTO) greater than typical default values of Retransmission TimeOut (RTO)
algorithms. Furthermore, buffering at network elements such as radio algorithms. Furthermore, buffering at network elements such as radio
skipping to change at page 2, line 16 skipping to change at page 2, line 16
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Ideal scenario RTT . . . . . . . . . . . . . . . . . . . . . 3 3. Ideal scenario U-RTT . . . . . . . . . . . . . . . . . . . . 3
3.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Higher order RTT . . . . . . . . . . . . . . . . . . . . . . 5 4. Higher order U-RTT . . . . . . . . . . . . . . . . . . . . . 5
5. Discussion and proposed dual RTO algorithm . . . . . . . . . 6 5. D-RTT analysis . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Discussion and proposed dual RTO algorithm . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Low-Power Wide Area Network (LPWAN) technologies offer appealing Low-Power Wide Area Network (LPWAN) technologies offer appealing
features, such as multikilometer wireless link range, while allowing features, such as multikilometer wireless link range, while allowing
low energy consumption for Internet of Things (IoT) devices. low energy consumption for Internet of Things (IoT) devices.
However, these advantages come at the expense of reduced physical However, these advantages come at the expense of reduced physical
layer (PHY) bit and message rates, which in some regions are further layer (PHY) bit and message rates, which in some regions are further
affected by spectrum access regulatory constraints. In some LPWAN affected by spectrum access regulatory constraints. In some LPWAN
scenarios, with flagship LPWAN technologies such as LoRaWAN or scenarios, with flagship LPWAN technologies such as LoRaWAN or
skipping to change at page 3, line 14 skipping to change at page 3, line 17
default RTO used to be 3 seconds and was reduced to 1 second default RTO used to be 3 seconds and was reduced to 1 second
[RFC7414]. In a similar order, the Constrained Application Protocol [RFC7414]. In a similar order, the Constrained Application Protocol
(CoAP), which is the preferred application-layer protocol for (CoAP), which is the preferred application-layer protocol for
IPv6-based LPWAN, has a default RTO randomly chosen between 2 and 3 IPv6-based LPWAN, has a default RTO randomly chosen between 2 and 3
seconds [RFC7252]. At the adaptation layer between IPv6 and the seconds [RFC7252]. At the adaptation layer between IPv6 and the
LPWAN technology, some of the Static Context Header Compression LPWAN technology, some of the Static Context Header Compression
(SCHC) fragmentation modes also use RTOs, which need to be defined (SCHC) fragmentation modes also use RTOs, which need to be defined
suitably for each LPWAN technology suitably for each LPWAN technology
[I-D.ietf-lpwan-ipv6-static-context-hc]. [I-D.ietf-lpwan-ipv6-static-context-hc].
This document provides guidance for suitable RTO configuration and/or This document provides guidance for suitable RTO configuration in
usage in LPWAN. First, the document characterizes the RTT for LPWAN. Both the Uplink RTT (U-RTT) and the Downlink RTT (D-RTT) are
LoRaWAN and Sigfox in absence of communication errors, buffering considered. The former refers to an RTT where the first message in
delays or processing delays. Second, higher order RTTs are the RTT is sent in the uplink (and the response is sent in the
described, capturing the impact of message rate limitations due to downlink), whereas the latter refers to the opposite. First, the
regulatory constraints and radio gateway buffering delays. Finally, document characterizes the U-RTT for LoRaWAN and Sigfox in absence of
the document discusses suitable RTO settings in LPWAN, and describes communication errors, buffering delays or processing delays. Second,
an experimental LPWAN-specific dual RTO algorithm. 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 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Ideal scenario RTT 3. Ideal scenario U-RTT
This section provides an analysis of the RTT for relevant LPWAN This section provides an analysis of the U-RTT for relevant LPWAN
technologies, such as LoRaWAN and Sigfox, assuming ideal conditions technologies, such as LoRaWAN and Sigfox, assuming ideal conditions
(i.e. no losses, as well as negligible buffering and processing (i.e. no losses, as well as negligible buffering and processing
delay). For detailed descriptions of LoRaWAN and Sigfox, the reader delay). For detailed descriptions of LoRaWAN and Sigfox, the reader
may refer to the literature [RFC8376][LoRaWAN][Sigfox]. may refer to the literature [RFC8376][LoRaWAN][Sigfox].
In the analysis, the RTT comprises the time since the start of the 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 transmission of an uplink message by an IoT device until a response
is completely received by the IoT device. A 4-byte SCHC-compressed is completely received by the IoT device. A 4-byte SCHC-compressed
IPv6/UDP/CoAP packet is assumed for the downlink response. Of IPv6/UDP/CoAP packet is assumed for the downlink response. Of
course, larger sized packets will lead to greater RTTs. course, larger sized packets will lead to greater RTTs.
3.1. LoRaWAN 3.1. LoRaWAN
Figure 1 shows the minimum and maximum theoretical RTT values for 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 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 assume a 4-byte uplink frame payload, and a downlink response sent in
the first receive window. For the maximum ones, we assume the the first receive window. For the maximum ones, we assume the
maximum allowed uplink payload size for each Data Rate (DR), and a maximum allowed uplink payload size for each Data Rate (DR), and a
downlink response sent in the second receive window. Note that there downlink response sent in the second receive window. Note that there
is a 1- or 2-second delay between the uplink transmission and the is a 1- or 2-second delay between the uplink transmission and the
first or second receive window, respectively. first or second receive window, respectively.
+------------------------+ +------------------------+
| Maximum | | Maximum |
skipping to change at page 4, line 32 skipping to change at page 4, line 41
| 5 | 242 | 0.40 | 0.04 | 1.37 | 2.44 | | 5 | 242 | 0.40 | 0.04 | 1.37 | 2.44 |
+----+--------+-------+-------+------+------+ +----+--------+-------+-------+------+------+
| 6 | 242 | 0.20 | 0.02 | 1.19 | 2.22 | | 6 | 242 | 0.20 | 0.02 | 1.19 | 2.22 |
+----+--------+-------+-------+------+------+ +----+--------+-------+-------+------+------+
| 7 | 242 | 0.04 | 0.003| 1.00 | 2.05 | | 7 | 242 | 0.04 | 0.003| 1.00 | 2.05 |
+----+--------+-------+-------+------+------+ +----+--------+-------+-------+------+------+
ULpld: uplink frame payload, in bytes ULpld: uplink frame payload, in bytes
TtxUL: uplink frame transmission time, in seconds TtxUL: uplink frame transmission time, in seconds
TtxDL: downlink frame transmission time, in seconds TtxDL: downlink frame transmission time, in seconds
RTTmin: minimum RTT, in seconds RTTmin: minimum U-RTT, in seconds
RTTmax: maximum RTT, in seconds RTTmax: maximum U-RTT, in seconds
Figure 1: Minimum and maximum RTT values for LoRaWAN in the EU, Figure 1: Minimum and maximum U-RTT values for LoRaWAN in the EU,
without losses, and in absence of buffering delay and processing without losses, and in absence of buffering delay and processing
delay. delay.
As shown in Figure 1, and under the conditions assumed, the minimum As shown in Figure 1, and under the conditions assumed, the minimum
RTT value for DR0 will always (for DR1, will almost always) exceed U-RTT value for DR0 will always (for DR1, will almost always) exceed
the default CoAP RTO. The maximum RTT will always exceed the default the default CoAP RTO. The maximum U-RTT will always exceed the
CoAP RTO for DR0-DR2, and will often exceed the default CoAP RTO for default CoAP RTO for DR0-DR2, and will often exceed the default CoAP
DR3-DR7. Note that since DR6 and DR7 are optional, they are not RTO for DR3-DR7. Note that since DR6 and DR7 are optional, they are
necessarily supported in real deployments. not necessarily supported in real deployments.
3.2. Sigfox 3.2. Sigfox
Figure 2 shows the minimum and maximum theoretical RTT values for 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 Sigfox in ideal conditions. For the minimum ones, we assume a 4-byte
uplink frame payload, and a downlink response sent right at the uplink frame payload, and a downlink response sent right at the
beginning of the downlink receive window. For the maximum ones, we beginning of the downlink receive window. For the maximum ones, we
assume the maximum allowed uplink payload size, and a downlink assume the maximum allowed uplink payload size, and a downlink
response sent at the end of the receive window. Note that there is a 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 20-second delay between the frame uplink transmission and the start
of the downlink receive window. of the downlink receive window.
+------------------------+ +------------------------+
| Maximum | | Maximum |
skipping to change at page 5, line 24 skipping to change at page 5, line 32
+-----+--------+-------+-------+------+------+ +-----+--------+-------+-------+------+------+
| 100 | 12 | 2.08 | 0.39 | 21.8 | 47.1 | | 100 | 12 | 2.08 | 0.39 | 21.8 | 47.1 |
+-----+--------+-------+-------+------+------+ +-----+--------+-------+-------+------+------+
| 600 | 12 | 0.35 | 0.39 | 20.6 | 45.4 | | 600 | 12 | 0.35 | 0.39 | 20.6 | 45.4 |
+-----+--------+-------+-------+------+------+ +-----+--------+-------+-------+------+------+
UL BR: uplink bit rate, in bit/s UL BR: uplink bit rate, in bit/s
ULpld: uplink frame payload, in bytes ULpld: uplink frame payload, in bytes
TtxUL: uplink frame transmission time, in seconds TtxUL: uplink frame transmission time, in seconds
TtxDL: downlink frame transmission time, in seconds TtxDL: downlink frame transmission time, in seconds
RTTmin: minimum RTT, in seconds RTTmin: minimum U-RTT, in seconds
RTTmax: maximum RTT, in seconds RTTmax: maximum U-RTT, in seconds
Figure 2: Minimum and maximum RTT values for Sigfox, without losses, Figure 2: Minimum and maximum U-RTT values for Sigfox, without
and in absence of buffering delay and processing delay. losses, and in absence of buffering delay and processing delay.
As shown in Figure 2, and under the conditions assumed, the RTT in As shown in Figure 2, and under the conditions assumed, the U-RTT in
Sigfox will be one order of magnitude greater than the default CoAP Sigfox is one order of magnitude greater than the default CoAP RTO
RTO for all uplink bit rates and uplink frame payload sizes. for all uplink bit rates and uplink frame payload sizes.
4. Higher order RTT 4. Higher order U-RTT
The high RTTs found in ideal conditions can be further exacerbated by The high U-RTTs found in ideal conditions can be further exacerbated
two further behaviours of LPWAN networks: i) policies for compliance by two further behaviours of LPWAN networks: i) policies for
with duty cycle constraints, and ii) radio gateway buffering delays. compliance with duty cycle constraints, and ii) radio gateway
buffering delays.
EU spectrum access regulations for some ISM bands used by LPWAN EU spectrum access regulations for some ISM bands used by LPWAN
technologies state that, unless listen-before-talk is used, the duty 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 cycle needs to be lower than some limit (e.g. 1% in some frequency
bands). Both LoRaWAN and Sigfox need to comply with such bands). Both LoRaWAN and Sigfox need to comply with such
regulations. There may be different applicable policies intended to regulations. There may be different applicable policies intended to
ensure compliance with the regulations. In one of them, in order to ensure compliance with the regulations. In one of them, in order to
comply with the 1% duty cycle limitation, after sending an uplink comply with the 1% duty cycle limitation, after sending an uplink
frame, an IoT device keeps an idle period equal to 99 times the frame, an IoT device keeps an idle period equal to 99 times the
transmission time of the uplink frame. Such a policy may increase transmission time of the uplink frame. Such a policy may increase
the RTT by up to two orders of magnitude. For example, in LoRaWAN, the RTT by up to two orders of magnitude. For example, in LoRaWAN,
this policy leads to RTTs that will always exceed the default CoAP this policy leads to U-RTTs that will always exceed the default CoAP
RTO, leading to an RTT of up to 282 seconds in the worst case. 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 Another phenomenon that may happen in LPWAN relates with the fact
that in some technologies and scenarios (e.g. the most typical that in some technologies and scenarios (e.g. the most typical
LoRaWAN class, called class A, and in Sigfox), a downlink frame can LoRaWAN class, called class A, and in Sigfox), a downlink frame can
only be sent during a given time interval (called receive window) only be sent during a given time interval (called receive window)
after the uplink frame transmission. If a radio gateway misses the after the uplink frame transmission. If a radio gateway misses the
opportunity to send a downlink response to an uplink frame (e.g. opportunity to send a downlink response to an uplink frame (e.g.
because the radio gateway is busy sending other downlink messages or because the radio gateway is busy sending other downlink messages or
because it needs to refrain from transmitting immediately in order to because it needs to refrain from transmitting immediately in order to
comply with duty cycle regulations), the response to an uplink frame comply with duty cycle regulations), the response to an uplink frame
may be queued by the radio gateway until the next opportunity for may be queued by the radio gateway until the next opportunity for
sending a downlink frame. This problem has already been described in sending a downlink frame. This problem has already been described in
[I-D.toutain-core-time-scale]. If the problem occurs, the RTT will [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 be tied to the time between two uplink consecutive frames. Depending
on the application and its traffic pattern, such time may take values on the application and its traffic pattern, such time may take values
in the order of seconds, minutes, hours or even days. in the order of seconds, minutes, hours or even days.
5. Discussion and proposed dual RTO algorithm 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.
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.
+-------------+
| 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 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 timeouts. The latter are particularly expensive in LPWAN due to the
message rate constraints in these networks, and also since they message rate constraints in these networks, and also since they
consume energy unnecessarily. However, as stated in consume energy unnecessarily. However, as stated in
[I-D.ietf-tcpm-rto-consider], "each implementation of a [I-D.ietf-tcpm-rto-consider], "each implementation of a
retransmission timeout mechanism represents a balance between retransmission timeout mechanism represents a balance between
correctness and timeliness and therefore no implementation suits all correctness and timeliness and therefore no implementation suits all
situations". situations".
If delay is not relevant for an application, setting the default RTO If delay is not relevant for an application, setting the default RTO
to at least the highest frequently expected RTT, denoted HIGH_RTT, to at least the highest frequently expected RTT, denoted HIGH_RTT,
may be a suitable approach. may be a suitable approach.
The problem arises when delay, even if at LPWAN scales, matters, and The problem arises when delay, even if at LPWAN scales, matters, and
higher order RTTs (Section 3) are expected in addition to the ideal higher order RTTs (e.g. see Section 3) are expected in addition to
scenario ones (Section 2). At the very least, the default RTO needs the ideal scenario ones (e.g. see Section 2). At the very least, the
to be greater than the corresponding ideal scenario RTT value shown default RTO needs to be greater than the corresponding ideal scenario
in Section 2. If higher order RTTs are expected, one option is using RTT value shown in Section 2. If higher order RTTs are expected, one
a simple dual RTO approach as follows. option is using a simple dual RTO approach as follows.
The LPWAN device keeps two RTO instances. One instance (called Low The LPWAN device keeps two RTO instances. One instance (called Low
RTO) is initialized to a suitable ideal scenario RTT, denoted RTO) is initialized to a suitable ideal scenario RTT, denoted
LOW_RTT. The other instance (called High RTO) is initialized to a 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 value of at least HIGH_RTT. The dual RTO operates as follows (see
Figure 3): Figure 5):
o Initially, the LPWAN device uses the High RTO. o Initially, the LPWAN device uses the High RTO.
o When the device uses the High RTO, after N_THRESH_LOW consecutive o When the device uses the High RTO, after N_THRESH_LOW consecutive
RTT samples lower than THRESH_LOW_RTT, the device switches to RTT samples lower than THRESH_LOW_RTT, the device switches to
using the Low RTO. using the Low RTO.
o When the device uses the Low RTO, after N_THRESH_HIGH consecutive o When the device uses the Low RTO, after N_THRESH_HIGH consecutive
RTT samples greater than THRESH_HIGH_RTT, the device switches back RTT samples greater than THRESH_HIGH_RTT, the device switches back
to using the High RTO. to using the High RTO.
skipping to change at page 7, line 23 skipping to change at page 9, line 23
+----------+ +----------+
+--->| High RTO |----+ +--->| High RTO |----+
| +----------+ | | +----------+ |
if N_THRESH_HIGH | | if N_THRESH_LOW if N_THRESH_HIGH | | if N_THRESH_LOW
consecutive RTT samples | | consecutive RTT samples consecutive RTT samples | | consecutive RTT samples
> THRESH_HIGH_RTT | | < THRESH_LOW_RTT > THRESH_HIGH_RTT | | < THRESH_LOW_RTT
| +----------+ | | +----------+ |
+----| Low RTO |<---+ +----| Low RTO |<---+
+----------+ +----------+
Figure 3: State machine of the dual RTO algorithm. Figure 5: State machine of the dual RTO algorithm.
The above described dual RTO algorithm may be applied to different The above described dual RTO algorithm may be applied to different
RTO approaches, such as a constant RTO, a constant but dithered RTO 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 (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, or CoCoA [I-D.ietf-core-cocoa]), etc. If an adaptive RTO is used,
performance will benefit from separating lower RTT and higher RTT performance will benefit from separating lower RTT and higher RTT
regimes, avoiding inaccuracy due to a too high RTT variance. Note regimes, avoiding inaccuracy due to a too high RTT variance. Note
that the phenomena described in Section 3 are expected to yield that the phenomena described in Section 3 are expected to yield
systematically large step function RTT distributions. These deviate systematically large step function RTT distributions. These deviate
significantly from the roughly normal/gaussian RTT statistics assumed significantly from the roughly normal/gaussian RTT statistics assumed
by the TCP RTO algorithm. by the TCP RTO algorithm.
Further refinement of the mechanism, to be discussed. Further refinement of the mechanism, to be discussed.
6. Security Considerations 7. Security Considerations
TBD TBD
7. Acknowledgments 8. Acknowledgments
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Ciencia, Innovacion y Universidades) through the Jose (Ministerio de Ciencia, Innovacion y Universidades) through the Jose
Castillejo grant CAS18/00170 and by European Regional Development Castillejo grant CAS18/00170 and by European Regional Development
Fund (ERDF) and the Spanish Government through project Fund (ERDF) and the Spanish Government through project
TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has TEC2016-79988-P, AEI/FEDER, UE. His contribution to this work has
been carried out during his stay as a visiting scholar at the been carried out during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge. Computer Laboratory of the University of Cambridge.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-core-cocoa] [I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-ietf- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-03 (work in progress), February 2018. core-cocoa-03 (work in progress), February 2018.
[I-D.ietf-lpwan-ipv6-static-context-hc] [I-D.ietf-lpwan-ipv6-static-context-hc]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
Zuniga, "LPWAN Static Context Header Compression (SCHC) Zuniga, "LPWAN Static Context Header Compression (SCHC)
and fragmentation for IPv6 and UDP", draft-ietf-lpwan- and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
 End of changes. 28 change blocks. 
61 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/