doc: Add RFC documents

1 files changed, 1343 insertions, 0 deletions

diff --git a/doc/rfc/rfc9006.txt b/doc/rfc/rfc9006.txt
new file mode 100644
index 0000000..d4e7435
--- /dev/null
+++ b/doc/rfc/rfc9006.txt
@@ -0,0 +1,1343 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          C. Gomez
+Request for Comments: 9006                                           UPC
+Category: Informational                                     J. Crowcroft
+ISSN: 2070-1721                                  University of Cambridge
+                                                               M. Scharf
+                                                    Hochschule Esslingen
+                                                              March 2021
+
+
+           TCP Usage Guidance in the Internet of Things (IoT)
+
+Abstract
+
+   This document provides guidance on how to implement and use the
+   Transmission Control Protocol (TCP) in Constrained-Node Networks
+   (CNNs), which are a characteristic of the Internet of Things (IoT).
+   Such environments require a lightweight TCP implementation and may
+   not make use of optional functionality.  This document explains a
+   number of known and deployed techniques to simplify a TCP stack as
+   well as corresponding trade-offs.  The objective is to help embedded
+   developers with decisions on which TCP features to use.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9006.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Characteristics of CNNs Relevant for TCP
+     2.1.  Network and Link Properties
+     2.2.  Usage Scenarios
+     2.3.  Communication and Traffic Patterns
+   3.  TCP Implementation and Configuration in CNNs
+     3.1.  Addressing Path Properties
+       3.1.1.  Maximum Segment Size (MSS)
+       3.1.2.  Explicit Congestion Notification (ECN)
+       3.1.3.  Explicit Loss Notifications
+     3.2.  TCP Guidance for Single-MSS Stacks
+       3.2.1.  Single-MSS Stacks -- Benefits and Issues
+       3.2.2.  TCP Options for Single-MSS Stacks
+       3.2.3.  Delayed Acknowledgments for Single-MSS Stacks
+       3.2.4.  RTO Calculation for Single-MSS Stacks
+     3.3.  General Recommendations for TCP in CNNs
+       3.3.1.  Loss Recovery and Congestion/Flow Control
+         3.3.1.1.  Selective Acknowledgments (SACKs)
+       3.3.2.  Delayed Acknowledgments
+       3.3.3.  Initial Window
+   4.  TCP Usage Recommendations in CNNs
+     4.1.  TCP Connection Initiation
+     4.2.  Number of Concurrent Connections
+     4.3.  TCP Connection Lifetime
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  TCP Implementations for Constrained Devices
+     A.1.  uIP
+     A.2.  lwIP
+     A.3.  RIOT
+     A.4.  TinyOS
+     A.5.  FreeRTOS
+     A.6.  uC/OS
+     A.7.  Summary
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The Internet Protocol suite is being used for connecting Constrained-
+   Node Networks (CNNs) to the Internet, enabling the so-called Internet
+   of Things (IoT) [RFC7228].  In order to meet the requirements that
+   stem from CNNs, the IETF has produced a suite of new protocols
+   specifically designed for such environments (see, e.g., [RFC8352]).
+   New IETF protocol stack components include the IPv6 over Low-Power
+   Wireless Personal Area Networks (6LoWPANs) adaptation layer
+   [RFC4944][RFC6282][RFC6775], the IPv6 Routing Protocol for Low-Power
+   and Lossy Networks (RPL) [RFC6550], and the Constrained Application
+   Protocol (CoAP) [RFC7252].
+
+   As of this writing, the main transport-layer protocols in IP-based
+   IoT 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,
+   unsuitability for multicast, and always-confirmed data delivery, are
+   not optimal for IoT scenarios.  However, many typical claims on TCP
+   unsuitability for IoT (e.g., a high complexity, connection-oriented
+   approach incompatibility with radio duty-cycling and spurious
+   congestion control activation in wireless links) are not valid, can
+   be solved, or are also found in well-accepted IoT end-to-end
+   reliability mechanisms (see a detailed analysis in [IntComp]).
+
+   At the application layer, CoAP was developed over UDP [RFC7252].
+   However, the integration of some CoAP deployments with existing
+   infrastructure is being challenged by middleboxes such as firewalls,
+   which may limit and even block UDP-based communications.  This is the
+   main reason why a CoAP over TCP specification has been developed
+   [RFC8323].
+
+   Other application-layer protocols not specifically 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 by default
+   [RFC7230] [RFC7540], and the Extensible Messaging and Presence
+   Protocol (XMPP) [RFC6120].  TCP is also used by non-IETF application-
+   layer protocols in the IoT space such as the Message Queuing
+   Telemetry Transport (MQTT) [MQTT] and its lightweight variants.
+
+   TCP is a sophisticated transport protocol that includes optional
+   functionality (e.g., TCP options) that may improve performance in
+   some environments.  However, many optional TCP extensions require
+   complex logic inside the TCP stack and increase the code size and the
+   memory requirements.  Many TCP extensions are not required for
+   interoperability with other standard-compliant TCP endpoints.  Given
+   the limited resources on constrained devices, careful selection of
+   optional TCP features can make an implementation more lightweight.
+
+   This document provides guidance on how to implement and configure TCP
+   and guidance on how applications should use TCP in CNNs.  The
+   overarching goal is to offer simple measures to allow for lightweight
+   TCP implementation and suitable operation in such environments.  A
+   TCP implementation following the guidance in this document is
+   intended to be compatible with a TCP endpoint that is compliant to
+   the TCP standards, albeit possibly with a lower performance.  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 able to connect with a standard-compliant TCP client.
+
+   This document assumes that the reader is familiar with TCP.  A
+   comprehensive survey of the TCP standards can be found in RFC 7414
+   [RFC7414].  Similar guidance regarding the use of TCP in special
+   environments has been published before, e.g., for cellular wireless
+   networks [RFC3481].
+
+2.  Characteristics of CNNs Relevant for TCP
+
+2.1.  Network and Link Properties
+
+   CNNs are defined in [RFC7228] as networks whose characteristics 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 [RFC7228].
+   The first two dimensions pose constraints on the complexity and
+   memory footprint of the protocols that constrained nodes can support.
+   The latter requires techniques to save energy, such as radio duty-
+   cycling in wireless devices [RFC8352] and the minimization of the
+   number of messages transmitted/received (and their size).
+
+   [RFC7228] lists typical network constraints in CNNs, including low
+   achievable bitrate/throughput, high packet loss and high variability
+   of packet loss, highly asymmetric link characteristics, severe
+   penalties for using larger packets, limits on reachability over time,
+   etc.  CNNs may use wireless or wired technologies (e.g., Power Line
+   Communication), and the transmission rates are typically low (e.g.,
+   below 1 Mbps).
+
+   For use of TCP, one challenge is that not all technologies in a CNN
+   may be aligned with typical Internet subnetwork design principles
+   [RFC3819].  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 [RFC6077].
+
+2.2.  Usage Scenarios
+
+   There are different deployment and usage scenarios for CNNs.  Some
+   CNNs 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.  Alternatively, CNNs may also follow the multihop
+   topology [RFC6606].
+
+   In constrained environments, there can be different types of devices
+   [RFC7228].  For example, there can be devices with a single combined
+   send/receive buffer, 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.
+
+   One key use case for TCP in CNNs is a model where constrained devices
+   connect to unconstrained servers in the Internet.  But it is also
+   possible that both TCP endpoints run on constrained devices.  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 scenario is asymmetric, as the unconstrained device will
+   typically not suffer the severe constraints of the constrained
+   device.  The unconstrained device is expected to be mains-powered,
+   have a high amount of memory and processing power, and be connected
+   to a resource-rich network.
+
+   Assuming that a majority of constrained devices will correspond to
+   sensor nodes, the amount of data traffic sent by constrained devices
+   (e.g., sensor node measurements) is expected to be higher than the
+   amount of data traffic in the opposite direction.  Nevertheless,
+   constrained devices may receive requests (to which they may respond),
+   commands (for configuration purposes and for constrained devices
+   including actuators), and relatively infrequent firmware/software
+   updates.
+
+
+                                                      +---------------+
+           o     o <-------- TCP communication -----> |               |
+          o     o                                     |               |
+             o     o                                  | Unconstrained |
+       o        o              +-----------+          |    device     |
+           o     o   o  ------ | Middlebox |  ------- |               |
+            o   o              +-----------+          | (e.g., cloud) |
+          o    o  o                                   |               |
+                                                      +---------------+
+      Constrained devices
+
+      Figure 1: TCP Communication between a Constrained Device and an
+                Unconstrained Device, Traversing a Middlebox
+
+2.3.  Communication and Traffic Patterns
+
+   IoT applications are characterized by a number of different
+   communication patterns.  The following non-comprehensive list
+   explains some typical examples:
+
+   Unidirectional transfers:  An IoT device (e.g., a sensor) can
+      (repeatedly) send updates to the other endpoint.  There is not
+      always a need for an application response back to the IoT device.
+
+   Request-response patterns:  An IoT device receiving a request from
+      the other endpoint, which triggers a response from the IoT device.
+
+   Bulk data transfers:  A typical example for a long file transfer
+      would be an IoT device firmware update.
+
+   A typical communication pattern is that a constrained device
+   communicates with an unconstrained device (cf. Figure 1).  But it is
+   also possible that constrained devices communicate amongst
+   themselves.
+
+3.  TCP Implementation and Configuration in CNNs
+
+   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.
+
+3.1.  Addressing Path Properties
+
+3.1.1.  Maximum Segment Size (MSS)
+
+   Assuming that IPv6 is used, and for the sake of lightweight
+   implementation and operation, unless applications 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 datagram size to
+   1280 bytes in order to avoid the need to support Path MTU Discovery
+   [RFC8201].  In addition, an IP datagram size of 1280 bytes avoids
+   incurring IPv6-layer fragmentation [RFC8900].
+
+   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
+   the TCP MSS to 1220 bytes or less.  Note that it is already a
+   requirement for TCP implementations to consume payload space instead
+   of increasing datagram size when including IP or TCP options in an IP
+   packet to be sent [RFC6691].  Therefore, it is not required to
+   advertise an MSS smaller than 1220 bytes in order to accommodate TCP
+   options.
+
+   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 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.  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 [RFC8200], while IEEE 802.15.4 lacks
+   fragmentation mechanisms.  6LoWPAN defines an IEEE 802.15.4 link MTU
+   of 1280 bytes [RFC4944].  Other technologies, such as Bluetooth low
+   energy [RFC7668], ITU-T G.9959 [RFC7428], or Digital Enhanced
+   Cordless Telecommunications (DECT) Ultra Low Energy (ULE) [RFC8105],
+   also use 6LoWPAN-based adaptation layers in order to enable IPv6
+   support.  These technologies do support link-layer fragmentation.  By
+   exploiting this functionality, the adaptation layers that enable IPv6
+   over such technologies also define an MTU of 1280 bytes.
+
+   On the other hand, there exist technologies also used in the CNN
+   space, such as Master Slave (MS) / Token Passing (TP) [RFC8163],
+   Narrowband IoT (NB-IoT) [RFC8376], or IEEE 802.11ah [6LO-WLANAH],
+   that do not suffer the same degree of frame size limitations as the
+   technologies mentioned above.  It is recommended that the MTU for MS/
+   TP be 1500 bytes [RFC8163]; the MTU in NB-IoT is 1600 bytes, and the
+   maximum frame payload size for IEEE 802.11ah is 7991 bytes.
+
+   Using a larger MSS (to a suitable extent) may be beneficial in some
+   scenarios, especially when transferring large payloads, as it reduces
+   the number of packets (and packet headers) 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 delivery is used, the amount of data that TCP
+   unnecessarily retransmits due to fragment loss increases (and
+   throughput decreases) quickly with the MSS.  This happens because the
+   loss of a fragment leads to the loss of the whole fragmented packet
+   being transmitted.  Unnecessary data retransmission is particularly
+   harmful in CNNs due to the resource constraints of such environments.
+   Note that, while the original 6LoWPAN fragmentation mechanism
+   [RFC4944] does not offer reliable fragment delivery, fragment
+   recovery functionality for 6LoWPAN or 6Lo environments has been
+   standardized [RFC8931].
+
+3.1.2.  Explicit Congestion Notification (ECN)
+
+   ECN [RFC3168] allows a router to signal in the IP header of a packet
+   that congestion is rising, for example, when a queue size reaches a
+   certain threshold.  An ECN-enabled TCP receiver will echo back the
+   congestion signal to the TCP sender by setting a flag in its next TCP
+   Acknowledgment (ACK).  The sender triggers congestion control
+   measures as if a packet loss had happened.
+
+   RFC 8087 [RFC8087] outlines the principal gains in terms of increased
+   throughput, reduced delay, and other benefits when ECN is used over a
+   network path that includes equipment that supports Congestion
+   Experienced (CE) marking.  In the context of CNNs, a remarkable
+   feature of ECN is that congestion can be signaled without incurring
+   packet drops (which will lead to retransmissions and consumption of
+   limited resources such as energy and bandwidth).
+
+   ECN can further reduce packet losses since congestion control
+   measures can be applied earlier [RFC2884].  Fewer lost packets
+   implies that the number of retransmitted segments decreases, which is
+   particularly beneficial in CNNs, where energy and bandwidth resources
+   are typically limited.  Also, it makes sense to try to avoid packet
+   drops for transactional workloads with small data sizes, which are
+   typical for CNNs.  In such traffic patterns, it is more difficult and
+   often impossible to detect packet loss without retransmission
+   timeouts (e.g., as there may not be three duplicate ACKs).  Any
+   retransmission timeout slows down the data transfer significantly.
+   In addition, if the constrained device uses power-saving techniques,
+   a retransmission timeout will incur a wake-up action, in contrast to
+   ACK 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
+   (ECN-Echo (ECE) flag) arrives 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 timer expires.  Effectively, at that
+   moment, the TCP sender reduces its 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 received in
+   subsequent TCP ACKs.  Otherwise, if an ECN signal is not present in a
+   subsequent TCP ACK, the TCP sender resumes the normal ACK-clocked
+   transmission of segments [RFC3168].
+
+   ECN can be incrementally deployed in the Internet.  Guidance on
+   configuration and usage of ECN is provided in RFC 7567 [RFC7567].
+   Given the benefits, more and more TCP stacks in the Internet support
+   ECN, and it makes sense to specifically leverage ECN in controlled
+   environments such as CNNs.  As of this writing, there is ongoing work
+   to extend the types of TCP packets that are ECN capable, including
+   pure ACKs [TCPM-ECN].  Such a feature may further increase the
+   benefits of ECN in CNN environments.  Note, however, that supporting
+   ECN increases implementation complexity.
+
+3.1.3.  Explicit Loss Notifications
+
+   There has been a significant body of research on solutions capable of
+   explicitly indicating whether a TCP segment loss is due to
+   corruption, in order to avoid activation of congestion control
+   mechanisms [ETEN] [RFC2757].  While such solutions may provide
+   significant improvement, they have not been widely deployed and
+   remain as experimental work.  In fact, as of today, the IETF has not
+   standardized any such solution.
+
+3.2.  TCP Guidance for Single-MSS Stacks
+
+   This section discusses TCP stacks that allow transferring a single
+   MSS.  More general guidance is provided in Section 3.3.
+
+3.2.1.  Single-MSS Stacks -- Benefits and Issues
+
+   A TCP stack can reduce the memory requirements by advertising a TCP
+   window size of 1 MSS and also transmit, at most, 1 MSS of
+   unacknowledged data.  In that case, both congestion and flow control
+   implementation are quite simple.  Such a small receive and send
+   window may be sufficient for simple message exchanges in the CNN
+   space.  However, only using a window of 1 MSS can significantly
+   affect performance.  A stop-and-wait operation results in low
+   throughput for transfers that exceed the length of 1 MSS, e.g., a
+   firmware download.  Furthermore, a single-MSS solution relies solely
+   on timer-based loss recovery, therefore missing the performance gain
+   of Fast Retransmit and Fast Recovery (which requires a larger window
+   size; see Section 3.3.1).
+
+   If CoAP is used over TCP with the default setting for NSTART in RFC
+   7252 [RFC7252], a CoAP endpoint is not allowed to send a new message
+   to a destination until a response for the previous message sent to
+   that destination has been received.  This is equivalent to an
+   application-layer window size of 1 data unit.  For this use of CoAP,
+   a maximum TCP window of 1 MSS may be sufficient, as long as the CoAP
+   message size does not exceed 1 MSS.  An exception in CoAP over TCP,
+   though, is the Capabilities and Settings Message (CSM) that must be
+   sent at the 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 exceeds the MSS, a sender using a single-MSS stack will
+   need to wait for the ACK confirming the CSM before sending the
+   application message.
+
+3.2.2.  TCP Options for Single-MSS Stacks
+
+   A TCP implementation needs to support, at a minimum, TCP options 2,
+   1, and 0.  These are, respectively, the MSS option, the No-Operation
+   option, and the End Of Option List marker [RFC0793].  None of these
+   are a substantial burden to support.  These options are sufficient
+   for interoperability with a standard-compliant TCP endpoint, albeit
+   many TCP stacks support additional options and can negotiate their
+   use.  A TCP implementation is permitted to silently ignore all other
+   TCP options.
+
+   A TCP implementation for a constrained device that uses a single-MSS
+   TCP receive or transmit window size may not benefit from supporting
+   the following TCP options: Window Scale [RFC7323], TCP Timestamps
+   [RFC7323], Selective Acknowledgment (SACK) [RFC2018], and SACK-
+   Permitted [RFC2018].  Also, other TCP options may not be required on
+   a constrained device with a very lightweight implementation.  With
+   regard to the Window Scale option, note that it is only useful if a
+   window size greater than 64 kB is needed.
+
+   Note that a TCP sender can benefit from the TCP Timestamps option
+   [RFC7323] in detecting spurious RTOs.  The latter are quite likely to
+   occur 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 by the Timestamps option (of up to 12 bytes)
+   needs to be taken into account.
+
+3.2.3.  Delayed Acknowledgments for Single-MSS Stacks
+
+   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
+   general, usefulness of Delayed ACKs depends heavily on the usage
+   scenario (see Section 3.3.2).  There can be interactions with single-
+   MSS stacks.
+
+   When traffic is unidirectional, if the sender can send at most 1 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 [RFC5681], which limits the throughput and can
+   increase data delivery time.  Note that, in some cases, it may not be
+   possible to disable Delayed ACKs.  One known workaround is to split
+   the data to be sent into two segments of smaller size.  A standard-
+   compliant TCP receiver may immediately acknowledge the second MSS of
+   data, which can improve throughput.  However, this "split hack" may
+   not always work since a TCP receiver is required to acknowledge every
+   second full-sized segment, but not two consecutive small segments.
+   The overhead of sending two IP packets instead of one is another
+   downside of the "split hack".
+
+   Similar issues may happen when the sender uses the Nagle algorithm,
+   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 at the TCP level.
+
+   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 payload.  Disabling Delayed ACKs at the
+   request sender allows an immediate ACK for the data segment carrying
+   the response.
+
+3.2.4.  RTO Calculation for Single-MSS Stacks
+
+   The RTO calculation is one of the fundamental TCP algorithms
+   [RFC6298].  There is a fundamental trade-off: a short, aggressive RTO
+   behavior reduces wait time before retransmissions, but it also
+   increases the probability of spurious timeouts.  The latter leads to
+   unnecessary waste of potentially scarce resources in CNNs such as
+   energy and bandwidth.  In contrast, a conservative timeout can result
+   in long error recovery times and, thus, needlessly delay data
+   delivery.
+
+   If a TCP sender uses a very small window size, and it cannot benefit
+   from Fast Retransmit and Fast Recovery or SACK, the RTO algorithm has
+   a large impact on performance.  In that case, RTO algorithm tuning
+   may be considered, although careful assessment of possible drawbacks
+   is recommended [RFC8961].
+
+   As an example, adaptive RTO algorithms defined for CoAP over UDP have
+   been found to perform well in CNN scenarios [Commag] [CORE-FASOR].
+
+3.3.  General Recommendations for TCP in CNNs
+
+   This section summarizes some widely used techniques to improve TCP,
+   with a focus on their use in CNNs.  The TCP extensions discussed here
+   are useful in a wide range of network scenarios, including CNNs.
+   This section is not comprehensive.  A comprehensive survey of TCP
+   extensions is published in RFC 7414 [RFC7414].
+
+3.3.1.  Loss Recovery and Congestion/Flow Control
+
+   Devices that have enough memory to allow a larger (i.e., more than 3
+   MSS of data) TCP window size can leverage a more efficient loss
+   recovery than the timer-based approach used for a smaller TCP window
+   size (see Section 3.2.1) by using Fast Retransmit and Fast Recovery
+   [RFC5681], at 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 to work efficiently: in a given
+   TCP transmission of full-sized segments 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 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 of a size of 5 MSS
+   would require 6100 bytes.
+
+   The example in the previous paragraph did not use a further TCP
+   improvement such as Limited Transmit [RFC3042].  The latter 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 in the previous paragraph, Limited Transmit allows
+   sending 5 MSS with a congestion window (cwnd) of three segments, plus
+   two additional segments for the first two duplicate ACKs.  With
+   Limited Transmit, even a cwnd of two segments allows sending 5 MSS,
+   at the expense of additional delay contributed by the Delayed ACK
+   timer for the ACK that confirms segment 1.
+
+   When a multiple-segment window is used, the receiver will need to
+   manage the reception of possible out-of-order received segments,
+   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 send multiple sub-MSS packets that fit in the window.  (On
+   the other hand, the receiver is free to simply drop out-of-order
+   segments, thus forcing retransmissions.)
+
+3.3.1.1.  Selective Acknowledgments (SACKs)
+
+   If a device with less severe memory and processing constraints can
+   afford advertising a TCP window size of several MSSs, it makes sense
+   to support the SACK option to improve performance.  SACK allows a
+   data receiver to inform the data sender of non-contiguous data blocks
+   received, thus a sender (having previously sent the SACK-Permitted
+   option) can avoid performing unnecessary retransmissions, saving
+   energy and bandwidth, as well as reducing latency.  In addition, SACK
+   often allows for faster loss recovery when there is more than one
+   lost segment in a window 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 8*n+2 bytes to the TCP
+   header, where n denotes the number of data blocks received, up to
+   four blocks.  For a low number of out-of-order segments, the header
+   overhead penalty of SACK is compensated by avoiding unnecessary
+   retransmissions.  When the sender discovers the data blocks that have
+   already been received, it needs to also store the necessary state to
+   avoid unnecessary retransmission of data segments that have already
+   been received.
+
+3.3.2.  Delayed Acknowledgments
+
+   For certain traffic patterns, Delayed ACKs may have a detrimental
+   effect, as already noted in Section 3.2.3.  Advanced TCP stacks may
+   use heuristics to determine the maximum delay for an ACK.  For CNNs,
+   the recommendation depends on the expected communication patterns.
+
+   When traffic over a CNN is expected mostly to be unidirectional
+   messages with a size typically up to 1 MSS, and the time between two
+   consecutive message transmissions is greater than the Delayed ACK
+   timeout, 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 interface in receive mode) during that time.
+   Note that disabling Delayed ACKs may only be possible if the peer
+   device is administered by the same entity managing the constrained
+   device.  For request-response 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 a client issues requests infrequently, disabling Delayed
+   ACKs at the client allows an immediate ACK for the data segment
+   carrying the response.
+
+   In contrast, Delayed ACKs allow for a reduced number of ACKs in bulk
+   transfer types of traffic, e.g., for firmware/software updates or for
+   transferring larger data units containing a batch of sensor readings.
+
+   Note that, in many scenarios, the peer that a constrained device
+   communicates with will be a general purpose system that communicates
+   with both constrained and unconstrained devices.  Since Delayed ACKs
+   are often configured through system-wide parameters, the behavior of
+   Delayed ACKs at the peer will be the same regardless of the nature of
+   the endpoints it talks to.  Such a peer will typically have Delayed
+   ACKs enabled.
+
+3.3.3.  Initial Window
+
+   [RFC5681] specifies a TCP Initial Window (IW) of roughly 4 kB.
+   Subsequently, RFC 6928 [RFC6928] defines an experimental new value
+   for the IW, which in practice will result in an IW of 10 MSS.
+   Nowadays, the latter is used in many TCP implementations.
+
+   Note that a 10-MSS IW was recommended for resource-rich environments
+   (e.g., broadband environments), which are significantly different
+   from CNNs.  In CNNs, many application-layer data units are relatively
+   small (e.g., below 1 MSS).  However, larger objects (e.g., large
+   files containing sensor readings, firmware updates, etc.) may also
+   need to be transferred 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.  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 IW
+   setting will be smaller than 10 MSS.
+
+4.  TCP Usage Recommendations in CNNs
+
+   This section discusses how TCP can be used by applications that are
+   developed for CNN scenarios.  These remarks are by and large
+   independent of how TCP is exactly implemented.
+
+4.1.  TCP Connection Initiation
+
+   In the scenario of a constrained device to an unconstrained device
+   illustrated above, a TCP connection is typically initiated by the
+   constrained device, in order for the device to support possible sleep
+   periods to save energy.
+
+4.2.  Number of Concurrent Connections
+
+   TCP endpoints with a small amount of memory may only support a small
+   number of connections.  Each TCP connection requires storing a number
+   of variables in the TCB.  Depending on 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.).
+
+   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 of simultaneous open connections that it maintains to a
+   given server.  Multiple connections could, for instance, be used to
+   avoid the "head-of-line blocking" problem in an application transfer.
+   However, in addition to consuming resources, using multiple
+   connections can also cause undesirable side effects in congested
+   networks.  For example, the HTTP/1.1 specification encourages clients
+   to be conservative when opening multiple connections [RFC7230].
+   Furthermore, each new connection will start with a three-way
+   handshake, therefore increasing message overhead.
+
+   Being conservative when opening multiple TCP connections is of
+   particular importance in Constrained-Node Networks.
+
+4.3.  TCP Connection Lifetime
+
+   In order to minimize message overhead, it makes sense to keep a TCP
+   connection open as long as the two TCP endpoints have more data to
+   send.  If applications exchange data rather infrequently, i.e., if
+   TCP connections would stay idle for a long time, 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.  RFC 5382 [RFC5382] specifies a minimum value
+   for such an interval of 124 minutes.  Measurement studies have
+   reported that TCP NAT binding timeouts are highly variable across
+   devices, with the median being around 60 minutes, the shortest
+   timeout being around 2 minutes, and more than 50% of the devices with
+   a timeout shorter than the aforementioned minimum timeout of 124
+   minutes [HomeGateway].  The timeout duration used by a middlebox
+   implementation may not be known to the TCP endpoints.
+
+   In CNNs, such middleboxes may, e.g., be present at the boundary
+   between the CNN and other networks.  If the middlebox can be
+   optimized for CNN use cases, it makes sense to increase the initial
+   value for filter state inactivity timers to avoid problems with idle
+   connections.  Apart from that, this problem can be dealt with by
+   different connection-handling strategies, each having pros and cons.
+
+   One approach for infrequent data transfer is to use short-lived TCP
+   connections.  Instead of trying to maintain a TCP connection for a
+   long time, it is possible that short-lived 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 messages
+   and the latency resulting from starting new connections, it is
+   recommended to use a sequence of short-lived connections instead of
+   maintaining a single long-lived connection.
+
+   The message and latency overhead that stems from using a sequence of
+   short-lived connections could be reduced by TCP Fast Open (TFO)
+   [RFC7413], which is an experimental TCP extension, at the expense of
+   increased implementation complexity and increased TCB size.  TFO
+   allows data to be carried in SYN (and SYN-ACK) segments and to be
+   consumed immediately by the receiving endpoint.  This reduces the
+   message and latency overhead compared to the traditional three-way
+   handshake to establish a TCP connection.  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 bytes, is then included
+   in SYN packets of subsequent connections.  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 connections between
+   the same two endpoints, the latter may become vulnerable to privacy
+   threats.  In addition, a valid cookie may be stolen from a
+   compromised host and may be used to perform SYN flood attacks, as
+   well as amplified reflection attacks to victim hosts (see Section 5
+   of [RFC7413]).  Nevertheless, TFO is more efficient than frequently
+   opening new TCP connections with the traditional three-way handshake,
+   as long as the cookie can be reused in subsequent connections.
+   However, as stated in [RFC7413], TFO deviates from the standard TCP
+   semantics, since the data in the SYN could be replayed to an
+   application in some rare circumstances.  Applications should not use
+   TFO unless they can tolerate this issue, e.g., by using TLS
+   [RFC7413].  A comprehensive discussion on TFO can be found in RFC
+   7413 [RFC7413].
+
+   Another approach is to use long-lived TCP connections with
+   application-layer heartbeat messages.  Various application protocols
+   support such heartbeat messages (e.g., CoAP over TCP [RFC8323]).
+   Periodic application-layer heartbeats can prevent early filter state
+   record deletion in middleboxes.  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 the middlebox TCP binding timeout.  Otherwise, the
+   implementer needs to take into account that middlebox TCP binding
+   timeouts fall in a wide range of possible values [HomeGateway], and
+   it may be hard to find a proper heartbeat period for application-
+   layer heartbeat messages.
+
+   One specific advantage of heartbeat messages is that they also allow
+   liveness checks at the application level.  In general, it makes sense
+   to realize liveness checks at the highest protocol layer possible
+   that is meaningful to the application, in order to maximize the depth
+   of the liveness check.  In addition, timely detection of a dead peer
+   may allow savings in terms of TCB memory use.  However, the
+   transmission of heartbeat messages consumes resources.  This aspect
+   needs to be assessed carefully, considering the characteristics of
+   each specific CNN.
+
+   A TCP implementation may also be able to send "keep-alive" segments
+   to test a TCP connection.  According to [RFC1122], keep-alives are an
+   optional TCP mechanism that is turned off by default, i.e., an
+   application must explicitly enable it for a TCP connection.  The
+   interval between keep-alive messages must be configurable, and it
+   must default to no less than two hours.  With this large timeout, TCP
+   keep-alive messages might not always be useful to avoid deletion of
+   filter state records in some middleboxes.  However, sending TCP keep-
+   alive probes more frequently risks draining power on energy-
+   constrained devices.
+
+5.  Security Considerations
+
+   Best current practices for securing TCP and TCP-based communication
+   also applies to CNN.  As an example, use of TLS [RFC8446] is strongly
+   recommended if it is applicable.  However, note that TLS protects
+   only the contents of the data segments.
+
+   There are TCP options that can actually protect the transport layer.
+   One example is the TCP Authentication Option (TCP-AO) [RFC5925].
+   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 performance when using TCP-AO, considering
+   the characteristics (in terms of energy, bandwidth, and computational
+   power) of the environment where TCP will be used.
+
+   For the mechanisms discussed in this document, the corresponding
+   considerations apply.  For instance, if TFO is used, the security
+   considerations of RFC 7413 [RFC7413] apply.
+
+   Constrained devices are expected to support smaller TCP window sizes
+   than 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 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 [SHREW], whereby one or more sources
+   generate a packet spike targeted to coincide with consecutive 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
+   blocking by routers able to detect shrew attacks based on their
+   traffic pattern.
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122,
+              DOI 10.17487/RFC1122, October 1989,
+              <https://www.rfc-editor.org/info/rfc1122>.
+
+   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
+              Selective Acknowledgment Options", RFC 2018,
+              DOI 10.17487/RFC2018, October 1996,
+              <https://www.rfc-editor.org/info/rfc2018>.
+
+   [RFC3042]  Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
+              TCP's Loss Recovery Using Limited Transmit", RFC 3042,
+              DOI 10.17487/RFC3042, January 2001,
+              <https://www.rfc-editor.org/info/rfc3042>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
+              <https://www.rfc-editor.org/info/rfc5681>.
+
+   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
+              "Computing TCP's Retransmission Timer", RFC 6298,
+              DOI 10.17487/RFC6298, June 2011,
+              <https://www.rfc-editor.org/info/rfc6298>.
+
+   [RFC6691]  Borman, D., "TCP Options and Maximum Segment Size (MSS)",
+              RFC 6691, DOI 10.17487/RFC6691, July 2012,
+              <https://www.rfc-editor.org/info/rfc6691>.
+
+   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
+              "Increasing TCP's Initial Window", RFC 6928,
+              DOI 10.17487/RFC6928, April 2013,
+              <https://www.rfc-editor.org/info/rfc6928>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
+              Scheffenegger, Ed., "TCP Extensions for High Performance",
+              RFC 7323, DOI 10.17487/RFC7323, September 2014,
+              <https://www.rfc-editor.org/info/rfc7323>.
+
+   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <https://www.rfc-editor.org/info/rfc7413>.
+
+   [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
+              Recommendations Regarding Active Queue Management",
+              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
+              <https://www.rfc-editor.org/info/rfc7567>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+7.2.  Informative References
+
+   [6LO-WLANAH]
+              Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6
+              over 802.11ah", Work in Progress, Internet-Draft, draft-
+              delcarpio-6lo-wlanah-01, 19 October 2015,
+              <https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-
+              01>.
+
+   [Commag]   Betzler, A., Gomez, C., Demirkol, I., and J. Paradells,
+              "CoAP Congestion Control for the Internet of Things", IEEE
+              Communications Magazine, Vol. 54, Issue 7, pp. 154-160,
+              DOI 10.1109/MCOM.2016.7509394, July 2016,
+              <https://doi.org/10.1109/MCOM.2016.7509394>.
+
+   [CORE-FASOR]
+              Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast-
+              Slow Retransmission Timeout and Congestion Control
+              Algorithm for CoAP", Work in Progress, Internet-Draft,
+              draft-ietf-core-fasor-01, 19 October 2020,
+              <https://tools.ietf.org/html/draft-ietf-core-fasor-01>.
+
+   [Dunk]     Dunkels, A., "Full TCP/IP for 8-Bit Architectures",
+              MobiSys '03, pp. 85-98, DOI 10.1145/1066116.106611, May
+              2003, <https://doi.org/10.1145/1066116.106611>.
+
+   [ETEN]     Krishnan, R., Sterbenz, J., Eddy, W., and C. Partridge,
+              "Explicit transport error notification (ETEN) for error-
+              prone wireless and satellite networks", Computer Networks,
+              DOI 10.1016/j.comnet.2004.06.012, June 2004,
+              <https://doi.org/10.1016/j.comnet.2004.06.012>.
+
+   [GNRC]     Lenders, M., Kietzmann, P., Hahm, O., Petersen, H.,
+              Gündoğa, C., Baccelli, E., Schleiser, K., Schmidt, T., and
+              M. Wählisch, "Connecting the World of Embedded Mobiles:
+              The RIOT Approach to Ubiquitous Networking for the IoT",
+              arXiv:1801.02833v1 [cs.NI], January 2018.
+
+   [HomeGateway]
+              Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
+              Sarolahti, P., and M. Kojo, "An Experimental Study of Home
+              Gateway Characteristics", Proceedings of the 10th ACM
+              SIGCOMM conference on Internet measurement, pp. 260-266,
+              DOI 10.1145/1879141.1879174, November 2010,
+              <https://doi.org/10.1145/1879141.1879174>.
+
+   [IntComp]  Gomez, C., Arcia-Moret, A., and J. Crowcroft, "TCP in the
+              Internet of Things: from Ostracism to Prominence", IEEE
+              Internet Computing, Vol. 22, Issue 1, pp. 29-41,
+              DOI 10.1109/MIC.2018.112102200, January 2018,
+              <https://doi.org/10.1109/MIC.2018.112102200>.
+
+   [MQTT]     ISO/IEC, "Information technology -- Message Queuing
+              Telemetry Transport (MQTT) v3.1.1", ISO/IEC 20922:2016,
+              June 2016.
+
+   [RFC2757]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
+              Vaidya, "Long Thin Networks", RFC 2757,
+              DOI 10.17487/RFC2757, January 2000,
+              <https://www.rfc-editor.org/info/rfc2757>.
+
+   [RFC2884]  Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
+              Explicit Congestion Notification (ECN) in IP Networks",
+              RFC 2884, DOI 10.17487/RFC2884, July 2000,
+              <https://www.rfc-editor.org/info/rfc2884>.
+
+   [RFC3481]  Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov,
+              A., and F. Khafizov, "TCP over Second (2.5G) and Third
+              (3G) Generation Wireless Networks", BCP 71, RFC 3481,
+              DOI 10.17487/RFC3481, February 2003,
+              <https://www.rfc-editor.org/info/rfc3481>.
+
+   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
+              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
+              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
+              RFC 3819, DOI 10.17487/RFC3819, July 2004,
+              <https://www.rfc-editor.org/info/rfc3819>.
+
+   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+              "Transmission of IPv6 Packets over IEEE 802.15.4
+              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
+              <https://www.rfc-editor.org/info/rfc4944>.
+
+   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, DOI 10.17487/RFC5382, October 2008,
+              <https://www.rfc-editor.org/info/rfc5382>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6077]  Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
+              Briscoe, "Open Research Issues in Internet Congestion
+              Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
+              <https://www.rfc-editor.org/info/rfc6077>.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+              March 2011, <https://www.rfc-editor.org/info/rfc6120>.
+
+   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
+              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
+              DOI 10.17487/RFC6282, September 2011,
+              <https://www.rfc-editor.org/info/rfc6282>.
+
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550,
+              DOI 10.17487/RFC6550, March 2012,
+              <https://www.rfc-editor.org/info/rfc6550>.
+
+   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
+              Statement and Requirements for IPv6 over Low-Power
+              Wireless Personal Area Network (6LoWPAN) Routing",
+              RFC 6606, DOI 10.17487/RFC6606, May 2012,
+              <https://www.rfc-editor.org/info/rfc6606>.
+
+   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
+              Bormann, "Neighbor Discovery Optimization for IPv6 over
+              Low-Power Wireless Personal Area Networks (6LoWPANs)",
+              RFC 6775, DOI 10.17487/RFC6775, November 2012,
+              <https://www.rfc-editor.org/info/rfc6775>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <https://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC7414]  Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
+              Zimmermann, "A Roadmap for Transmission Control Protocol
+              (TCP) Specification Documents", RFC 7414,
+              DOI 10.17487/RFC7414, February 2015,
+              <https://www.rfc-editor.org/info/rfc7414>.
+
+   [RFC7428]  Brandt, A. and J. Buron, "Transmission of IPv6 Packets
+              over ITU-T G.9959 Networks", RFC 7428,
+              DOI 10.17487/RFC7428, February 2015,
+              <https://www.rfc-editor.org/info/rfc7428>.
+
+   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <https://www.rfc-editor.org/info/rfc7540>.
+
+   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
+              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
+              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
+              <https://www.rfc-editor.org/info/rfc7668>.
+
+   [RFC8087]  Fairhurst, G. and M. Welzl, "The Benefits of Using
+              Explicit Congestion Notification (ECN)", RFC 8087,
+              DOI 10.17487/RFC8087, March 2017,
+              <https://www.rfc-editor.org/info/rfc8087>.
+
+   [RFC8105]  Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
+              M., and D. Barthel, "Transmission of IPv6 Packets over
+              Digital Enhanced Cordless Telecommunications (DECT) Ultra
+              Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
+              2017, <https://www.rfc-editor.org/info/rfc8105>.
+
+   [RFC8163]  Lynn, K., Ed., Martocci, J., Neilson, C., and S.
+              Donaldson, "Transmission of IPv6 over Master-Slave/Token-
+              Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
+              May 2017, <https://www.rfc-editor.org/info/rfc8163>.
+
+   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
+              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
+              DOI 10.17487/RFC8201, July 2017,
+              <https://www.rfc-editor.org/info/rfc8201>.
+
+   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
+              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
+              Application Protocol) over TCP, TLS, and WebSockets",
+              RFC 8323, DOI 10.17487/RFC8323, February 2018,
+              <https://www.rfc-editor.org/info/rfc8323>.
+
+   [RFC8352]  Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed.,
+              "Energy-Efficient Features of Internet of Things
+              Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018,
+              <https://www.rfc-editor.org/info/rfc8352>.
+
+   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
+              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
+              <https://www.rfc-editor.org/info/rfc8376>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8900]  Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
+              and F. Gont, "IP Fragmentation Considered Fragile",
+              BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
+              <https://www.rfc-editor.org/info/rfc8900>.
+
+   [RFC8931]  Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
+              Area Network (6LoWPAN) Selective Fragment Recovery",
+              RFC 8931, DOI 10.17487/RFC8931, November 2020,
+              <https://www.rfc-editor.org/info/rfc8931>.
+
+   [RFC8961]  Allman, M., "Requirements for Time-Based Loss Detection",
+              BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020,
+              <https://www.rfc-editor.org/info/rfc8961>.
+
+   [RIOT]     Baccelli, E., Gündoğa, C., Hahm, O., Kietzmann, P.,
+              Lenders, M., Petersen, H., Schleiser, K., Schmidt, T., and
+              M. Wählisch, "RIOT: An Open Source Operating System for
+              Low-End Embedded Devices in the IoT", IEEE Internet of
+              Things Journal, Vol. 5, Issue 6,
+              DOI 10.1109/JIOT.2018.2815038, March 2018,
+              <https://doi.org/10.1109/JIOT.2018.2815038>.
+
+   [SHREW]    Nyrhinen, A. and E. Knightly, "Low-Rate TCP-Targeted
+              Denial of Service Attacks (The Shrew vs. the Mice and
+              Elephants)", SIGCOMM'03, DOI 10.1145/863955.863966, August
+              2003, <https://doi.org/10.1145/863955.863966>.
+
+   [TCPM-ECN] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
+              Congestion Notification (ECN) to TCP Control Packets",
+              Work in Progress, Internet-Draft, draft-ietf-tcpm-
+              generalized-ecn-07, 16 February 2021,
+              <https://tools.ietf.org/html/draft-ietf-tcpm-generalized-
+              ecn-07>.
+
+Appendix A.  TCP Implementations for Constrained Devices
+
+   This section overviews the main features of TCP implementations for
+   constrained devices.  The survey is limited to open-source stacks
+   with a small footprint.  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 implement TCP.  On the other
+   hand, please be aware that this Annex is based on information
+   available as of the writing.
+
+A.1.  uIP
+
+   uIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers,
+   which 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 [Dunk].  Later versions of uIP
+   implement IPv6 as well.
+
+   uIP uses the same global buffer for both incoming and outgoing
+   traffic, 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.
+
+   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 allows for the avoidance of sliding window
+   operations, which use 32-bit arithmetic extensively and are expensive
+   on 8-bit CPUs.
+
+   Contiki uses the "split hack" technique (see Section 3.2.3) to avoid
+   Delayed ACKs for senders using a single segment.
+
+   The code size of the TCP implementation in Contiki-NG has been
+   measured to be 3.2 kB on CC2538DK, cross-compiling on Linux.
+
+A.2.  lwIP
+
+   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 [Dunk].  Both IPv4 and
+   IPv6 are supported in lwIP since v2.0.0.
+
+   In contrast with uIP, lwIP decouples applications from the network
+   stack. lwIP supports a TCP transmission window greater than a single
+   segment, as well as the buffering of incoming and outgoing data.
+   Other implemented mechanisms comprise slow start, congestion
+   avoidance, fast retransmit, and fast recovery.  SACK and Window Scale
+   support has been recently added to lwIP.
+
+A.3.  RIOT
+
+   The RIOT TCP implementation (called "GNRC TCP") has been designed for
+   Class 1 devices [RFC7228].  The main target platforms 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, retransmission is also handled by GNRC TCP.  For
+   simplicity, GNRC TCP uses a single-MSS implementation.  The
+   application programmer does not need to know anything about the TCP
+   internals; therefore, GNRC TCP can be seen as a user-friendly uIP TCP
+   implementation.
+
+   The MSS is set on connections establishment and cannot be changed
+   during connection lifetime.  GNRC TCP allows multiple connections in
+   parallel, but each TCB must be allocated somewhere in the system.  By
+   default, there is only enough memory allocated for a single TCP
+   connection, but it can be increased at compile time if the user needs
+   multiple parallel connections.
+
+   The RIOT TCP implementation offers an optional Portable Operating
+   System Interface (POSIX) socket wrapper that enables POSIX
+   compliance, if needed.
+
+   Further details on RIOT and GNRC can be found in [RIOT] and [GNRC].
+
+A.4.  TinyOS
+
+   TinyOS was important as a platform for early constrained devices.
+   TinyOS has an experimental TCP stack that uses a simple non-blocking
+   library-based implementation of TCP, which provides a subset of the
+   socket interface primitives.  The application is responsible for
+   buffering.  The TCP library does not do any receive-side buffering.
+   Instead, it will immediately dispatch new, in-order data to the
+   application or otherwise drop the segment.  A send buffer is provided
+   by the application.  Multiple TCP connections are possible.
+   Recently, there has been little work on the stack.
+
+A.5.  FreeRTOS
+
+   FreeRTOS is a real-time operating system kernel for embedded devices
+   that is supported by 16- and 32-bit microprocessors.  Its TCP
+   implementation is based on multiple-segment window size, although a
+   "Tiny-TCP" option, which is a single-MSS variant, can be enabled.
+   Delayed ACKs are supported, with a 20 ms Delayed ACK timer as a
+   technique intended "to gain performance".
+
+A.6.  uC/OS
+
+   uC/OS is a real-time operating system kernel for embedded devices,
+   which is maintained by Micrium.  uC/OS is intended for 8-, 16-, and
+   32-bit microprocessors.  The uC/OS TCP implementation supports a
+   multiple-segment window size.
+
+A.7.  Summary
+
+   None of the implementations considered in this Annex support ECN or
+   TFO.
+
+   +==========+=====+======+==========+======+========+==========+=====+
+   |          | uIP |lwIP  | lwIP 2.1 | RIOT | TinyOS | FreeRTOS |uC/OS|
+   |          |     |orig  |          |      |        |          |     |
+   +==========+=====+======+==========+======+========+==========+=====+
+   | Code     |  <5 |~9 to |    38    |  <7  |  N/A   |   <9.2   | N/A |
+   | Size     |     | ~14  |          |      |        |          |     |
+   | (kB)     |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   | Memory   | (a) | (T1) |   (T4)   | (T3) |  N/A   |   (T2)   | N/A |
+   +==========+=====+======+==========+======+========+==========+=====+
+   | TCP                                                               |
+   | Features                                                          |
+   +==========+=====+======+==========+======+========+==========+=====+
+   |  Single- | Yes |  No  |    No    | Yes  |   No   |    No    |  No |
+   |    Segm. |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |     Slow |  No | Yes  |   Yes    |  No  |  Yes   |    No    | Yes |
+   |    start |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |     Fast |  No | Yes  |   Yes    |  No  |  Yes   |    No    | Yes |
+   | rec/retx |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |    Keep- |  No |  No  |   Yes    |  No  |   No   |   Yes    | Yes |
+   |    alive |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |     Win. |  No |  No  |   Yes    |  No  |   No   |   Yes    |  No |
+   |    Scale |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |      TCP |  No |  No  |   Yes    |  No  |   No   |   Yes    |  No |
+   |  timest. |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |     SACK |  No |  No  |   Yes    |  No  |   No   |   Yes    |  No |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |     Del. |  No | Yes  |   Yes    |  No  |   No   |   Yes    | Yes |
+   |     ACKs |     |      |          |      |        |          |     |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |   Socket |  No |  No  | Optional | (I)  | Subset |   Yes    | Yes |
+   +----------+-----+------+----------+------+--------+----------+-----+
+   |  Concur. | Yes | Yes  |   Yes    | Yes  |  Yes   |   Yes    | Yes |
+   |    Conn. |     |      |          |      |        |          |     |
+   +==========+=====+======+==========+======+========+==========+=====+
+   | TLS supp |  No |  No  |   Yes    | Yes  |  Yes   |   Yes    | Yes |
+   | orted    |     |      |          |      |        |          |     |
+   +==========+=====+======+==========+======+========+==========+=====+
+
+       Table 1: Summary of TCP Features for Different Lightweight TCP
+                              Implementations
+
+   Legend:
+
+   (T1):   TCP-only, on x86 and AVR platforms
+
+   (T2):   TCP-only, on ARM Cortex-M platform
+
+   (T3):   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)
+
+   (T4):   TCP-only, on CC2538DK, cross-compiling on Linux
+
+   (a):    Includes IP, ICMP, and TCP on x86 and AVR platforms.  The
+           Contiki-NG TCP implementation has a code size of 3.2 kB on
+           CC2538DK, cross-compiling on Linux
+
+   (I):    Optional POSIX socket wrapper that enables POSIX compliance
+           if needed
+
+   Mult.:  Multiple
+
+   N/A:    Not Available
+
+Acknowledgments
+
+   The work of Carles Gomez has been funded in part by the Spanish
+   Government (Ministerio de Educacion, Cultura y Deporte) through Jose
+   Castillejo grants CAS15/00336 and CAS18/00170; the European Regional
+   Development Fund (ERDF); the Spanish Government through projects
+   TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, and UE; and the
+   Generalitat de Catalunya Grant 2017 SGR 376.  Part of his
+   contribution to this work has been carried out during his stays as a
+   visiting scholar at the Computer Laboratory of the University of
+   Cambridge.
+
+   The authors appreciate the feedback received for this document.  The
+   following folks provided comments that helped improve the document:
+   Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keränen, Abhijan
+   Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred
+   Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes
+   Tschofenig, David Black, Ilpo Jarvinen, Emmanuel Baccelli, Stuart
+   Cheshire, Gorry Fairhurst, Ingemar Johansson, Ted Lemon, and Michael
+   Tüxen.  Simon Brummer provided details and kindly performed Random
+   Access Memory (RAM) and Read-Only Memory (ROM) usage measurements 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 lwIP 2.1.2 TCP implementations.
+   He also provided details on the uIP TCP implementation.
+
+Authors' Addresses
+
+   Carles Gomez
+   UPC
+   C/Esteve Terradas, 7
+   08860 Castelldefels
+   Spain
+
+   Email: carlesgo@entel.upc.edu
+
+
+   Jon Crowcroft
+   University of Cambridge
+   JJ Thomson Avenue
+   Cambridge
+   CB3 0FD
+   United Kingdom
+
+   Email: jon.crowcroft@cl.cam.ac.uk
+
+
+   Michael Scharf
+   Hochschule Esslingen
+   University of Applied Sciences
+   Flandernstr. 101
+   73732 Esslingen am Neckar
+   Germany
+
+   Email: michael.scharf@hs-esslingen.de