RFC 9006

TCP Usage Guidance in the Internet of Things (IoT)

๐Ÿ“… published March 2021, from ietf

RFC 9006: TCP Usage Guidance in the Internet of Things (IoT) ๐ŸŽ€

okay bestie, this is the title block ๐Ÿ’… It's an Informational doc (so NOT a Standards Track spec, just helpful guidance ๐ŸŒธ). It was written by C. Gomez (UPC), J. Crowcroft (University of Cambridge), and M. Scharf (Hochschule Esslingen) and published in March 2021. Its ISSN is 2070-1721. It doesn't obsolete or update anything. ๐Ÿซถ

Here's the vibe of the whole thing: TCP gets roasted a LOT for being "unsuitable for IoT," and this doc is like "okay, some of that is true, but a lot of it is not, and here's how to make TCP lightweight so embedded devs can actually use it" โœจ

Abstract

okay so the abstract is giving "here's the tea" ๐Ÿ“ This doc is about how to implement and use TCP in Constrained-Node Networks (CNNs), which are a big part of the Internet of Things (IoT) ๐Ÿฆ‹. These environments need a lightweight TCP, and they may skip the optional stuff ๐Ÿ™ˆ The doc goes through a bunch of known, already-deployed tricks to simplify a TCP stack, plus the trade-offs that come with each one. The goal is to help embedded devs pick which TCP features to use ๐Ÿ’œ

Status of This Memo

okay this part is boring but iykyk ๐Ÿ™ˆ This is not an Internet Standards Track spec, it's published for info only ๐Ÿ’… It's still an IETF product with IETF community consensus, public review, and IESG approval. Not every IESG-approved doc is a candidate for any Internet Standard level, so check Section 2 of RFC 7841 if you're curious ๐Ÿ‘‘

Errata and feedback live at https://www.rfc-editor.org/info/rfc9006 ๐ŸŒˆ

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ๐Ÿ”ฅ

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Please actually read those, bestie, because they explain your rights ๐Ÿซถ Any Code Components pulled out of this doc have to include the Simplified BSD License text (Section 4.e of the Trust Legal Provisions) and come with no warranty, as the Simplified BSD License says ๐Ÿ’…

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 ๐ŸŒธ

okay so the Internet Protocol suite is being used to hook Constrained-Node Networks (CNNs) up to the Internet, which is what we call the Internet of Things (IoT) [RFC7228] ๐Ÿฆ‹ To meet the needs of CNNs, the IETF built a whole set of new protocols made for these environments (see, e.g., [RFC8352]) โœจ The new stack bits 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 are UDP and TCP ๐Ÿ’… TCP gets criticized a LOT, and honestly a lot of that is unfair ๐Ÿ˜ญ It's true that some TCP stuff, like the relatively long header, not being great for multicast, and always-confirmed delivery, isn't ideal for IoT ๐Ÿ™ˆ But lots of the usual claims (high complexity, the connection-oriented approach not playing well with radio duty-cycling, and spurious congestion control kicking in on wireless links) are not valid, can be solved, or also show up in well-loved IoT end-to-end reliability mechanisms. There's a detailed breakdown in [IntComp] ๐Ÿ‘‘

At the application layer, CoAP was built over UDP [RFC7252]. But getting CoAP deployments to play nice with existing infrastructure is hard, because middleboxes like firewalls can limit or even block UDP traffic ๐Ÿซฃ That's the main reason a CoAP over TCP spec got made [RFC8323] ๐ŸŽ€

Other application protocols that weren't designed for CNNs are also being considered for IoT, like HTTP/2 and even HTTP/1.1, which both run over TCP by default [RFC7230] [RFC7540], plus the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] ๐Ÿงš TCP is also used by non-IETF app protocols in IoT, like the Message Queuing Telemetry Transport (MQTT) [MQTT] and its lightweight variants ๐ŸŒˆ

