<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!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.org/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 --> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" 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)" --> number="9006" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.5.0 -->

  <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">
    TCP Usage Guidance in the Internet of Things (IoT)
    </title>

    <!--
    <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 -->
    <seriesInfo name="RFC" value="9006"/>

    <author fullname="Carles Gomez" initials="C.G" initials="C." surname="Gomez">
      <organization>UPC</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <city>Castelldefels</city>
          <region/>
          <code>08860</code>
          <country>Spain</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>carlesgo@entel.upc.edu</email>
        <uri/>
      </address>
    </author>
    <author fullname="Jon Crowcroft" initials="J.C" initials="J." surname="Crowcroft">
      <organization>University of Cambridge</organization>
      <address>
        <postal>
          <street>JJ Thomson Avenue</street>
          <city>Cambridge</city>

          <region>CB3 0FD</region>

          <code/>
          <code>CB3 0FD</code>
          <country>United Kingdom</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>jon.crowcroft@cl.cam.ac.uk</email>
        <uri/>
      </address>
    </author>
    <author fullname="Michael Scharf" initials="M.S" initials="M." surname="Scharf">
      <organization>Hochschule Esslingen</organization>
      <address>
        <postal>
	  <street> University of Applied Sciences</street>
          <street>Flandernstr. 101</street>

          <city>Esslingen</city>
          <city>Esslingen am Neckar</city>
          <region/>
          <code>73732</code>
          <country>Germany</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>michael.scharf@hs-esslingen.de</email>
        <uri/>
      </address>
    </author>

    <!-- uri and facsimile elements may also be added -->

    <date month="October" year="2020"/>

    <!-- If the month and year are both specified month="March" year="2021"/>

    <area>APP</area>
    <workgroup>LWIG Working Group</workgroup>

    <abstract>
      <t> This document provides guidance on how to implement and are the current ones, xml2rfc will fill
         in the current day for you. If only use the current year is specified, xml2rfc will fill Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of 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 specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>APP</area>

    <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>
      <t> 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 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 tradeoffs. trade-offs. The objective is to help embedded developers with decisions on which TCP features to use.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction "> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Internet Protocol suite is being used for connecting Constrained-Node Networks (CNNs) to the Internet, enabling the so-called Internet of Things (IoT) <xref target="RFC7228"/>. target="RFC7228" format="default"/>. 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. (see, e.g., <xref target="RFC8352"/>). target="RFC8352" format="default"/>).
         New IETF protocol stack components include the IPv6 over Low-power Low-Power Wireless Personal Area Networks (6LoWPAN) (6LoWPANs) adaptation layer
         <xref target="RFC4944"/><xref target="RFC6282"/><xref target="RFC6775"/>, target="RFC4944" format="default"/><xref target="RFC6282" format="default"/><xref target="RFC6775" format="default"/>, the IPv6 Routing Protocol for Low-power Low-Power and lossy networks Lossy Networks (RPL) routing protocol
         <xref target="RFC6550"/>, target="RFC6550" format="default"/>, and the Constrained Application Protocol (CoAP) <xref target="RFC7252"/>.</t> target="RFC7252" format="default"/>.</t>
      <t>As of the this writing, the main current transport layer 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. (e.g., a high complexity, connection-oriented approach incompatibility with radio duty-cycling, duty-cycling and spurious congestion control activation
         in wireless links) are not valid, can be solved, or are also found in well accepted well-accepted IoT end-to-end reliability mechanisms (see <xref target="IntComp"/> for a detailed analysis). analysis in <xref target="IntComp" format="default"/>).
      </t>
      <t>At the application layer, CoAP was developed over UDP <xref target="RFC7252"/>. target="RFC7252" format="default"/>.  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  <xref target="RFC8323"/>.</t> target="RFC8323" format="default"/>.</t>

      <t>Other application layer 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  <xref target="RFC7230"/> target="RFC7230" format="default"/> <xref target="RFC7540"/>, target="RFC7540" format="default"/>, and the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/>. target="RFC6120" format="default"/>.  TCP is also used by non-IETF
   application-layer protocols in the IoT space such as the Message Queuing Telemetry Transport (MQTT) <xref target="MQTT"/> target="MQTT" format="default"/> and its
      lightweight variants.</t>

      <t>TCP is a sophisticated transport protocol that includes optional
   functionality (e.g. (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.
      </t>
      <t>This document provides guidance on how to implement and configure TCP,
   as well as TCP
 and guidance on how applications should use TCP is advisable to be used by applications, 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.</t>
      <t>This document assumes that the reader is familiar with TCP. A comprehensive survey of the TCP standards can be found in RFC 7414 <xref target="RFC7414"/>. target="RFC7414" format="default"/>. Similar guidance regarding the use of TCP in special environments has been published before, e.g., for cellular wireless networks <xref target="RFC3481"/>. target="RFC3481" format="default"/>.
      </t>
    </section>
    <section title="Characteristics numbered="true" toc="default">
      <name>Characteristics of CNNs relevant Relevant for TCP"> TCP</name>
      <section title="Network numbered="true" toc="default">
        <name>Network and link properties"> Link Properties</name>
        <t>CNNs are defined in <xref target="RFC7228"/> target="RFC7228" format="default"/> 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 <xref target="RFC7228"/>. target="RFC7228" format="default"/>.
         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 devices <xref target="RFC8352"/>, as well as target="RFC8352" format="default"/> and the minimization of the number of messages transmitted/received (and their size).</t>
        <t><xref target="RFC7228"/> target="RFC7228" format="default"/> lists typical network constraints in CNN, 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. CNN CNNs may use wireless or wired technologies (e.g., Power Line Communication), and the transmission rates are typically low (e.g. (e.g., below 1 Mbps).</t>
        <t>For use of TCP, one challenge is that not all technologies in a CNN may be aligned with typical Internet subnetwork design principles <xref target="RFC3819"/>. target="RFC3819" format="default"/>. For instance, constrained nodes often use physical/link layer 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 <xref target="RFC6077"/>. target="RFC6077" format="default"/>.
        </t>
      </section>
      <section title="Usage scenarios"> numbered="true" toc="default">
        <name>Usage Scenarios</name>
        <t>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 <xref target="RFC6606"/>. target="RFC6606" format="default"/>.
        </t>
        <t>In constrained environments, there can be different types of devices <xref target="RFC7228"/>. target="RFC7228" format="default"/>.
      For example, there can be devices with a single combined send/receive buffer, devices with a separate send and receive buffer, or devices with a pool
      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>
      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 has to traverse a middlebox (e.g. (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, to have a high
   amount of memory and processing power, and to be connected to a
   resource-rich network.
        </t>
        <t>
   Assuming that a majority of constrained devices will correspond to
   sensor nodes, the amount of data traffic sent by constrained devices
   (e.g.
   (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) actuators), and relatively infrequent
   firmware/software updates.

        </t>
        <figure title="TCP communication anchor="fig_scenario">
          <name>TCP Communication between a constrained device Constrained Device and an
    unconstrained device, traversing Unconstrained Device, Traversing a middlebox."
                anchor="fig_scenario">
        <artwork><![CDATA[ Middlebox</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                                   +---------------+
        o     o <-------- TCP communication -----> |               |
       o     o                                     |               |
          o     o                                  | Unconstrained |
    o        o              +-----------+          |    device     |
        o     o   o  ------ | Middlebox |  ------- |               |
         o   o              +-----------+          |  (e.g. (e.g., cloud) |
       o    o  o                                   |               |
                                                   +---------------+
   constrained
   Constrained devices

        ]]></artwork></figure>

      </t>
        ]]></artwork>
        </figure>
      </section>
      <section title="Communication numbered="true" toc="default">
        <name>Communication and traffic patterns"> Traffic Patterns</name>
        <t>IoT applications are characterized by a number of different communication patterns. The following non-comprehensive list explains some typical examples:</t>

     <t><list style="symbols">

       <t>Unidirectional transfers: An
        <dl spacing="normal">
          <dt>Unidirectional transfers:</dt><dd>An IoT device (e.g. (e.g., a sensor) can send (repeatedly) send updates to the other endpoint. There is not always a need for an application response back to the IoT device. </t>

       <t>Request-response patterns: An </dd>
          <dt>Request-response patterns:</dt><dd>An IoT device receiving a request from the other endpoint, which triggers a response from the IoT device.</t>

       <t>Bulk device.</dd>
          <dt>Bulk data transfers: A transfers:</dt><dd>A typical example for a long file transfer would be an IoT device firmware update.</t>

     </list></t> update.</dd>
        </dl>
        <t>A typical communication pattern is that a constrained device communicates with an unconstrained device (cf. <xref target="fig_scenario"/>). (cf.&nbsp;<xref target="fig_scenario" format="default"/>). But it is also possible that constrained devices communicate amongst themselves.</t>
      </section>
    </section>
    <section title="TCP implementation numbered="true" toc="default">
      <name>TCP Implementation and configuration Configuration in CNNs"> 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>
      <section title="Addressing path properties"> numbered="true" toc="default">
        <name>Addressing Path Properties</name>
        <section title="Maximum numbered="true" toc="default">
          <name>Maximum Segment Size (MSS)"> (MSS)</name>
          <t>Assuming that IPv6 is used, and for the sake of lightweight implementation and operation, unless applications
          require handling large data units (i.e. (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 <xref target="RFC8201"/>. target="RFC8201" format="default"/>.
          In addition, an IP datagram size of 1280 bytes avoids incurring IPv6-layer fragmentation <xref target="RFC8900"/>. target="RFC8900" format="default"/>.
          </t>

          <t>An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than to 1220 bytes. bytes or less.  Note that
   it is already a requirement that 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 <xref target="RFC6691"/>. target="RFC6691" format="default"/>.  Therefore, it is not required to advertise an MSS smaller than 1220 bytes in order to accommodate TCP options.
          </t>
          <t>Note that setting the MTU to 1280 bytes is possible for link layer link-layer technologies in the CNN space, even if some of them are characterized by a short data unit payload size, e.g. 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 <xref target="RFC8200"/>, target="RFC8200" format="default"/>, while IEEE 802.15.4 lacked lacks fragmentation mechanisms.
          6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes <xref target="RFC4944"/>. target="RFC4944" format="default"/>. Other technologies, such as Bluetooth LE low energy <xref target="RFC7668"/>, target="RFC7668" format="default"/>,
          ITU-T G.9959 <xref target="RFC7428"/> target="RFC7428" format="default"/>, or DECT-ULE Digital Enhanced Cordless
            Telecommunications (DECT) Ultra Low Energy (ULE) <xref target="RFC8105"/>, target="RFC8105" format="default"/>, also use 6LoWPAN-based adaptation layers in order to enable
          IPv6 support. These technologies do support link layer link-layer fragmentation.  By exploiting this
          functionality, the adaptation layers that enable IPv6 over such technologies also define an MTU of 1280 bytes.
          </t>
          <t>On the other hand, there exist technologies also used in the CNN space, such as Master Slave (MS) / Token Passing (TP) <xref target="RFC8163"/>, target="RFC8163" format="default"/>,
             Narrowband IoT (NB-IoT) <xref target="RFC8376"/> target="RFC8376" format="default"/>, or IEEE 802.11ah <xref target="I-D.delcarpio-6lo-wlanah"/>, target="I-D.delcarpio-6lo-wlanah" format="default"/>,
             that do not suffer the same degree of frame size limitations as the technologies mentioned above. The
	     It is recommended that the MTU for MS/TP is recommended to be 1500 bytes <xref target="RFC8163"/>, 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.
          </t>
          <t> 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 <xref target="RFC4944"/> target="RFC4944" format="default"/> does not offer reliable fragment delivery, fragment recovery functionality for 6LoWPAN or 6Lo environments
              is being
              has been standardized as of the writing <xref target="I-D.ietf-6lo-fragment-recovery"/>. target="RFC8931" format="default"/>.
          </t>
        </section>
        <section title="Explicit Congestion Notification (ECN)">

          <t>Explicit numbered="true" toc="default">
          <name>Explicit Congestion Notification (ECN) (ECN)</name>
          <t>ECN <xref target="RFC3168"/> ECN target="RFC3168" format="default"/> allows a router to signal
             in the IP header of a packet that congestion is arising, rising, for example 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 ACK. Acknowledgment (ACK).  The sender triggers congestion
             control measures as if a packet loss had happened.
          </t>

          <t>The document
          <t>RFC 8087 <xref target="RFC8087"/> target="RFC8087" format="default"/> 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 signalled signaled without incurring packet drops (which will lead to retransmissions and consumption of limited resources such as energy and bandwidth).
          </t>
          <t>ECN can further reduce packet losses since congestion control
   measures can be applied earlier <xref target="RFC2884"/>. target="RFC2884" format="default"/>.  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 no three duplicate ACKs).  Any retransmission timeout slows
   down the data transfer significantly.  In addition, if the
   constrained device uses power saving power-saving techniques, a retransmission
   timeout will incur a wake-up action, in contrast to ACK clock-
   triggered
   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 (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 at that
  moment its
  sending rate from 1 segment per Round Trip 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 ACK, the TCP sender resumes the normal
  ACK-clocked transmission of segments <xref target="RFC3168"/>. target="RFC3168" format="default"/>.
          </t>
          <t>ECN can be
   incrementally deployed in the Internet.  Guidance on configuration and usage of ECN is provided in RFC 7567 <xref target="RFC7567"/>. target="RFC7567" format="default"/>.
   Given the benefits, more and more TCP stacks in the Internet support ECN, and it specifically makes sense to specifically leverage ECN in controlled
   environments such as CNNs. As of the this writing, there is on-going ongoing work to extend the types of TCP packets that are ECN-capable, ECN capable, including pure ACKs <xref target="I-D.ietf-tcpm-generalized-ecn"/>. target="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.
          </t>
        </section>
        <section title="Explicit loss notifications"> numbered="true" toc="default">
          <name>Explicit Loss Notifications</name>
          <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 order to avoid activation of congestion control mechanisms <xref target="ETEN"/> target="ETEN" format="default"/> <xref target="RFC2757"/>. target="RFC2757" format="default"/>. 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.
          </t>
        </section>
      </section>
      <section title="TCP guidance numbered="true" toc="default">
        <name>TCP Guidance for single-MSS stacks"> Single-MSS Stacks</name>
        <t>This section discusses TCP stacks that allow transferring a single MSS. More general guidance is provided in <xref target="Beyond1MSS"/>. target="Beyond1MSS" format="default"/>.
        </t>
        <section title="Single-MSS stacks - benefits numbered="true" toc="default" anchor="single_MSS_stacks_benefits">
          <name>Single-MSS Stacks -- Benefits and issues"> Issues</name>
          <t>   A TCP stack can reduce the memory requirements by advertising a TCP window size of one MSS, 1 MSS and also transmit transmit, at most one 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 one 1 MSS can significantly affect
                performance.  A stop-and-wait operation results in low throughput for transfers that exceed the length of one 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 require requires a larger window size, size; see Section 3.3.1). <xref target="loss_recovery_flow" format="default"/>).
          </t>
          <t>If CoAP is used over TCP with the default setting for NSTART in RFC 7252 <xref target="RFC7252"/>, target="RFC7252" format="default"/>, 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 one 1 MSS may be sufficient, as long as the
             CoAP message size does not exceed one 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.
          </t>
        </section>
        <section title="TCP options numbered="true" toc="default">
          <name>TCP Options for single-MSS stacks"> Single-MSS Stacks</name>
          <t>A TCP implementation needs to support, at a minimum, TCP options 2, 1 1, and 0. These are, respectively, the Maximum Segment Size (MSS) MSS option,
             the No-Operation option, and the End Of Option List marker <xref target="RFC0793"/>. target="RFC0793" format="default"/>. 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.
          </t>
          <t>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 Scale <xref target="RFC7323"/>, target="RFC7323" format="default"/>, TCP Timestamps <xref target="RFC7323"/>, target="RFC7323" format="default"/>, Selective Acknowledgments Acknowledgment (SACK) <xref target="RFC2018" format="default"/>, and SACK-Permitted <xref target="RFC2018"/>. Also target="RFC2018" format="default"/>. Also, other TCP options may not be required on a constrained device with a very lightweight implementation. With regard to
             the Window scale Scale option, note that it is only useful if a window size greater than 64 kB is needed.
          </t>
          <t>
	     Note that a TCP sender can benefit from the TCP Timestamps option <xref target="RFC7323"/> target="RFC7323" format="default"/> in detecting spurious RTOs. The latter are quite likely to occur
             in CNN scenarios due to a number of reasons (e.g. (e.g., route changes in a multihop scenario, link layer link-layer retries, etc.). The header overhead incurred
             by the Timestamps option (of up to 12 bytes) needs to be taken into account.
          </t>
        </section>
        <section title="Delayed anchor="DelAck" numbered="true" toc="default">
          <name>Delayed Acknowledgments for single-MSS stacks" anchor="DelAck"> Single-MSS Stacks</name>
          <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 general, usefulness of Delayed ACKs depends heavily on the usage
             scenario (see Section 3.3.2). <xref target="delayed_ACKs" format="default"/>).  There can be interactions with single-MSS stacks.
          </t>
          <t>When traffic is unidirectional, if the sender can send at most one 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], <xref target="RFC5681" format="default"/>, 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 standard-compliant TCP receiver may immediately acknowledge the second MSS of data, which
             can improve throughput. However, this 'split hack' "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'. "split hack".
          </t>
          <t>Similar issues may happen when the sender uses the Nagle algorithm, since the sender may need to wait for an unnecessarily delayed 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.
          </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 payload.
             Disabling Delayed ACKs at the request sender allows an immediate ACK for the data segment carrying the response.
          </t>

<!-- Comment from Rahul:
          A single MSS implies max one in-flight segment ... While such a mechanism sure will help reduce implementation complexity and the buffer requirement on the sender, but it has a major problem with delayed ACKs mechanism on the receiver. There is a hack (http://contiki.sourceforge.net/docs/2.6/a01696.html) implemented in UIP which circumvents this issue.
-->

        </section>
        <section title="RTO calculation numbered="true" toc="default">
          <name>RTO Calculation for single-MSS stacks"> Single-MSS Stacks</name>
          <t>The RTO calculation is one of the fundamental TCP algorithms <xref target="RFC6298"/>. target="RFC6298" format="default"/>. There is a fundamental trade-off:
             A
             a short, aggressive RTO behavior reduces wait time before retransmissions, but it also increases the probability of spurious timeouts.
             The latter lead 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 and, thus, needlessly delay data delivery.
          </t>
          <t>If a TCP sender uses a very small window size, and it cannot benefit from Fast Retransmit/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 <xref target="I-D.ietf-tcpm-rto-consider"/>. target="RFC8961" format="default"/>.
          </t>
          <t>As an example, adaptive RTO algorithms defined for CoAP over UDP have been found to perform well in CNN scenarios <xref target="Commag"/> target="Commag" format="default"/>
            <xref target="I-D.ietf-core-fasor"/>. target="I-D.ietf-core-fasor" format="default"/>.
          </t>
        </section>
      </section>
      <section title="General recommendations anchor="Beyond1MSS" numbered="true" toc="default">
        <name>General Recommendations for TCP in CNNs" anchor="Beyond1MSS"> CNNs</name>
        <t>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 <xref target="RFC7414"/>.</t> target="RFC7414" format="default"/>.</t>
        <section title="Loss recovery numbered="true" toc="default" anchor="loss_recovery_flow">
          <name>Loss Recovery and congestion/flow control"> Congestion/Flow Control</name>
          <t>Devices that have enough memory to allow a larger (i.e. (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) <xref target="single_MSS_stacks_benefits" format="default"/>) by
             using Fast Retransmit and Fast Recovery <xref target="RFC5681"/>, target="RFC5681" format="default"/>, 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: If 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.
          </t>
          <t>The example in the previous paragraph did not use a further TCP improvement such as Limited Transmit <xref target="RFC3042"/>. target="RFC3042" format="default"/>. 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 3 three segments, plus two additional
             segments for the first two duplicate ACKs. With Limited Transmit, even a cwnd of 2 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.
          </t>
          <t>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 1-MSS 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). retransmissions.)
          </t>
          <section title="Selective numbered="true" toc="default">
            <name>Selective Acknowledgments (SACK)"> (SACKs)</name>
            <t>
   If a device with less severe memory and processing constraints can
   afford advertising a TCP window size of several MSS, 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 4 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.
            </t>
          </section>
        </section>
        <section title="Delayed Acknowledgments"> numbered="true" toc="default" anchor="delayed_ACKs">
          <name>Delayed Acknowledgments</name>
          <t>For certain traffic patterns, Delayed ACKs may have a detrimental effect, as already noted in <xref target="DelAck"/>. target="DelAck" format="default"/>. Advanced TCP stacks may use heuristics to determine the maximum delay for an ACK. For CNNs, the recommendation depends on the expected communication patterns.
          </t>
          <t>When traffic over a CNN is expected to mostly to be unidirectional messages with a size typically up to one 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. 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.
          </t>
          <t>In contrast, Delayed ACKs allow to reduce the for a reduced number of ACKs in bulk transfer type types of traffic, e.g. e.g., for firmware/software updates or for transferring larger data units containing a batch of sensor readings.
          </t>
          <t>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 Delayed ACKs are often configured through system-wide parameters, delayed ACKs 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 Delayed ACKs enabled.
          </t>
        </section>
        <section title="Initial Window">

          <t>RFC 5681 numbered="true" toc="default">
          <name>Initial Window</name>
          <t><xref target="RFC5681" format="default"/> specifies a TCP Initial Window (IW) of roughly 4 kB <xref target="RFC5681"/>. kB. Subsequently, RFC 6928 defined <xref target="RFC6928" format="default"/> defines an experimental new value for the IW,
             which in practice will result in an IW of 10 MSS <xref target="RFC6928"/>. The MSS. Nowadays, the latter is nowadays used in many TCP implementations.
          </t>
          <t>Note that a 10-MSS IW was recommended for resource-rich environments (e.g. (e.g., broadband environments), which are significantly different from CNNs.
             In CNNs, many application layer application-layer data units are relatively small (e.g. (e.g., below one 1 MSS). However, larger objects (e.g. (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, in CNNs the IW needs to be carefully set, set in CNNs, based
             on device and network resource constraints. In many cases, a safe IW setting will be smaller than 10 MSS.
          </t>
        </section>
      </section>
    </section>
    <section title="TCP usage recommendations numbered="true" toc="default">
      <name>TCP Usage Recommendations in CNNs"> CNNs</name>
      <t>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.
      </t>
      <section title="TCP connection initiation"> numbered="true" toc="default">
        <name>TCP Connection Initiation</name>
        <t>In the scenario of a constrained device to an unconstrained device scenario illustrated
        above, a TCP connection is typically initiated by the constrained
        device, in order for this the device to support possible sleep periods to
        save energy.
        </t>
      </section>
      <section title="Number numbered="true" toc="default">
        <name>Number of concurrent connections"> Concurrent Connections</name>
        <t>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. (e.g., further memory overhead for send and receive buffers, etc). etc.).
        </t>
        <t>A careful application design may try to keep the number of concurrent connections as small as possible. A client can can, for instance instance, limit the number of simultaneous open connections that it maintains to a given server. Multiple connections could could, for instance 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 <xref target="RFC7230"/>. target="RFC7230" format="default"/>.
           Furthermore, each new connection will start with a 3-way three-way handshake, therefore increasing message overhead.
        </t>
        <t>Being conservative when opening multiple TCP connections is of particular importance in Constrained-Node Networks.</t>
      </section>
      <section title="TCP connection lifetime" anchor="short_connections"> anchor="short_connections" numbered="true" toc="default">
        <name>TCP Connection Lifetime</name>
        <t>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 <xref target="RFC5382" format="default"/> 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 a 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 <xref target="HomeGateway"/>. target="HomeGateway" format="default"/>. The timeout duration used by a
        middlebox implementation may not be known to the TCP endpoints.</t>

        <t>In CNNs, such middleboxes may e.g. 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 connection-handling strategies, each having pros and cons.</t>

        <t>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, possibly 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, connections instead of maintaining a single long-lived connection.</t>
        <t>
        The message and latency overhead that stems from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) <xref target="RFC7413"/>, target="RFC7413" format="default"/>,
        which is an experimental TCP extension, at the expense of increased implementation complexity and increased TCP Control Block (TCB) TCB size.  TFO allows data to be
        carried in SYN (and SYN-ACK) segments, 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 RFC 7413). <xref target="RFC7413" sectionFormat="of" section="5"/>).
        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 RFC 7413, <xref target="RFC7413" format="default"/>, 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
        Transport Layer Security (TLS) [RFC7413].
        TLS <xref target="RFC7413" format="default"/>. A comprehensive discussion on TFO can be found at in RFC 7413. 7413 <xref target="RFC7413" format="default"/>.
        </t>
        <t>Another approach is to use long-lived TCP connections with
          application-layer heartbeat messages.  Various application protocols
          support such heartbeat messages (e.g. (e.g., CoAP over TCP [RFC8323]). <xref target="RFC8323" format="default"/>).
          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 <xref target="HomeGateway"/>, target="HomeGateway" format="default"/>, and it may be hard to find a proper heartbeat period for application-layer heartbeat messages.
        </t>
        <t>
          One specific advantage of Heartbeat heartbeat messages is that they also allow aliveness liveness checks at the
          application level.  In general, it makes sense to realize
          aliveness
          liveness checks at the highest protocol layer possible that is
          meaningful to the application, in order to maximize the depth of the
          aliveness
          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.
        </t>
        <t>A TCP implementation may also be able to send "keep-alive" segments to test a TCP connection.
        According to <xref target="RFC1122"/>, "keep-alives" 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 for a TCP connection.
        The interval between "keep-alive" keep-alive messages must be configurable 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.
        </t>

        <!-- TODO: Check before publication if there is an official recommendation for "keep-alives" following
        from the discussion https://www.ietf.org/mail-archive/web/tsv-area/current/msg01511.html -->

      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Best current practice practices for securing TCP and TCP-based communication also applies to CNN. As an example, use of Transport Layer Security (TLS) TLS <xref target="RFC8446"/> target="RFC8446" format="default"/> is strongly recommended if it is applicable.
         However, note that TLS protects only the contents of the data segments.
      </t>
      <t>There are TCP options which that can actually protect the transport layer.  One example is the TCP Authentication Option (TCP-AO) <xref target="RFC5925"/>. target="RFC5925" format="default"/>.
         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 bandwidth, and computational power)
         of the environment where TCP will be used.
      </t>
      <t>For the mechanisms discussed in this document, the corresponding considerations apply. For instance, if TFO is used, the security considerations of  RFC 7413 <xref target="RFC7413"/> target="RFC7413" format="default"/> apply.</t>
      <t>Constrained devices are expected to support smaller TCP window sizes than less limited 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 Denial-of-Service (DoS) attack <xref target="shrew"/>, target="SHREW" format="default"/>, 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. </t>
    </section>

 <section anchor="IANA" numbered="true" toc="default">
   <name>IANA Considerations</name>
   <t>This document has no IANA actions.</t>
 </section>

  </middle>

  <back>

<displayreference target="I-D.ietf-core-fasor" to="CORE-FASOR"/>
<displayreference target="I-D.delcarpio-6lo-wlanah" to="6LO-WLANAH"/>
<displayreference target="I-D.ietf-tcpm-generalized-ecn" to="TCPM-ECN"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3042.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6691.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2757.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2884.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3481.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5382.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6077.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7414.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7428.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7668.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8105.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8163.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8352.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/>

<!-- This PI places the pagebreak correctly (before the section title) in the text output. [CS] Note: [draft-delcarpio-6lo-wlanah] The long version of this reference
     was added because it was causing this xml2rfc Error: Failure validating
     reference xml from
     https://datatracker.ietf.org/doc/bibxml3/draft-delcarpio-6lo-wlanah.xml
     Error: XInclude processing failed: could not load
     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 -->

<!-- Possibly a 'Contributors' section ... draft-delcarpio-6lo-wlanah-01; Expired -->

    <section anchor="ACKs" title="Acknowledgments">

      <t>Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through
<reference anchor='I-D.delcarpio-6lo-wlanah'>
<front>
<title>IPv6 over 802.11ah</title>
<author initials='L' surname='Del Carpio Vega' fullname='Luis Felipe Del Carpio Vega'>
    <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>

<!--  [I-D.ietf-core-fasor] IESG state I-D Exists -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-core-fasor.xml"/>

<!--  [I-D.ietf-tcpm-rto-consider] Published as RFC 8961 -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8961.xml"/>

<!--  [I-D.ietf-6lo-fragment-recovery] Published as RFC 8931 -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml"/>

<!-- [I-D.ietf-tcpm-generalized-ecn] IESG state I-D Exists -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tcpm-generalized-ecn.xml"/>

<reference anchor="Commag">
  <front>
    <title>CoAP Congestion Control for the Jose Castillejo grants CAS15/00336
         and and CAS18/00170,
         and by European Regional Development Fund (ERDF) and Internet of Things</title>
    <author initials='A.' surname='Betzler' fullname='August Betzler'>
     <organization />
    </author>
  <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</refcontent>
</reference>

        <reference anchor="IntComp">
          <front>
            <title>TCP in the Spanish Government through projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, UE, and
         by Generalitat de Catalunya Grant 2017 SGR 376.
         Part Internet of his contribution Things: from Ostracism to this work has been carried out during his stays as a visiting scholar at the Computer Laboratory 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</refcontent>
        </reference>

        <reference anchor="MQTT">
          <front>
            <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>

        <reference anchor="HomeGateway">
          <front>
            <title>An Experimental Study of the University 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 Sarolahti'>
		 <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 Cambridge.</t>

      <t> 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 Keranen,
   Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe
   Touch, Fred Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen,
   Emmanuel Baccelli, Stuart Cheshire, Gorry Fairhurst, Ingemar Johansson, Ted Lemon, and Michael Tuexen.
   Simon Brummer provided details, and kindly performed RAM and ROM usage measurements, 10th ACM SIGCOMM conference on Internet measurement, pp. 260-266</refcontent>
        </reference>

        <reference anchor="SHREW">
          <front>
            <title>Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the RIOT TCP implementation. Xavi Vilajosana provided details on Mice and Elephants)</title>
	     <author initials='A.' surname='Nyrhinen' fullname='Aleksandar Kuzmanovic'>
              <organization /></author>
              <author initials='E.' surname='Knightly' fullname='Edward Knightly'>
              <organization /></author>
            <date year="2003" month="August"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/863955.863966"/>
	  <refcontent>SIGCOMM'03</refcontent>
        </reference>

        <reference anchor="ETEN">
          <front>
            <title>Explicit transport error notification (ETEN) for error-prone wireless and satellite networks</title>
	      <author initials='R.' surname='Krishnan' fullname='Rajesh Krishnan'>
              <organization /></author>
	       <author initials='J.' surname='Sterbenz' fullname='James Sterbenz'>
               <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>

     <reference anchor="Dunk">
          <front>
            <title>Full TCP/IP for 8-Bit Architectures</title>
	    <author initials='A.' surname='Dunkels' fullname='Adam Dunkels'>
              <organization /></author>
            <date year="2003" month="May"/>
          </front>
	   <seriesInfo name="DOI" value="10.1145/1066116.106611"/>
	  <refcontent>MobiSys '03, pp. 85-98</refcontent>
        </reference>

        <reference anchor="RIOT">
          <front>
            <title>RIOT: An Open Source Operating System for Low-End Embedded Devices in the OpenWSN TCP implementation.
   Rahul Jadhav kindly performed code size measurements on IoT</title>
 <author initials='E.' surname='Baccelli' fullname='Emmanuel Baccelli'>
 <organization /></author>
  <author initials='C.' surname='Gündoğa' fullname='Cenk Gündoğa'>
  <organization /></author>
  <author initials='O.' surname='Hahm' fullname='Oliver Hahm'>
  <organization /></author>
    <author initials='P.' surname='Kietzmann' fullname='Kietzmann'>
    <organization /></author>
      <author initials='M.' surname='Lenders' fullname='Martine Lenders'>
      <organization /></author>
        <author initials='H.' surname='Petersen' fullname='Hauke Petersen'>
	<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="March"/>
          </front>
	   <seriesInfo name="DOI" value="10.1109/JIOT.2018.2815038"/>
	   <refcontent>IEEE Internet of Things Journal, Vol. 5, Issue 6</refcontent>
        </reference>

        <reference anchor="GNRC">
          <front>
            <title>Connecting the Contiki-NG and lwIP 2.1.2 TCP implementations. He also provided details on World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the uIP TCP implementation.
      </t>

    </section> IoT</title>
	   <author initials='M.' surname='Lenders' fullname='Martine Lenders'>
	   <organization /></author>
           <author initials='P.' surname='Kietzmann' fullname='Kietzmann'>
	   <organization /></author>
	   <author initials='O.' surname='Hahm' fullname='Oliver Hahm'>
	   <organization /></author>
	    <author initials='H.' surname='Petersen' fullname='Hauke Petersen'>
	    <organization /></author>
	    <author initials='C.' surname='Gündoğa' fullname='Cenk Gündoğa'>
	    <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>

        <section title="Annex. TCP implementations numbered="true" toc="default">
      <name>TCP Implementations for constrained devices"> Constrained Devices</name>
      <t>This section overviews the main features of TCP implementations for constrained devices. The survey is limited to open source 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.</t>
      <section title="uIP"> numbered="true" toc="default">
        <name>uIP</name>
        <t>uIP is a TCP/IP stack, targetted targeted for 8 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 ICMP, and TCP)
           has been reported for uIP <xref target="Dunk"/>. target="Dunk" format="default"/>. Later versions of uIP implement IPv6 as well.</t>
        <t>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, supported but need to share the global buffer.
        </t>
        <t>The MSS is announced via the MSS option on connection establishment establishment, and the receive window size (of one 1 MSS) is not modified during a connection. Stop-and-wait operation is used for sending data. Among other optimizations, this allows to avoid 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"/>) target="DelAck" format="default"/>) to avoid Delayed ACKs for senders using a single segment.</t>

        <t>The code size of the TCP implementation in Contiki-NG has been measured to be of 3.2 kB on CC2538DK, cross-compiling on Linux.</t>
      </section>
      <section title="lwIP"> numbered="true" toc="default">
        <name>lwIP</name>
        <t>lwIP is a TCP/IP stack, targetted 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 ICMP, and TCP), TCP) and a TCP code size of ~9 kB to ~14 kB <xref target="Dunk"/>. target="Dunk" format="default"/>.
        Both IPv4 and IPv6 are supported in lwIP since v2.0.0.</t>

        <t>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 outcoming outgoing data. Other implemented mechanisms comprise slow start, congestion avoidance, fast retransmit retransmit, and fast recovery.
           SACK and Window Scale support has been recently added to lwIP.</t>
      </section>
      <section title="RIOT"> numbered="true" toc="default">
        <name>RIOT</name>
        <t> The RIOT TCP implementation (called GNRC TCP) "GNRC TCP") has been designed for Class 1 devices [RFC 7228]. <xref target="RFC7228" format="default"/>. 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 internals; therefore, GNRC TCP can be seen as a user-friendly uIP TCP implementation.
        </t>
        <t> 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 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.
        </t>

        <t> The RIOT TCP implementation offers an optional POSIX Portable Operating System Interface (POSIX) socket wrapper that enables POSIX compliance, if needed.
        </t>
        <t> Further details on RIOT and GNRC can be found in the literature <xref target="RIOT"/>, target="RIOT" format="default"/> and <xref target="GNRC"/>. target="GNRC" format="default"/>.
        </t>
      </section>
      <section title="TinyOS"> numbered="true" toc="default">
        <name>TinyOS</name>
        <t>TinyOS was important as a platform for early constrained devices. TinyOS has an experimental TCP stack that uses a simple nonblocking 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 and or otherwise drop the segment. A send buffer is provided by the application. Multiple TCP connections are possible. Recently Recently, there has been little further work on the stack.</t>
      </section>
      <section title="FreeRTOS"> numbered="true" toc="default">
        <name>FreeRTOS</name>
        <t>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' "Tiny-TCP" option, which is a single-MSS variant, can be enabled. Delayed ACKs are supported, with a 20-ms 20 ms Delayed ACK timer as a technique intended 'to "to gain performance'. performance".
        </t>
      </section>
      <section title="uC/OS"> numbered="true" toc="default">
        <name>uC/OS</name>
        <t>uC/OS is a real-time operating system kernel for embedded devices, which is maintained by Micrium. Micrium.&nbsp; uC/OS is intended for 8-, 16- 16-, and 32-bit microprocessors. The uC/OS TCP implementation supports a multiple-segment window size.
        </t>
      </section>
      <section title="Summary">
        <t>
        <figure title="Summary of TCP features for different lightweight TCP implementations. None numbered="true" toc="default">
        <name>Summary</name>

	<t>None of the implementations considered in this Annex support ECN or TFO."
                anchor="fig_summary">
        <artwork><![CDATA[
                        +---+---------+--------+----+------+--------+-----+
                        |uIP|lwIP orig|lwIP 2.1|RIOT|TinyOS|FreeRTOS|uC/OS|
   +------+-------------+---+---------+--------+----+------+--------+-----+
   |Memory|Code size(kB)| <5|~9 to ~14|   38   | <7 | N/A  |  <9.2  | N/A |
   |      |             |(a)|   (T1)  |  (T4)  |(T3)|      |  (T2)  |     |
   +------+-------------+---+---------+--------+----+------+--------+-----+
   |      | Single-Segm.|Yes|    No   |   No   | Yes|  No  |   No   |  No |
   |      +-------------+---+---------+--------+----+------+--------+-----+
   |      |  Slow start | No|   Yes   |   Yes  | No | Yes  |   No   | Yes |
   |  T   +-------------+---+---------+--------+----+------+--------+-----+
   |  C   |Fast rec/retx| No|   Yes   |   Yes  | No | Yes  |   No   | Yes |
   |  P   +-------------+---+---------+--------+----+------+--------+-----+
   |      |  Keep-alive | No|    No   |   Yes  | No |  No  |  Yes   | Yes |
   |      +-------------+---+---------+--------+----+------+--------+-----+
   |  f   |  Win. Scale | No|    No   |   Yes  | No |  No  |  Yes   |  No |
   |  e   +-------------+---+---------+--------+----+------+--------+-----+
   |  a   |  TCP timest.| No|    No   |   Yes  | No |  No  |  Yes   |  No |
   |  t   +-------------+---+---------+--------+----+------+--------+-----+
   |  u   |      SACK   | No|    No   |   Yes  | No |  No  |  Yes   |  No |
   |  r   +-------------+---+---------+--------+----+------+--------+-----+
   |  e   |  Del. ACKs  | No|   Yes   |   Yes  | No |  No  |  Yes   | Yes |
   |  s   +-------------+---+---------+--------+----+------+--------+-----+
   |      |     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, TFO.</t>

<table anchor="table_1">
  <name>Summary of TCP Features for Different Lightweight TCP Implementations</name>
  <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>

<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>

  </tbody>
</table>

<t>Legend:</t>

<dl spacing="normal" indent="8">
  <dt>(T1):</dt><dd>TCP-only, on x86 and AVR platforms
     (T2)  = TCP-only, platforms</dd>
     <dt>(T2):</dt><dd>TCP-only, on ARM Cortex-M platform
     (T3)  = TCP-only, 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)
     (T4)  = TCP-only, connection)</dd>
    <dt>(T4):</dt><dd>TCP-only, on CC2538DK, cross-compiling on Linux
     (a)   = includes Linux</dd>
    <dt>(a):</dt><dd>Includes IP, ICMP 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 Linux</dd>
    <dt>(I):</dt><dd>Optional POSIX socket wrapper which that enables POSIX compliance if needed
     Mult. = Multiple
     N/A   = Not Available

        ]]></artwork></figure>
        </t> needed</dd>
    <dt>Mult.:</dt><dd>Multiple</dd>
    <dt>N/A:</dt><dd>Not Available</dd>
