rfc9006xml2.original.xml   rfc9006.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.o
rg/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-lwig-tcp-constrained-node-networks-13"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lwig-tcp-con
strained-node-networks-13" number="9006" ipr="trust200902" obsoletes="" updates=
"" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclu
de="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="TCP in IoT"> <title abbrev="TCP in IoT">
TCP Usage Guidance in the Internet of Things (IoT) TCP Usage Guidance in the Internet of Things (IoT)
</title> </title>
<seriesInfo name="RFC" value="9006"/>
<!-- <author fullname="Carles Gomez" initials="C." surname="Gomez">
<title abbrev="TCP over CNN">
TCP over Constrained-Node Networks
</title>
-->
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Carles Gomez" initials="C.G" surname="Gomez">
<organization>UPC</organization> <organization>UPC</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>C/Esteve Terradas, 7</street>
<city>Castelldefels</city> <city>Castelldefels</city>
<region/> <region/>
<code>08860</code> <code>08860</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>carlesgo@entel.upc.edu</email> <email>carlesgo@entel.upc.edu</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
<author fullname="Jon Crowcroft" initials="J.C" surname="Crowcroft">
<organization>University of Cambridge</organization> <organization>University of Cambridge</organization>
<address> <address>
<postal> <postal>
<street>JJ Thomson Avenue</street> <street>JJ Thomson Avenue</street>
<city>Cambridge</city> <city>Cambridge</city>
<code>CB3 0FD</code>
<region>CB3 0FD</region>
<code/>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>jon.crowcroft@cl.cam.ac.uk</email> <email>jon.crowcroft@cl.cam.ac.uk</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<author fullname="Michael Scharf" initials="M.S" surname="Scharf">
<organization>Hochschule Esslingen</organization> <organization>Hochschule Esslingen</organization>
<address> <address>
<postal> <postal>
<street> University of Applied Sciences</street>
<street>Flandernstr. 101</street> <street>Flandernstr. 101</street>
<city>Esslingen am Neckar</city>
<city>Esslingen</city>
<region/> <region/>
<code>73732</code> <code>73732</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>michael.scharf@hs-esslingen.de</email> <email>michael.scharf@hs-esslingen.de</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<!-- uri and facsimile elements may also be added --> <date month="March" year="2021"/>
<date month="October" year="2020"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>APP</area> <area>APP</area>
<workgroup>LWIG Working Group</workgroup> <workgroup>LWIG Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<!---->
<abstract> <abstract>
<t> This document provides guidance on how to implement and use the Transm ission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a c haracteristic of the Internet of Things (IoT). Such environments require a light weight TCP implementation and may not make use of optional functionality. This d ocument explains a number of known and deployed techniques to simplify a TCP sta ck as well as corresponding tradeoffs. The objective is to help embedded develop ers with decisions on which TCP features to use.</t> <t> This document provides guidance on how to implement and use the Transm ission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a c haracteristic of the Internet of Things (IoT). Such environments require a light weight TCP implementation and may not make use of optional functionality. This d ocument explains a number of known and deployed techniques to simplify a TCP sta ck as well as corresponding trade-offs. The objective is to help embedded develo pers with decisions on which TCP features to use.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction "> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The Internet Protocol suite is being used for connecting Constrained-No <t>The Internet Protocol suite is being used for connecting Constrained-No
de Networks (CNNs) to the Internet, enabling the so-called Internet of Things (I de Networks (CNNs) to the Internet, enabling the so-called Internet of Things (I
oT) <xref target="RFC7228"/>. In order to meet the requirements that stem from C oT) <xref target="RFC7228" format="default"/>. In order to meet the requirements
NNs, the IETF has produced a suite of new protocols specifically designed for su that stem from CNNs, the IETF has produced a suite of new protocols specificall
ch environments (see e.g. <xref target="RFC8352"/>). y designed for such environments (see, e.g., <xref target="RFC8352" format="defa
New IETF protocol stack components include the IPv6 over Low-power Wire ult"/>).
less Personal Area Networks (6LoWPAN) adaptation layer New IETF protocol stack components include the IPv6 over Low-Power Wire
<xref target="RFC4944"/><xref target="RFC6282"/><xref target="RFC6775"/ less Personal Area Networks (6LoWPANs) adaptation layer
>, the IPv6 Routing Protocol for Low-power and lossy networks (RPL) routing prot <xref target="RFC4944" format="default"/><xref target="RFC6282" format=
ocol "default"/><xref target="RFC6775" format="default"/>, the IPv6 Routing Protocol
<xref target="RFC6550"/>, and the Constrained Application Protocol (CoA for Low-Power and Lossy Networks (RPL)
P) <xref target="RFC7252"/>.</t> <xref target="RFC6550" format="default"/>, and the Constrained Applicat
ion Protocol (CoAP) <xref target="RFC7252" format="default"/>.</t>
<t>As of the writing, the main current transport layer protocols in IP-bas <t>As of this writing, the main transport-layer protocols in IP-based IoT
ed IoT scenarios are UDP and TCP. TCP has been scenarios are UDP and TCP. TCP has been
criticized, often unfairly, as a protocol that is unsuitable for the IoT. It is true that some TCP features, such as relatively long header size, criticized, often unfairly, as a protocol that is unsuitable for the IoT. It is true that some TCP features, such as relatively long header size,
unsuitability for multicast, and always-confirmed data delivery, are not opti mal for IoT scenarios. However, unsuitability for multicast, and always-confirmed data delivery, are not opti mal for IoT scenarios. However,
many typical claims on TCP unsuitability for IoT (e.g. a high complexit many typical claims on TCP unsuitability for IoT (e.g., a high complexi
y, connection-oriented approach incompatibility with radio duty-cycling, and spu ty, connection-oriented approach incompatibility with radio duty-cycling and spu
rious congestion control activation rious congestion control activation
in wireless links) are not valid, can be solved, or are also found in w in wireless links) are not valid, can be solved, or are also found in w
ell accepted IoT end-to-end reliability mechanisms (see <xref target="IntComp"/> ell-accepted IoT end-to-end reliability mechanisms (see a detailed analysis in <
for a detailed analysis). xref target="IntComp" format="default"/>).
</t> </t>
<t>At the application layer, CoAP was developed over UDP <xref target="RFC
<t>At the application layer, CoAP was developed over UDP <xref target="RFC 7252" format="default"/>. However, the integration of some
7252"/>. However, the integration of some
CoAP deployments with existing infrastructure is being challenged by CoAP deployments with existing infrastructure is being challenged by
middleboxes such as firewalls, which may limit and even block UDP-based middleboxes such as firewalls, which may limit and even block UDP-based
communications. This is the main reason why a CoAP over TCP communications. This is the main reason why a CoAP over TCP
specification has been developed <xref target="RFC8323"/>.</t> specification has been developed <xref target="RFC8323" format="default"/ >.</t>
<t>Other application layer protocols not specifically <t>Other application-layer protocols not specifically
designed for CNNs are also being considered for the IoT space. Some designed for CNNs are also being considered for the IoT space. Some
examples include HTTP/2 and even HTTP/1.1, both of which run over TCP examples include HTTP/2 and even HTTP/1.1, both of which run over TCP
by default <xref target="RFC7230"/> <xref target="RFC7540"/>, and the Extens by default <xref target="RFC7230" format="default"/> <xref target="RFC7540"
ible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/>. TCP is al format="default"/>, and the Extensible Messaging and Presence Protocol (XMPP) <x
so used by non-IETF ref target="RFC6120" format="default"/>. TCP is also used by non-IETF
application-layer protocols in the IoT space such as the Message Queuing Tele application-layer protocols in the IoT space such as the Message Queuing Tele
metry Transport (MQTT) <xref target="MQTT"/> and its metry Transport (MQTT) <xref target="MQTT" format="default"/> and its
lightweight variants.</t> lightweight variants.</t>
<t>TCP is a sophisticated transport protocol that includes optional <t>TCP is a sophisticated transport protocol that includes optional
functionality (e.g. TCP options) that may improve performance in some environ functionality (e.g., TCP options) that may improve performance in some enviro
ments. However, many nments. However, many
optional TCP extensions require complex logic inside the TCP stack optional TCP extensions require complex logic inside the TCP stack
and increase the code size and the memory requirements. Many and increase the code size and the memory requirements. Many
TCP extensions are not required for interoperability with other TCP extensions are not required for interoperability with other
standard-compliant TCP endpoints. Given standard-compliant TCP endpoints. Given
the limited resources on constrained devices, careful selection of optional T CP features can make an implementation more lightweight. the limited resources on constrained devices, careful selection of optional T CP features can make an implementation more lightweight.
</t>
<t>This document provides guidance on how to implement and configure TCP,
as well as on how TCP is advisable to be used by applications, in CNNs. The o
verarching goal is to offer simple measures to allow for lightweight TCP impleme
ntation and suitable operation in such environments. A TCP implementation follow
ing the guidance in this document is intended to be compatible with a TCP endpoi
nt that is compliant to the TCP standards, albeit possibly with a lower performa
nce. This implies that such a TCP client would always be able to connect with a
standard-compliant TCP server, and a corresponding TCP server would always be ab
le to connect with a standard-compliant TCP client.</t>
<t>This document assumes that the reader is familiar with TCP. A comprehensi
ve survey of the TCP standards can be found in <xref target="RFC7414"/>. Similar
guidance regarding the use of TCP in special environments has been published be
fore, e.g., for cellular wireless networks <xref target="RFC3481"/>.
</t>
</section>
<section title="Characteristics of CNNs relevant for TCP">
<section title="Network and link properties">
<t>CNNs are defined in <xref target="RFC7228"/> as networks whose characte
ristics are influenced by being composed of a significant portion of constrained
nodes.
The latter are characterized by significant limitations on processing,
memory, and energy resources, among others <xref target="RFC7228"/>.
The first two dimensions pose constraints on the complexity and on the
memory footprint of the protocols that constrained nodes can support. The latter
requires techniques to save energy, such as radio duty-cycling in wireless devi
ces <xref target="RFC8352"/>, as well as minimization of the number of messages
transmitted/received (and their size).</t>
<t><xref target="RFC7228"/> lists typical network constraints in CNN, incl
uding low achievable bitrate/throughput, high packet loss and high variability o
f packet loss, highly asymmetric link characteristics, severe penalties for usin
g larger packets, limits on reachability over time, etc. CNN may use wireless or
wired technologies (e.g., Power Line Communication), and the transmission rates
are typically low (e.g. below 1 Mbps).</t>
<t>For use of TCP, one challenge is that not all technologies in CNN may be a
ligned with typical Internet subnetwork design principles <xref target="RFC3819"
/>. For instance, constrained nodes often use physical/link layer technologies t
hat
have been characterized as 'lossy', i.e., exhibit a relatively high bit error
rate. Dealing with corruption loss is one of the open issues in the Internet <x
ref target="RFC6077"/>.
</t> </t>
<t>This document provides guidance on how to implement and configure TCP
</section> and guidance on how applications should use TCP in CNNs. The overarching goal i
s to offer simple measures to allow for lightweight TCP implementation and suita
<section title="Usage scenarios"> ble operation in such environments. A TCP implementation following the guidance
in this document is intended to be compatible with a TCP endpoint that is compli
<t>There are different deployment and usage scenarios for CNNs. Some CNNs ant to the TCP standards, albeit possibly with a lower performance. This implies
follow the star topology, whereby one or several hosts are linked to a central that such a TCP client would always be able to connect with a standard-complian
device that acts as a router connecting the CNN to the Internet. Altern t TCP server, and a corresponding TCP server would always be able to connect wit
atively, CNNs may also follow the multihop topology <xref target="RFC6606"/>. h a standard-compliant TCP client.</t>
<t>This document assumes that the reader is familiar with TCP. A comprehen
sive survey of the TCP standards can be found in RFC 7414 <xref target="RFC7414"
format="default"/>. Similar guidance regarding the use of TCP in special enviro
nments has been published before, e.g., for cellular wireless networks <xref tar
get="RFC3481" format="default"/>.
</t> </t>
</section>
<t>In constrained environments, there can be different types of devices <x <section numbered="true" toc="default">
ref target="RFC7228"/>. <name>Characteristics of CNNs Relevant for TCP</name>
For example, there can be devices with single combined send/receive buffer <section numbered="true" toc="default">
, devices with a separate send and receive buffer, or devices with a pool <name>Network and Link Properties</name>
<t>CNNs are defined in <xref target="RFC7228" format="default"/> as netw
orks whose characteristics are influenced by being composed of a significant por
tion of constrained nodes.
The latter are characterized by significant limitations on processing,
memory, and energy resources, among others <xref target="RFC7228" format="defaul
t"/>.
The first two dimensions pose constraints on the complexity and memory
footprint of the protocols that constrained nodes can support. The latter requir
es techniques to save energy, such as radio duty-cycling in wireless devices <xr
ef target="RFC8352" format="default"/> and the minimization of the number of mes
sages transmitted/received (and their size).</t>
<t><xref target="RFC7228" format="default"/> lists typical network const
raints in CNNs, including low achievable bitrate/throughput, high packet loss an
d high variability of packet loss, highly asymmetric link characteristics, sever
e penalties for using larger packets, limits on reachability over time, etc. CNN
s may use wireless or wired technologies (e.g., Power Line Communication), and t
he transmission rates are typically low (e.g., below 1 Mbps).</t>
<t>For use of TCP, one challenge is that not all technologies in a CNN m
ay be aligned with typical Internet subnetwork design principles <xref target="R
FC3819" format="default"/>. For instance, constrained nodes often use physical-
/ link-layer technologies that
have been characterized as 'lossy', i.e., exhibit a relatively high bit error
rate. Dealing with corruption loss is one of the open issues in the Internet <x
ref target="RFC6077" format="default"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>Usage Scenarios</name>
<t>There are different deployment and usage scenarios for CNNs. Some CNN
s follow the star topology, whereby one or several hosts are linked to a central
device that acts as a router connecting the CNN to the Internet. Altern
atively, CNNs may also follow the multihop topology <xref target="RFC6606" forma
t="default"/>.
</t>
<t>In constrained environments, there can be different types of devices
<xref target="RFC7228" format="default"/>.
For example, there can be devices with a single combined send/receive buff
er, a separate send and receive buffer, or a pool
of multiple send/receive buffers. In the latter case, it is possible that buffers are also shared for other protocols.</t> of multiple send/receive buffers. In the latter case, it is possible that buffers are also shared for other protocols.</t>
<!--
TODO: Check https://tools.ietf.org/html/draft-bormann-lwig-7228bis-01
<t> <t>
One key use case for TCP in CNNs is a model where One key use case for TCP in CNNs is a model where
constrained devices connect to unconstrained servers in the Internet. constrained devices connect to unconstrained servers in the Internet.
But it is also possible that both TCP endpoints run on constrained But it is also possible that both TCP endpoints run on constrained
devices. In the first case, devices.
communication possibly has to traverse a middlebox (e.g. a firewall, In the first case,
communication will possibly traverse a middlebox (e.g., a firewall,
NAT, etc.). Figure 1 illustrates such a scenario. Note that the NAT, etc.). Figure 1 illustrates such a scenario. Note that the
scenario is asymmetric, as the unconstrained device will typically scenario is asymmetric, as the unconstrained device will typically
not suffer the severe constraints of the constrained device. The not suffer the severe constraints of the constrained device. The
unconstrained device is expected to be mains-powered, to have high unconstrained device is expected to be mains-powered, have a high
amount of memory and processing power, and to be connected to a amount of memory and processing power, and be connected to a
resource-rich network. resource-rich network.
</t> </t>
<t>
<t>
Assuming that a majority of constrained devices will correspond to Assuming that a majority of constrained devices will correspond to
sensor nodes, the amount of data traffic sent by constrained devices sensor nodes, the amount of data traffic sent by constrained devices
(e.g. sensor node measurements) is expected to be higher than the (e.g., sensor node measurements) is expected to be higher than the
amount of data traffic in the opposite direction. Nevertheless, amount of data traffic in the opposite direction. Nevertheless,
constrained devices may receive requests (to which they may constrained devices may receive requests (to which they may
respond), commands (for configuration purposes and for constrained respond), commands (for configuration purposes and for constrained
devices including actuators) and relatively infrequent devices including actuators), and relatively infrequent
firmware/software updates. firmware/software updates.
<figure title="TCP communication between a constrained device and an </t>
unconstrained device, traversing a middlebox." <figure anchor="fig_scenario">
anchor="fig_scenario"> <name>TCP Communication between a Constrained Device and an Unconstrai
<artwork><![CDATA[ ned Device, Traversing a Middlebox</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------+ +---------------+
o o <-------- TCP communication -----> | | o o <-------- TCP communication -----> | |
o o | | o o | |
o o | Unconstrained | o o | Unconstrained |
o o +-----------+ | device | o o +-----------+ | device |
o o o ------ | Middlebox | ------- | | o o o ------ | Middlebox | ------- | |
o o +-----------+ | (e.g. cloud) | o o +-----------+ | (e.g., cloud) |
o o o | | o o o | |
+---------------+ +---------------+
constrained devices Constrained devices
]]></artwork>
]]></artwork></figure> </figure>
</section>
</t> <section numbered="true" toc="default">
<name>Communication and Traffic Patterns</name>
</section> <t>IoT applications are characterized by a number of different communica
tion patterns. The following non-comprehensive list explains some typical exampl
<section title="Communication and traffic patterns"> es:</t>
<dl spacing="normal">
<t>IoT applications are characterized by a number of different communicatio <dt>Unidirectional transfers:</dt><dd>An IoT device (e.g., a sensor) c
n patterns. The following non-comprehensive list explains some typical examples: an (repeatedly) send updates to the other endpoint. There is not always a need f
</t> or an application response back to the IoT device. </dd>
<dt>Request-response patterns:</dt><dd>An IoT device receiving a reque
<t><list style="symbols"> st from the other endpoint, which triggers a response from the IoT device.</dd>
<dt>Bulk data transfers:</dt><dd>A typical example for a long file tra
<t>Unidirectional transfers: An IoT device (e.g. a sensor) can send (repe nsfer would be an IoT device firmware update.</dd>
atedly) updates to the other endpoint. There is not always a need for an applica </dl>
tion response back to the IoT device. </t> <t>A typical communication pattern is that a constrained device communic
ates with an unconstrained device (cf.&nbsp;<xref target="fig_scenario" format="
<t>Request-response patterns: An IoT device receiving a request from the default"/>). But it is also possible that constrained devices communicate amongs
other endpoint, which triggers a response from the IoT device.</t> t themselves.</t>
</section>
<t>Bulk data transfers: A typical example for a long file transfer would
be an IoT device firmware update.</t>
</list></t>
<t>A typical communication pattern is that a constrained device communicate
s with an unconstrained device (cf. <xref target="fig_scenario"/>). But it is al
so possible that constrained devices communicate amongst themselves.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="TCP implementation and configuration in CNNs"> <name>TCP Implementation and Configuration in CNNs</name>
<t>This section explains how a TCP stack can deal with typical constraints in CNN. The guidance in this section relates to the TCP implementation and its configuration. <t>This section explains how a TCP stack can deal with typical constraints in CNN. The guidance in this section relates to the TCP implementation and its configuration.
</t> </t>
<section numbered="true" toc="default">
<section title="Addressing path properties"> <name>Addressing Path Properties</name>
<section numbered="true" toc="default">
<section title="Maximum Segment Size (MSS)"> <name>Maximum Segment Size (MSS)</name>
<t>Assuming that IPv6 is used, and for the sake of lightweight impleme ntation and operation, unless applications <t>Assuming that IPv6 is used, and for the sake of lightweight impleme ntation and operation, unless applications
require handling large data units (i.e. leading to an IPv6 datagram require handling large data units (i.e., leading to an IPv6 datagram
size greater than 1280 bytes), it may be desirable to limit the IP dat agram size to size greater than 1280 bytes), it may be desirable to limit the IP dat agram size to
1280 bytes in order to avoid the need to support Path MTU Discovery <x 1280 bytes in order to avoid the need to support Path MTU Discovery <x
ref target="RFC8201"/>. ref target="RFC8201" format="default"/>.
In addition, an IP datagram size of 1280 bytes avoids incurring IPv6-l In addition, an IP datagram size of 1280 bytes avoids incurring IPv6-l
ayer fragmentation <xref target="RFC8900"/>. ayer fragmentation <xref target="RFC8900" format="default"/>.
</t> </t>
<t>An IPv6 datagram size exceeding 1280 bytes can be avoided by settin <t>An IPv6 datagram size exceeding 1280 bytes can be avoided by settin
g the TCP MSS not larger than 1220 bytes. Note that g the TCP MSS to 1220 bytes or less. Note that
it is already a requirement that TCP implementations consume payload space in it is already a requirement for TCP implementations to consume payload space
stead of increasing datagram size when including IP or TCP options instead of increasing datagram size when including IP or TCP options
in an IP packet to be sent <xref target="RFC6691"/>. Therefore, it is not re in an IP packet to be sent <xref target="RFC6691" format="default"/>. Theref
quired to advertise an MSS smaller than 1220 bytes in order to accommodate TCP o ore, it is not required to advertise an MSS smaller than 1220 bytes in order to
ptions. accommodate TCP options.
</t> </t>
<t>Note that setting the MTU to 1280 bytes is possible for link-layer
<t>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 by a short
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 of bytes.
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 802.15.4 networks. The adaptation layer includes a fragmentation mechanism, 6LoWPAN defined an adaptation layer to support IPv6 over IEEE 802.15.4 networks. The adaptation layer includes a fragmentation mechanism,
since IPv6 requires the layer below to support an MTU of 1280 bytes <x since IPv6 requires the layer below to support an MTU of 1280 bytes <x
ref target="RFC8200"/>, while IEEE 802.15.4 lacked fragmentation mechanisms. ref target="RFC8200" format="default"/>, while IEEE 802.15.4 lacks fragmentation
6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes <xref target=" mechanisms.
RFC4944"/>. Other technologies, such as Bluetooth LE <xref target="RFC7668"/>, 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes <xref target="
ITU-T G.9959 <xref target="RFC7428"/> or DECT-ULE <xref target="RFC810 RFC4944" format="default"/>. Other technologies, such as Bluetooth low energy <x
5"/>, also use 6LoWPAN-based adaptation layers in order to enable ref target="RFC7668" format="default"/>,
IPv6 support. These technologies do support link layer fragmentation. ITU-T G.9959 <xref target="RFC7428" format="default"/>, or Digital Enh
By exploiting this anced Cordless
Telecommunications (DECT) Ultra Low Energy (ULE) <xref target="RFC81
05" format="default"/>, also use 6LoWPAN-based adaptation layers in order to ena
ble
IPv6 support. These technologies do support link-layer fragmentation.
By exploiting this
functionality, the adaptation layers that enable IPv6 over such techno logies also define an MTU of 1280 bytes. functionality, the adaptation layers that enable IPv6 over such techno logies also define an MTU of 1280 bytes.
</t> </t>
<t>On the other hand, there exist technologies also used in the CNN sp
<t>On the other hand, there exist technologies also used in the CNN sp ace, such as Master Slave (MS) / Token Passing (TP) <xref target="RFC8163" forma
ace, such as Master Slave / Token Passing (TP) <xref target="RFC8163"/>, t="default"/>,
Narrowband IoT (NB-IoT) <xref target="RFC8376"/> or IEEE 802.11ah < Narrowband IoT (NB-IoT) <xref target="RFC8376" format="default"/>,
xref target="I-D.delcarpio-6lo-wlanah"/>, or IEEE 802.11ah <xref target="I-D.delcarpio-6lo-wlanah" format="default"/>,
that do not suffer the same degree of frame size limitations as the that do not suffer the same degree of frame size limitations as the
technologies mentioned above. The MTU for MS/TP is recommended to be 1500 bytes technologies mentioned above.
<xref target="RFC8163"/>, It is recommended that the MTU for MS/TP be 1500 bytes <xref target=
"RFC8163" format="default"/>;
the MTU in NB-IoT is 1600 bytes, and the maximum frame payload size for IEEE 802.11ah is 7991 bytes. the MTU in NB-IoT is 1600 bytes, and the maximum frame payload size for IEEE 802.11ah is 7991 bytes.
</t> </t>
<t> Using a larger MSS (to a suitable extent) may be beneficial in som
<t> Using larger MSS (to a suitable extent) may be beneficial in some e scenarios,
scenarios,
especially when transferring large payloads, as it reduces the num ber of packets (and packet headers) especially when transferring large payloads, as it reduces the num ber of packets (and packet headers)
required for a given payload. However, the characteristics of the constrained network need to be considered. required for a given payload. However, the characteristics of the constrained network need to be considered.
In particular, in a lossy network where unreliable fragment delive ry is used, the amount of data that TCP unnecessarily In particular, in a lossy network where unreliable fragment delive ry is used, the amount of data that TCP unnecessarily
retransmits due to fragment loss increases (and throughput decreas es) quickly with the MSS. This happens because the loss of a fragment leads to t he retransmits due to fragment loss increases (and throughput decreas es) quickly with the MSS. This happens because the loss of a fragment leads to t he
loss of the whole fragmented packet being transmitted. Unnecessary data retransmission is particularly loss of the whole fragmented packet being transmitted. Unnecessary data retransmission is particularly
harmful in CNNs due to the resource constraints of such environmen harmful in CNNs due to the resource constraints of such environmen
ts. Note that, while the original 6LoWPAN fragmentation ts.
mechanism <xref target="RFC4944"/> does not offer reliable fragmen
t delivery, fragment recovery functionality for 6LoWPAN or 6Lo environments
is being standardized as of the writing <xref target="I-D.ietf-6lo
-fragment-recovery"/>.
</t>
Note that, while the original 6LoWPAN fragmentation
mechanism <xref target="RFC4944" format="default"/> does not offer
reliable fragment delivery, fragment recovery functionality for 6LoWPAN or 6Lo
environments
has been standardized <xref target="RFC8931" format="default"/>.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Explicit Congestion Notification (ECN)"> <name>Explicit Congestion Notification (ECN)</name>
<t>ECN <xref target="RFC3168" format="default"/> allows a router to si
<t>Explicit Congestion Notification (ECN) <xref target="RFC3168"/> ECN gnal
allows a router to signal in the IP header of a packet that congestion is rising, for example
in the IP header of a packet that congestion is arising, for exampl ,
e
when a queue size reaches a certain threshold. An ECN-enabled TCP when a queue size reaches a certain threshold. An ECN-enabled TCP
receiver will echo back the congestion signal to the TCP sender by receiver will echo back the congestion signal to the TCP sender by
setting a flag in its next TCP ACK. The sender triggers congestion setting a flag in its next TCP Acknowledgment (ACK). The sender tr iggers congestion
control measures as if a packet loss had happened. control measures as if a packet loss had happened.
</t> </t>
<t>RFC 8087 <xref target="RFC8087" format="default"/> outlines the pri
<t>The document <xref target="RFC8087"/> outlines the principal gains ncipal gains in terms of increased throughput,
in terms of increased throughput,
reduced delay, and other benefits when ECN is used over a network p ath that includes equipment that supports Congestion Experienced reduced delay, and other benefits when ECN is used over a network p ath that includes equipment that supports Congestion Experienced
(CE) marking. In the context of CNNs, a remarkable feature of ECN (CE) marking. In the context of CNNs, a remarkable feature of ECN
is that congestion can be signalled without incurring packet drops (which will l is that congestion can be signaled without incurring packet drops (which will le
ead to retransmissions and consumption of limited resources such as energy and b ad to retransmissions and consumption of limited resources such as energy and ba
andwidth). ndwidth).
</t> </t>
<t>ECN can further reduce packet losses since congestion control <t>ECN can further reduce packet losses since congestion control
measures can be applied earlier <xref target="RFC2884"/>. Fewer lost packets implies measures can be applied earlier <xref target="RFC2884" format="default"/>. F ewer lost packets implies
that the number of retransmitted segments decreases, which is 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 often i mpossible to typical for CNNs. In such traffic patterns, it is more difficult and often i mpossible to
detect packet loss without retransmission timeouts (e.g., as there detect packet loss without retransmission timeouts (e.g., as there
may be no three duplicate ACKs). Any retransmission timeout slows may not be three duplicate ACKs). Any retransmission timeout slows
down the data transfer significantly. In addition, if the down the data transfer significantly. In addition, if the
constrained device uses power saving techniques, a retransmission constrained device uses power-saving techniques, a retransmission
timeout will incur a wake-up action, in contrast to ACK clock- timeout will incur a wake-up action, in contrast to ACK
triggered sending. When the congestion window of a TCP sender has a clock-triggered sending. When the congestion window of a TCP sender has a
size of one segment and a TCP ACK with an ECN signal (ECE flag) arrives size of one segment and a TCP ACK with an ECN signal (ECN-Echo (ECE) flag) arr
ives
at the TCP sender, the TCP sender resets the retransmit timer, and at the TCP sender, the TCP sender resets the retransmit timer, and
the sender will only be able to send a new packet when the retransmit the sender will only be able to send a new packet when the retransmit
timer expires. Effectively, the TCP sender reduces at that timer expires. Effectively, at that moment, the TCP sender reduces its
moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 sending rate from 1 segment per Round-Trip Time (RTT) to 1
segment per Retransmission Timeout (RTO) and reduces the sending rate further on each ECN signal segment per Retransmission Timeout (RTO) and reduces the sending rate further on each ECN signal
received in subsequent TCP ACKs. Otherwise, if an ECN signal is not received in subsequent TCP ACKs. Otherwise, if an ECN signal is not
present in a subsequent TCP ACK the TCP sender resumes the normal present in a subsequent TCP ACK, the TCP sender resumes the normal
ACK-clocked transmission of segments <xref target="RFC3168"/>. ACK-clocked transmission of segments <xref target="RFC3168" format="default"/>
.
</t> </t>
<t>ECN can be <t>ECN can be
incrementally deployed in the Internet. Guidance on configuration and usage incrementally deployed in the Internet. Guidance on configuration and usage
of ECN is provided in <xref target="RFC7567"/>. of ECN is provided in RFC 7567 <xref target="RFC7567" format="default"/>.
Given the benefits, more and more TCP stacks in the Internet support ECN, and Given the benefits, more and more TCP stacks in the Internet support ECN, and
it specifically makes sense to leverage ECN in controlled it makes sense to specifically leverage ECN in controlled
environments such as CNNs. As of the writing, there is on-going work to exten environments such as CNNs. As of this writing, there is ongoing work to exten
d the types of TCP packets that are ECN-capable, including pure ACKs <xref targe d the types of TCP packets that are ECN capable, including pure ACKs <xref targe
t="I-D.ietf-tcpm-generalized-ecn"/>. t="I-D.ietf-tcpm-generalized-ecn" format="default"/>.
Such a feature may further increase the benefits of ECN in CNN environments. Note, however, that supporting ECN increases implementation complexity. Such a feature may further increase the benefits of ECN in CNN environments. Note, however, that supporting ECN increases implementation complexity.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Explicit loss notifications"> <name>Explicit Loss Notifications</name>
<t>There has been a significant body of research on solutions capable
<t>There has been a significant body of research on solutions capable of explicitly indicating whether a TCP segment loss is due to corruption, in ord
of explicitly indicating whether a TCP segment loss is due to corruption, in ord er to avoid activation of congestion control mechanisms <xref target="ETEN" form
er to avoid activation of congestion control mechanisms <xref target="ETEN"/> <x at="default"/> <xref target="RFC2757" format="default"/>. While such solutions m
ref target="RFC2757"/>. While such solutions may provide significant improvement ay provide significant improvement, they have not been widely deployed and remai
, they have not been widely deployed and remain as experimental work. In fact, a n as experimental work. In fact, as of today, the IETF has not standardized any
s of today, the IETF has not standardized any such solution. such solution.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="TCP guidance for single-MSS stacks"> <name>TCP Guidance for Single-MSS Stacks</name>
<t>This section discusses TCP stacks that allow transferring a single MS
<t>This section discusses TCP stacks that allow transferring a single S. More general guidance is provided in <xref target="Beyond1MSS" format="defaul
MSS. More general guidance is provided in <xref target="Beyond1MSS"/>. t"/>.
</t> </t>
<section numbered="true" toc="default" anchor="single_MSS_stacks_benefit
<section title="Single-MSS stacks - benefits and issues"> s">
<name>Single-MSS Stacks -- Benefits and Issues</name>
<t> A TCP stack can reduce the memory requirements by advertising a <t> A TCP stack can reduce the memory requirements by advertising a
TCP window size of one MSS, and also transmit at most one MSS of TCP window size of 1 MSS and also transmit, at most, 1 MSS of
unacknowledged data. In that case, both congestion and flow con trol implementation are quite simple. Such a small receive and send window unacknowledged data. In that case, both congestion and flow con trol implementation are 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 1 MSS can significantly affect
performance. A stop-and-wait operation results in low throughpu performance. A stop-and-wait operation results in low throughpu
t for transfers that exceed the length of one MSS, e.g., a firmware t for transfers that exceed the length of 1 MSS, e.g., a firmware
download. Furthermore, a single-MSS solution relies solely on t imer-based loss recovery, therefore missing the performance gain of Fast download. Furthermore, a single-MSS solution relies solely on t imer-based loss recovery, therefore missing the performance gain of Fast
Retransmit and Fast Recovery (which require a larger window size , see Section 3.3.1). Retransmit and Fast Recovery (which requires a larger window siz e; see <xref target="loss_recovery_flow" format="default"/>).
</t> </t>
<t>If CoAP is used over TCP with the default setting for NSTART in RFC
<t>If CoAP is used over TCP with the default setting for NSTART in <xr 7252 <xref target="RFC7252" format="default"/>, a CoAP endpoint is not allowed
ef target="RFC7252"/>, a CoAP endpoint is not allowed to send to send
a new message to a destination until a response for the previous me ssage sent to that destination has been received. This is equivalent to an a new message to a destination until a response for the previous me ssage sent to that destination has been received. This is equivalent to an
application-layer window size of 1 data unit. For this use of CoAP application-layer window size of 1 data unit. For this use of CoAP
, a maximum TCP window of one MSS may be sufficient, as long as the , a maximum TCP window of 1 MSS may be sufficient, as long as the
CoAP message size does not exceed one MSS. An exception in CoAP ove CoAP message size does not exceed 1 MSS. An exception in CoAP over
r TCP, though, is the Capabilities and Settings Message (CSM) that must be sent TCP, though, is the Capabilities and Settings Message (CSM) that must be sent at
at the the
start of the TCP connection. The first application message carrying user data is allowed to be sent immediately after the CSM message. start of the TCP connection. The first application message carrying user data is allowed to be sent immediately after the CSM message.
If the sum of the CSM size plus the application message size exceed s the MSS, a sender using a single-MSS stack will need to wait for the ACK confi rming If the sum of the CSM size plus the application message size exceed s the MSS, a sender using a single-MSS stack will need to wait for the ACK confi rming
the CSM before sending the application message. the CSM before sending the application message.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="TCP options for single-MSS stacks"> <name>TCP Options for Single-MSS Stacks</name>
<t>A TCP implementation needs to support, at a minimum, TCP options 2,
<t>A TCP implementation needs to support, at a minimum, TCP options 2, 1, and 0. These are, respectively, the MSS option,
1 and 0. These are, respectively, the Maximum Segment Size (MSS) option, the No-Operation option, and the End Of Option List marker <xref ta
the No-Operation option, and the End Of Option List marker <xref ta rget="RFC0793" format="default"/>. None of these are a substantial burden to sup
rget="RFC0793"/>. None of these are a substantial burden to support. port.
These options are sufficient for interoperability with a standard-c ompliant TCP endpoint, albeit many TCP stacks support additional options These options are sufficient for interoperability with a standard-c ompliant TCP endpoint, albeit many TCP stacks support additional options
and can negotiate their use. A TCP implementation is permitted to s ilently ignore all other TCP options. and can negotiate their use. A TCP implementation is permitted to s ilently ignore all other TCP options.
</t> </t>
<t>A TCP implementation for a constrained device that uses a single-MS
<t>A TCP implementation for a constrained device that uses a single-MS S TCP receive or transmit window size may not benefit from supporting the follow
S TCP receive or transmit window size may not benefit from supporting the follow ing TCP options: Window Scale <xref target="RFC7323" format="default"/>, TCP Tim
ing TCP options: Window scale <xref target="RFC7323"/>, TCP Timestamps <xref tar estamps <xref target="RFC7323" format="default"/>, Selective Acknowledgment (SAC
get="RFC7323"/>, Selective Acknowledgments (SACK) and SACK-Permitted <xref targe K) <xref target="RFC2018" format="default"/>, and SACK-Permitted <xref target="R
t="RFC2018"/>. Also other TCP options may not be required on a constrained devic FC2018" format="default"/>. Also, other TCP options may not be required on a con
e with a very lightweight implementation. With regard to strained device with a very lightweight implementation. With regard to
the Window scale option, note that it is only useful if a window si the Window Scale option, note that it is only useful if a window si
ze greater than 64 kB is needed. ze greater than 64 kB is needed.
</t> </t>
<t> <t>
Note that a TCP sender can benefit from the TCP Timestamps option <x Note that a TCP sender can benefit from the TCP Timestamps option <x
ref target="RFC7323"/> in detecting spurious RTOs. The latter are quite likely t ref target="RFC7323" format="default"/> in detecting spurious RTOs. The latter a
o occur re quite likely to occur
in CNN scenarios due to a number of reasons (e.g. route changes in in CNN scenarios due to a number of reasons (e.g., route changes in
a multihop scenario, link layer retries, etc.). The header overhead incurred a multihop scenario, link-layer retries, etc.). The header overhead incurred
by the Timestamps option (of up to 12 bytes) needs to be taken into account. by the Timestamps option (of up to 12 bytes) needs to be taken into account.
</t> </t>
</section> </section>
<section anchor="DelAck" numbered="true" toc="default">
<section title="Delayed Acknowledgments for single-MSS stacks" anchor="D <name>Delayed Acknowledgments for Single-MSS Stacks</name>
elAck">
<t>TCP Delayed Acknowledgments are meant to reduce the number of ACKs sent within a TCP connection, thus reducing network overhead, but <t>TCP Delayed Acknowledgments are meant to reduce the number of ACKs sent within a TCP connection, thus reducing network overhead, but
they may increase the time until a sender may receive an ACK. In g eneral, usefulness of Delayed ACKs depends heavily on the usage they may increase the time until a sender may receive an ACK. In g eneral, usefulness of Delayed ACKs depends heavily on the usage
scenario (see Section 3.3.2). There can be interactions with singl e-MSS stacks. scenario (see <xref target="delayed_ACKs" format="default"/>). The re can be interactions with single-MSS stacks.
</t> </t>
<t>When traffic is unidirectional, if the sender can send at most 1 MS
<t>When traffic is unidirectional, if the sender can send at most one S of data or the receiver advertises a receive window not greater than the MSS,
MSS of data or the receiver advertises a receive window not greater than the MSS Delayed ACKs may unnecessarily contribute delay (up to 500 ms) to the RTT <xref
, Delayed ACKs may unnecessarily contribute delay (up to 500 ms) to the RTT [RFC target="RFC5681" format="default"/>, which limits the throughput and can increas
5681], which limits the throughput and can increase data delivery time. Note tha e data delivery time. Note that, in some cases, it may not be possible to disabl
t, in some cases, it may not be possible to disable Delayed ACKs. One known w e Delayed ACKs. One known workaround is to split the
orkaround is to split the data to be sent into two segments of smaller size. A standard-comp
data to be sent into two segments of smaller size. A standard comp liant TCP receiver may immediately acknowledge the second MSS of data, which
liant TCP receiver may immediately acknowledge the second MSS of data, which can improve throughput. However, this "split hack" may not always w
can improve throughput. However, this 'split hack' may not always w ork since a TCP receiver is required to acknowledge every second full-sized segm
ork since a TCP receiver is required to acknowledge every second full-sized segm ent, but not two consecutive small segments. The overhead of sending two IP
ent, but not two consecutive small segments. The overhead of sending two IP packets instead of one is another downside of the "split hack".
packets instead of one is another downside of the 'split hack'.
</t> </t>
<t>Similar issues may happen when the sender uses the Nagle algorithm,
<t>Similar issues may happen when the sender uses the Nagle algorithm, since the sender may need to wait for an unnecessarily Delayed ACK
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 the sender can only handle stop-and-wait operation to 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. at the TCP level.
</t> </t>
<t>For request-response traffic, when the receiver uses Delayed ACKs, a response to a data message can piggyback an ACK, as long as the latter is sent before the Delayed ACK timer expires, thus avoiding unnecessary ACKs without pa yload. <t>For request-response traffic, when the receiver uses Delayed ACKs, a response to a data message can piggyback an ACK, as long as the latter is sent before the Delayed ACK timer expires, thus avoiding unnecessary ACKs without pa yload.
Disabling Delayed ACKs at the request sender allows an immediate AC K for the data segment carrying the response. Disabling Delayed ACKs at the request sender allows an immediate AC K for the data segment carrying the response.
</t> </t>
<!-- Comment from Rahul:
A single MSS implies max one in-flight segment ... While such a mechan
ism sure will help reduce implementation complexity and the buffer requirement o
n the sender, but it has a major problem with delayed ACKs mechanism on the rece
iver. There is a hack (http://contiki.sourceforge.net/docs/2.6/a01696.html) impl
emented in UIP which circumvents this issue.
</section> </section>
<section numbered="true" toc="default">
<section title="RTO calculation for single-MSS stacks"> <name>RTO Calculation for Single-MSS Stacks</name>
<t>The RTO calculation is one of the fundamental TCP algorithms <xref
<t>The RTO calculation is one of the fundamental TCP algorithms <xref target="RFC6298" format="default"/>. There is a fundamental trade-off:
target="RFC6298"/>. There is a fundamental trade-off: a short, aggressive RTO behavior reduces wait time before retransmi
A short, aggressive RTO behavior reduces wait time before retransmi ssions, but it also increases the probability of spurious timeouts.
ssions, but it also increases the probability of spurious timeouts. The latter leads to unnecessary waste of potentially scarce resourc
The latter lead to unnecessary waste of potentially scarce resource es in CNNs such as energy and bandwidth. In contrast,
s in CNNs such as energy and bandwidth. In contrast, a conservative timeout can result in long error recovery times and,
a conservative timeout can result in long error recovery times and thus, needlessly delay data delivery.
thus needlessly delay data delivery. </t>
</t> <t>If a TCP sender uses a very small window size, and it cannot benefi
t from Fast Retransmit and Fast Recovery or SACK, the RTO algorithm has a
<t>If a TCP sender uses a very small window size, and it cannot benefit
from Fast Retransmit/Fast Recovery or SACK, the RTO algorithm has a
large impact on performance. In that case, RTO algorithm tuning may be considered, although careful large impact on performance. In that case, RTO algorithm tuning may be considered, although careful
assessment of possible drawbacks is recommended <xref target="I-D.ie assessment of possible drawbacks is recommended <xref target="RFC896
tf-tcpm-rto-consider"/>. 1" format="default"/>.
</t> </t>
<t>As an example, adaptive RTO algorithms defined for CoAP over UDP ha
<t>As an example, adaptive RTO algorithms defined for CoAP over UDP hav ve been found to perform well in CNN scenarios <xref target="Commag" format="def
e been found to perform well in CNN scenarios <xref target="Commag"/> ault"/>
<xref target="I-D.ietf-core-fasor"/>. <xref target="I-D.ietf-core-fasor" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Beyond1MSS" numbered="true" toc="default">
<section title="General recommendations for TCP in CNNs" anchor="Beyond1MS <name>General Recommendations for TCP in CNNs</name>
S"> <t>This section summarizes some widely used techniques to improve TCP, w
ith a focus on their use in CNNs. The TCP extensions discussed here are useful i
<t>This section summarizes some widely used techniques to improve TCP n a wide range of network scenarios, including CNNs. This section is not compreh
, with a focus on their use in CNNs. The TCP extensions discussed here are usefu ensive. A comprehensive survey of TCP extensions is published in RFC 7414 <xref
l in a wide range of network scenarios, including CNNs. This section is not comp target="RFC7414" format="default"/>.</t>
rehensive. A comprehensive survey of TCP extensions is published in <xref target <section numbered="true" toc="default" anchor="loss_recovery_flow">
="RFC7414"/>.</t> <name>Loss Recovery and Congestion/Flow Control</name>
<t>Devices that have enough memory to allow a larger (i.e., more than
<section title="Loss recovery and congestion/flow control"> 3 MSS of data) TCP window size can leverage a more efficient loss recovery
than the timer-based approach used for a smaller TCP window size (s
<t>Devices that have enough memory to allow a larger (i.e. more than 3 ee <xref target="single_MSS_stacks_benefits" format="default"/>) by
MSS of data) TCP window size can leverage a more efficient loss recovery using Fast Retransmit and Fast Recovery <xref target="RFC5681" form
than the timer-based approach used for smaller TCP window size (see at="default"/>, at the expense of slightly greater complexity and Transmission C
Section 3.2.1) by ontrol Block (TCB) size.
using Fast Retransmit and Fast Recovery <xref target="RFC5681"/>, a
t the expense of slightly greater complexity and Transmission Control Block (TCB
) size.
Assuming that Delayed ACKs are used by the receiver, a window size of up to 5 MSS is required for Fast Retransmit and Fast Recovery Assuming that Delayed ACKs are used by the receiver, a window size of up to 5 MSS is required for Fast Retransmit and Fast Recovery
to work efficiently: If in a given TCP transmission of full-sized s egments 1, 2, 3, 4, and 5, segment 2 gets lost, and the ACK for segment 1 to work efficiently: in a given TCP transmission of full-sized segm ents 1, 2, 3, 4, and 5, if segment 2 gets lost, and the ACK for segment 1
is held by the Delayed ACK timer, then the sender should get an ACK for segment 1 when 3 arrives and duplicate ACKs when segments 4, 5, and 6 is held by the Delayed ACK timer, then the sender should get an ACK for segment 1 when 3 arrives and duplicate ACKs when segments 4, 5, and 6
arrive. It will retransmit segment 2 when the third duplicate ACK arrives. In order to have segments 2, 3, 4, 5, and 6 sent, the window arrive. It will retransmit segment 2 when the third duplicate ACK arrives. In order to have segments 2, 3, 4, 5, and 6 sent, the window
has to be of at least 5 MSS. With an MSS of 1220 bytes, a buffer o f a size of 5 MSS would require 6100 bytes. has to be of at least 5 MSS. With an MSS of 1220 bytes, a buffer o f a size of 5 MSS would require 6100 bytes.
</t> </t>
<t>The example in the previous paragraph did not use a further TCP imp
<t>The example in the previous paragraph did not use a further TCP imp rovement such as Limited Transmit <xref target="RFC3042" format="default"/>. The
rovement such as Limited Transmit <xref target="RFC3042"/>. The latter latter
may also be useful for any transfer that has more than one segment in flight. Small transfers tend may also be useful for any transfer that has more than one segment in flight. Small transfers tend
to benefit more from Limited Transmit, because they are more likely to not receive enough duplicate ACKs. Assuming the example to benefit more from Limited Transmit, because they are more likely to not receive enough duplicate ACKs. Assuming the example
in the previous paragraph, Limited Transmit allows sending 5 MSS wi in the previous paragraph, Limited Transmit allows sending 5 MSS wi
th a congestion window (cwnd) of 3 segments, plus two additional th a congestion window (cwnd) of three segments, plus two additional
segments for the first two duplicate ACKs. With Limited Transmit, e segments for the first two duplicate ACKs. With Limited Transmit, e
ven a cwnd of 2 segments allows sending 5 MSS, at the expense of ven a cwnd of two segments allows sending 5 MSS, at the expense of
additional delay contributed by the Delayed ACK timer for the ACK t hat confirms segment 1. additional delay contributed by the Delayed ACK timer for the ACK t hat confirms segment 1.
</t> </t>
<t>When a multiple-segment window is used, the receiver will need to m anage the reception of possible out-of-order received segments, <t>When a multiple-segment window is used, the receiver will need to m anage the reception of possible out-of-order received segments,
requiring sufficient buffer space. Note that even when a 1-MSS wind ow is used, out-of-order arrival should also be managed, as the sender may send multiple sub-MSS packets that fit in the window. (On the other hand, the receive r is free to simply drop out-of-order segments, thus forcing retransmissions). requiring sufficient buffer space. Note that even when a window of 1 MSS is used, out-of-order arrival should also be managed, as the sender may se nd multiple sub-MSS packets that fit in the window. (On the other hand, the rece iver is free to simply drop out-of-order segments, thus forcing retransmissions. )
</t> </t>
<section title="Selective Acknowledgments (SACK)"> <section numbered="true" toc="default">
<name>Selective Acknowledgments (SACKs)</name>
<t> <t>
If a device with less severe memory and processing constraints can If a device with less severe memory and processing constraints can
afford advertising a TCP window size of several MSS, it makes sense afford advertising a TCP window size of several MSSs, it makes sense
to support the SACK option to improve performance. SACK allows a to support the SACK option to improve performance. SACK allows a
data receiver to inform the data sender of non-contiguous data blocks data receiver to inform the data sender of non-contiguous data blocks
received, thus a sender (having previously sent the SACK-Permitted received, thus a sender (having previously sent the SACK-Permitted
option) can avoid performing unnecessary retransmissions, saving option) can avoid performing unnecessary retransmissions, saving
energy and bandwidth, as well as reducing latency. In addition, SACK often al lows for faster loss recovery when there is more than one lost segment in a wind ow of data, since SACK recovery may complete with less RTTs. SACK is energy and bandwidth, as well as reducing latency. In addition, SACK often al lows for faster loss recovery when there is more than one lost segment in a wind ow of data, since SACK recovery may complete with less RTTs. SACK is
particularly useful for bulk data transfers. A receiver supporting SACK will need to keep track of the data blocks that need to be received. The sender will also need to keep track of which data segments need to be resent after learning which data blocks are missing at the receiver. SACK adds particularly useful for bulk data transfers. A receiver supporting SACK will need to keep track of the data blocks that need to be received. The sender will also need to keep track of which data segments need to be resent after learning which data blocks are missing at the receiver. SACK adds
8*n+2 bytes to the TCP header, where n denotes the number of data 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 blocks received, up to four blocks. For a low number of out-of-order
segments, the header overhead penalty of SACK is compensated by segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions. When the sender discovers the data bloc ks that have already been received, it needs to also avoiding unnecessary retransmissions. When the sender discovers the data bloc ks that have already been received, it needs to also
store the necessary state to avoid unnecessary retransmission of data segment s that have already been received. store the necessary state to avoid unnecessary retransmission of data segment s that have already been received.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default" anchor="delayed_ACKs">
<section title="Delayed Acknowledgments"> <name>Delayed Acknowledgments</name>
<t>For certain traffic patterns, Delayed ACKs may have a detrimental e
<t>For certain traffic patterns, Delayed ACKs may have a detrimental e ffect, as already noted in <xref target="DelAck" format="default"/>. Advanced TC
ffect, as already noted in <xref target="DelAck"/>. Advanced TCP stacks may use P stacks may use heuristics to determine the maximum delay for an ACK. For CNNs,
heuristics to determine the maximum delay for an ACK. For CNNs, the recommendati the recommendation depends on the expected communication patterns.
on depends on the expected communication patterns. </t>
</t> <t>When traffic over a CNN is expected mostly to be unidirectional mes
sages with a size typically up to 1 MSS, and the time between two
<t>When traffic over a CNN is expected to mostly be unidirectional mes
sages with a size typically up to one MSS, and the time between two
consecutive message transmissions is greater than the Delayed ACK t imeout, it may make sense to use a smaller timeout or disable Delayed ACKs consecutive message transmissions is greater than the Delayed ACK t imeout, it may make sense to use a smaller timeout or disable Delayed ACKs
at the receiver. This avoids incurring additional delay, as well as the energy consumption of the sender (which might e.g. keep its radio at the receiver. This avoids incurring additional delay, as well as the energy consumption of the sender (which might, e.g., keep its radio
interface in receive mode) during that time. Note that disabling De layed ACKs may only be possible if the peer device is administered interface in receive mode) during that time. Note that disabling De layed ACKs may only be possible if the peer device is administered
by the same entity managing the constrained device. For request-res ponse traffic, enabling Delayed ACKs is recommended at by the same entity managing the constrained device. For request-res ponse traffic, enabling Delayed ACKs is recommended at
the server end, in order to allow combining a response with the ACK into a single segment, thus increasing efficiency. In addition, if the server end, in order to allow combining a response with the ACK into a single segment, thus increasing efficiency. In addition, if
a client issues requests infrequently, disabling Delayed ACKs at th e client allows an immediate ACK for the data segment a client issues requests infrequently, disabling Delayed ACKs at th e client allows an immediate ACK for the data segment
carrying the response. carrying the response.
</t> </t>
<t>In contrast, Delayed ACKs allow for a reduced number of ACKs in bul
<t>In contrast, Delayed ACKs allow to reduce the number of ACKs in bul k transfer types of traffic, e.g., for firmware/software updates or for transfer
k transfer type of traffic, e.g. for firmware/software updates or for transferri ring larger data units containing a batch of sensor readings.
ng larger data units containing a batch of sensor readings.
</t> </t>
<t>Note that, in many scenarios, the peer that a constrained device co
<t>Note that, in many scenarios, the peer that a constrained device com mmunicates with will be a general purpose system that communicates with both con
municates with will be a general purpose system that communicates with both cons strained and unconstrained devices. Since Delayed ACKs are often configured thro
trained and unconstrained devices. Since delayed ACKs are often configured throu ugh system-wide parameters, the behavior of Delayed ACKs at the peer will be the
gh system-wide parameters, delayed ACKs behavior at the peer will be the same re same regardless of the nature of the endpoints it talks to. Such a peer will ty
gardless of the nature of the endpoints it talks to. Such a peer will typically pically have Delayed ACKs enabled.
have delayed ACKs enabled.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Initial Window</name>
<section title="Initial Window"> <t><xref target="RFC5681" format="default"/> specifies a TCP Initial W
indow (IW) of roughly 4 kB. Subsequently, RFC 6928 <xref target="RFC6928" format
<t>RFC 5681 specifies a TCP Initial Window (IW) of roughly 4 kB <xref ="default"/> defines an experimental new value for the IW,
target="RFC5681"/>. Subsequently, RFC 6928 defined an experimental new value for which in practice will result in an IW of 10 MSS. Nowadays, the lat
the IW, ter is used in many TCP implementations.
which in practice will result in an IW of 10 MSS <xref target="RFC6
928"/>. The latter is nowadays used in many TCP implementations.
</t> </t>
<t>Note that a 10-MSS IW was recommended for resource-rich environment
<t>Note that a 10-MSS IW was recommended for resource-rich environment s (e.g., broadband environments), which are significantly different from CNNs.
s (e.g. broadband environments), which are significantly different from CNNs. In CNNs, many application-layer data units are relatively small (e.
In CNNs, many application layer data units are relatively small (e. g., below 1 MSS). However, larger objects (e.g., large files containing
g. below one MSS). However, larger objects (e.g. large files containing
sensor readings, firmware updates, etc.) may also need to be transf erred in CNNs. If such a large object is transferred in CNNs, with an IW sensor readings, firmware updates, etc.) may also need to be transf erred in CNNs. If such a large object is transferred in CNNs, with an IW
setting of 10 MSS, there is significant buffer overflow risk, since many CNN devices support network or radio buffers of a size smaller than 10 MSS . setting of 10 MSS, there is significant buffer overflow risk, since many CNN devices support network or radio buffers of a size smaller than 10 MSS .
In order to avoid such problem, in CNNs the IW needs to be carefull y set, based In order to avoid such a problem, the IW needs to be carefully set in CNNs, based
on device and network resource constraints. In many cases, a safe I W setting will be smaller than 10 MSS. on device and network resource constraints. In many cases, a safe I W setting will be smaller than 10 MSS.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="TCP usage recommendations in CNNs"> <name>TCP Usage Recommendations in CNNs</name>
<t>This section discusses how TCP can be used by applications that are dev
<t>This section discusses how TCP can be used by applications that are eloped for CNN scenarios. These remarks are by and large independent of how TCP
developed for CNN scenarios. These remarks are by and large independent of how T is exactly implemented.
CP is exactly implemented.
</t> </t>
<section numbered="true" toc="default">
<section title="TCP connection initiation"> <name>TCP Connection Initiation</name>
<t>In the scenario of a constrained device to an unconstrained device il
<t>In the constrained device to unconstrained device scenario illustrate lustrated
d
above, a TCP connection is typically initiated by the constrained above, a TCP connection is typically initiated by the constrained
device, in order for this device to support possible sleep periods to device, in order for the device to support possible sleep periods to
save energy. save energy.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Number of concurrent connections"> <name>Number of Concurrent Connections</name>
<t>TCP endpoints with a small amount of memory may only support a small <t>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 TCB. Depending on of variables in the TCB. Depending on
the internal TCP implementation, each connection may result in the internal TCP implementation, each connection may result in
further memory overhead, and connections may compete for scarce resources (e. g. further memory overhead for send and receive buffers, etc). further memory overhead, and connections may compete for scarce resources (e. g., further memory overhead for send and receive buffers, etc.).
</t> </t>
<t>A careful application design may try to keep the number of concurrent
<t>A careful application design may try to keep the number of concurrent connections as small as possible. A client can, for instance, limit the number
connections as small as possible. A client can for instance limit the number of of simultaneous open connections that it maintains to a given server. Multiple c
simultaneous open connections that it maintains to a given server. Multiple con onnections could, for instance, be used to avoid the "head-of-line blocking" pro
nections could for instance be used to avoid the "head-of-line blocking" problem blem in an application transfer. However, in addition to consuming resources, us
in an application transfer. However, in addition to consuming resources, using ing multiple connections can also cause undesirable side effects in congested ne
multiple connections can also cause undesirable side effects in congested networ tworks.
ks. For example, the HTTP/1.1 specification encourages clients to be cons
For example, the HTTP/1.1 specification encourages clients to be cons ervative when opening multiple connections <xref target="RFC7230" format="defaul
ervative when opening multiple connections <xref target="RFC7230"/>. t"/>.
Furthermore, each new connection will start with a 3-way handshake, t Furthermore, each new connection will start with a three-way handshak
herefore increasing message overhead. e, therefore increasing message overhead.
</t> </t>
<t>Being conservative when opening multiple TCP connections is of partic ular importance in Constrained-Node Networks.</t> <t>Being conservative when opening multiple TCP connections is of partic ular importance in Constrained-Node Networks.</t>
</section> </section>
<section anchor="short_connections" numbered="true" toc="default">
<section title="TCP connection lifetime" anchor="short_connections"> <name>TCP Connection Lifetime</name>
<t>In order to minimize message overhead, it makes sense to keep a TCP c onnection <t>In order to minimize message overhead, it makes sense to keep a TCP c onnection
open as long as the two TCP endpoints have more data to send. If applica tions open as long as the two TCP endpoints have more data to send. If applica tions
exchange data rather infrequently, i.e., if TCP connections would stay i dle for a long time, exchange data rather infrequently, i.e., if TCP connections would stay i dle for a long time,
the idle time can result in problems. For instance, certain middleboxes the idle time can result in problems. For instance, certain middleboxes
such as firewalls or NAT devices are known to delete state records after an inactivity interval. such as firewalls or NAT devices are known to delete state records after an inactivity interval.
RFC 5382 specifies a minimum value for such interval of 124 minutes. Mea
surement studies have reported that TCP NAT binding timeouts are highly RFC 5382 <xref target="RFC5382" format="default"/> specifies a minimum
value for such an interval of 124 minutes. Measurement studies have reported tha
t TCP NAT binding timeouts are highly
variable across devices, variable across devices,
with a median around 60 minutes, the shortest timeout being around 2 min with the median being around 60 minutes, the shortest timeout being arou
utes, and more than 50% of the devices with a timeout shorter than the nd 2 minutes, and more than 50% of the devices with a timeout shorter than the
aforementioned minimum timeout of 124 minutes <xref target="HomeGateway aforementioned minimum timeout of 124 minutes <xref target="HomeGateway"
"/>. The timeout duration used by a format="default"/>. The timeout duration used by a
middlebox implementation may not be known to the TCP endpoints.</t> middlebox implementation may not be known to the TCP endpoints.</t>
<t>In CNNs, such middleboxes may e.g. be present at the boundary between the CNN and other networks. <t>In CNNs, such middleboxes may, e.g., be present at the boundary betwe en the CNN and other networks.
If the middlebox can be optimized for CNN use cases, it makes sense to i ncrease the initial value If the middlebox can be optimized for CNN use cases, it makes sense to i ncrease the initial value
for filter state inactivity timers to avoid problems with idle connectio ns. Apart from that, for filter state inactivity timers to avoid problems with idle connectio ns. Apart from that,
this problem can be dealt with by different connection handling strategi es, each having pros and cons.</t> this problem can be dealt with by different connection-handling strategi es, each having pros and cons.</t>
<t>One approach for infrequent data transfer is to use short-lived TCP c onnections. <t>One approach for infrequent data transfer is to use short-lived TCP c onnections.
Instead of trying to maintain a TCP connection for a long time, possibly short-lived Instead of trying to maintain a TCP connection for a long time, it is po ssible that short-lived
connections can be opened between two endpoints, which are closed if no more data needs connections can be opened between two endpoints, which are closed if no more data needs
to be exchanged. For use cases that can cope with the additional message s and the latency to be exchanged. For use cases that can cope with the additional message s and the latency
resulting from starting new connections, it is recommended to use a sequ resulting from starting new connections, it is recommended to use a sequ
ence of short-lived connections, ence of short-lived connections instead of maintaining a single long-lived conne
instead of maintaining a single long-lived connection.</t> ction.</t>
<t> <t>
The message and latency overhead that stems from using a sequence of sho The message and latency overhead that stems from using a sequence of sho
rt-lived connections could be reduced by TCP Fast Open (TFO) <xref target="RFC74 rt-lived connections could be reduced by TCP Fast Open (TFO) <xref target="RFC74
13"/>, 13" format="default"/>,
which is an experimental TCP extension, at the expense of increased impl which is an experimental TCP extension, at the expense of increased impl
ementation complexity and increased TCP Control Block (TCB) size. TFO allows da ementation complexity and increased TCB size. TFO allows data to be
ta to be carried in SYN (and SYN-ACK) segments and to be consumed immediately
carried in SYN (and SYN-ACK) segments, and to be consumed immediately
by the receiving endpoint. This reduces the message and latency overhea d compared to by the receiving endpoint. This reduces the message and latency overhea d compared to
the traditional three-way handshake to establish a TCP connection. the traditional three-way handshake to establish a TCP connection.
For security reasons, the connection initiator has to request a TFO For security reasons, the connection initiator has to request a TFO
cookie from the other endpoint. The cookie, with a size of 4 or 16 cookie from the other endpoint. The cookie, with a size of 4 or 16
bytes, is then included in SYN packets of subsequent connections. bytes, is then included in SYN packets of subsequent connections.
The cookie needs to be refreshed (and obtained by the client) after a The cookie needs to be refreshed (and obtained by the client) after a
certain amount of time. While a given cookie is used for multiple conne ctions between the same two endpoints, certain amount of time. While a given cookie is used for multiple conne ctions between the same two endpoints,
the latter may become vulnerable to privacy threats. In addition, a vali d cookie may be stolen from a compromised host the latter may become vulnerable to privacy threats. In addition, a vali d cookie may be stolen from a compromised host
and may be used to perform SYN flood attacks, as well as amplified refle ction attacks to victim hosts (see Section 5 of RFC 7413). and may be used to perform SYN flood attacks, as well as amplified refle ction attacks to victim hosts (see <xref target="RFC7413" sectionFormat="of" sec tion="5"/>).
Nevertheless, TFO is more efficient than Nevertheless, TFO is more efficient than
frequently opening new TCP connections with the traditional three-way frequently opening new TCP connections with the traditional three-way
handshake, as long as the cookie can be reused in subsequent handshake, as long as the cookie can be reused in subsequent
connections. However, as stated in RFC 7413, TFO deviates from the stand ard TCP semantics, since the data in the SYN could be replayed connections. However, as stated in <xref target="RFC7413" format="defaul t"/>, TFO deviates from the standard TCP semantics, since the data in the SYN co uld be replayed
to an application in some rare circumstances. Applications should not us e TFO unless they can tolerate this issue, e.g., by using to an application in some rare circumstances. Applications should not us e TFO unless they can tolerate this issue, e.g., by using
Transport Layer Security (TLS) [RFC7413]. A comprehensive discussion on TFO can be found at RFC 7413. TLS <xref target="RFC7413" format="default"/>. A comprehensive discussio n on TFO can be found in RFC 7413 <xref target="RFC7413" format="default"/>.
</t> </t>
<t>Another approach is to use long-lived TCP connections with <t>Another approach is to use long-lived TCP connections with
application-layer heartbeat messages. Various application protocols application-layer heartbeat messages. Various application protocols
support such heartbeat messages (e.g. CoAP over TCP [RFC8323]). support such heartbeat messages (e.g., CoAP over TCP <xref target="RFC 8323" format="default"/>).
Periodic application-layer heartbeats can prevent early filter state r ecord deletion in middleboxes. Periodic application-layer heartbeats can prevent early filter state r ecord deletion in middleboxes.
If the TCP binding timeout for a middlebox to be traversed by a given connection is known, middlebox filter If the TCP binding timeout for a middlebox to be traversed by a given connection is known, middlebox filter
state deletion will be avoided if the heartbeat period is lower than t he middlebox TCP binding timeout. state deletion will be avoided if the heartbeat period is lower than t he middlebox TCP binding timeout.
Otherwise, the implementer needs to take into account that middlebox T CP binding timeouts fall in a wide range Otherwise, the implementer needs to take into account that middlebox T CP binding timeouts fall in a wide range
of possible values <xref target="HomeGateway"/>, and it may be hard to find a proper heartbeat period for application-layer heartbeat messages. of possible values <xref target="HomeGateway" format="default"/>, and it may be hard to find a proper heartbeat period for application-layer heartbeat messages.
</t> </t>
<t> <t>
One specific advantage of Heartbeat messages is that they also allow a liveness checks at the One specific advantage of heartbeat messages is that they also allow l iveness checks at the
application level. In general, it makes sense to realize application level. In general, it makes sense to realize
aliveness checks at the highest protocol layer possible that is liveness checks at the highest protocol layer possible that is
meaningful to the application, in order to maximize the depth of the meaningful to the application, in order to maximize the depth of the
aliveness check. In addition, timely detection of a dead peer may liveness check. In addition, timely detection of a dead peer may
allow savings in terms of TCB memory use. However, the transmission of allow savings in terms of TCB memory use. However, the transmission of
heartbeat messages consumes resources. This aspect needs to be assesse d carefully, considering the characteristics of each specific CNN. heartbeat messages consumes resources. This aspect needs to be assesse d carefully, considering the characteristics of each specific CNN.
</t> </t>
<t>A TCP implementation may also be able to send "keep-alive" segments t o test a TCP connection. <t>A TCP implementation may also be able to send "keep-alive" segments t o test a TCP connection.
According to <xref target="RFC1122"/>, "keep-alives" are an optional TCP mechanism that is According to <xref target="RFC1122" format="default"/>, keep-alives are an optional TCP mechanism that is
turned off by default, i.e., an application must explicitly enable it fo r a TCP connection. turned off by default, i.e., an application must explicitly enable it fo r a TCP connection.
The interval between "keep-alive" messages must be configurable and it m ust default to no less The interval between keep-alive messages must be configurable, and it mu st default to no less
than two hours. With this large timeout, TCP keep-alive messages might n ot always be useful to avoid deletion of than two hours. With this large timeout, TCP keep-alive messages might n ot always be useful to avoid deletion of
filter state records in some middleboxes. However, sending TCP keep-ali ve probes more frequently risks draining power on energy- filter state records in some middleboxes. However, sending TCP keep-ali ve probes more frequently risks draining power on energy-
constrained devices. constrained devices.
</t> </t>
<!-- TODO: Check before publication if there is an official recommendati
on for "keep-alives" following
from the discussion https://www.ietf.org/mail-archive/web/tsv-area/curre
nt/msg01511.html -->
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Best current practices for securing TCP and TCP-based communication als
<t>Best current practice for securing TCP and TCP-based communication also o applies to CNN. As an example, use of TLS <xref target="RFC8446" format="defau
applies to CNN. As example, use of Transport Layer Security (TLS) <xref target= lt"/> is strongly recommended if it is applicable.
"RFC8446"/> is strongly recommended if it is applicable.
However, note that TLS protects only the contents of the data segments. However, note that TLS protects only the contents of the data segments.
</t> </t>
<t>There are TCP options that can actually protect the transport layer. O
<t>There are TCP options which can actually protect the transport layer. ne example is the TCP Authentication Option (TCP-AO) <xref target="RFC5925" form
One example is the TCP Authentication Option (TCP-AO) <xref target="RFC5925"/>. at="default"/>.
However, this option adds overhead and complexity. TCP-AO typically has a size of 16-20 bytes. However, this option adds overhead and complexity. TCP-AO typically has a size of 16-20 bytes.
An implementer needs to asses the trade-off between security and perfor mance when using TCP-AO, considering the characteristics (in terms of energy, ba ndwidth and computational power) An implementer needs to asses the trade-off between security and perfor mance when using TCP-AO, considering the characteristics (in terms of energy, ba ndwidth, and computational power)
of the environment where TCP will be used. of the environment where TCP will be used.
</t> </t>
<t>For the mechanisms discussed in this document, the corresponding consid
<t>For the mechanisms discussed in this document, the corresponding consid erations apply. For instance, if TFO is used, the security considerations of RF
erations apply. For instance, if TFO is used, the security considerations of <x C 7413 <xref target="RFC7413" format="default"/> apply.</t>
ref target="RFC7413"/> apply.</t> <t>Constrained devices are expected to support smaller TCP window sizes th
an less-limited devices. In such conditions, segment retransmission
<t>Constrained devices are expected to support smaller TCP window sizes th
an less limited devices. In such conditions, segment retransmission
triggered by RTO expiration is expected to be relatively frequent, due to lack of (enough) duplicate ACKs, especially when a constrained device triggered by RTO expiration is expected to be relatively frequent, due to lack of (enough) duplicate ACKs, especially when a constrained device
uses a single-MSS implementation. For this reason, constrained devices running TCP may appear as particularly appealing victims of the so-called uses a single-MSS implementation. For this reason, constrained devices running TCP may appear as particularly appealing victims of the so-called
"shrew" Denial of Service (DoS) attack <xref target="shrew"/>, whereby one or more sources generate a packet spike targeted to coincide with consecutiv e "shrew" Denial-of-Service (DoS) attack <xref target="SHREW" format="def ault"/>, whereby one or more sources generate a packet spike targeted to coincid e with consecutive
RTO-expiration-triggered retry attempts of a victim node. Note that the attack may be performed by Internet-connected devices, RTO-expiration-triggered retry attempts of a victim node. Note that the attack may be performed by Internet-connected devices,
including constrained devices in the same CNN as the victim, as well as remote ones. Mitigation techniques include RTO randomization and attack blockin g by routers able to detect including constrained devices in the same CNN as the victim, as well as remote ones. Mitigation techniques include RTO randomization and attack blockin g by routers able to detect
shrew attacks based on their traffic pattern. </t> shrew attacks based on their traffic pattern. </t>
</section> </section>
<!-- This PI places the pagebreak correctly (before the section title) in th <section anchor="IANA" numbered="true" toc="default">
e text output. --> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<!-- Possibly a 'Contributors' section ... --> </section>
<section anchor="ACKs" title="Acknowledgments"> </middle>
<t>Carles Gomez has been funded in part by the Spanish Government (Ministe <back>
rio de Educacion, Cultura y Deporte) through the Jose Castillejo grants CAS15/00
336
and and CAS18/00170,
and by European Regional Development Fund (ERDF) and the Spanish Govern
ment through projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, UE, and
by Generalitat de Catalunya Grant 2017 SGR 376.
Part of his contribution to this work has been carried out during his s
tays as a visiting scholar at the Computer Laboratory of the University of Cambr
idge.</t>
<t> The authors appreciate the feedback received for this document. The <displayreference target="I-D.ietf-core-fasor" to="CORE-FASOR"/>
following folks provided comments that helped improve the document: <displayreference target="I-D.delcarpio-6lo-wlanah" to="6LO-WLANAH"/>
Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, <displayreference target="I-D.ietf-tcpm-generalized-ecn" to="TCPM-ECN"/>
Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe
Touch, Fred Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hanne
s Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen,
Emmanuel Baccelli, Stuart Cheshire, Gorry Fairhurst, Ingemar Johansson, Ted L
emon, and Michael Tuexen.
Simon Brummer provided details, and kindly performed RAM and ROM usage measur
ements, on the RIOT TCP implementation. Xavi Vilajosana provided details on the
OpenWSN TCP implementation.
Rahul Jadhav kindly performed code size measurements on the Contiki-NG and lw
IP 2.1.2 TCP implementations. He also provided details on the uIP TCP implementa
tion.
</t>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2018.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3042.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6298.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6691.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6928.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7228.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7413.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7567.xml"/>
</references>
<references>
<name>Informative References</name>
<section title="Annex. TCP implementations for constrained devices"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8201.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2757.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2884.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3481.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3819.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4944.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5382.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6077.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6120.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6606.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7414.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7428.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7540.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7668.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8087.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8105.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8163.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8352.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8376.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8900.xml"/>
<t>This section overviews the main features of TCP implementations for c <!-- [CS] Note: [draft-delcarpio-6lo-wlanah] The long version of this reference
onstrained devices. The survey is limited to open source stacks with small footp was added because it was causing this xml2rfc Error: Failure validating
rint. It is not meant to be all-encompassing. For more powerful embedded systems reference xml from
(e.g., with 32-bit processors), there are further stacks that comprehensively i https://datatracker.ietf.org/doc/bibxml3/draft-delcarpio-6lo-wlanah.xml
mplement TCP. On the other hand, please be aware that this Annex is based on inf Error: XInclude processing failed: could not load
ormation available as of the writing.</t> https://datatracker.ietf.org/doc/bibxml3/draft-delcarpio-6lo-wlanah.xml,
and no fallback was found, line 901 Unable to complete processing
draft-ietf-lwig-tcp-constrained-node-networks-13.xml -->
<section title="uIP"> <!-- draft-delcarpio-6lo-wlanah-01; Expired -->
<t>uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers, w <reference anchor='I-D.delcarpio-6lo-wlanah'>
hich pioneered TCP/IP implementations for constrained devices. <front>
uIP has been deployed with Contiki and the Arduino Ethernet shield. A <title>IPv6 over 802.11ah</title>
code size of ~5 kB (which comprises checksumming, IPv4, ICMP and TCP) <author initials='L' surname='Del Carpio Vega' fullname='Luis Felipe Del Carpio
has been reported for uIP <xref target="Dunk"/>. Later versions of uI Vega'>
P implement IPv6 as well.</t> <organization />
</author>
<author initials='M' surname='Robles' fullname='Maria Ines Robles'>
<organization />
</author>
<author initials='R' surname='Morabito' fullname='Roberto Morabito'>
<organization />
</author>
<date month='October' day='19' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-delcarpio-6lo-wlanah-01' />
</reference>
<t>uIP uses the same global buffer for both incoming and outgoing traffi <!-- [I-D.ietf-core-fasor] IESG state I-D Exists -->
c, which has a <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
size of a single packet. In case of a retransmission, an application .ietf-core-fasor.xml"/>
must be able to reproduce the same user data that had been
transmitted. Multiple connections are supported, but need to share th
e global buffer.
</t>
<t>The MSS is announced via the MSS option on connection establishment a
nd the receive window size (of one MSS) is not modified during a connection. Sto
p-and-wait operation is used for sending data. Among other optimizations, this a
llows to avoid sliding window operations, which use 32-bit arithmetic extensivel
y and are expensive on 8-bit CPUs.</t>
<t>Contiki uses the "split hack" technique (see <xref target="DelAck"/>)
to avoid Delayed ACKs for senders using a single segment.</t>
<t>The code size of the TCP implementation in Contiki-NG has been measur
ed to be of 3.2 kB on CC2538DK, cross-compiling on Linux.</t>
</section>
<section title="lwIP"> <!-- [I-D.ietf-tcpm-rto-consider] Published as RFC 8961 -->
<t>lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
lwIP has a total code size of ~14 kB to ~22 kB FC.8961.xml"/>
(which comprises memory management, checksumming, network interfaces,
IPv4, ICMP and TCP), and a TCP code size of ~9 kB to ~14 kB <xref target="Dunk"/
>.
Both IPv4 and IPv6 are supported in lwIP since v2.0.0.</t>
<t>In contrast with uIP, lwIP decouples applications from the network st <!-- [I-D.ietf-6lo-fragment-recovery] Published as RFC 8931 -->
ack. lwIP supports a TCP transmission window greater than a single segment, as w <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ell as buffering of incoming and outcoming data. Other implemented mechanisms co FC.8931.xml"/>
mprise slow start, congestion avoidance, fast retransmit and fast recovery.
SACK and Window Scale support has been recently added to lwIP.</t>
</section>
<section title="RIOT"> <!-- [I-D.ietf-tcpm-generalized-ecn] IESG state I-D Exists -->
<t> The RIOT TCP implementation (called GNRC TCP) has been designed for <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
Class 1 devices [RFC 7228]. The main target platforms are 8- and 16-bit microcon .ietf-tcpm-generalized-ecn.xml"/>
trollers, with 32-bit platforms also supported. GNRC TCP
offers a similar function set as uIP, but it provides and maintains
an independent receive buffer for each connection. In contrast to uIP, retransmi
ssion is also handled by GNRC TCP. For simplicity, GNRC TCP uses a single-MSS im
plementation. The application programmer does not need to know anything about th
e TCP internals, therefore GNRC TCP can be seen as a user-friendly uIP TCP imple
mentation.
</t>
<t> The MSS is set on connections establishment and cannot be changed du <reference anchor="Commag">
ring connection lifetime. GNRC TCP allows multiple connections in parallel, but <front>
each TCB must <title>CoAP Congestion Control for the Internet of Things</title>
be allocated somewhere in the system. By default there is only enoug <author initials='A.' surname='Betzler' fullname='August Betzler'>
h memory allocated for a single TCP connection, but it can be increased at compi <organization />
le time if the user needs multiple parallel connections. </author>
</t> <author initials='C.' surname='Gomez' fullname='Carles Gomez'>
<organization /></author>
<author initials='I.' surname='Demirkol' fullname='Ilker Demirkol'>
<organization />
</author>
<author initials='J.' surname='Paradells' fullname='Josep Paradelis'>
<organization /></author>
<date year="2016" month="July"/>
</front>
<seriesInfo name="DOI" value="10.1109/MCOM.2016.7509394"/>
<refcontent>IEEE Communications Magazine, Vol. 54, Issue 7, pp. 154-160</refco
ntent>
</reference>
<t> The RIOT TCP implementation offers an optional POSIX socket wrapper <reference anchor="IntComp">
that enables POSIX compliance, if needed. <front>
</t> <title>TCP in the Internet of Things: from Ostracism to Prominence</
title>
<author initials='C.' surname='Gomez' fullname='Carles Gomez'>
<organization /></author>
<author initials='A.' surname='Arcia-Moret' fullname='Andres Arcia-
Moret'>
<organization /></author>
<author initials='J.' surname='Crowcroft' fullname='Jon Crowcroft'
>
<organization /></author>
<date year="2018" month="January"/>
</front>
<seriesInfo name="DOI" value="10.1109/MIC.2018.112102200"/>
<refcontent>IEEE Internet Computing, Vol. 22, Issue 1, pp. 29-41</refcon
tent>
</reference>
<t> Further details on RIOT and GNRC can be found in the literature <xref <reference anchor="MQTT">
target="RIOT"/>, <xref target="GNRC"/>. <front>
</t> <title>Information technology -- Message Queuing Telemetry Transport
(MQTT) v3.1.1</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2016" month="June"/>
</front>
<refcontent>ISO/IEC 20922:2016</refcontent>
</reference>
</section> <reference anchor="HomeGateway">
<front>
<title>An Experimental Study of Home Gateway Characteristics</title>
<author initials='S.' surname='Haetoenen' fullname='Seppo Haetoenen
'>
<organization /></author>
<author initials='A.' surname='Nyrhinen' fullname='Aki Nyrhinen'>
<organization /></author>
<author initials='L.' surname='Eggert' fullname='Lars Eggert'>
<organization /></author>
<author initials='S.' surname='Strowes' fullname='S. Strowes'>
<organization /></author>
<author initials='P.' surname='Sarolahti' fullname='Pasi Sarolah
ti'>
<organization /></author>
<author initials='M.' surname='Kojo' fullname='Markku Kojo'>
<organization /></author>
<date year="2010" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1145/1879141.1879174"/>
<refcontent>Proceedings of the 10th ACM SIGCOMM conference on Internet
measurement, pp. 260-266</refcontent>
</reference>
<section title="TinyOS"> <reference anchor="SHREW">
<t>TinyOS was important as a platform for early constrained devices. <front>
TinyOS has an experimental TCP stack that uses a simple nonblocking library-base <title>Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs
d implementation of TCP, which provides a subset of the socket interface primiti . the Mice and Elephants)</title>
ves. The application is responsible for buffering. The TCP library does not do a <author initials='A.' surname='Nyrhinen' fullname='Aleksandar Kuzman
ny receive-side buffering. Instead, it will immediately dispatch new, in-order d ovic'>
ata to the application and otherwise drop the segment. A send buffer is provided <organization /></author>
by the application. Multiple TCP connections are possible. Recently there has b <author initials='E.' surname='Knightly' fullname='Edward Knightly
een little further work on the stack.</t> '>
</section> <organization /></author>
<date year="2003" month="August"/>
</front>
<seriesInfo name="DOI" value="10.1145/863955.863966"/>
<refcontent>SIGCOMM'03</refcontent>
</reference>
<section title="FreeRTOS"> <reference anchor="ETEN">
<t>FreeRTOS is a real-time operating system kernel for embedded devic <front>
es that <title>Explicit transport error notification (ETEN) for error-prone
is supported by 16- and 32-bit microprocessors. Its TCP implementa wireless and satellite networks</title>
tion is based on multiple-segment window size, although a 'Tiny-TCP' option, whi <author initials='R.' surname='Krishnan' fullname='Rajesh Krishnan'
ch is a single-MSS variant, can be enabled. Delayed ACKs are supported, with a 2 >
0-ms Delayed ACK timer as a technique intended 'to gain performance'. <organization /></author>
</t> <author initials='J.' surname='Sterbenz' fullname='James Sterbenz'
</section> >
<organization /></author>
<author initials='W.' surname='Eddy' fullname='Wesley Eddy'>
<organization /></author>
<author initials='C.' surname='Partridge' fullname='C. Partridge'>
<organization /></author>
<date year="2004" month="June"/>
</front>
<seriesInfo name="DOI" value="10.1016/j.comnet.2004.06.012"/>
<refcontent>Computer Networks</refcontent>
</reference>
<section title="uC/OS"> <reference anchor="Dunk">
<t>uC/OS is a real-time operating system kernel for embedded devices, <front>
which is maintained by Micrium. uC/OS is intended for 8-, 16- and 32-bit microp <title>Full TCP/IP for 8-Bit Architectures</title>
rocessors. The uC/OS TCP implementation supports a multiple-segment window size. <author initials='A.' surname='Dunkels' fullname='Adam Dunkels'>
</t> <organization /></author>
</section> <date year="2003" month="May"/>
</front>
<seriesInfo name="DOI" value="10.1145/1066116.106611"/>
<refcontent>MobiSys '03, pp. 85-98</refcontent>
</reference>
<section title="Summary"> <reference anchor="RIOT">
<t> <front>
<figure title="Summary of TCP features for different lightweight TCP imp <title>RIOT: An Open Source Operating System for Low-End Embedded De
lementations. None of the implementations considered in this Annex support ECN o vices in the IoT</title>
r TFO." <author initials='E.' surname='Baccelli' fullname='Emmanuel Baccelli'>
anchor="fig_summary"> <organization /></author>
<artwork><![CDATA[ <author initials='C.' surname='Gündoğa' fullname='Cenk Gündoğa'>
+---+---------+--------+----+------+--------+-----+ <organization /></author>
|uIP|lwIP orig|lwIP 2.1|RIOT|TinyOS|FreeRTOS|uC/OS| <author initials='O.' surname='Hahm' fullname='Oliver Hahm'>
+------+-------------+---+---------+--------+----+------+--------+-----+ <organization /></author>
|Memory|Code size(kB)| <5|~9 to ~14| 38 | <7 | N/A | <9.2 | N/A | <author initials='P.' surname='Kietzmann' fullname='Kietzmann'>
| | |(a)| (T1) | (T4) |(T3)| | (T2) | | <organization /></author>
+------+-------------+---+---------+--------+----+------+--------+-----+ <author initials='M.' surname='Lenders' fullname='Martine Lenders'>
| | Single-Segm.|Yes| No | No | Yes| No | No | No | <organization /></author>
| +-------------+---+---------+--------+----+------+--------+-----+ <author initials='H.' surname='Petersen' fullname='Hauke Petersen'>
| | Slow start | No| Yes | Yes | No | Yes | No | Yes | <organization /></author>
| T +-------------+---+---------+--------+----+------+--------+-----+ <author initials='K.' surname='Schleiser' fullname='Schleiser'>
| C |Fast rec/retx| No| Yes | Yes | No | Yes | No | Yes | <organization /></author>
| P +-------------+---+---------+--------+----+------+--------+-----+ <author initials='T.' surname='Schmidt' fullname='Thomas Schmidt'>
| | Keep-alive | No| No | Yes | No | No | Yes | Yes | <organization /></author>
| +-------------+---+---------+--------+----+------+--------+-----+ <author initials='M.' surname='Wählisch' fullname='Matthias Wählisc
| f | Win. Scale | No| No | Yes | No | No | Yes | No | h'>
| e +-------------+---+---------+--------+----+------+--------+-----+ <organization /></author>
| a | TCP timest.| No| No | Yes | No | No | Yes | No | <date year="2018" month="March"/>
| t +-------------+---+---------+--------+----+------+--------+-----+ </front>
| u | SACK | No| No | Yes | No | No | Yes | No | <seriesInfo name="DOI" value="10.1109/JIOT.2018.2815038"/>
| r +-------------+---+---------+--------+----+------+--------+-----+ <refcontent>IEEE Internet of Things Journal, Vol. 5, Issue 6</refconte
| e | Del. ACKs | No| Yes | Yes | No | No | Yes | Yes | nt>
| s +-------------+---+---------+--------+----+------+--------+-----+ </reference>
| | Socket | No| No |Optional|(I) |Subset| Yes | Yes |
| +-------------+---+---------+--------+----+------+--------+-----+
| |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes |
+------+-------------+---+---------+--------+----+------+--------+-----+
| TLS supported | No| No | Yes | Yes| Yes | Yes | Yes |
+--------------------+---+---------+--------+----+------+--------+-----+
(T1) = TCP-only, on x86 and AVR platforms <reference anchor="GNRC">
(T2) = TCP-only, on ARM Cortex-M platform <front>
(T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same <title>Connecting the World of Embedded Mobiles: The RIOT Approach t
platform o Ubiquitous Networking for the IoT</title>
is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional <author initials='M.' surname='Lenders' fullname='Martine Lenders'>
connection) <organization /></author>
(T4) = TCP-only, on CC2538DK, cross-compiling on Linux <author initials='P.' surname='Kietzmann' fullname='Kietzmann'>
(a) = includes IP, ICMP and TCP on x86 and AVR platforms. The Contiki-NG <organization /></author>
TCP implementation has a code size of 3.2 kB on CC2538DK, cross-compiling on Lin <author initials='O.' surname='Hahm' fullname='Oliver Hahm'>
ux <organization /></author>
(I) = optional POSIX socket wrapper which enables POSIX compliance if nee <author initials='H.' surname='Petersen' fullname='Hauke Petersen'>
ded <organization /></author>
Mult. = Multiple <author initials='C.' surname='Gündoğa' fullname='Cenk Gündoğa'>
N/A = Not Available <organization /></author>
<author initials='E.' surname='Baccelli' fullname='Emmanuel Baccelli'
>
<organization /></author>
<author initials='K.' surname='Schleiser' fullname='Schleiser'>
<organization /></author>
<author initials='T.' surname='Schmidt' fullname='Thomas Schmidt'>
<organization /></author>
<author initials='M.' surname='Wählisch' fullname='Matthias Wählisch'
>
<organization /></author>
<date year="2018" month="January"/>
</front>
<refcontent>arXiv:1801.02833v1 [cs.NI]</refcontent>
</reference>
</references>
</references>
]]></artwork></figure> <section numbered="true" toc="default">
<name>TCP Implementations for Constrained Devices</name>
<t>This section overviews the main features of TCP implementations for con
strained devices. The survey is limited to open-source stacks with a small footp
rint. It is not meant to be all-encompassing. For more powerful embedded systems
(e.g., with 32-bit processors), there are further stacks that comprehensively i
mplement TCP. On the other hand, please be aware that this Annex is based on inf
ormation available as of the writing.</t>
<section numbered="true" toc="default">
<name>uIP</name>
<t>uIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers, w
hich pioneered TCP/IP implementations for constrained devices.
uIP has been deployed with Contiki and the Arduino Ethernet shield. A
code size of ~5 kB (which comprises checksumming, IPv4, ICMP, and TCP)
has been reported for uIP <xref target="Dunk" format="default"/>. Lat
er versions of uIP implement IPv6 as well.</t>
<t>uIP uses the same global buffer for both incoming and outgoing traffi
c, which has a
size of a single packet. In case of a retransmission, an application
must be able to reproduce the same user data that had been
transmitted. Multiple connections are supported but need to share the
global buffer.
</t> </t>
<t>The MSS is announced via the MSS option on connection establishment,
and the receive window size (of 1 MSS) is not modified during a connection. Stop
-and-wait operation is used for sending data. Among other optimizations, this al
lows for the avoidance of sliding window operations, which use 32-bit arithmetic
extensively and are expensive on 8-bit CPUs.</t>
<t>Contiki uses the "split hack" technique (see <xref target="DelAck" fo
rmat="default"/>) to avoid Delayed ACKs for senders using a single segment.</t>
</section> <t>The code size of the TCP implementation in Contiki-NG has been measur
ed to be 3.2 kB on CC2538DK, cross-compiling on Linux.</t>
</section>
<section title="Annex. Changes compared to previous versions">
<t>RFC Editor: To be removed prior to publication</t>
<section title="Changes between -00 and -01">
<t><list style="symbols">
<t>Changed title and abstract</t>
<t>Clarification that communication with standard-compliant TCP endpoi
nts is required, based on feedback from Joe Touch</t>
<t>Additional discussion on communication patters</t>
<t>Numerous changes to address a comprehensive review from Hannes Tsch
ofenig</t>
<t>Reworded security considerations</t>
<t>Additional references and better distinction between normative and
informative entries</t>
<t>Feedback from Rahul Jadhav on the uIP TCP implementation</t>
<t>Basic data for the TinyOS TCP implementation added, based on source
code analysis</t>
</list></t>
</section>
<section title="Changes between -01 and -02">
<t><list style="symbols">
<t>Added text to the Introduction section, and a reference, on traditi
onal bad perception of TCP for IoT </t>
<t>Added sections on FreeRTOS and uC/OS</t>
<t>Updated TinyOS section</t>
<t>Updated summary table</t>
<t>Reorganized Section 4 (single-MSS vs multiple-MSS window size), som
e content now also in new Section 5</t>
</list></t>
</section>
<section title="Changes between -02 and -03">
<t><list style="symbols">
<t>Rewording to better explain the benefit of ECN</t>
<t>Additional context information on the surveyed implementations</t>
<t>Added details, but removed "Data size" raw, in the summary table </
t>
<t>Added discussion on shrew attacks</t>
</list></t>
</section>
<section title="Changes between -03 and -04">
<t><list style="symbols">
<t>Addressing the remaining TODOs</t>
<t>Alignment of the wording on TCP "keep-alives" with related discussi
ons in the IETF transport area</t>
<t>Added further discussion on delayed ACKs </t>
<t>Removed OpenWSN section from the Annex </t>
</list></t>
</section>
<section title="Changes between -04 and -05">
<t><list style="symbols">
<t>Addressing comments by Yoshifumi Nishida</t>
<t>Removed mentioning MD5 as an example (comment by David Black)</t>
<t>Added memory footprint details of TCP implementations (Contiki-NG a
nd lwIP 2.1.2) provided by Rahul Jadhav in the Annex</t>
<t>Addressed comments by Ilpo Jarvinen throughout the whole document</
t>
<t>Improved the RIOT section in the Annex, based on feedback from Emma
nuel Baccelli</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<name>lwIP</name>
<t>lwIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers.
lwIP has a total code size of ~14 kB to ~22 kB
(which comprises memory management, checksumming, network interfaces,
IPv4, ICMP, and TCP) and a TCP code size of ~9 kB to ~14 kB <xref target="Dunk"
format="default"/>.
Both IPv4 and IPv6 are supported in lwIP since v2.0.0.</t>
<section title="Changes between -05 and -06"> <t>In contrast with uIP, lwIP decouples applications from the network st
ack. lwIP supports a TCP transmission window greater than a single segment, as w
<t><list style="symbols"> ell as the buffering of incoming and outgoing data. Other implemented mechanisms
comprise slow start, congestion avoidance, fast retransmit, and fast recovery.
<t>Incorporated suggestions by Stuart Cheshire</t> SACK and Window Scale support has been recently added to lwIP.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<name>RIOT</name>
<t> The RIOT TCP implementation (called "GNRC TCP") has been designed fo
r Class 1 devices <xref target="RFC7228" format="default"/>. The main target pla
tforms are 8- and 16-bit microcontrollers, with 32-bit platforms also supported.
GNRC TCP
offers a similar function set as uIP, but it provides and maintains
an independent receive buffer for each connection. In contrast to uIP, retransmi
ssion is also handled by GNRC TCP. For simplicity, GNRC TCP uses a single-MSS im
plementation. The application programmer does not need to know anything about th
e TCP internals; therefore, GNRC TCP can be seen as a user-friendly uIP TCP impl
ementation.
</t>
<t> The MSS is set on connections establishment and cannot be changed du
ring connection lifetime. GNRC TCP allows multiple connections in parallel, but
each TCB must
be allocated somewhere in the system. By default, there is only enou
gh memory allocated for a single TCP connection, but it can be increased at comp
ile time if the user needs multiple parallel connections.
</t>
<section title="Changes between -06 and -07"> <t> The RIOT TCP implementation offers an optional Portable Operating Sy
stem Interface (POSIX) socket wrapper that enables POSIX compliance, if needed.
<t><list style="symbols"> </t>
<t> Further details on RIOT and GNRC can be found in <xref target="RIOT"
<t>Addressed comments by Gorry Fairhurst</t> format="default"/> and <xref target="GNRC" format="default"/>.
</t>
</list></t>
</section>
<section title="Changes between -07 and -08">
<t><list style="symbols">
<t>Addressed WGLC comments by Ilpo Jarvinen, Markku Kojo and Ingemar J
ohansson throughout the document, including
the addition of a new section on Initial Window considerations.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Changes between -08 and -09"> <name>TinyOS</name>
<t>TinyOS was important as a platform for early constrained devices. Tin
<t><list style="symbols"> yOS has an experimental TCP stack that uses a simple non-blocking library-based
implementation of TCP, which provides a subset of the socket interface primitive
<t>Addressed second round of comments by Ilpo Jarvinen and Markku Kojo s. The application is responsible for buffering. The TCP library does not do any
, based on the previous draft update.</t> receive-side buffering. Instead, it will immediately dispatch new, in-order dat
a to the application or otherwise drop the segment. A send buffer is provided by
</list></t> the application. Multiple TCP connections are possible. Recently, there has bee
n little work on the stack.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Changes between -09 and -10"> <name>FreeRTOS</name>
<t>FreeRTOS is a real-time operating system kernel for embedded devices
<t><list style="symbols"> that
is supported by 16- and 32-bit microprocessors. Its TCP implementa
<t>Addressed comments by Erik Kline.</t> tion is based on multiple-segment window size, although a "Tiny-TCP" option, whi
ch is a single-MSS variant, can be enabled. Delayed ACKs are supported, with a 2
<t>Addressed a comment by Markku Kojo on advice given in RFC 6691. </t 0 ms Delayed ACK timer as a technique intended "to gain performance".
> </t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Changes between -10 and -11"> <name>uC/OS</name>
<t>uC/OS is a real-time operating system kernel for embedded devices, wh
<t><list style="symbols"> ich is maintained by Micrium.&nbsp; uC/OS is intended for 8-, 16-, and 32-bit mi
croprocessors. The uC/OS TCP implementation supports a multiple-segment window s
<t>Addressed a comment by Ted Lemon on MSS advice. </t> ize.
</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<name>Summary</name>
<section title="Changes between -11 and -12"> <t>None of the implementations considered in this Annex support ECN or TF
O.</t>
<t><list style="symbols">
<t>Addressed comments from IESG and various directorates. </t>
</list></t>
</section>
<section title="Changes between -12 and -13"> <table anchor="table_1">
<name>Summary of TCP Features for Different Lightweight TCP Implementations</n
ame>
<thead>
<tr>
<th colspan="2"></th>
<th>uIP</th>
<th>lwIP orig</th>
<th>lwIP 2.1</th>
<th>RIOT</th>
<th>TinyOS</th>
<th>FreeRTOS</th>
<th>uC/OS</th>
</tr>
</thead>
<tbody>
<t><list style="symbols"> <tr>
<td colspan="2">Code Size (kB)</td>
<td align="center">&lt;5</td>
<td align="center">~9 to ~14</td>
<td align="center">38</td>
<td align="center">&lt;7</td>
<td align="center">N/A</td>
<td align="center">&lt;9.2</td>
<td align="center">N/A</td>
</tr>
<tr>
<td colspan="2">Memory</td>
<td align="center">(a)</td>
<td align="center">(T1)</td>
<td align="center">(T4)</td>
<td align="center">(T3)</td>
<td align="center">N/A</td>
<td align="center">(T2)</td>
<td align="center">N/A</td>
</tr>
<tr>
<th rowspan="1" colspan="9" align="left">TCP Features</th>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Single-Segm.</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">No</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Slow start</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Fast rec/retx</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Keep-alive</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Win. Scale</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">TCP timest.</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">SACK</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Del. ACKs</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Socket</td>
<td align="center">No</td>
<td align="center">No</td>
<td>Optional</td>
<td align="center">(I)</td>
<td>Subset</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="2" align="right">Concur. Conn.</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<th rowspan="1" colspan="2" align="left">TLS supported</th>
<th align="center">No</th>
<th align="center">No</th>
<th align="center">Yes</th>
<th align="center">Yes</th>
<th align="center">Yes</th>
<th align="center">Yes</th>
<th align="center">Yes</th>
</tr>
<t>Fixed two typos. </t> </tbody>
</table>
<t>Addressed a comment by Barry Leiba. </t> <t>Legend:</t>
</list></t> <dl spacing="normal" indent="8">
<dt>(T1):</dt><dd>TCP-only, on x86 and AVR platforms</dd>
<dt>(T2):</dt><dd>TCP-only, on ARM Cortex-M platform</dd>
<dt>(T3):</dt><dd>TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for
the same platform
is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional
connection)</dd>
<dt>(T4):</dt><dd>TCP-only, on CC2538DK, cross-compiling on Linux</dd>
<dt>(a):</dt><dd>Includes IP, ICMP, and TCP on x86 and AVR platforms. The Co
ntiki-NG TCP implementation has a code size of 3.2 kB on CC2538DK, cross-compili
ng on Linux</dd>
<dt>(I):</dt><dd>Optional POSIX socket wrapper that enables POSIX compliance
if needed</dd>
<dt>Mult.:</dt><dd>Multiple</dd>
<dt>N/A:</dt><dd>Not Available</dd>
</dl>
</section> </section>
</section> </section>
</middle> <section anchor="ACKs" numbered="false" toc="default">
<name>Acknowledgments</name>
<!-- *****BACK MATTER ***** --> <t>The work of <contact fullname="Carles Gomez"/> has been funded in part
by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through J
<back> ose Castillejo grants CAS15/00336
<!-- References split into informative and normative --> and CAS18/00170; the European Regional Development Fund (ERDF); the Spa
nish Government through projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDE
<!-- There are 2 ways to insert reference entries from the citation librarie R, and UE; and
s: the Generalitat de Catalunya Grant 2017 SGR 376.
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here Part of his contribution to this work has been carried out during his stay
(as shown) s as a visiting scholar at the Computer Laboratory of the University of Cambridg
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm e.</t>
l"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.0793.xml'?>
<?rfc include='reference.RFC.1122.xml'?>
<?rfc include='reference.RFC.7323.xml'?>
<?rfc include='reference.RFC.2018.xml'?>
<?rfc include='reference.RFC.8200.xml'?>
<?rfc include='reference.RFC.3168.xml'?>
<?rfc include='reference.RFC.3042.xml'?>
<?rfc include='reference.RFC.5681.xml'?>
<?rfc include='reference.RFC.6298.xml'?>
<?rfc include='reference.RFC.6691.xml'?>
<?rfc include='reference.RFC.6928.xml'?>
<?rfc include='reference.RFC.7228.xml'?>
<?rfc include='reference.RFC.7413.xml'?>
<?rfc include='reference.RFC.7567.xml'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.RFC.8201.xml'?>
<?rfc include='reference.RFC.2757.xml'?>
<?rfc include='reference.RFC.2884.xml'?>
<?rfc include='reference.RFC.3481.xml'?>
<?rfc include='reference.RFC.3819.xml'?>
<?rfc include='reference.RFC.4944.xml'?>
<?rfc include='reference.RFC.5925.xml'?>
<?rfc include='reference.RFC.6077.xml'?>
<?rfc include='reference.RFC.6120.xml'?>
<?rfc include='reference.RFC.6282.xml'?>
<?rfc include='reference.RFC.6550.xml'?>
<?rfc include='reference.RFC.6606.xml'?>
<?rfc include='reference.RFC.6775.xml'?>
<?rfc include='reference.RFC.7230.xml'?>
<?rfc include='reference.RFC.7252.xml'?>
<?rfc include='reference.RFC.7414.xml'?>
<?rfc include='reference.RFC.7428.xml'?>
<?rfc include='reference.RFC.7540.xml'?>
<?rfc include='reference.RFC.7668.xml'?>
<?rfc include='reference.RFC.8087.xml'?>
<?rfc include='reference.RFC.8105.xml'?>
<?rfc include='reference.RFC.8163.xml'?>
<?rfc include='reference.RFC.8323.xml'?>
<?rfc include='reference.RFC.8352.xml'?>
<?rfc include='reference.RFC.8376.xml'?>
<?rfc include='reference.RFC.8446.xml'?>
<?rfc include='reference.RFC.8900.xml'?>
<?rfc include='reference.I-D.delcarpio-6lo-wlanah'?>
<?rfc include='reference.I-D.ietf-core-fasor'?>
<?rfc include='reference.I-D.ietf-tcpm-rto-consider'?>
<?rfc include='reference.I-D.ietf-6lo-fragment-recovery'?>
<?rfc include='reference.I-D.ietf-tcpm-generalized-ecn'?>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.
2119.xml"?-->
<reference anchor="Commag">
<front>
<title>CoAP Congestion Control for the Internet of Things</title>
<author>
<organization>A. Betzler, C. Gomez, I. Demirkol, J. Paradells</organ
ization>
</author>
<date year="2016" month="IEEE Communications Magazine, June"/>
</front>
</reference>
<reference anchor="IntComp">
<front>
<title>TCP in the Internet of Things: from ostracism to prominence</
title>
<author>
<organization>C. Gomez, A. Arcia-Moret, J. Crowcroft</organization>
</author>
<date year="2018" month="IEEE Internet Computing, January-February"/
>
</front>
</reference>
<reference anchor="MQTT">
<front>
<title>Message Queuing Telemetry Transport (MQTT) v3.1.1</title>
<author>
<organization>ISO/IEC 20922:2016</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="HomeGateway">
<front>
<title>An Experimental Study of Home Gateway Characteristics</title>
<author>
<organization>Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo</organization>
</author>
<date year="2010" month="Proceedings of the 10th ACM SIGCOMM confere
nce on Internet measurement"/>
</front>
</reference>
<reference anchor="shrew">
<front>
<title>Low-Rate TCP-Targeted Denial of Service Attacks</title>
<author>
<organization>A. Kuzmanovic, E. Knightly</organization>
</author>
<date year="2003" month="SIGCOMM'03"/>
</front>
</reference>
<reference anchor="ETEN">
<front>
<title>Explicit transport error notification (ETEN) for error-prone
wireless and satellite networks</title>
<author>
<organization>R. Krishnan et al </organization>
</author>
<date year="2004" month="Computer Networks"/>
</front>
</reference>
<!--
<reference anchor="MQTTS">
<front>
<title>MQTT-S: A Publish/Subscribe Protocol For
Wireless Sensor Networks</title>
<author>
<organization>U. Hunkeler, H.-L. Truong, A. Stanford-Clark </organiz
ation>
</author>
<date year="2008"/>
</front>
</reference>
-->
<reference anchor="Dunk">
<front>
<title>Full TCP/IP for 8-Bit Architectures</title>
<author>
<organization>A. Dunkels </organization>
</author>
<date year="2003"/>
</front>
</reference>
<reference anchor="RIOT">
<front>
<title>RIOT: an Open Source Operating Systemfor Low-end Embedded Dev
ices in the IoT</title>
<author>
<organization>E. Baccelli et al. </organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="GNRC">
<front>
<title>Connecting the World of Embedded Mobiles: The RIOTApproach to
Ubiquitous Networking for the IoT</title>
<author>
<organization>M. Lenders et al. </organization>
</author>
<date year="2018"/>
</front>
</reference>
</references> <t> The authors appreciate the feedback received for this document. The
following folks provided comments that helped improve the document:
<contact fullname="Carsten Bormann"/>, <contact fullname="Zhen Cao"/>, <conta
ct fullname="Wei Genyu"/>, <contact fullname="Ari Keranen"/>, <contact fullname=
"Abhijan Bhattacharyya"/>, <contact fullname="Andres Arcia-Moret"/>, <contact fu
llname="Yoshifumi Nishida"/>, <contact fullname="Joe Touch"/>, <contact fullname
="Fred Baker"/>, <contact fullname="Nik Sultana"/>, <contact fullname="Kerry Lyn
n"/>, <contact fullname="Erik Nordmark"/>, <contact fullname="Markku Kojo"/>, <c
ontact fullname="Hannes Tschofenig"/>, <contact fullname="David Black"/>, <conta
ct fullname="Ilpo Jarvinen"/>,
<contact fullname="Emmanuel Baccelli"/>, <contact fullname="Stuart Cheshire"/
>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Ingemar Johansson"/
>, <contact fullname="Ted Lemon"/>, and <contact fullname="Michael Tuexen"/>.
<contact fullname="Simon Brummer"/> provided details and kindly performed Ran
dom Access Memory (RAM) and Read-Only Memory (ROM) usage measurements on the RIO
T TCP implementation. <contact fullname="Xavi Vilajosana"/> provided details on
the OpenWSN TCP implementation.
<contact fullname="Rahul Jadhav"/> kindly performed code size measurements on
the Contiki-NG and lwIP 2.1.2 TCP implementations. He also provided details on
the uIP TCP implementation.
</t>
</section>
<!-- -->
</back> </back>
</rfc> </rfc>
 End of changes. 198 change blocks. 
1247 lines changed or deleted 1079 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/