TCP is a sophisticated transport protocol with optional features (like TCP options) that can boost performance in some environments โœจ But a lot of the optional TCP extensions need complex logic in the stack and make the code and memory footprint bigger ๐Ÿ˜ฉ Plenty of TCP extensions aren't needed for interoperating with other standard-compliant TCP endpoints. So with constrained devices and their tiny resources, picking your optional TCP features carefully can make your implementation way more lightweight ๐Ÿ“

This doc gives guidance on how to implement and configure TCP, plus how apps should use TCP in CNNs ๐Ÿ’– The big goal is simple measures for a lightweight TCP implementation that still works well in these environments ๐Ÿฆ‹ A TCP implementation that follows this guidance is meant to be compatible with a TCP endpoint that follows the TCP standards, maybe with lower performance ๐Ÿ’… That means a TCP client following this guidance can always connect to a standard-compliant TCP server, and a TCP server following it can always connect to a standard-compliant TCP client ๐Ÿซถ

This doc assumes you already know TCP. A full survey of the TCP standards is in RFC 7414 [RFC7414] ๐Ÿ“š There's been similar guidance for TCP in special environments before, like for cellular wireless networks [RFC3481] ๐ŸŒธ

2. Characteristics of CNNs Relevant for TCP ๐ŸŽ€

CNNs are defined in [RFC7228] as networks whose characteristics are shaped by being made up of a big chunk of constrained nodes ๐Ÿ’… Those nodes have real limits on processing, memory, and energy ๐Ÿ˜ญ The first two limits constrain how complex and how big the protocols they can run are ๐Ÿ‘‘ Energy means they need tricks to save power, like radio duty-cycling in wireless devices [RFC8352], and minimizing how many messages get sent and received (and how big they are) ๐ŸŒˆ

[RFC7228] lists typical network constraints in CNNs, like low achievable bitrate/throughput, high packet loss with high variability in that loss, highly asymmetric links, severe penalties for bigger packets, limited reachability over time, and more ๐Ÿ™ˆ CNNs can use wireless or wired tech (e.g., Power Line Communication), and transmission rates are usually low (e.g., below 1 Mbps) ๐Ÿ“

For TCP, one challenge is that not all the tech in a CNN lines up with typical Internet subnetwork design principles [RFC3819] ๐Ÿงš For example, constrained nodes often use physical/link-layer techs that have been described as 'lossy', meaning they have a relatively high bit error rate ๐Ÿ’œ Dealing with corruption loss is one of the open issues on the Internet [RFC6077] โœจ

2.2. Usage Scenarios ๐ŸŒธ

There are different deployment and usage scenarios for CNNs ๐Ÿ’– Some follow the star topology, where one or several hosts link to a central device that acts as a router connecting the CNN to the Internet ๐Ÿฆ‹ Others may follow the multihop topology [RFC6606] ๐Ÿซถ

In constrained environments there can be different kinds of devices [RFC7228] ๐ŸŽ€ For example, some have a single combined send/receive buffer, some have a separate send and receive buffer, and some have a pool of multiple send/receive buffers ๐Ÿ’… In that last case, the buffers might also be shared with other protocols ๐Ÿ‘‘

One key use case for TCP in CNNs is constrained devices connecting to unconstrained servers on the Internet ๐ŸŒˆ But it's also possible for both TCP endpoints to run on constrained devices ๐Ÿ’œ In the first case, the communication will possibly go through a middlebox (like a firewall, NAT, etc.) ๐Ÿ™ˆ Figure 1 shows this scenario ๐Ÿฆ‹ Note that the scenario is asymmetric, because the unconstrained device usually won't have the severe constraints of the constrained one ๐Ÿ’… The unconstrained device is expected to be mains-powered, have lots of memory and processing power, and be on a resource-rich network โœจ

Assuming most constrained devices are sensor nodes, the data sent by constrained devices (like sensor measurements) is expected to be higher than the data going the other way ๐Ÿ“ˆ Still, constrained devices may receive requests (which they may answer), commands (for configuration, and for constrained devices including actuators), and fairly 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

okay that's the first chunk, bestie ๐Ÿ’– Part 2 is coming up next with Section 2.3 and the rest of the TCP goodies, so stay tuned ๐Ÿซถโœจ