</dl>

      </section>
    </section>

 <section title="Annex. Changes compared to previous versions">

      <t>RFC Editor: To be removed prior to publication</t>

      <section title="Changes between -00 anchor="ACKs" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The work of <contact fullname="Carles Gomez"/> has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through Jose Castillejo grants CAS15/00336
         and -01">

        <t><list style="symbols">

          <t>Changed title CAS18/00170; the European Regional Development Fund (ERDF); the Spanish Government through projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, and abstract</t>

          <t>Clarification that communication with standard-compliant TCP endpoints is required, based on feedback from Joe Touch</t>

          <t>Additional discussion on communication patters</t>

          <t>Numerous changes UE; and
         the Generalitat de Catalunya Grant 2017 SGR 376.
      Part of his contribution to address this work has been carried out during his stays as a comprehensive review from Hannes Tschofenig</t>

          <t>Reworded security considerations</t>

          <t>Additional references visiting scholar at the Computer Laboratory of the University of Cambridge.</t>

      <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"/>, <contact fullname="Wei Genyu"/>, <contact fullname="Ari Keranen"/>, <contact fullname="Abhijan Bhattacharyya"/>, <contact fullname="Andres Arcia-Moret"/>, <contact fullname="Yoshifumi Nishida"/>, <contact fullname="Joe Touch"/>, <contact fullname="Fred Baker"/>, <contact fullname="Nik Sultana"/>, <contact fullname="Kerry Lynn"/>, <contact fullname="Erik Nordmark"/>, <contact fullname="Markku Kojo"/>, <contact fullname="Hannes Tschofenig"/>, <contact fullname="David Black"/>, <contact fullname="Ilpo Jarvinen"/>,
   <contact fullname="Emmanuel Baccelli"/>, <contact fullname="Stuart Cheshire"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Ingemar Johansson"/>, <contact fullname="Ted Lemon"/>, and better distinction between normative <contact fullname="Michael Tuexen"/>.
   <contact fullname="Simon Brummer"/> provided details and informative entries</t>

          <t>Feedback from Rahul Jadhav kindly performed Random Access Memory (RAM) and Read-Only Memory (ROM) usage measurements on the uIP RIOT TCP implementation</t>

          <t>Basic data for implementation. <contact fullname="Xavi Vilajosana"/> provided details on the TinyOS OpenWSN TCP implementation added, based on source implementation.
   <contact fullname="Rahul Jadhav"/> kindly performed code analysis</t>

         </list></t>

      </section>

      <section title="Changes between -01 and -02">

        <t><list style="symbols">

          <t>Added text to size measurements on the Introduction section, Contiki-NG and a reference, on traditional bad perception of lwIP 2.1.2 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), some content now implementations. He 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 provided details on the surveyed implementations</t>

          <t>Added details, but removed "Data size" raw, in the summary table uIP TCP implementation.
      </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 discussions 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 and 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 Emmanuel Baccelli</t>

         </list></t>

      </section>

      <section title="Changes between -05 and -06">

        <t><list style="symbols">

          <t>Incorporated suggestions by Stuart Cheshire</t>

         </list></t>

      </section>

    <section title="Changes between -06 and -07">

        <t><list style="symbols">

          <t>Addressed comments by Gorry Fairhurst</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 Johansson throughout the document, including
             the addition of a new section on Initial Window considerations.</t>

         </list></t>

      </section>

      <section title="Changes between -08 and -09">

        <t><list style="symbols">

          <t>Addressed second round of comments by Ilpo Jarvinen and Markku Kojo, based on the previous draft update.</t>

        </list></t>

      </section>

      <section title="Changes between -09 and -10">

        <t><list style="symbols">

          <t>Addressed comments by Erik Kline.</t>

          <t>Addressed a comment by Markku Kojo on advice given in RFC 6691. </t>

         </list></t>

      </section>

      <section title="Changes between -10 and -11">

        <t><list style="symbols">

          <t>Addressed a comment by Ted Lemon on MSS advice. </t>

         </list></t>

      </section>

      <section title="Changes between -11 and -12">

        <t><list style="symbols">

          <t>Addressed comments from IESG and various directorates. </t>

         </list></t>

      </section>

      <section title="Changes between -12 and -13">

        <t><list style="symbols">

          <t>Fixed two typos. </t>

          <t>Addressed a comment by Barry Leiba. </t>

         </list></t>

      </section>

    </section>

   </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> 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 files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either 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</organization>
            </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 conference 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 </organization>
            </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 Devices 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>

    <!-- -->

  </back>
</rfc>