draft-ietf-lwig-tcp-constrained-node-networks-01.txt   draft-ietf-lwig-tcp-constrained-node-networks-02.txt 
LWIG Working Group C. Gomez LWIG Working Group C. Gomez
Internet-Draft UPC/i2CAT Internet-Draft UPC/i2CAT
Intended status: Informational J. Crowcroft Intended status: Informational J. Crowcroft
Expires: April 17, 2018 University of Cambridge Expires: August 31, 2018 University of Cambridge
M. Scharf M. Scharf
Nokia Nokia
October 14, 2017 February 27, 2018
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-01 draft-ietf-lwig-tcp-constrained-node-networks-02
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 April 17, 2018. This Internet-Draft will expire on August 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4 3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4
3.1. Network and link properties . . . . . . . . . . . . . . . 4 3.1. Network and link properties . . . . . . . . . . . . . . . 4
3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 4 3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 5
3.3. Communication and traffic patterns . . . . . . . . . . . 5 3.3. Communication and traffic patterns . . . . . . . . . . . 6
4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 6 4. TCP implementation and configuration in CNNs . . . . . . . . 6
4.1. TCP connection initiation . . . . . . . . . . . . . . . . 6 4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 6
4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 6 4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7
4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 7
4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8
4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 8 4.2. TCP guidance for small windows and buffers . . . . . . . 8
4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 8 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 8
4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 9 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9
4.6. Explicit congestion notification . . . . . . . . . . . . 9 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 9
4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 10
4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 11 4.3. General recommendations for TCP in CNNs . . . . . . . . . 10
4.9. Explicit loss notifications . . . . . . . . . . . . . . . 11 4.3.1. Error recovery and congestion/flow control . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.3.2. Selective Acknowledgments (SACK) . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. Delayed Acknowledgments . . . . . . . . . . . . . . . 11
7. Annex. TCP implementations for constrained devices . . . . . 12 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 11
7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12
7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. TCP connection lifetime . . . . . . . . . . . . . . . . . 12
7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Long TCP connection lifetime . . . . . . . . . . . . 12
7.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Short TCP connection lifetime . . . . . . . . . . . . 12
7.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Number of parallel connections . . . . . . . . . . . . . 13
7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Annex. Changes compared to previous versions . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Changes compared to -00 . . . . . . . . . . . . . . . . . 15 8. Annex. TCP implementations for constrained devices . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 17 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 8.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.6. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16
8.7. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Annex. Changes compared to previous versions . . . . . . . . 18
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 18
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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
stem from CNNs, the IETF has produced a suite of new protocols stem from CNNs, the IETF has produced a suite of new protocols
specifically designed for such environments (see e.g. specifically designed for such environments (see e.g.
[I-D.ietf-lwig-energy-efficient]). [I-D.ietf-lwig-energy-efficient]). New IETF protocol stack
components include the IPv6 over Low-power Wireless Personal Area
Networks (6LoWPAN) adaptation layer, the IPv6 Routing Protocol for
Low-power and lossy networks (RPL) routing protocol, and the
Constrained Application Protocol (CoAP).
At the application layer, the Constrained Application Protocol (CoAP) As of the writing, the main current transport layer protocols in IP-
was developed over UDP [RFC7252]. However, the integration of some based IoT scenarios are UDP and TCP. However, TCP has been
CoAP deployments with existing infrastructure is being challenged by criticized (often, unfairly) as a protocol for the IoT. In fact,
middleboxes such as firewalls, which may limit and even block UDP- some TCP features are not optimal for IoT scenarios, such as
based communications. This the main reason why a CoAP over TCP relatively long header size, unsuitability for multicast, and always-
specification is being developed [I-D.ietf-core-coap-tcp-tls]. confirmed data delivery. However, many typical claims on TCP
unsuitability for IoT (e.g. a high complexity, connection-oriented
approach incompatibility with radio duty-cycling, and spurious
congestion control activation in wireless links) are not valid, can
be solved, or are also found in well accepted IoT end-to-end
reliability mechanisms (see [IntComp] for a detailed analysis).
At the application layer, CoAP was developed over UDP [RFC7252].
However, the integration of some CoAP deployments with existing
infrastructure is being challenged by middleboxes such as firewalls,
which may limit and even block UDP-based communications. This the
main reason why a CoAP over TCP specification has been developed
[RFC8323].
Other application layer protocols not specifically designed for CNNs Other application layer protocols not specifically designed for CNNs
are also being considered for the IoT space. Some examples include are also being considered for the IoT space. Some examples include
HTTP/2 and even HTTP/1.1, both of which run over TCP by default HTTP/2 and even HTTP/1.1, both of which run over TCP by default
[RFC7540] [RFC2616], and the Extensible Messaging and Presence [RFC7540] [RFC2616], and the Extensible Messaging and Presence
Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application- Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application-
layer protocols in the IoT space such as the Message Queue Telemetry layer protocols in the IoT space such as the Message Queue Telemetry
Transport (MQTT) and its lightweight variants. Transport (MQTT) and its lightweight variants.
TCP is a sophisticated transport protocol that includes many optional TCP is a sophisticated transport protocol that includes optional
functionality and TCP options that improve performance. Many functionality (e.g. TCP options) that may improve performance in
optional TCP extensions require complex logic inside the TCP stack some environments. However, many optional TCP extensions require
and increase the codesize and the RAM requirements. However, many complex logic inside the TCP stack and increase the codesize and the
TCP extensions are not required for interoperability with other RAM requirements. Many TCP extensions are not required for
standard-compliant TCP endpoints. Given the limited resources on interoperability with other standard-compliant TCP endpoints. Given
constrained devices, careful "tuning" of the TCP implementation can the limited resources on constrained devices, careful "tuning" of the
make an implementation more lightweight. TCP implementation can make an implementation more lightweight.
This document provides guidance on how to implement and use TCP in This document provides guidance on how to implement and use TCP in
CNNs. The overarching goal is to offer simple measures to allow for CNNs. The overarching goal is to offer simple measures to allow for
lightweight TCP implementation and suitable operation in such lightweight TCP implementation and suitable operation in such
environments. A TCP implementation following the guidance in this environments. A TCP implementation following the guidance in this
document is intended to be compatible with a TCP endpoint that is document is intended to be compatible with a TCP endpoint that is
compliant to the TCP standards, albeit possibly with a lower compliant to the TCP standards, albeit possibly with a lower
performance. This implies that such a TCP client would always be performance. This implies that such a TCP client would always be
able to connect with a standard-compliant TCP server, and a able to connect with a standard-compliant TCP server, and a
corresponding TCP server would always be able to connect with a corresponding TCP server would always be able to connect with a
skipping to change at page 6, line 21 skipping to change at page 6, line 41
the other endpoint, which triggers a response from the IoT device. the other endpoint, which triggers a response from the IoT device.
o Bulk data transfers: A typical example for a long file transfer o Bulk data transfers: A typical example for a long file transfer
would be an IoT device firmware update. would be an IoT device firmware update.
A typical communication pattern is that a constrained device A typical communication pattern is that a constrained device
communicates with an unconstrained device (cf. Figure 1). But it is communicates with an unconstrained device (cf. Figure 1). But it is
also possible that constrained devices communicate amongst also possible that constrained devices communicate amongst
themselves. themselves.
4. TCP over CNNs 4. TCP implementation and configuration in CNNs
4.1. TCP connection initiation
In the constrained device to unconstrained device scenario This section explains how a TCP stack can deal with typical
illustrated above, a TCP connection is typically initiated by the constraints in CNN. The guidance in this section relates to the TCP
constrained device, in order for this device to support possible implementation and its configuration.
sleep periods to save energy.
4.2. Maximum Segment Size (MSS) 4.1. Path properties
4.1.1. Maximum Segment Size (MSS)
Some link layer technologies in the CNN space are characterized by a Some link layer technologies in the CNN space are characterized by a
short data unit payload size, e.g. up to a few tens or hundreds of 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 127 bytes. For example, the maximum frame size in IEEE 802.15.4 is 127
bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE
802.15.4 networks. The adaptation layer includes a fragmentation 802.15.4 networks. The adaptation layer includes a fragmentation
mechanism, since IPv6 requires the layer below to support an MTU of mechanism, since IPv6 requires the layer below to support an MTU of
1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation 1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation
mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes
[RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T [RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T
skipping to change at page 7, line 17 skipping to change at page 7, line 40
For the sake of lightweight implementation and operation, unless For the sake of lightweight implementation and operation, unless
applications require handling large data units (i.e. leading to an applications require handling large data units (i.e. leading to an
IPv6 datagram size greater than 1280 bytes), it may be desirable to IPv6 datagram size greater than 1280 bytes), it may be desirable to
limit the MTU to 1280 bytes in order to avoid the need to support limit the MTU to 1280 bytes in order to avoid the need to support
Path MTU Discovery [RFC1981]. Path MTU Discovery [RFC1981].
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. (Note: IP version 6 is the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is
assumed.) assumed.)
4.3. Window Size 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs.
ECN allows a router to signal in the IP header of a packet that
congestion is arising, for example when queue size reaches a certain
threshold. If such a packet encapsulates a TCP data packet, an ECN-
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
congestion control measures as if a packet loss had happened. In
that case, when the congestion window of a TCP sender has a size of
one segment, the TCP sender resets the retransmit timer, and will
only be able to send a new packet when the retransmit timer expires
[RFC3168]. Effectively, the TCP sender reduces at that moment its
sending rate from 1 segment per Round Trip Time (RTT) to 1 segment
per default RTO.
ECN can reduce packet losses, since congestion control measures can
be applied earlier than after the reception of three duplicate ACKs
(if the TCP sender window is large enough) or upon TCP sender RTO
expiration [RFC2884]. Therefore, the number of retries decreases,
which is particularly beneficial in CNNs, where energy and bandwidth
resources are typically limited. Furthermore, latency and jitter are
also reduced.
ECN is particularly appropriate in CNNs, since in these environments
transactional type interactions are a dominant traffic pattern. As
transactional data size decreases, the probability of detecting
congestion by the presence of three duplicate ACKs decreases. In
contrast, ECN can still activate congestion control measures without
requiring three duplicate ACKs.
4.1.3. Explicit loss notifications
There has been a significant body of research on solutions capable of
explicitly indicating whether a TCP segment loss is due to
corruption, in order to avoid activation of congestion control
mechanisms [ETEN] [RFC2757]. While such solutions may provide
significant improvement, they have not been widely deployed and
remain as experimental work. In fact, as of today, the IETF has not
standardized any such solution.
4.2. TCP guidance for small windows and buffers
This section discusses TCP stacks that focus on transferring a single
MSS. More general guidance is provided in Section 4.3.
4.2.1. Single-MSS stacks - benefits and issues
A TCP stack can reduce the RAM requirements by advertising a TCP A TCP stack can reduce the RAM requirements by advertising a TCP
window size of one MSS, and also transmit at most one MSS of window size of one MSS, and also transmit at most one MSS of
unacknowledged data. In that case, both congestion and flow control unacknowledged data. In that case, both congestion and flow control
implementation is quite simple. Such a small receive and send window implementation is quite simple. Such a small receive and send window
may be sufficient for simple message exchanges in the CNN space. may be sufficient for simple message exchanges in the CNN space.
However, only using a window of one MSS can significantly affect However, only using a window of one MSS can significantly affect
performance. A stop-and-wait operation results in low throughput for performance. A stop-and-wait operation results in low throughput for
transfers that exceed the lengths of one MSS, e.g., a firmware transfers that exceed the lengths of one MSS, e.g., a firmware
download. In addition, there can be interactions with the delayed download.
acknowledgements (see Section 4.8).
Devices that have enough memory to allow larger TCP window size can
leverage a more efficient error recovery using Fast Retransmit and
Fast Recovery [RFC5681]. These algorithms work efficiently for
window sizes of at least 5 MSS: If in a given TCP transmission of
segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should
get an acknowledgement for segment 1 when 3 arrives and duplicate
acknowledgements when 4, 5, and 6 arrive. It will retransmit segment
2 when the third duplicate ack arrives. In order to have segment 2,
3, 4, 5, and 6 sent, the window has to be at least five. With an MSS
of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte.
For bulk data transfers further TCP improvements may also be useful,
such as limited transmit [RFC3402].
If CoAP is used over TCP with the default setting for NSTART in If CoAP is used over TCP with the default setting for NSTART in
[RFC7252], a CoAP endpoint is not allowed to send a new message to a [RFC7252], a CoAP endpoint is not allowed to send a new message to a
destination until a response for the previous message sent to that destination until a response for the previous message sent to that
destination has been received. This is equivalent to an application- destination has been received. This is equivalent to an application-
layer window size of 1. For this use of CoAP, a maximum TCP window layer window size of 1. For this use of CoAP, a maximum TCP window
of one MSS will be sufficient. of one MSS will be sufficient.
4.4. RTO estimation 4.2.2. TCP options for single-MSS stacks
A TCP implementation needs to support options 0, 1 and 2 [RFC0793].
These options are sufficient for interoperability with a standard-
compliant TCP endpoint, albeit many TCP stacks support additional
options and can negotiate their use.
A TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size may not benefit from supporting
the following TCP options: Window scale [RFC1323], TCP Timestamps
[RFC1323], Selective Acknowledgments (SACK) and SACK-Permitted
[RFC2018]. Also other TCP options may not be required on a
constrained device with a very lightweight implementation.
One potentially relevant TCP option in the context of CNNs is TCP
Fast Open (TFO) [RFC7413]. As described in Section 5.2.2, TFO can be
used to address the problem of traversing middleboxes that perform
early filter state record deletion.
4.2.3. Delayed Acknowledgments for single-MSS stacks
TCP Delayed Acknowledgments are meant to reduce the number of
transferred bytes within a TCP connection, but they may increase the
time until a sender may receive an ACK. There can be interactions
with stacks that use very small windows.
A device that advertises a single-MSS receive window should avoid use
of delayed ACKs in order to avoid contributing unnecessary delay (of
up to 500 ms) to the RTT [RFC5681], which limits the throughput and
can increase the data delivery time.
A device that can send at most one MSS of data is significantly
affected if the receiver uses delayed ACKs, e.g., if a TCP server or
receiver is outside the CNN. One known workaround is to split the
data to be sent into two segments of smaller size. A standard
compliant TCP receiver will then immediately acknowledge the second
segment, which can improve throughput. This "split hack" works if
the TCP receiver uses Delayed Acks, but the downside is the overhead
of sending two IP packets instead of one.
4.2.4. RTO estimation for single-MSS stacks
The Retransmission Timeout (RTO) estimation is one of the fundamental The Retransmission Timeout (RTO) estimation is one of the fundamental
TCP algorithms. There is a fundamental trade-off: A short, TCP algorithms. There is a fundamental trade-off: A short,
aggressive RTO behavior reduces wait time before retransmissions, but aggressive RTO behavior reduces wait time before retransmissions, but
it also increases the probability of spurious timeouts. The latter it also increases the probability of spurious timeouts. The latter
lead to unnecessary waste of potentially scarce resources in CNNs lead to unnecessary waste of potentially scarce resources in CNNs
such as energy and bandwidth. In contrast, a conservative timeout such as energy and bandwidth. In contrast, a conservative timeout
can result in long error recovery times and thus needlessly delay can result in long error recovery times and thus needlessly delay
data delivery. data delivery.
skipping to change at page 8, line 27 skipping to change at page 10, line 27
uses very small window size and cannot use Fast Retransmit/Fast uses very small window size and cannot use Fast Retransmit/Fast
Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a
larger impact on performance than for a more powerful TCP stack. In larger impact on performance than for a more powerful TCP stack. In
that case, RTO algorithm tuning may be considered, although careful that case, RTO algorithm tuning may be considered, although careful
assessment of possible drawbacks is recommended. assessment of possible drawbacks is recommended.
As an example, an adaptive RTO algorithm for CoAP over UDP has been As an example, an adaptive RTO algorithm for CoAP over UDP has been
defined [I-D.ietf-core-cocoa] that has been found to perform well in defined [I-D.ietf-core-cocoa] that has been found to perform well in
CNN scenarios [Commag]. CNN scenarios [Commag].
4.5. TCP connection lifetime 4.3. General recommendations for TCP in CNNs
[[Note: future revisions will better separate what a TCP stack should This section summarizes some widely used techniques to improve TCP,
support, or not, and how the TCP stack should be used by with a focus on their use in CNNs. The TCP extensions discussed here
applications, e.g., whether to close connections or not.]] are useful in a wide range of network scenarios, including CNNs.
This section is not comprehensive. A comprehensive survey of TCP
extensions is published in [RFC7414].
4.5.1. Long TCP connection lifetime 4.3.1. Error recovery and congestion/flow control
Devices that have enough memory to allow larger TCP window size can
leverage a more efficient error recovery using Fast Retransmit and
Fast Recovery [RFC5681]. These algorithms work efficiently for
window sizes of at least 5 MSS: If in a given TCP transmission of
segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should
get an acknowledgement for segment 1 when 3 arrives and duplicate
acknowledgements when 4, 5, and 6 arrive. It will retransmit segment
2 when the third duplicate ack arrives. In order to have segment 2,
3, 4, 5, and 6 sent, the window has to be at least five. With an MSS
of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte.
For bulk data transfers further TCP improvements may also be useful,
such as limited transmit [RFC3042].
4.3.2. Selective Acknowledgments (SACK)
If a device with less severe memory and processing constraints can
afford advertising a TCP window size of several MSSs, it makes sense
to support the SACK option to improve performance. SACK allows a
data receiver to inform the data sender of non-contiguous data blocks
received, thus a sender (having previously sent the SACK-Permitted
option) can avoid performing unnecessary retransmissions, saving
energy and bandwidth, as well as reducing latency. SACK is
particularly useful for bulk data transfers. The receiver supporting
SACK will need to manage the reception of possible out-of-order
received segments, requiring sufficient buffer space. SACK adds
8*n+2 bytes to the TCP header, where n denotes the number of data
blocks received, up to 4 blocks. For a low number of out-of-order
segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions.
4.3.3. Delayed Acknowledgments
For certain traffic patterns, Delayed Acknowledgements may have a
detrimental effect, as already noted in Section 4.2.3. Advanced TCP
stacks may use heuristics to determine the maximum delay for an ACK.
For CNNs, the recommendation depends on the expected communication
patterns.
If a stack is able to deal with more than one MSS of data, it may
make sense to use a small timeout or disable delayed ACKs when
traffic over a CNN is expected to mostly be small messages with a
size typically below one MSS. For request-response traffic between a
constrained device and a peer (e.g. backend infrastructure) that uses
delayed ACKs, the maximum ACK rate of the peer will be typically of
one ACK every 200 ms (or even lower). If in such conditions the peer
device is administered by the same entity managing the constrained
device, it is recommended to disable delayed ACKs at the peer side.
In contrast, delayed ACKs allow to reduce the number of ACKs in bulk
transfer type of traffic, e.g. for firmware/software updates or for
transferring larger data units containing a batch of sensor readings.
5. TCP usage recommendations in CNNs
This section discusses how a TCP stack can be used by applications
that are developed for CNN scenarios. These remarks are by and large
independent of how TCP is exactly implemented.
5.1. TCP connection initiation
In the constrained device to unconstrained device scenario
illustrated above, a TCP connection is typically initiated by the
constrained device, in order for this device to support possible
sleep periods to save energy.
5.2. TCP connection lifetime
[[TODO: This section may need rewording in the next revision.]]
5.2.1. Long TCP connection lifetime
In CNNs, in order to minimize message overhead, a TCP connection In CNNs, in order to minimize message overhead, a TCP connection
should be kept open as long as the two TCP endpoints have more data should be kept open as long as the two TCP endpoints have more data
to exchange or it is envisaged that further segment exchanges will to exchange or it is envisaged that further segment exchanges will
take place within an interval of two hours since the last segment has take place within an interval of two hours since the last segment has
been sent. A greater interval may be used in scenarios where been sent. A greater interval may be used in scenarios where
applications exchange data infrequently. applications exchange data infrequently.
TCP keep-alive messages [RFC1122] may be supported by a server, to TCP keep-alive messages [RFC1122] may be supported by a server, to
check whether a TCP connection is active, in order to release state check whether a TCP connection is active, in order to release state
skipping to change at page 9, line 9 skipping to change at page 12, line 41
hours [RFC1122], TCP keep-alive messages are not useful to guarantee hours [RFC1122], TCP keep-alive messages are not useful to guarantee
that filter state records in middleboxes such as firewalls will not that filter state records in middleboxes such as firewalls will not
be deleted after an inactivity interval typically in the order of a be deleted after an inactivity interval typically in the order of a
few minutes [RFC6092]. In scenarios where such middleboxes are few minutes [RFC6092]. In scenarios where such middleboxes are
present, alternative measures to avoid early deletion of filter state present, alternative measures to avoid early deletion of filter state
records (which might lead to frequent establishment of new TCP records (which might lead to frequent establishment of new TCP
connections between the two involved endpoints) include increasing connections between the two involved endpoints) include increasing
the initial value for the filter state inactivity timers (if the initial value for the filter state inactivity timers (if
possible), and using application layer heartbeat messages. possible), and using application layer heartbeat messages.
4.5.2. Short TCP connection lifetime 5.2.2. Short TCP connection lifetime
A different approach to addressing the problem of traversing A different approach to addressing the problem of traversing
middleboxes that perform early filter state record deletion relies on middleboxes that perform early filter state record deletion relies on
using TCP Fast Open (TFO) [RFC7413]. In this case, instead of trying using TFO [RFC7413]. In this case, instead of trying to maintain a
to maintain a TCP connection for long time, possibly short-lived TCP connection for long time, possibly short-lived connections can be
connections can be opened between two endpoints while incurring low opened between two endpoints while incurring low overhead. In fact,
overhead. In fact, TFO allows data to be carried in SYN (and SYN- TFO allows data to be carried in SYN (and SYN-ACK) packets, and to be
ACK) packets, and to be consumed immediately by the receceiving consumed immediately by the receceiving endpoint, thus reducing
endpoint, thus reducing overhead compared with the traditional three- overhead compared with the traditional three-way handshake required
way handshake required to establish a TCP connection. to establish a TCP connection.
For security reasons, TFO requires the TCP endpoint that will open For security reasons, TFO requires the TCP endpoint that will open
the TCP connection (which in CNNs will typically be the constrained the TCP connection (which in CNNs will typically be the constrained
device) to request a cookie from the other endpoint. The cookie, device) to request a cookie from the other endpoint. The cookie,
with a size of 4 or 16 bytes, is then included in SYN packets of with a size of 4 or 16 bytes, is then included in SYN packets of
subsequent connections. The cookie needs to be refreshed (and subsequent connections. The cookie needs to be refreshed (and
obtained by the client) after a certain amount of time. obtained by the client) after a certain amount of time.
Nevertheless, TFO is more efficient than frequently opening new TCP Nevertheless, TFO is more efficient than frequently opening new TCP
connections (by using the traditional three-way handshake) for connections (by using the traditional three-way handshake) for
transmitting new data, as long as the cookie update rate is well transmitting new data, as long as the cookie update rate is well
below the data new connection rate. below the data new connection rate.
4.6. Explicit congestion notification 5.3. Number of parallel connections
Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs.
ECN allows a router to signal in the IP header of a packet that
congestion is arising, for example when queue size reaches a certain
threshold. If such a packet encapsulates a TCP data packet, an ECN-
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
congestion control measures as if a packet loss had happened. In
that case, when the congestion window of a TCP sender has a size of
one segment, the TCP sender resets the retransmit timer, and will
only be able to send a new packet when the retransmit timer expires
[RFC3168]. Effectively, the TCP sender reduces at that moment its
sending rate from 1 segment per Round Trip Time (RTT) to 1 segment
per default RTO.
ECN can reduce packet losses, since congestion control measures can
be applied earlier than after the reception of three duplicate ACKs
(if the TCP sender window is large enough) or upon TCP sender RTO
expiration [RFC2884]. Therefore, the number of retries decreases,
which is particularly beneficial in CNNs, where energy and bandwidth
resources are typically limited. Furthermore, latency and jitter are
also reduced.
ECN is particularly appropriate in CNNs, since in these environments
transactional type interactions are a dominant traffic pattern. As
transactional data size decreases, the probability of detecting
congestion by the presence of three duplicate ACKs decreases. In
contrast, ECN can still activate congestion control measures without
requiring three duplicate ACKs.
4.7. TCP options
A TCP implementation needs to support options 0, 1 and 2 [RFC0793].
These options are sufficient for interoperability with a standard-
compliant TCP endpoint, albeit many TCP stacks support additional
options and can negotiate their use.
A TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size may not benefit from supporting
the following TCP options: Window scale [RFC1323], TCP Timestamps
[RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted
[RFC2018]. Also other TCP options may not be required on a
constrained device with a very lightweight implementation.
If a device with less severe memory and processing constraints can
afford advertising a TCP window size of several MSSs, it makes sense
to support the SACK option to improve performance. SACK allows a
data receiver to inform the data sender of non-contiguous data blocks
received, thus a sender (having previously sent the SACK-Permitted
option) can avoid performing unnecessary retransmissions, saving
energy and bandwidth, as well as reducing latency. SACK is
particularly useful for bulk data transfers. The receiver supporting
SACK will need to manage the reception of possible out-of-order
received segments, requiring sufficient buffer space. SACK adds
8*n+2 bytes to the TCP header, where n denotes the number of data
blocks received, up to 4 blocks. For a low number of out-of- order
segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions.
Another potentially relevant TCP option in the context of CNNs is
(TFO) [RFC7413]. As described in Section 4.5.2, TFO can be used to
address the problem of traversing middleboxes that perform early
filter state record deletion.
4.8. Delayed Acknowledgments
TCP Delayed Acknowledgements reduce the number of transferred bytes
within a TCP connection, but they may increase the time until a
sender may receive an ACK. For certain traffic patterns Delayed
Acknowledgements may have a detrimental effect. Advanced TCP stacks
may use heuristics to determine the maximum delay for an ACK. For
CNNs, the recommendation depends on the expected communication
patterns.
A device that advertises a single-MSS receive window should avoid use
of delayed ACKs in order to avoid contributing unnecessary delay (of
up to 500 ms) to the RTT [RFC5681], which limits the throughput and
can increase the data delivery time.
A device that can send at most one MSS of data is significantly
affected if the receiver uses delayed ACKs, e.g., if a TCP server or
receiver is outside the CNN. One known workaround is to split the
data to be sent into two segments of smaller size. A standard
compliant TCP receiver will then immediately acknowledge the second
segment, which can improve throughput. This "split hack" works if
the TCP receiver uses Delayed Acks, but the downside is the overhead
of sending two IP packets instead of one.
Also for larger windows, it may make sense to use a small timeout or
disable delayed ACKs when traffic over a CNN is expected to mostly be
small messages with a size typically below one MSS. For request-
response traffic between a constrained device and a peer (e.g.
backend infrastructure) that uses delayed ACKs, the maximum ACK rate
of the peer will be typically of one ACK every 200 ms (or even
lower). If in such conditions the peer device is administered by the
same entity managing the constrained device, it is recommended to
disable delayed ACKs at the peer side.
In contrast, delayed ACKs allow to reduce the number of ACKs in bulk
transfer type of traffic, e.g. for firmware/software updates or for
transferring larger data units containing a batch of sensor readings.
4.9. Explicit loss notifications [[TODO: This has been added in -02 but needs further alignment]]
There has been a significant body of research on solutions capable of TCP endpoints with a small amount of RAM may only support a small
explicitly indicating whether a TCP segment loss is due to number of connections. Each connection may result in overhead, and
corruption, in order to avoid activation of congestion control depending on the internal TCP implementation, they may compete for
mechanisms [ETEN] [RFC2757]. While such solutions may provide scarce resources. A careful application design may try to keep the
significant improvement, they have not been widely deployed and number of parallel connections as small as possible.
remain as experimental work. In fact, as of today, the IETF has not
standardized any such solution.
5. Security Considerations 6. Security Considerations
Best current practise for securing TCP and TCP-based communication Best current practise for securing TCP and TCP-based communication
also applies to CNN. As example, use of Transport Layer Security also applies to CNN. As example, use of Transport Layer Security
(TLS) is strongly recommended if it is applicable. (TLS) is strongly recommended if it is applicable.
There are also TCP options which can improve TCP security. Examples There are also TCP options which can improve TCP security. Examples
include the TCP MD5 signature option [RFC2385] and the TCP include the TCP MD5 signature option [RFC2385] and the TCP
Authentication Option (TCP-AO) [RFC5925]. However, both options add Authentication Option (TCP-AO) [RFC5925]. However, both options add
overhead and complexity. The TCP MD5 signature option adds 18 bytes overhead and complexity. The TCP MD5 signature option adds 18 bytes
to every segment of a connection. TCP-AO typically has a size of to every segment of a connection. TCP-AO typically has a size of
16-20 bytes. 16-20 bytes.
For the mechanisms discussed in this document, the corresponding For the mechanisms discussed in this document, the corresponding
considerations apply. For instance, if TFO is used, the security considerations apply. For instance, if TFO is used, the security
considerations of [RFC7413] apply. considerations of [RFC7413] apply.
6. 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 grant CAS15/00336 and by European Regional Development Castillejo grant CAS15/00336 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. Part of his contribution to this TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this
work has been carried out during his stay as a visiting scholar at work has been carried out during his stay as a visiting scholar at
the Computer Laboratory of the University of Cambridge. 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, and Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and
Hannes Tschofenig. Simon Brummer provided details on the RIOT TCP Hannes Tschofenig. Simon Brummer provided details on the RIOT TCP
implementation. Xavi Vilajosana provided details on the OpenWSN TCP implementation. Xavi Vilajosana provided details on the OpenWSN TCP
implementation. Rahul Jadhav provided details on the uIP TCP implementation. Rahul Jadhav provided details on the uIP TCP
implementation. implementation.
7. Annex. TCP implementations for constrained devices 8. Annex. TCP implementations for constrained devices
This section overviews the main features of TCP implementations for This section overviews the main features of TCP implementations for
constrained devices. constrained devices.
7.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.
uIP has been deployed with Contiki and the Arduino Ethernet shield. uIP has been deployed with Contiki and the Arduino Ethernet shield.
A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP)
has been reported for uIP [Dunk]. has been reported for uIP [Dunk].
uIP uses same buffer both incoming and outgoing traffic, with has a uIP uses same buffer both incoming and outgoing traffic, with has a
size of a single packet. In case of a retransmission, an application size of a single packet. In case of a retransmission, an application
must be able to reproduce the same user data that had been must be able to reproduce the same user data that had been
transmitted. transmitted.
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
other optimizations, this allows to avoid sliding window operations, other optimizations, this allows to avoid sliding window operations,
which use 32-bit arithmetic extensively and are expensive on 8-bit which use 32-bit arithmetic extensively and are expensive on 8-bit
CPUs. CPUs.
Contiki uses the "split hack" technique (see Section 4.8) to avoid Contiki uses the "split hack" technique (see Section 4.2.3) to avoid
delayed ACKs for senders using a single MSS. delayed ACKs for senders using a single MSS.
7.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, IP, 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].
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 have been fast retransmit and fast recovery. SACK and Window Scale have been
recently added to lwIP. recently added to lwIP.
7.3. RIOT 8.3. RIOT
The RIOT TCP implementation (called GNRC TCP) has been designed for The RIOT TCP implementation (called GNRC TCP) has been designed for
Class 1 devices [RFC 7228]. The main target platforms are 8- and Class 1 devices [RFC 7228]. The main target platforms are 8- and
16-bit microcontrollers. GNRC TCP offers a similar function set as 16-bit microcontrollers. GNRC TCP offers a similar function set as
uIP, but it provides and maintains an independent receive buffer for uIP, but it provides and maintains an independent receive buffer for
each connection. In contrast to uIP, retransmission is also handled each connection. In contrast to uIP, retransmission is also handled
by GNRC TCP. GNRC TCP uses a single-MSS window size, which by GNRC TCP. GNRC TCP uses a single-MSS window size, which
simplifies the implementation. The application programmer does not simplifies the implementation. The application programmer does not
need to know anything about the TCP internals, therefore GNRC TCP can need to know anything about the TCP internals, therefore GNRC TCP can
be seen as a user-friendly uIP TCP implementation. be seen as a user-friendly uIP TCP implementation.
The MSS is set on connections establishment and cannot be changed The MSS is set on connections establishment and cannot be changed
during connection lifetime. GNRC TCP allows multiple connections in during connection lifetime. GNRC TCP allows multiple connections in
parallel, but each TCB must be allocated somewhere in the system. By parallel, but each TCB must be allocated somewhere in the system. By
default there is only enough memory allocated for a single TCP default there is only enough memory allocated for a single TCP
connection, but it can be increased at compile time if the user needs connection, but it can be increased at compile time if the user needs
multiple parallel connections. multiple parallel connections.
7.4. OpenWSN The RIOT TCP implementation does not currently support classic POSIX
sockets. However, it supports an interface that has been inspired by
POSIX.
8.4. OpenWSN
The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP
implementation. OpenWSN TCP implementation only supports the minimum implementation. OpenWSN TCP implementation only supports the minimum
state machine functionality required. For example, it does not state machine functionality required. For example, it does not
perform retransmissions. perform retransmissions.
7.5. TinyOS 8.5. TinyOS
TODO: To be verified
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. The application is responsible library-based implementation of TCP, which provides a subset of the
for buffering. The TCP library does not do any receive-side socket interface primitives. The application is responsible for
buffering. Instead, it will immediately dispatch new, in-order data buffering. The TCP library does not do any receive-side buffering.
to the application and otherwise drop the segment. A send buffer is Instead, it will immediately dispatch new, in-order data to the
application and otherwise drop the segment. A send buffer is
provided so that the TCP implementation can automatically retransmit provided so that the TCP implementation can automatically retransmit
missing segments. missing segments. Multiple TCP connections are possible.
7.6. Summary 8.6. FreeRTOS
+-------+---------+---------+------+---------+--------+
| uIP |lwIP orig|lwIP 2.0 | RIOT | OpenWSN | TinyOS | FreeRTOS is a real-time operating system kernel for embedded devices
+--------+----------------+-------+---------+---------+------+---------+--------+ that is supported by 16- and 32-bit microprocessors. Its TCP
| | Data size | * | * | * | * | * | * | implementation is based on multiple-MSS window size, although a
| Memory +----------------+-------+---------+---------+------+---------+--------+ 'Tiny-TCP' option, which is a single-MSS variant, can be enabled.
| | Code size (kB) | < 5 |~9 to ~14| * | * | * | * | Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a
+--------+----------------+-------+---------+---------+------+---------+--------+ technique intended 'to gain performance'.
| |Window size(MSS)| 1 | Multiple| Multiple| 1 | 1 |Multiple|
| +----------------+-------+---------+---------+------+---------+--------+ 8.7. uC/OS
| | Slow start | No | Yes | Yes | No | No | Yes |
| T +----------------+-------+---------+---------+------+---------+--------+ uC/OS is a real-time operating system kernel for embedded devices,
| C | Fast rec/retx | No | Yes | Yes | No | No | Yes | which is maintained by Micrium. uC/OS is intended for 8-, 16- and
| P +----------------+-------+---------+---------+------+---------+--------+ 32-bit microprocessors. The uC/OS TCP implementation supports a
| | Keep-alive | No | * | * | No | No | No | multiple-MSS window size.
| +----------------+-------+---------+---------+------+---------+--------+
| f | TFO | No | No | * | No | No | No | 8.8. Summary
| e +----------------+-------+---------+---------+------+---------+--------+ +---+---------+--------+----+-------+------+--------+-----+
| a | ECN | No | No | * | No | No | No | |uIP|lwIP orig|lwIP 2.0|RIOT|OpenWSN|TinyOS|FreeRTOS|uC/OS|
| t +----------------+-------+---------+---------+------+---------+--------+ +------+-------------+---+---------+--------+----+-------+------+--------+-----+
| u | Window Scale | No | No | Yes | No | No | No | | |Data size(kB)| * | * | * | * | * | * | * | * |
| r +----------------+-------+---------+---------+------+---------+--------+ |Memory+-------------+---+---------+--------+----+-------+------+--------+-----+
| e | TCP timestamps | No | No | Yes | No | No | No | | |Code size(kB)| <5|~9 to ~14| ~40 | * | * | * | <9.2 | * |
| s +----------------+-------+---------+---------+------+---------+--------+ | | |(a)| (T1) | (b) | | | | (T2) | |
| | SACK | No | No | Yes | No | No | No | +------+-------------+---+---------+--------+----+-------+------+--------+-----+
| +----------------+-------+---------+---------+------+---------+--------+ | |Win size(MSS)| 1 | Mult. | Mult. | 1 | 1 | Mult.| Mult. |Mult.|
| | Delayed ACKs | No | Yes | Yes | No | No | No | | +-------------+---+---------+--------+----+-------+------+--------+-----+
+--------+----------------+-------+---------+---------+------+---------+--------+ | | Slow start | No| Yes | Yes | No | No | Yes | * | Yes |
| T +-------------+---+---------+--------+----+-------+------+--------+-----+
| C |Fast rec/retx| No| Yes | Yes | No | No | Yes | * | Yes |
| P +-------------+---+---------+--------+----+-------+------+--------+-----+
| | Keep-alive | No| No | Yes | No | No | No | Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+
| f | Win. Scale | No| No | Yes | No | No | No | Yes | No |
| e +-------------+---+---------+--------+----+-------+------+--------+-----+
| a | TCP timest. | No| No | Yes | No | No | No | Yes | No |
| t +-------------+---+---------+--------+----+-------+------+--------+-----+
| u | SACK | No| No | Yes | No | No | No | Yes | No |
| r +-------------+---+---------+--------+----+-------+------+--------+-----+
| e | Del. ACKs | No| Yes | Yes | No | No | No | Yes | Yes |
| s +-------------+---+---------+--------+----+-------+------+--------+-----+
| | Socket | No| No |Optional|(I) | * |Subset| Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+
| |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | * | * |
+------+-------------+---+---------+--------+----+-------+------+--------+-----+
(T1) = TCP-only, on x86 and AVR platforms
(T2) = TCP-only, on ARM Cortex-M platform
(a) = includes IP, ICMP and TCP on x86 and AVR platforms
(b) = the whole protocol stack on mbed
(I) = interface inspired by POSIX
Mult. = Multiple
Figure 2: Summary of TCP features for differrent lightweight TCP Figure 2: Summary of TCP features for differrent lightweight TCP
implementations. implementations. None of the implementations considered in this
Annex support ECN or TFO.
TODO: Add information about RAM requirements (in addition to TODO: Add information about RAM requirements (in addition to
codesize) codesize)
8. Annex. Changes compared to previous versions 9. Annex. Changes compared to previous versions
RFC Editor: To be removed prior to publication RFC Editor: To be removed prior to publication
8.1. Changes compared to -00 9.1. Changes between -00 and -01
o Changed title and abstract o Changed title and abstract
o Clarification that communcation with standard-compliant TCP o Clarification that communcation with standard-compliant TCP
endpoints is required, based on feedback from Joe Touch endpoints is required, based on feedback from Joe Touch
o Additional discussion on communication patters o Additional discussion on communication patters
o Numerous changes to address a comprehensive review from Hannes o Numerous changes to address a comprehensive review from Hannes
Tschofenig Tschofenig
o Reworded security considerations o Reworded security considerations
o Additional references and better distinction between normative and o Additional references and better distinction between normative and
informative entries informative entries
o Feedback from Rahul Jadhav on the uIP TCP implementation o Feedback from Rahul Jadhav on the uIP TCP implementation
skipping to change at page 16, line 17 skipping to change at page 18, line 31
o Reworded security considerations o Reworded security considerations
o Additional references and better distinction between normative and o Additional references and better distinction between normative and
informative entries informative entries
o Feedback from Rahul Jadhav on the uIP TCP implementation o Feedback from Rahul Jadhav on the uIP TCP implementation
o Basic data for the TinyOS TCP implementation added, based on o Basic data for the TinyOS TCP implementation added, based on
source code analysis source code analysis
9. References 9.2. Changes between -01 and -02
9.1. Normative References o Added text to the Introduction section, and a reference, on
traditional bad perception of TCP for IoT
o Added sections on FreeRTOS and uC/OS
o Updated TinyOS section
o Updated summary table
o Reorganized Section 4 (single-MSS vs multiple-MSS window size),
some content now also in new Section 5
10. 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,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 16, line 48 skipping to change at page 19, line 28
[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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
DOI 10.17487/RFC3042, January 2001,
<https://www.rfc-editor.org/info/rfc3042>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402,
October 2002, <https://www.rfc-editor.org/info/rfc3402>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004, RFC 3819, DOI 10.17487/RFC3819, July 2004,
<https://www.rfc-editor.org/info/rfc3819>. <https://www.rfc-editor.org/info/rfc3819>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
skipping to change at page 17, line 37 skipping to change at page 20, line 19
[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>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
9.2. Informative References 10.2. Informative References
[Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP [Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP
Congestion Control for the Internet of Things", IEEE Congestion Control for the Internet of Things", IEEE
Communications Magazine, June 2016. Communications Magazine, June 2016.
[Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003. [Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003.
[ETEN] R. Krishnan et al, "Explicit transport error notification [ETEN] R. Krishnan et al, "Explicit transport error notification
(ETEN) for error-prone wireless and satellite networks", (ETEN) for error-prone wireless and satellite networks",
Computer Networks 2004. Computer Networks 2004.
[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-core-coap-tcp-tls] [I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-09 (work in progress), May draft-ietf-core-coap-tcp-tls-11 (work in progress),
2017. December 2017.
[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-01 (work in progress), March 2017. core-cocoa-03 (work in progress), February 2018.
[I-D.ietf-lpwan-overview] [I-D.ietf-lpwan-overview]
Farrell, S., "LPWAN Overview", draft-ietf-lpwan- Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
overview-07 (work in progress), October 2017. overview-10 (work in progress), February 2018.
[I-D.ietf-lwig-energy-efficient] [I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols", Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-07 (work in progress), draft-ietf-lwig-energy-efficient-08 (work in progress),
March 2017. October 2017.
[IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the
Internet of Things: from ostracism to prominence", IEEE
Communications Magazine, January-February 2018.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <https://www.rfc-editor.org/info/rfc1981>. 1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 20, line 26 skipping to change at page 23, line 16
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <https://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
UPC/i2CAT UPC/i2CAT
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
 End of changes. 50 change blocks. 
259 lines changed or deleted 381 lines changed or added

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