2.3. Communication and Traffic Patterns ๐Ÿ’Œ

okay so IoT apps have a bunch of different ways of talking to each other ๐Ÿซถ this isn't a full list, just some super common vibes:

  • Unidirectional transfers: an IoT device (think a sensor ๐ŸŒก๏ธ) can keep sending updates to the other endpoint again and again ๐Ÿ”. There isn't always a need for the app to reply back to the IoT device, so it's kinda one-way ๐Ÿฆ‹
  • Request-response patterns: an IoT device gets a request from the other endpoint, and that request triggers a response from the IoT device ๐Ÿ’ฌโœจ
  • Bulk data transfers: the classic example is a long file transfer, like an IoT device firmware update ๐Ÿ“ฆ๐Ÿ’œ

The typical pattern is a constrained device chatting with an unconstrained device (see Figure 1 ๐ŸŽ€). But constrained devices can totally talk to each other too ๐Ÿ‘ฏโ€โ™€๏ธ

3. TCP Implementation and Configuration in CNNs โœจ

this section is all about how a TCP stack can handle the usual constraints in CNNs ๐Ÿงš the advice here is about the TCP implementation itself and how it gets configured ๐Ÿ› ๏ธ

3.1. Addressing Path Properties ๐Ÿ›ฃ๏ธ

3.1.1. Maximum Segment Size (MSS) ๐Ÿ“

so, assuming IPv6 is being used ๐ŸŒ, and we want the implementation to stay lightweight and easy to run, unless apps actually need to handle big data units (aka an IPv6 datagram bigger than 1280 bytes), it may be desirable to cap the IP datagram size at 1280 bytes ๐Ÿ’…. That way you don't have to support Path MTU Discovery [RFC8201] ๐Ÿ™Œ. Plus, a 1280-byte IP datagram avoids IPv6-layer fragmentation [RFC8900] ๐ŸŽฏ

you can keep an IPv6 datagram from going over 1280 bytes by setting the TCP MSS to 1220 bytes or less ๐Ÿ“. Also, it's already a requirement for TCP implementations to use up payload space instead of making the datagram bigger when IP or TCP options get added to a packet being sent [RFC6691] ๐Ÿ’–. So it's not required to advertise an MSS smaller than 1220 bytes just to fit TCP options in ๐Ÿซถ

fr, setting the MTU to 1280 bytes is possible for link-layer techs in the CNN space โœจ, even though some of them have really tiny data unit payloads (like a few tens or hundreds of bytes) ๐Ÿฃ. For example, the maximum frame size in IEEE 802.15.4 is 127 bytes ๐Ÿ˜ญ. 6LoWPAN made an adaptation layer so IPv6 can run over IEEE 802.15.4 networks ๐Ÿฆ‹. That adaptation layer has a fragmentation mechanism, because IPv6 needs the layer below it to support an MTU of 1280 bytes [RFC8200], and IEEE 802.15.4 doesn't have fragmentation mechanisms of its own ๐Ÿ’€. So 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes [RFC4944] ๐Ÿ‘‘

other techs like Bluetooth low energy [RFC7668], ITU-T G.9959 [RFC7428], and Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) [RFC8105] also use 6LoWPAN-based adaptation layers to get IPv6 support ๐ŸŒˆ. These techs do support link-layer fragmentation, and by using that, the adaptation layers that enable IPv6 over them also define an MTU of 1280 bytes ๐Ÿงšโ€โ™€๏ธ

