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