draft-ietf-lwig-tcp-constrained-node-networks-09.txt   draft-ietf-lwig-tcp-constrained-node-networks-10.txt 
LWIG Working Group C. Gomez LWIG Working Group C. Gomez
Internet-Draft UPC Internet-Draft UPC
Intended status: Informational J. Crowcroft Intended status: Informational J. Crowcroft
Expires: May 6, 2020 University of Cambridge Expires: March 10, 2021 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
November 3, 2019 September 6, 2020
TCP Usage Guidance in the Internet of Things (IoT) TCP Usage Guidance in the Internet of Things (IoT)
draft-ietf-lwig-tcp-constrained-node-networks-09 draft-ietf-lwig-tcp-constrained-node-networks-10
Abstract Abstract
This document provides guidance on how to implement and use the This document provides guidance on how to implement and use the
Transmission Control Protocol (TCP) in Constrained-Node Networks Transmission Control Protocol (TCP) in Constrained-Node Networks
(CNNs), which are a characterstic of the Internet of Things (IoT). (CNNs), which are a characterstic of the Internet of Things (IoT).
Such environments require a lightweight TCP implementation and may Such environments require a lightweight TCP implementation and may
not make use of optional functionality. This document explains a not make use of optional functionality. This document explains a
number of known and deployed techniques to simplify a TCP stack as number of known and deployed techniques to simplify a TCP stack as
well as corresponding tradeoffs. The objective is to help embedded well as corresponding tradeoffs. The objective is to help embedded
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2020. This Internet-Draft will expire on March 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 14 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 14
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 14 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 14
5.2. Number of concurrent connections . . . . . . . . . . . . 14 5.2. Number of concurrent connections . . . . . . . . . . . . 14
5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 15 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. Annex. TCP implementations for constrained devices . . . . . 18 8. Annex. TCP implementations for constrained devices . . . . . 18
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 20
8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Annex. Changes compared to previous versions . . . . . . . . 22 9. Annex. Changes compared to previous versions . . . . . . . . 22
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 22 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 22
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 22 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 22
9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 22 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 22
9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 23 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 23
9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 23 9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 23
9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 23 9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 23
9.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 23 9.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 23
9.8. Changes between -07 and -08 . . . . . . . . . . . . . . . 23 9.8. Changes between -07 and -08 . . . . . . . . . . . . . . . 23
9.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 23 9.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 23
9.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Internet Protocol suite is being used for connecting Constrained- The Internet Protocol suite is being used for connecting Constrained-
Node Networks (CNNs) to the Internet, enabling the so-called Internet Node Networks (CNNs) to the Internet, enabling the so-called Internet
of Things (IoT) [RFC7228]. In order to meet the requirements that of Things (IoT) [RFC7228]. In order to meet the requirements that
skipping to change at page 7, line 24 skipping to change at page 7, line 24
[RFC8201]. In addition, an IP datagram size of 1280 bytes avoids [RFC8201]. In addition, an IP datagram size of 1280 bytes avoids
incurring IPv6-layer fragmentation. incurring IPv6-layer fragmentation.
An IPv6 datagram size exceeding 1280 bytes can be avoided by setting An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
the TCP MSS not larger than 1220 bytes. This assumes that the remote the TCP MSS not larger than 1220 bytes. This assumes that the remote
sender will use no TCP options, aside from possibly the MSS option, sender will use no TCP options, aside from possibly the MSS option,
which is only used in the initial TCP SYN packet. which is only used in the initial TCP SYN packet.
In order to accommodate unrequested TCP options that may be used by In order to accommodate unrequested TCP options that may be used by
some TCP implementations, a constrained device may advertise an MSS some TCP implementations, a constrained device may advertise an MSS
smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that
that, in many implementations, TCP options generally consume payload it is advised for TCP implementations to consume payload space
space instead of increasing datagram size, therefore this suggestion instead of increasing datagram size when including IP or TCP options
might be overcautious and its suitability will depend on each in an IP packet to be sent [RFC6691]. Therefore, the suggestion of
specific scenario. advertising an MSS smaller than 1220 bytes is likely to be
overcautious and its suitability should be considered carefully.
Note that setting the MTU to 1280 bytes is possible for link layer Note that setting the MTU to 1280 bytes is possible for link layer
technologies in the CNN space, even if some of them are characterized technologies in the CNN space, even if some of them are characterized
by a short data unit payload size, e.g. up to a few tens or hundreds by a short data unit payload size, e.g. up to a few tens or hundreds
of bytes. For example, the maximum frame size in IEEE 802.15.4 is of bytes. For example, the maximum frame size in IEEE 802.15.4 is
127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over 127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over
IEEE 802.15.4 networks. The adaptation layer includes a IEEE 802.15.4 networks. The adaptation layer includes a
fragmentation mechanism, since IPv6 requires the layer below to fragmentation mechanism, since IPv6 requires the layer below to
support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked
fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU
skipping to change at page 8, line 7 skipping to change at page 8, line 7
On the other hand, there exist technologies also used in the CNN On the other hand, there exist technologies also used in the CNN
space, such as Master Slave / Token Passing (TP) [RFC8163], space, such as Master Slave / Token Passing (TP) [RFC8163],
Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah
[I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of
frame size limitations as the technologies mentioned above. The MTU frame size limitations as the technologies mentioned above. The MTU
for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB-
IoT is 1600 bytes, and the maximum frame payload size for IEEE IoT is 1600 bytes, and the maximum frame payload size for IEEE
802.11ah is 7991 bytes. 802.11ah is 7991 bytes.
Finally, note that using larger MSS (to a suitable extent) may be Note that using larger MSS (to a suitable extent) may be beneficial,
beneficial, especially when transferring large payloads, as it especially when transferring large payloads, as it reduces the number
reduces the number of packets (and packet headers) required for a of packets (and packet headers) required for a given payload.
given payload. However, use of MTUs that exceed 1280 bytes (including the typical
1500-byte MTU for communication paths including broader Internet
segments) may incur Path MTU Discovery overhead.
4.1.2. Explicit Congestion Notification (ECN) 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router
to signal in the IP header of a packet that congestion is arising, to signal in the IP header of a packet that congestion is arising,
for example when a queue size reaches a certain threshold. An ECN- for example when a queue size reaches a certain threshold. An ECN-
enabled TCP receiver will echo back the congestion signal to the TCP enabled TCP receiver will echo back the congestion signal to the TCP
sender by setting a flag in its next TCP ACK. The sender triggers sender by setting a flag in its next TCP ACK. The sender triggers
congestion control measures as if a packet loss had happened. congestion control measures as if a packet loss had happened.
The document [RFC8087] outlines the principal gains in terms of The document [RFC8087] outlines the principal gains in terms of
increased throughput, reduced delay, and other benefits when ECN is increased throughput, reduced delay, and other benefits when ECN is
used over a network path that includes equipment that supports used over a network path that includes equipment that supports
Congestion Experienced (CE) marking. In the context of CNNs, a Congestion Experienced (CE) marking. In the context of CNNs, a
remarkable feature of ECN is that congestion can be signalled without remarkable feature of ECN is that congestion can be signalled without
incurring packet drops (which will lead to retransmissions and incurring packet drops (which will lead to retransmissions and
consumption of limited resources such as energy and bandwitdh). consumption of limited resources such as energy and bandwitdh).
ECN can further reduce packet losses since congestion control ECN can further reduce packet losses since congestion control
measures can be applied earlier [RFC2884]. Less lost packets implies measures can be applied earlier [RFC2884]. Fewer lost packets
that the number of retransmitted segments decreases, which is implies that the number of retransmitted segments decreases, which is
particularly beneficial in CNNs, where energy and bandwidth resources particularly beneficial in CNNs, where energy and bandwidth resources
are typically limited. Also, it makes sense to try to avoid packet are typically limited. Also, it makes sense to try to avoid packet
drops for transactional workloads with small data sizes, which are drops for transactional workloads with small data sizes, which are
typical for CNNs. In such traffic patterns, it is more difficult and typical for CNNs. In such traffic patterns, it is more difficult and
often impossible to detect packet loss without retransmission often impossible to detect packet loss without retransmission
timeouts (e.g., as there may be no three duplicate ACKs). Any timeouts (e.g., as there may be no three duplicate ACKs). Any
retransmission timeout slows down the data transfer significantly. retransmission timeout slows down the data transfer significantly.
In addition, if the constrained device uses power saving techniques, In addition, if the constrained device uses power saving techniques,
a retransmission timeout will incur a wake-up action, in contrast to a retransmission timeout will incur a wake-up action, in contrast to
ACK clock- triggered sending. When the congestion window of a TCP ACK clock- triggered sending. When the congestion window of a TCP
skipping to change at page 11, line 12 skipping to change at page 11, line 16
MSS of data or the receiver advertises a receive window not greater MSS of data or the receiver advertises a receive window not greater
than the MSS, Delayed ACKs may unnecessarily contribute delay (up to than the MSS, Delayed ACKs may unnecessarily contribute delay (up to
500 ms) to the RTT [RFC5681], which limits the throughput and can 500 ms) to the RTT [RFC5681], which limits the throughput and can
increase data delivery time. Note that, in some cases, it may not be increase data delivery time. Note that, in some cases, it may not be
possible to disable Delayed ACKs. One known workaround is to split possible to disable Delayed ACKs. One known workaround is to split
the data to be sent into two segments of smaller size. A standard the data to be sent into two segments of smaller size. A standard
compliant TCP receiver may immediately acknowledge the second MSS of compliant TCP receiver may immediately acknowledge the second MSS of
data, which can improve throughput. However, this 'split hack' may data, which can improve throughput. However, this 'split hack' may
not always work since a TCP receiver is required to acknowledge every not always work since a TCP receiver is required to acknowledge every
second full-sized segment, but not two consecutive small segments. second full-sized segment, but not two consecutive small segments.
Furthermore, the overhead of sending two IP packets instead of one is The overhead of sending two IP packets instead of one is another
another downside of the 'split hack'. downside of the 'split hack'.
Similar issues may happen when the sender uses the Nagle algorithm, Similar issues may happen when the sender uses the Nagle algorithm,
since the sender may need to wait for an unnecessarily delayed ACK to since the sender may need to wait for an unnecessarily delayed ACK to
send a new segment. Disabling the algorithm will not have impact if send a new segment. Disabling the algorithm will not have impact if
the sender can only handle stop-and-wait operation at the TCP level. the sender can only handle stop-and-wait operation at the TCP level.
For request-response traffic, when the receiver uses Delayed ACKs, a For request-response traffic, when the receiver uses Delayed ACKs, a
response to a data message can piggyback an ACK, as long as the response to a data message can piggyback an ACK, as long as the
latter is sent before the Delayed ACK timer expires, thus avoiding latter is sent before the Delayed ACK timer expires, thus avoiding
unnecessary ACKs without payload. Disabling Delayed ACKs at the unnecessary ACKs without payload. Disabling Delayed ACKs at the
skipping to change at page 12, line 20 skipping to change at page 12, line 20
This section is not comprehensive. A comprehensive survey of TCP This section is not comprehensive. A comprehensive survey of TCP
extensions is published in [RFC7414]. extensions is published in [RFC7414].
4.3.1. Loss recovery and congestion/flow control 4.3.1. Loss recovery and congestion/flow control
Devices that have enough memory to allow a larger (i.e. more than 3 Devices that have enough memory to allow a larger (i.e. more than 3
MSS of data) TCP window size can leverage a more efficient loss MSS of data) TCP window size can leverage a more efficient loss
recovery than the timer-based approach used for smaller TCP window recovery than the timer-based approach used for smaller TCP window
size (see Subsection 3.2.1) by using Fast Retransmit and Fast size (see Subsection 3.2.1) by using Fast Retransmit and Fast
Recovery [RFC5681], at the expense of slightly greater complexity and Recovery [RFC5681], at the expense of slightly greater complexity and
TCB size. Assuming that Delayed ACKs are used by the receiver, a Transmission Control Block (TCB) size. Assuming that Delayed ACKs
window size of up to 5 MSS is required for Fast Retransmit and Fast are used by the receiver, a window size of up to 5 MSS is required
Recovery to work efficiently: If in a given TCP transmission of full- for Fast Retransmit and Fast Recovery to work efficiently: If in a
sized segments 1, 2, 3, 4, and 5, segment 2 gets lost, and the ACK given TCP transmission of full-sized segments 1, 2, 3, 4, and 5,
for segment 1 is held by the Delayed ACK timer, then the sender segment 2 gets lost, and the ACK for segment 1 is held by the Delayed
should get an ACK for segment 1 when 3 arrives and duplicate ACKs ACK timer, then the sender should get an ACK for segment 1 when 3
when segments 4, 5, and 6 arrive. It will retransmit segment 2 when arrives and duplicate ACKs when segments 4, 5, and 6 arrive. It will
the third duplicate ACK arrives. In order to have segments 2, 3, 4, retransmit segment 2 when the third duplicate ACK arrives. In order
5, and 6 sent, the window has to be of at least 5 MSS. With an MSS to have segments 2, 3, 4, 5, and 6 sent, the window has to be of at
of 1220 bytes, a buffer of a size of 5 MSS would require 6100 bytes. least 5 MSS. With an MSS of 1220 bytes, a buffer of a size of 5 MSS
would require 6100 bytes.
The example in the previous paragraph did not use a further TCP The example in the previous paragraph did not use a further TCP
improvement such as Limited Transmit [RFC3042]. The latter may also improvement such as Limited Transmit [RFC3042]. The latter may also
be useful for any transfer that has more than one segment in flight. be useful for any transfer that has more than one segment in flight.
Small transfers tend to benefit more from Limited Transmit, because Small transfers tend to benefit more from Limited Transmit, because
they are more likely to not receive enough duplicate ACKs. Assuming they are more likely to not receive enough duplicate ACKs. Assuming
the example in the previous paragraph, Limited Transmit allows the example in the previous paragraph, Limited Transmit allows
sending 5 MSS with a congestion window (cwnd) of 3 segments, plus two sending 5 MSS with a congestion window (cwnd) of 3 segments, plus two
additional segments for the first two duplicate ACKs. With Limited additional segments for the first two duplicate ACKs. With Limited
Transmit, even a cwnd of 2 segments allows sending 5 MSS, at the Transmit, even a cwnd of 2 segments allows sending 5 MSS, at the
skipping to change at page 14, line 45 skipping to change at page 14, line 46
In the constrained device to unconstrained device scenario In the constrained device to unconstrained device scenario
illustrated above, a TCP connection is typically initiated by the illustrated above, a TCP connection is typically initiated by the
constrained device, in order for this device to support possible constrained device, in order for this device to support possible
sleep periods to save energy. sleep periods to save energy.
5.2. Number of concurrent connections 5.2. Number of concurrent connections
TCP endpoints with a small amount of memory may only support a small TCP endpoints with a small amount of memory may only support a small
number of connections. Each TCP connection requires storing a number number of connections. Each TCP connection requires storing a number
of variables in the Transmission Control Block (TCB). Depending on of variables in the TCB. Depending on the internal TCP
the internal TCP implementation, each connection may result in implementation, each connection may result in further memory
further memory overhead, and connections may compete for scarce overhead, and connections may compete for scarce resources (e.g.
resources (e.g. further memory overhead for send and receive buffers, further memory overhead for send and receive buffers, etc).
etc).
A careful application design may try to keep the number of concurrent A careful application design may try to keep the number of concurrent
connections as small as possible. A client can for instance limit connections as small as possible. A client can for instance limit
the number of simultaneous open connections that it maintains to a the number of simultaneous open connections that it maintains to a
given server. Multiple connections could for instance be used to given server. Multiple connections could for instance be used to
avoid the "head-of-line blocking" problem in an application transfer. avoid the "head-of-line blocking" problem in an application transfer.
However, in addition to consuming resources, using multiple However, in addition to consuming resources, using multiple
connections can also cause undesirable side effects in congested connections can also cause undesirable side effects in congested
networks. For example, the HTTP/1.1 specification encourages clients networks. For example, the HTTP/1.1 specification encourages clients
to be conservative when opening multiple connections [RFC7230]. to be conservative when opening multiple connections [RFC7230].
skipping to change at page 15, line 45 skipping to change at page 15, line 45
to the TCP endpoints. to the TCP endpoints.
In CNNs, such middleboxes may e.g. be present at the boundary between In CNNs, such middleboxes may e.g. be present at the boundary between
the CNN and other networks. If the middlebox can be optimized for the CNN and other networks. If the middlebox can be optimized for
CNN use cases, it makes sense to increase the initial value for CNN use cases, it makes sense to increase the initial value for
filter state inactivity timers to avoid problems with idle filter state inactivity timers to avoid problems with idle
connections. Apart from that, this problem can be dealt with by connections. Apart from that, this problem can be dealt with by
different connection handling strategies, each having pros and cons. different connection handling strategies, each having pros and cons.
One approach for infrequent data transfer is to use short-lived TCP One approach for infrequent data transfer is to use short-lived TCP
connections. Instead of trying to maintain a TCP connection for long connections. Instead of trying to maintain a TCP connection for a
time, possibly short-lived connections can be opened between two long time, possibly short-lived connections can be opened between two
endpoints, which are closed if no more data needs to be exchanged. endpoints, which are closed if no more data needs to be exchanged.
For use cases that can cope with the additional messages and the For use cases that can cope with the additional messages and the
latency resulting from starting new connections, it is recommended to latency resulting from starting new connections, it is recommended to
use a sequence of short-lived connections, instead of maintaining a use a sequence of short-lived connections, instead of maintaining a
single long-lived connection. single long-lived connection.
The message and latency overhead that stems from using a sequence of The message and latency overhead that stems from using a sequence of
short-lived connections could be reduced by TCP Fast Open (TFO) short-lived connections could be reduced by TCP Fast Open (TFO)
[RFC7413], which is an experimental TCP extension, at the expense of [RFC7413], which is an experimental TCP extension, at the expense of
increased implementation complexity and increased TCP Control Block increased implementation complexity and increased TCP Control Block
skipping to change at page 17, line 49 skipping to change at page 17, line 49
ones. Mitigation techniques include RTO randomization and attack ones. Mitigation techniques include RTO randomization and attack
blocking by routers able to detect shrew attacks based on their blocking by routers able to detect shrew attacks based on their
traffic pattern. traffic pattern.
7. Acknowledgments 7. 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 Educacion, Cultura y Deporte) through the Jose (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grants CAS15/00336 and and CAS18/00170, and by European Castillejo grants CAS15/00336 and and CAS18/00170, and by European
Regional Development Fund (ERDF) and the Spanish Government through Regional Development Fund (ERDF) and the Spanish Government through
project TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, UE, and by
this work has been carried out during his stays as a visiting scholar Generalitat de Catalunya Grant 2017 SGR 376. Part of his
at the Computer Laboratory of the University of Cambridge. contribution to this work has been carried out during his stays as a
visiting scholar at the Computer Laboratory of the University of
Cambridge.
The authors appreciate the feedback received for this document. The The authors appreciate the feedback received for this document. The
following folks provided comments that helped improve the document: following folks provided comments that helped improve the document:
Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan
Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred
Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes
Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen, Emmanuel Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen, Emmanuel
Baccelli, Stuart Cheshire, Gorry Fairhurst, and Ingemar Johansson. Baccelli, Stuart Cheshire, Gorry Fairhurst, and Ingemar Johansson.
Simon Brummer provided details, and kindly performed RAM and ROM Simon Brummer provided details, and kindly performed RAM and ROM
usage measurements, on the RIOT TCP implementation. Xavi Vilajosana usage measurements, on the RIOT TCP implementation. Xavi Vilajosana
skipping to change at page 18, line 32 skipping to change at page 18, line 34
constrained devices. The survey is limited to open source stacks constrained devices. The survey is limited to open source stacks
with small footprint. It is not meant to be all-encompassing. For with small footprint. It is not meant to be all-encompassing. For
more powerful embedded systems (e.g., with 32-bit processors), there more powerful embedded systems (e.g., with 32-bit processors), there
are further stacks that comprehensively implement TCP. On the other are further stacks that comprehensively implement TCP. On the other
hand, please be aware that this Annex is based on information hand, please be aware that this Annex is based on information
available as of the writing. available as of the writing.
8.1. uIP 8.1. uIP
uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers, uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers,
which pioneered TCP/IP implementations for constrained devices. uIP which pioneered TCP/IP implementations for constrained devices. uIP
has been deployed with Contiki and the Arduino Ethernet shield. A has been deployed with Contiki and the Arduino Ethernet shield. A
code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) code size of ~5 kB (which comprises checksumming, IPv4, ICMP and TCP)
has been reported for uIP [Dunk]. has been reported for uIP [Dunk]. Later versions of uIP implement
IPv6 as well.
uIP uses the same global buffer for both incoming and outgoing uIP uses the same global buffer for both incoming and outgoing
traffic, which has a size of a single packet. In case of a traffic, which has a size of a single packet. In case of a
retransmission, an application must be able to reproduce the same retransmission, an application must be able to reproduce the same
user data that had been transmitted. Multiple connections are user data that had been transmitted. Multiple connections are
supported, but need to share the global buffer. supported, but need to share the global buffer.
The MSS is announced via the MSS option on connection establishment The MSS is announced via the MSS option on connection establishment
and the receive window size (of one MSS) is not modified during a and the receive window size (of one MSS) is not modified during a
connection. Stop-and-wait operation is used for sending data. Among connection. Stop-and-wait operation is used for sending data. Among
skipping to change at page 19, line 12 skipping to change at page 19, line 15
Contiki uses the "split hack" technique (see Section 4.2.3) to avoid Contiki uses the "split hack" technique (see Section 4.2.3) to avoid
Delayed ACKs for senders using a single segment. Delayed ACKs for senders using a single segment.
The code size of the TCP implementation in Contiki-NG has been The code size of the TCP implementation in Contiki-NG has been
measured to be of 3.2 kB on CC2538DK, cross-compiling on Linux. measured to be of 3.2 kB on CC2538DK, cross-compiling on Linux.
8.2. lwIP 8.2. lwIP
lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers.
lwIP has a total code size of ~14 kB to ~22 kB (which comprises lwIP has a total code size of ~14 kB to ~22 kB (which comprises
memory management, checksumming, network interfaces, IP, ICMP and memory management, checksumming, network interfaces, IPv4, ICMP and
TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. Both IPv4 and
IPv6 are supported in lwIP since v2.0.0.
In contrast with uIP, lwIP decouples applications from the network In contrast with uIP, lwIP decouples applications from the network
stack. lwIP supports a TCP transmission window greater than a single stack. lwIP supports a TCP transmission window greater than a single
segment, as well as buffering of incoming and outcoming data. Other segment, as well as buffering of incoming and outcoming data. Other
implemented mechanisms comprise slow start, congestion avoidance, implemented mechanisms comprise slow start, congestion avoidance,
fast retransmit and fast recovery. SACK and Window Scale support has fast retransmit and fast recovery. SACK and Window Scale support has
been recently added to lwIP. been recently added to lwIP.
8.3. RIOT 8.3. RIOT
skipping to change at page 19, line 50 skipping to change at page 20, line 7
multiple parallel connections. multiple parallel connections.
The RIOT TCP implementation offers an optional POSIX socket wrapper The RIOT TCP implementation offers an optional POSIX socket wrapper
that enables POSIX compliance, if needed. that enables POSIX compliance, if needed.
Further details on RIOT and GNRC can be found in the literature Further details on RIOT and GNRC can be found in the literature
[RIOT], [GNRC]. [RIOT], [GNRC].
8.4. TinyOS 8.4. TinyOS
TinyOS was important as platform for early constrained devices. TinyOS was important as a platform for early constrained devices.
TinyOS has an experimental TCP stack that uses a simple nonblocking TinyOS has an experimental TCP stack that uses a simple nonblocking
library-based implementation of TCP, which provides a subset of the library-based implementation of TCP, which provides a subset of the
socket interface primitives. The application is responsible for socket interface primitives. The application is responsible for
buffering. The TCP library does not do any receive-side buffering. buffering. The TCP library does not do any receive-side buffering.
Instead, it will immediately dispatch new, in-order data to the Instead, it will immediately dispatch new, in-order data to the
application and otherwise drop the segment. A send buffer is application and otherwise drop the segment. A send buffer is
provided by the application. Multiple TCP connections are possible. provided by the application. Multiple TCP connections are possible.
Recently there has been little further work on the stack. Recently there has been little further work on the stack.
8.5. FreeRTOS 8.5. FreeRTOS
skipping to change at page 24, line 5 skipping to change at page 24, line 5
o Addressed WGLC comments by Ilpo Jarvinen, Markku Kojo and Ingemar o Addressed WGLC comments by Ilpo Jarvinen, Markku Kojo and Ingemar
Johansson throughout the document, including the addition of a new Johansson throughout the document, including the addition of a new
subsection on Initial Window considerations. subsection on Initial Window considerations.
9.9. Changes between -08 and -09 9.9. Changes between -08 and -09
o Addressed second round of comments by Ilpo Jarvinen and Markku o Addressed second round of comments by Ilpo Jarvinen and Markku
Kojo, based on the previous draft update. Kojo, based on the previous draft update.
9.10. Changes between -09 and -10
o Addressed comments by Erik Kline.
o Addressed a comment by Markku Kojo on advice given in RFC 6691.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
skipping to change at page 25, line 14 skipping to change at page 25, line 18
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012,
<https://www.rfc-editor.org/info/rfc6691>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
skipping to change at page 26, line 17 skipping to change at page 26, line 21
Sarolahti, P., and M. Kojo, "An Experimental Study of Home Sarolahti, P., and M. Kojo, "An Experimental Study of Home
Gateway Characteristics", Proceedings of the 10th ACM Gateway Characteristics", Proceedings of the 10th ACM
SIGCOMM conference on Internet measurement 2010. SIGCOMM conference on Internet measurement 2010.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-tcpm-rto-consider] [I-D.ietf-tcpm-rto-consider]
Allman, M., "Retransmission Timeout Requirements", draft- Allman, M., "Requirements for Time-Based Loss Detection",
ietf-tcpm-rto-consider-08 (work in progress), February draft-ietf-tcpm-rto-consider-17 (work in progress), July
2019. 2020.
[I-D.jarvinen-core-fasor] [I-D.jarvinen-core-fasor]
Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast- Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast-
Slow Retransmission Timeout and Congestion Control Slow Retransmission Timeout and Congestion Control
Algorithm for CoAP", draft-jarvinen-core-fasor-02 (work in Algorithm for CoAP", draft-jarvinen-core-fasor-02 (work in
progress), July 2019. progress), July 2019.
[IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the [IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the
Internet of Things: from ostracism to prominence", IEEE Internet of Things: from ostracism to prominence", IEEE
Internet Computing, January-February 2018. Internet Computing, January-February 2018.
 End of changes. 22 change blocks. 
48 lines changed or deleted 66 lines changed or added

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