BUT there are other techs in the CNN space, like Master Slave (MS) / Token Passing (TP) [RFC8163], Narrowband IoT (NB-IoT) [RFC8376], or IEEE 802.11ah [6LO-WLANAH], that don't have the same tight frame size limits as the ones above ๐Ÿ™…โ€โ™€๏ธ. The MTU for MS/TP is recommended to 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 bigger MSS (to a suitable extent) can be really good in some scenarios, especially when you're moving large payloads ๐Ÿ“ฆ, because you need fewer packets (and fewer packet headers) for a given payload ๐ŸŽ€. BUT the characteristics of the constrained network need to be considered ๐Ÿ‘€. Especially in a lossy network where unreliable fragment delivery is used ๐Ÿ˜ฉ, the amount of data TCP unnecessarily retransmits because of fragment loss goes up (and throughput goes down) really fast as the MSS grows ๐Ÿ“‰. That's because losing one fragment means losing the whole fragmented packet that was being sent ๐Ÿ’”. Unnecessary retransmissions are especially harmful in CNNs since those environments are so resource-constrained ๐Ÿชซ. Also, while the original 6LoWPAN fragmentation mechanism [RFC4944] doesn't 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] lets a router signal in the IP header of a packet that congestion is building up, for example when a queue size hits a certain threshold ๐Ÿšจ. An ECN-enabled TCP receiver echoes that congestion signal back to the TCP sender by setting a flag in its next TCP Acknowledgment (ACK) ๐Ÿชž. Then the sender triggers congestion control measures as if a packet loss had happened ๐Ÿ’ฅ

RFC 8087 [RFC8087] lays out the main gains (more throughput, less delay, and other perks) when ECN is used over a network path that includes equipment supporting Congestion Experienced (CE) marking ๐Ÿ†. In CNNs, ECN is a total slay because congestion can be signaled without dropping packets ๐Ÿ™Œ. Dropped packets lead to retransmissions and burn through limited resources like energy and bandwidth ๐Ÿ”‹

ECN can also cut down on packet losses, since congestion control can kick in earlier [RFC2884] โฐ. Fewer lost packets means fewer retransmitted segments, which is super beneficial in CNNs where energy and bandwidth are usually limited ๐ŸŒฟ. It also makes sense to avoid packet drops for transactional workloads with small data sizes, which are typical in CNNs ๐Ÿ’…. With that kind of traffic, it's harder and often impossible to detect packet loss without retransmission timeouts (for example, there may not be three duplicate ACKs ๐Ÿ™ƒ). And any retransmission timeout slows the data transfer down a lot ๐ŸŒ. If the constrained device uses power-saving techniques, a retransmission timeout also causes a wake-up action, unlike ACK clock-triggered sending โšก. When a TCP sender's congestion window is one segment in size and a TCP ACK with an ECN signal (ECN-Echo (ECE) flag) arrives, the sender resets the retransmit timer, and it can only send a new packet once that timer expires โณ. So at that point the sender drops its sending rate from 1 segment per Round-Trip Time (RTT) to 1 segment per Retransmission Timeout (RTO), and it keeps reducing the rate on each ECN signal in later TCP ACKs ๐Ÿ“‰. If a later TCP ACK doesn't carry an ECN signal, the sender goes back to normal ACK-clocked segment transmission [RFC3168] ๐ŸŽถ

ECN can be deployed incrementally across the Internet ๐ŸŒ. Guidance on configuring and using ECN is in RFC 7567 [RFC7567] ๐Ÿ“–. Given the benefits, more and more TCP stacks on the Internet support ECN, so it makes sense to specifically use it in controlled environments like CNNs ๐Ÿก. As of writing, there's ongoing work to extend which TCP packets are ECN capable, including pure ACKs [TCPM-ECN] ๐Ÿ‘€. That could boost ECN's benefits even more in CNN environments ๐Ÿš€. Just note that supporting ECN does add implementation complexity ๐Ÿงฉ

3.1.3. Explicit Loss Notifications ๐Ÿ”

there's been a ton of research on solutions that can explicitly indicate whether a TCP segment loss is due to corruption, so congestion control doesn't get triggered [ETEN] [RFC2757] ๐Ÿงช. Those solutions can help a lot, but they haven't been widely deployed and are still experimental ๐Ÿ”ฌ. In fact, as of today, the IETF hasn't standardized any such solution ๐Ÿ™ˆ

3.2. TCP Guidance for Single-MSS Stacks ๐Ÿงธ

this section covers TCP stacks that can only transfer a single MSS at a time ๐Ÿผ. More general guidance is in Section 3.3 ๐Ÿ“š

3.2.1. Single-MSS Stacks -- Benefits and Issues โš–๏ธ

a TCP stack can save memory by advertising a TCP window size of 1 MSS and also by sending at most 1 MSS of unacknowledged data ๐Ÿ’พ. In that case, both congestion and flow control are pretty simple to implement ๐Ÿซง. A small receive and send window like that may be enough for simple message exchanges in the CNN space โœจ. BUT only using a 1 MSS window can really hurt performance ๐Ÿ˜ต. A stop-and-wait operation gives low throughput for transfers longer than 1 MSS, like a firmware download ๐Ÿข. And a single-MSS solution only relies on timer-based loss recovery, so it misses out on the performance gains of Fast Retransmit and Fast Recovery (which need a bigger 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 it has received a response for the previous message sent to that destination ๐Ÿ™…โ€โ™€๏ธ. That's 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 enough, as long as the CoAP message size doesn't go over 1 MSS ๐Ÿ’…. The exception in CoAP over TCP is the Capabilities and Settings Message (CSM), which has to be sent at the start of the TCP connection ๐Ÿค. The first application message carrying user data is allowed to go out right after the CSM message โœจ. But if the CSM size plus the application message size goes over 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 ๐Ÿ”‘. Those are the MSS option, the No-Operation option, and the End Of Option List marker, in that order [RFC0793] ๐Ÿงพ. None of these are a big burden to support ๐Ÿ’ช. They're enough for interoperability with a standard-compliant TCP endpoint, though many TCP stacks support extra 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 these TCP options: Window Scale [RFC7323], TCP Timestamps [RFC7323], Selective Acknowledgment (SACK) [RFC2018], and SACK-Permitted [RFC2018] ๐Ÿงƒ. Other TCP options may also not be required on a constrained device with a very lightweight implementation ๐Ÿชถ. As for the Window Scale option, it's only useful if a window size greater than 64 kB is needed ๐Ÿ“

a TCP sender can benefit from the TCP Timestamps option [RFC7323] when detecting spurious RTOs ๐Ÿ•ต๏ธโ€โ™€๏ธ. Those are pretty likely to happen in CNN scenarios for a bunch of reasons (like route changes in a multihop scenario, link-layer retries, etc.) ๐ŸŒ€. Just make sure the header overhead from the Timestamps option (up to 12 bytes) gets taken into account ๐Ÿงฎ

3.2.3. Delayed Acknowledgments for Single-MSS Stacks โœจ

okay so TCP Delayed ACKs exist to cut down on how many ACKs get sent in a connection ๐Ÿซถ, which saves network overhead. the catch? the sender may have to wait longer before it gets an ACK ๐Ÿ˜ญ. how useful Delayed ACKs are depends HEAVILY on the usage scenario (see Section 3.3.2) ๐Ÿ’…. and yes, they can totally interact with single-MSS stacks ๐Ÿ™ˆ.

When traffic is unidirectional, and 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 add delay (up to 500 ms) to the RTT [RFC5681]. that limits throughput and can make data take longer to arrive ๐Ÿข. it's not always possible to turn Delayed ACKs off, fyi ๐Ÿฅบ. one known workaround is to split the data into two smaller segments ๐Ÿ“. a standard-compliant TCP receiver may immediately acknowledge the second MSS of data, which can boost throughput โœจ. BUT this "split hack" may not always work, because a TCP receiver is required to acknowledge every second full-sized segment, not two consecutive small segments ๐Ÿ’€. and sending two IP packets instead of one is another downside of the "split hack" ๐Ÿ™ƒ.

Similar issues can pop up when the sender uses the Nagle algorithm, since the sender may need to wait for an unnecessarily Delayed ACK before it can send a new segment ๐Ÿ˜ค. turning the algorithm off won't make a difference 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 that ACK goes out before the Delayed ACK timer expires ๐Ÿฆ‹. that way you avoid unnecessary ACKs with no payload, which is so efficient. disabling Delayed ACKs at the request sender lets an immediate ACK go out 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's a real trade-off here, bestie: a short, aggressive RTO reduces the wait before retransmissions, BUT it also raises the probability of spurious timeouts ๐Ÿ˜ฌ. those lead to unnecessary waste of potentially scarce resources in CNNs, like energy and bandwidth ๐Ÿ”‹. on the flip side, a conservative timeout can mean long error recovery times, which needlessly delays data delivery ๐ŸŒ.

if a TCP sender uses a very small window size, and it can't benefit from Fast Retransmit and Fast Recovery or SACK, the RTO algorithm has a huge 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 is a roundup of some widely used techniques to improve TCP, with a focus on how they're used in CNNs ๐Ÿ’œ. the TCP extensions discussed here are useful in a wide range of network scenarios, CNNs included ๐ŸŒธ. it is not comprehensive, though! a full survey of TCP extensions is published in RFC 7414 [RFC7414] ๐Ÿ“š.

3.3.1. Loss Recovery and Congestion/Flow Control

okay, so devices with enough memory for a bigger TCP window (more than 3 MSS of data) can use a more efficient loss recovery than the timer-based approach used for a smaller window (see Section 3.2.1) ๐Ÿง โœจ. they do it with Fast Retransmit and Fast Recovery [RFC5681], at the cost of slightly more complexity and Transmission Control Block (TCB) size ๐Ÿ’…. assuming 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 ๐Ÿ”ฅ. picture a 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 ๐Ÿ’–. to have segments 2, 3, 4, 5, and 6 sent, the window has to be at least 5 MSS. with an MSS of 1220 bytes, a buffer of 5 MSS would need 6100 bytes ๐ŸŽ€.

the example in the previous paragraph did not use another TCP improvement, Limited Transmit [RFC3042] ๐Ÿซถ. it may also be useful for any transfer with more than one segment in flight. small transfers tend to benefit more from Limited Transmit, because they're more likely to not receive enough duplicate ACKs ๐Ÿฅน. using the example above, Limited Transmit lets you send 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 extra delay from the Delayed ACK timer for the ACK that confirms segment 1 โณ. it's a trade, babe ๐Ÿ’….

when a multiple-segment window is used, the receiver will need to manage possibly out-of-order segments, which requires sufficient buffer space ๐Ÿ“ฆ. note that even when a window of 1 MSS is used, out-of-order arrival should also be managed, because 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 to advertise a TCP window size of several MSSs, it makes sense to support the SACK option for better performance ๐ŸŒŸ. SACK lets a data receiver tell the data sender about non-contiguous data blocks it has received ๐Ÿ“ฌ. so a sender (that previously sent the SACK-Permitted option) can avoid doing unnecessary retransmissions, saving energy and bandwidth, and reducing latency โšก. SACK also often allows faster loss recovery when there's more than one lost segment in a window of data, since SACK recovery may complete with fewer RTTs ๐Ÿƒโ€โ™€๏ธ. it's especially useful for bulk data transfers ๐Ÿ“ฆ๐Ÿ’•.

a receiver supporting SACK will need to keep track of the data blocks that still need to be received ๐Ÿ—‚๏ธ. the sender also needs to keep track of which data segments must be resent after it learns which data blocks are missing at the receiver ๐Ÿงฉ. SACK adds 8*n+2 bytes to the TCP header, where n is the number of data blocks received, up to four blocks ๐Ÿ“. for a low number of out-of-order segments, the header overhead of SACK is made up for by avoiding unnecessary retransmissions ๐Ÿ’œ. when the sender discovers the data blocks that were already received, it needs to store the state required to avoid unnecessarily retransmitting data segments that have already arrived ๐Ÿง โœจ.

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 figure out the maximum delay for an ACK ๐Ÿค“. for CNNs, the recommendation depends on the expected communication patterns ๐Ÿ’….

when traffic over a CNN is expected to be mostly 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 turn Delayed ACKs off at the receiver ๐Ÿ”‹. this avoids extra delay, plus the energy the sender burns during that time (it might, e.g., keep its radio interface in receive mode) ๐Ÿ“ก. 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, so a response can be combined with the ACK into a single segment, which is more efficient ๐Ÿซถ. plus, 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 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 ๐Ÿ“ฆโœจ.

one more thing: in many scenarios, the peer a constrained device talks to is 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 no matter what kind of endpoint it's talking 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 ๐Ÿ“–. then RFC 6928 [RFC6928] defines an experimental new value for the IW, which in practice results in an IW of 10 MSS ๐Ÿงช. nowadays, that's what many TCP implementations use ๐Ÿ’–.

okay, but a 10-MSS IW was recommended for resource-rich environments (e.g., broadband environments), which are really 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 a large object is transferred in a CNN with an IW of 10 MSS, there's a significant buffer overflow risk, since many CNN devices support network or radio buffers smaller than 10 MSS ๐Ÿ˜ฑ. to avoid that, 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 applications built for CNN scenarios can use TCP ๐Ÿงš. 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 ๐Ÿ”Œ. the reason? so the device can support possible sleep periods and save energy ๐Ÿ”‹๐Ÿ’ค.

4.2. Number of Concurrent Connections โœจ

okay so TCP endpoints with a small amount of memory may only support a small number of connections ๐Ÿงš bc every TCP connection has to store a bunch of variables in the TCB ๐Ÿ’…. Depending on how the TCP implementation is built, each connection can cause extra memory overhead, and connections can end up competing for scarce resources (like extra memory overhead for send and receive buffers, etc.) ๐Ÿ˜ญ

a careful app 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 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, on top of eating up 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 starts with a three-way handshake, which means more message overhead ๐Ÿ™ˆ.

Being conservative when opening multiple TCP connections is of particular importance in Constrained-Node Networks ๐Ÿซถ no cap.

4.3. TCP Connection Lifetime ๐Ÿฆ‹

so 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, that idle time can cause 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 having 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 using 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, and then 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 comes from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) [RFC7413], which is an experimental TCP extension ๐Ÿงช. The catch is that it comes 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 used 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 again) after a certain amount of time โฐ.

Now here's the tea ๐Ÿต: while a given cookie is used for multiple connections between the same two endpoints, those endpoints may become vulnerable to privacy threats ๐Ÿ‘€. In addition, a valid cookie may be stolen from a compromised host and used to perform SYN flood attacks, as well as amplified reflection attacks against 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 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, so 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 for avoiding 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 apply to CNNs ๐Ÿซก. 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 assess 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 a 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] ๐Ÿšจ. In that attack, 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 ๐Ÿ“šโœจ

okay bestie, this is the shelf of normative references ๐Ÿงš these are the docs the spec totally leans on. you need them to actually implement this stuff, so they're basically required reading ๐Ÿ’…

7.2. Informative References ๐Ÿ“šโœจ

okay bestie, here's the informative reading list ๐Ÿฆ‹ these ones are background and context, not the core spec, but they're lowkey a goldmine if you wanna go deeper ๐Ÿ’…

Appendix A. TCP Implementations for Constrained Devices ๐Ÿงš

okay bestie, this appendix is a tour of the main TCP stacks made for tiny devices ๐Ÿ’– the survey is limited to open-source stacks with a small footprint, and 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 โœจ also, be aware that this Annex is based on info available as of the writing ๐Ÿ“

A.1. uIP

uIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers, and it's kind of the OG that pioneered TCP/IP implementations for constrained devices ๐Ÿ‘‘ it 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, and that buffer is 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 they 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 ๐Ÿ’œ it 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 ๐ŸŒธ

ngl, lwIP is a glow-up compared to uIP ๐Ÿ”ฅ it 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 โœจ unlike 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, so GNRC TCP can be seen as a user-friendly uIP TCP implementation ๐Ÿฆ„

the MSS is set on connection 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, so it deserves a shoutout ๐Ÿซก 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

okay, the big recap ๐Ÿ“Š 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

this table is the whole vibe check ๐Ÿ’… here's the legend so you can read it like a pro:

   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

and that's a wrap on RFC 9006 ๐ŸŒˆ๐ŸŽ€ you made it, bestie!! ๐Ÿฆ‹โœจ

๐Ÿ“ฆ where this page comes from