idnits 2.17.1 draft-ietf-lwig-tcp-constrained-node-networks-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 32 instances of too long lines in the document, the longest one being 90 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 29, 2019) is 1854 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7228' is mentioned on line 805, but not defined == Unused Reference: 'RFC6092' is defined on line 1120, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-17) exists of draft-ietf-tcpm-rto-consider-08 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Informational J. Crowcroft 5 Expires: September 30, 2019 University of Cambridge 6 M. Scharf 7 Hochschule Esslingen 8 March 29, 2019 10 TCP Usage Guidance in the Internet of Things (IoT) 11 draft-ietf-lwig-tcp-constrained-node-networks-07 13 Abstract 15 This document provides guidance on how to implement and use the 16 Transmission Control Protocol (TCP) in Constrained-Node Networks 17 (CNNs), which are a characterstic of the Internet of Things (IoT). 18 Such environments require a lightweight TCP implementation and may 19 not make use of optional functionality. This document explains a 20 number of known and deployed techniques to simplify a TCP stack as 21 well as corresponding tradeoffs. The objective is to help embedded 22 developers with decisions on which TCP features to use. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 30, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 4 60 3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4 61 3.1. Network and link properties . . . . . . . . . . . . . . . 4 62 3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Communication and traffic patterns . . . . . . . . . . . 6 64 4. TCP implementation and configuration in CNNs . . . . . . . . 6 65 4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7 67 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 8 68 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9 69 4.2. TCP guidance for single-MSS windows and buffers . . . . . 9 70 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 9 71 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9 72 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 10 73 4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 11 74 4.3. General recommendations for TCP in CNNs . . . . . . . . . 11 75 4.3.1. Loss recovery and congestion/flow control . . . . . . 11 76 4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 12 77 4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12 78 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 13 79 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 13 80 5.2. Number of concurrent connections . . . . . . . . . . . . 13 81 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. Annex. TCP implementations for constrained devices . . . . . 16 85 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9. Annex. Changes compared to previous versions . . . . . . . . 20 93 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20 94 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20 95 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20 96 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21 97 9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21 98 9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 21 99 9.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 21 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 102 10.2. Informative References . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 The Internet Protocol suite is being used for connecting Constrained- 108 Node Networks (CNNs) to the Internet, enabling the so-called Internet 109 of Things (IoT) [RFC7228]. In order to meet the requirements that 110 stem from CNNs, the IETF has produced a suite of new protocols 111 specifically designed for such environments (see e.g. [RFC8352]). 112 New IETF protocol stack components include the IPv6 over Low-power 113 Wireless Personal Area Networks (6LoWPAN) adaptation layer, the IPv6 114 Routing Protocol for Low-power and lossy networks (RPL) routing 115 protocol, and the Constrained Application Protocol (CoAP). 117 As of the writing, the main current transport layer protocols in IP- 118 based IoT scenarios are UDP and TCP. However, TCP has been 119 criticized (often, unfairly) as a protocol for the IoT. In fact, 120 some TCP features are not optimal for IoT scenarios, such as 121 relatively long header size, unsuitability for multicast, and always- 122 confirmed data delivery. However, many typical claims on TCP 123 unsuitability for IoT (e.g. a high complexity, connection-oriented 124 approach incompatibility with radio duty-cycling, and spurious 125 congestion control activation in wireless links) are not valid, can 126 be solved, or are also found in well accepted IoT end-to-end 127 reliability mechanisms (see [IntComp] for a detailed analysis). 129 At the application layer, CoAP was developed over UDP [RFC7252]. 130 However, the integration of some CoAP deployments with existing 131 infrastructure is being challenged by middleboxes such as firewalls, 132 which may limit and even block UDP-based communications. This the 133 main reason why a CoAP over TCP specification has been developed 134 [RFC8323]. 136 Other application layer protocols not specifically designed for CNNs 137 are also being considered for the IoT space. Some examples include 138 HTTP/2 and even HTTP/1.1, both of which run over TCP by default 139 [RFC7230] [RFC7540], and the Extensible Messaging and Presence 140 Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application- 141 layer protocols in the IoT space such as the Message Queue Telemetry 142 Transport (MQTT) and its lightweight variants. 144 TCP is a sophisticated transport protocol that includes optional 145 functionality (e.g. TCP options) that may improve performance in 146 some environments. However, many optional TCP extensions require 147 complex logic inside the TCP stack and increase the codesize and the 148 memory requirements. Many TCP extensions are not required for 149 interoperability with other standard-compliant TCP endpoints. Given 150 the limited resources on constrained devices, careful "tuning" of the 151 TCP implementation can make an implementation more lightweight. 153 This document provides guidance on how to implement and use TCP in 154 CNNs. The overarching goal is to offer simple measures to allow for 155 lightweight TCP implementation and suitable operation in such 156 environments. A TCP implementation following the guidance in this 157 document is intended to be compatible with a TCP endpoint that is 158 compliant to the TCP standards, albeit possibly with a lower 159 performance. This implies that such a TCP client would always be 160 able to connect with a standard-compliant TCP server, and a 161 corresponding TCP server would always be able to connect with a 162 standard-compliant TCP client. 164 This document assumes that the reader is familiar with TCP. A 165 comprehensive survey of the TCP standards can be found in [RFC7414]. 166 Similar guidance regarding the use of TCP in special environments has 167 been published before, e.g., for cellular wireless networks 168 [RFC3481]. 170 2. Conventions used in this document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 3. Characteristics of CNNs relevant for TCP 178 3.1. Network and link properties 180 CNNs are defined in [RFC7228] as networks whose characteristics are 181 influenced by being composed of a significant portion of constrained 182 nodes. The latter are characterized by significant limitations on 183 processing, memory, and energy resources, among others [RFC7228]. 184 The first two dimensions pose constraints on the complexity and on 185 the memory footprint of the protocols that constrained nodes can 186 support. The latter requires techniques to save energy, such as 187 radio duty-cycling in wireless devices [RFC8352], as well as 188 minimization of the number of messages transmitted/received (and 189 their size). 191 [RFC7228] lists typical network constraints in CNN, including low 192 achievable bitrate/throughput, high packet loss and high variability 193 of packet loss, highly asymmetric link characteristics, severe 194 penalties for using larger packets, limits on reachability over time, 195 etc. CNN may use wireless or wired technologies (e.g., Power Line 196 Communication), and the transmission rates are typically low (e.g. 197 below 1 Mbps). 199 For use of TCP, one challenge is that not all technologies in CNN may 200 be aligned with typical Internet subnetwork design principles 201 [RFC3819]. For instance, constrained nodes often use physical/link 202 layer technologies that have been characterized as 'lossy', i.e., 203 exhibit a relatively high bit error rate. Dealing with corruption 204 loss is one of the open issues in the Internet [RFC6077]. 206 3.2. Usage scenarios 208 There are different deployment and usage scenarios for CNNs. Some 209 CNNs follow the star topology, whereby one or several hosts are 210 linked to a central device that acts as a router connecting the CNN 211 to the Internet. CNNs may also follow the multihop topology 212 [RFC6606]. One key use case for the use of TCP is a model where 213 constrained devices connect to unconstrained servers in the Internet. 214 But it is also possible that both TCP endpoints run on constrained 215 devices. 217 In constrained environments, there can be different types of devices 218 [RFC7228]. For example, there can be devices with single combined 219 send/receive buffer, devices with a separate send and receive buffer, 220 or devices with a pool of multiple send/receive buffers. In the 221 latter case, it is possible that buffers also be shared for other 222 protocols. 224 When a CNN comprising one or more constrained devices and an 225 unconstrained device communicate over the Internet using TCP, the 226 communication possibly has to traverse a middlebox (e.g. a firewall, 227 NAT, etc.). Figure 1 illustrates such scenario. Note that the 228 scenario is asymmetric, as the unconstrained device will typically 229 not suffer the severe constraints of the constrained device. The 230 unconstrained device is expected to be mains-powered, to have high 231 amount of memory and processing power, and to be connected to a 232 resource-rich network. 234 Assuming that a majority of constrained devices will correspond to 235 sensor nodes, the amount of data traffic sent by constrained devices 236 (e.g. sensor node measurements) is expected to be higher than the 237 amount of data traffic in the opposite direction. Nevertheless, 238 constrained devices may receive requests (to which they may respond), 239 commands (for configuration purposes and for constrained devices 240 including actuators) and relatively infrequent firmware/software 241 updates. 243 +---------------+ 244 o o <-------- TCP communication -----> | | 245 o o | | 246 o o | Unconstrained | 247 o o +-----------+ | device | 248 o o o ------ | Middlebox | ------- | | 249 o o +-----------+ | (e.g. cloud) | 250 o o o | | 251 +---------------+ 252 constrained devices 254 Figure 1: TCP communication between a constrained device and an 255 unconstrained device, traversing a middlebox. 257 3.3. Communication and traffic patterns 259 IoT applications are characterized by a number of different 260 communication patterns. The following non-comprehensive list 261 explains some typical examples: 263 o Unidirectional transfers: An IoT device (e.g. a sensor) can send 264 (repeatedly) updates to the other endpoint. Not in every case 265 there is a need for an application response back to the IoT 266 device. 268 o Request-response patterns: An IoT device receiving a request from 269 the other endpoint, which triggers a response from the IoT device. 271 o Bulk data transfers: A typical example for a long file transfer 272 would be an IoT device firmware update. 274 A typical communication pattern is that a constrained device 275 communicates with an unconstrained device (cf. Figure 1). But it is 276 also possible that constrained devices communicate amongst 277 themselves. 279 4. TCP implementation and configuration in CNNs 281 This section explains how a TCP stack can deal with typical 282 constraints in CNN. The guidance in this section relates to the TCP 283 implementation and its configuration. 285 4.1. Path properties 287 4.1.1. Maximum Segment Size (MSS) 289 Assuming that IPv6 is used, and for the sake of lightweight 290 implementation and operation, unless applications require handling 291 large data units (i.e. leading to an IPv6 datagram size greater than 292 1280 bytes), it may be desirable to limit the MTU to 1280 bytes in 293 order to avoid the need to support Path MTU Discovery [RFC8201]. 295 An IPv6 datagram size exceeding 1280 bytes can be avoided by setting 296 the TCP MSS not larger than 1220 bytes. This assumes that the remote 297 sender will use no TCP options, aside from possibly the MSS option, 298 which is only used in the initial TCP SYN packet. In order to 299 accommodate unrequested TCP options that may be used by some TCP 300 implementations, a constrained device may advertise an MSS not larger 301 than 1200 bytes. 303 Note that setting the MTU to 1280 bytes is possible for link layer 304 technologies in the CNN space, even if some of them are characterized 305 by a short data unit payload size, e.g. up to a few tens or hundreds 306 of bytes. For example, the maximum frame size in IEEE 802.15.4 is 307 127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over 308 IEEE 802.15.4 networks. The adaptation layer includes a 309 fragmentation mechanism, since IPv6 requires the layer below to 310 support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked 311 fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU 312 of 1280 bytes [RFC4944]. Other technologies, such as Bluetooth LE 313 [RFC7668], ITU-T G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 314 6LoWPAN-based adaptation layers in order to enable IPv6 support. 315 These technologies do support link layer fragmentation. By 316 exploiting this functionality, the adaptation layers that enable IPv6 317 over such technologies also define an MTU of 1280 bytes. 319 On the other hand, there exist technologies also used in the CNN 320 space, such as Master Slave / Token Passing (TP) [RFC8163], 321 Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah 322 [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of 323 frame size limitations as the technologies mentioned above. The MTU 324 for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- 325 IoT is 1600 bytes, and the maximum frame payload size for IEEE 326 802.11ah is 7991 bytes. 328 While IPv6 is the main IP version used in IP-based IoT environments, 329 some IoT scenarios use IPv4. In IPv4, the MTU is 576 bytes. In 330 order to avoid exceeding the IPv4 MTU, the MSS needs to be set to a 331 value not larger than 536 bytes. Similarly to the recommendations 332 given above for IPv6, a constrained device using IPv4 may advertise 333 an MSS not larger than 516 bytes in order to accommodate unrequested 334 TCP options. 336 Finally, note that using larger MSS (to a suitable extent) may be 337 beneficial, especially when transferring large payloads, as it 338 reduces the number of packets (and packet headers) required for a 339 given payload. 341 4.1.2. Explicit Congestion Notification (ECN) 343 Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router 344 to signal in the IP header of a packet that congestion is arising, 345 for example when a queue size reaches a certain threshold. An ECN- 346 enabled TCP receiver will echo back the congestion signal to the TCP 347 sender by setting a flag in its next TCP ACK. The sender triggers 348 congestion control measures as if a packet loss had happened. 350 The document [RFC8087] outlines the principal gains in terms of 351 increased throughput, reduced delay, and other benefits when ECN is 352 used over a network path that includes equipment that supports 353 Congestion Experienced (CE) marking. In the context of CNNs, a 354 remarkable feature of ECN is that congestion can be signalled without 355 incurring packet drops (which will lead to retransmissions and 356 consumption of limited resources such as energy and bandwitdh). 358 ECN can further reduce packet losses since congestion control 359 measures can be applied earlier [RFC2884]. Less lost packets implies 360 that the number of retransmitted segments decreases, which is 361 particularly beneficial in CNNs, where energy and bandwidth resources 362 are typically limited. Also, it makes sense to try to avoid packet 363 drops for transactional workloads with small data sizes, which are 364 typical for CNNs. In such traffic patterns, it is more difficult to 365 detect packet loss without retransmission timeouts (e.g., as there 366 may be no three duplicate ACKs). Any retransmission timeout slows 367 down the data transfer significantly. In addition, if the 368 constrained device uses power saving techniques, a retransmission 369 timeout will incur a wake-up action, in contrast to ACK clock- 370 triggered sending. When the congestion window of a TCP sender has a 371 size of one segment, the TCP sender resets the retransmit timer, and 372 the sender will only be able to send a new packet when the retransmit 373 timer expires [RFC3168]. Effectively, the TCP sender reduces at that 374 moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 375 segment per RTO, which can result in a very low throughput. In 376 addition to better throughput, ECN can also help reducing latency and 377 jitter. 379 ECN can be incrementally deployed in the Internet. Guidance on 380 configuration and usage of ECN is provided in [RFC7567]. Given the 381 benefits, more and more TCP stacks in the Internet support ECN, and 382 it specifically makes sense to leverage ECN in controlled 383 environments such as CNNs. Note, however, that supporting ECN 384 increases implementation complexity. 386 4.1.3. Explicit loss notifications 388 There has been a significant body of research on solutions capable of 389 explicitly indicating whether a TCP segment loss is due to 390 corruption, in order to avoid activation of congestion control 391 mechanisms [ETEN] [RFC2757]. While such solutions may provide 392 significant improvement, they have not been widely deployed and 393 remain as experimental work. In fact, as of today, the IETF has not 394 standardized any such solution. 396 4.2. TCP guidance for single-MSS windows and buffers 398 This section discusses TCP stacks that focus on transferring a single 399 MSS. More general guidance is provided in Section 4.3. 401 4.2.1. Single-MSS stacks - benefits and issues 403 A TCP stack can reduce the memory requirements by advertising a TCP 404 window size of one MSS, and also transmit at most one MSS of 405 unacknowledged data. In that case, both congestion and flow control 406 implementation is quite simple. Such a small receive and send window 407 may be sufficient for simple message exchanges in the CNN space. 408 However, only using a window of one MSS can significantly affect 409 performance. A stop-and-wait operation results in low throughput for 410 transfers that exceed the length of one MSS, e.g., a firmware 411 download. Furthermore, a single-MSS solution relies solely on timer- 412 based loss recovery, therefore missing the performance gain of Fast 413 Retransmit and Fast Recovery (which require a larger window size, see 414 Subsection 4.3.1). 416 If CoAP is used over TCP with the default setting for NSTART in 417 [RFC7252], a CoAP endpoint is not allowed to send a new message to a 418 destination until a response for the previous message sent to that 419 destination has been received. This is equivalent to an application- 420 layer window size of 1. For this use of CoAP, a maximum TCP window 421 of one MSS will be sufficient. 423 4.2.2. TCP options for single-MSS stacks 425 A TCP implementation needs to support, at a minimum, TCP options 2, 1 426 and 0. These are, respectively, the Maximum Segment Size (MSS) 427 option, the No-Operation option, and the End Of Option List marker 428 [RFC0793]. None of these are a substantial burden to support. These 429 options are sufficient for interoperability with a standard-compliant 430 TCP endpoint, albeit many TCP stacks support additional options and 431 can negotiate their use. A TCP implementation is permitted to 432 silently ignore all other TCP options. 434 A TCP implementation for a constrained device that uses a single-MSS 435 TCP receive or transmit window size may not benefit from supporting 436 the following TCP options: Window scale [RFC7323], TCP Timestamps 437 [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted 438 [RFC2018]. Also other TCP options may not be required on a 439 constrained device with a very lightweight implementation. With 440 regard to the Window scale option, note that it is only useful if a 441 window size greater than 64 kB is needed. 443 One potentially relevant TCP option in the context of CNNs is TCP 444 Fast Open (TFO) [RFC7413]. As described in Section 5.3, TFO can be 445 used to address the problem of traversing middleboxes that perform 446 early filter state record deletion. 448 4.2.3. Delayed Acknowledgments for single-MSS stacks 450 TCP Delayed Acknowledgments are meant to reduce the number of ACKs 451 sent within a TCP connection, thus reducing network overhead, but 452 they may increase the time until a sender may receive an ACK. In 453 general, usefulness of Delayed ACKs depends heavily on the usage 454 scenario. There can be interactions with stacks that use single-MSS 455 windows. 457 A device that advertises a single-MSS receive window should avoid use 458 of Delayed ACKs in order to avoid contributing unnecessary delay (of 459 up to 500 ms) to the RTT [RFC5681], which limits the throughput and 460 can increase the data delivery time. 462 A device that can send at most one MSS of data is significantly 463 affected if the receiver uses Delayed ACKs, e.g., if a TCP server or 464 receiver is outside the CNN. One known workaround is to split the 465 data to be sent into two segments of smaller size. A standard 466 compliant TCP receiver will acknowledge the second MSS of data, which 467 can improve throughput. This "split hack" works if the TCP receiver 468 uses Delayed ACKs, but the downside is the overhead of sending two IP 469 packets instead of one. 471 Similar issues happen when the sender uses the Nagle algorithm. 472 Disabling the algorithm will not have impact if the sender can only 473 handle stop-and-wait operation. 475 4.2.4. RTO estimation for single-MSS stacks 477 The Retransmission Timeout (RTO) estimation is one of the fundamental 478 TCP algorithms. There is a fundamental trade-off: A short, 479 aggressive RTO behavior reduces wait time before retransmissions, but 480 it also increases the probability of spurious timeouts. The latter 481 lead to unnecessary waste of potentially scarce resources in CNNs 482 such as energy and bandwidth. In contrast, a conservative timeout 483 can result in long error recovery times and thus needlessly delay 484 data delivery. 486 [RFC6298] describes the standard TCP RTO algorithm. If a TCP sender 487 uses very small window size, and it cannot use Fast Retransmit/Fast 488 Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a 489 larger impact on performance than for a more powerful TCP stack. In 490 that case, RTO algorithm tuning may be considered, although careful 491 assessment of possible drawbacks is recommended 492 [I-D.ietf-tcpm-rto-consider]. 494 As an example, an adaptive RTO algorithm for CoAP over UDP has been 495 defined [I-D.ietf-core-cocoa] that has been found to perform well in 496 CNN scenarios [Commag]. 498 4.3. General recommendations for TCP in CNNs 500 This section summarizes some widely used techniques to improve TCP, 501 with a focus on their use in CNNs. The TCP extensions discussed here 502 are useful in a wide range of network scenarios, including CNNs. 503 This section is not comprehensive. A comprehensive survey of TCP 504 extensions is published in [RFC7414]. 506 4.3.1. Loss recovery and congestion/flow control 508 Devices that have enough memory to allow a larger (i.e. more than 3 509 MSS of data) TCP window size can leverage a more efficient loss 510 recovery than the timer-based approach used for smaller TCP window 511 size (see Subsection 3.2.1) by using Fast Retransmit and Fast 512 Recovery [RFC5681], at the expense of slightly greater complexity and 513 TCB size. Assuming that Delayed ACKs are used by the receiver, the 514 mentioned algorithms work efficiently for window sizes of at least 5 515 MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6 516 the segment 2 gets lost, the sender should get an ACK for segment 1 517 when 3 arrives and duplicate acknowledgements when 4, 5, and 6 518 arrive. It will retransmit segment 2 when the third duplicate ACK 519 arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window 520 has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the 521 size of 5 MSS would require 6100 bytes. 523 For bulk data transfers further TCP improvements may also be useful, 524 such as limited transmit [RFC3042]. 526 4.3.1.1. Selective Acknowledgments (SACK) 528 If a device with less severe memory and processing constraints can 529 afford advertising a TCP window size of several MSS, it makes sense 530 to support the SACK option to improve performance. SACK allows a 531 data receiver to inform the data sender of non-contiguous data blocks 532 received, thus a sender (having previously sent the SACK-Permitted 533 option) can avoid performing unnecessary retransmissions, saving 534 energy and bandwidth, as well as reducing latency. SACK is 535 particularly useful for bulk data transfers. The receiver supporting 536 SACK will need to manage the reception of possible out-of-order 537 received segments, requiring sufficient buffer space. SACK adds 538 8*n+2 bytes to the TCP header, where n denotes the number of data 539 blocks received, up to 4 blocks. For a low number of out-of-order 540 segments, the header overhead penalty of SACK is compensated by 541 avoiding unnecessary retransmissions. 543 4.3.2. Delayed Acknowledgments 545 For certain traffic patterns, Delayed ACKs may have a detrimental 546 effect, as already noted in Section 4.2.3. Advanced TCP stacks may 547 use heuristics to determine the maximum delay for an ACK. For CNNs, 548 the recommendation depends on the expected communication patterns. 550 When traffic over a CNN is expected to mostly be unidirectional 551 messages with a size typically up to one MSS, and the time between 552 two consecutive message transmissions is greater than the delayed ACK 553 timeout, it may make sense to use a small timeout or disable delayed 554 ACKs at the receiver. This avoids incurring additional delay, as 555 well as the energy consumption of the sender (which might e.g. keep 556 its radio interface in receive mode) during that time. Note that 557 disabling delayed ACKs may only be possible if the peer device is 558 administered by the same entity managing the constrained device. For 559 request-response traffic, enabling delayed ACKs is recommended, in 560 order to allow combining a response with the ACK into a single 561 segment, thus increasing efficiency. 563 In contrast, Delayed ACKs allow to reduce the number of ACKs in bulk 564 transfer type of traffic, e.g. for firmware/software updates or for 565 transferring larger data units containing a batch of sensor readings. 567 Note that, in many scenarios, the peer that a constrained device 568 communicates with will be a general purpose system that communicates 569 with both constrained and unconstrained devices. Since delayed ACKs 570 are often configured through system-wide parameters, delayed ACKs 571 behavior at the peer will be the same regardless of the nature of the 572 endpoints it talks to. Such a peer will typically have delayed ACKs 573 enabled. 575 5. TCP usage recommendations in CNNs 577 This section discusses how a TCP stack can be used by applications 578 that are developed for CNN scenarios. These remarks are by and large 579 independent of how TCP is exactly implemented. 581 5.1. TCP connection initiation 583 In the constrained device to unconstrained device scenario 584 illustrated above, a TCP connection is typically initiated by the 585 constrained device, in order for this device to support possible 586 sleep periods to save energy. 588 5.2. Number of concurrent connections 590 TCP endpoints with a small amount of memory may only support a small 591 number of connections. Each TCP connection requires storing a number 592 of variables in the Transmission Control Block (TCB). Depending on 593 the internal TCP implementation, each connection may result in 594 further memory overhead, and connections may compete for scarce 595 resources (e.g. further memory overhead for send and receive buffers, 596 etc). 598 A careful application design may try to keep the number of concurrent 599 connections as small as possible. A client can for instance limit 600 the number of simultaneous open connections that it maintains to a 601 given server. Multiple connections could for instance be used to 602 avoid the "head-of-line blocking" problem in an application transfer. 603 However, in addition to comsuming resources, using multiple 604 connections can also cause undesirable side effects in congested 605 networks. For example, the HTTP/1.1 specification encourages clients 606 to be conservative when opening multiple connections [RFC7230]. 607 Furthermore, each new connection will start with a 3-way handshake, 608 therefore increasing message overhead. 610 Being conservative when opening multiple TCP connections is of 611 particular importance in Constrained-Node Networks. 613 5.3. TCP connection lifetime 615 In order to minimize message overhead, it makes sense to keep a TCP 616 connection open as long as the two TCP endpoints have more data to 617 send. If applications exchange data rather infrequently, i.e., if 618 TCP connections would stay idle for a long time, the idle time can 619 result in problems. For instance, certain middleboxes such as 620 firewalls or NAT devices are known to delete state records after an 621 inactivity interval. RFC 5382 specifies a minimum value for such 622 interval of 124 minutes. A mean TCP NAT binding timeout of 386 623 minutes has been reported, while in some cases, inactivity timeouts 624 are in the order of a few minutes [HomeGateway]. The timeout 625 duration used by a middlebox implementation may not be known to the 626 TCP endpoints. 628 In CNNs, such middleboxes may e.g. be present at the boundary between 629 the CNN and other networks. If the middlebox can be optimized for 630 CNN use cases, it makes sense to increase the initial value for 631 filter state inactivity timers to avoid problems with idle 632 connections. Apart from that, this problem can be dealt with by 633 different connection handling strategies, each having pros and cons. 635 One approach for infrequent data transfer is to use short-lived TCP 636 connections. Instead of trying to maintain a TCP connection for long 637 time, possibly short-lived connections can be opened between two 638 endpoints, which are closed if no more data needs to be exchanged. 639 For use cases that can cope with the additional messages and the 640 latency resulting from starting new connections, it is recommended to 641 use a sequence of short-lived connections, instead of maintaining a 642 single long-lived connection. 644 The message and latency overhead that stems from using a sequence of 645 short-lived connections could be reduced by TCP Fast Open (TFO) 646 [RFC7413], which is an experimental TCP extension, at the expense of 647 increased implementation complexity and increased TCP Control Block 648 (TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) 649 segments, and to be consumed immediately by the receiving endpoint. 650 This reduces the message and latency overhead compared to the 651 traditional three-way handshake to establish a TCP connection. For 652 security reasons, the connection initiator has to request a TFO 653 cookie from the other endpoint. The cookie, with a size of 4 or 16 654 bytes, is then included in SYN packets of subsequent connections. 655 The cookie needs to be refreshed (and obtained by the client) after a 656 certain amount of time. Nevertheless, TFO is more efficient than 657 frequently opening new TCP connections with the traditional three-way 658 handshake, as long as the cookie can be reused in subsequent 659 connections. However, as stated in RFC 7413, TFO deviates from the 660 standard TCP semantics, since the data in the SYN could be replayed 661 to an application in some rare circumstances. Applications should 662 not use TFO unless they can tolerate this issue, e.g., by using 663 Transport Layer Security (TLS) [RFC7413]. A comprehensive discussion 664 on TFO can be found at RFC 7413. 666 Another approach is to use long-lived TCP connections with 667 application-layer heartbeat messages. Various application protocols 668 support such heartbeat messages (e.g. CoAP over TCP [RFC8323]). 669 Periodic application-layer heartbeats can prevent early filter state 670 record deletion in middleboxes. If the TCP binding timeout for a 671 middlebox to be traversed by a given connection is known, middlebox 672 filter state deletion will be avoided if the heartbeat period is 673 lower than the middlebox TCP binding timeout. Otherwise, the 674 implementer needs to take into account that middlebox TCP binding 675 timeouts fall in a wide range of possible values [HomeGateway]. One 676 specific advantage of Heartbeat messages is that they also allow 677 aliveness checks at the application level. In general, it makes 678 sense to realize aliveness checks at the highest protocol layer 679 possible that is meaningful to the application, in order to maximize 680 the depth of the aliveness check. In addition, timely detection of a 681 dead peer may allow savings in terms of TCB memory use. However, the 682 transmission of heartbeat messages consumes resources. This aspect 683 needs to be assessed carefully, considering the characteristics of 684 each specific CNN. 686 A TCP implementation may also be able to send "keep-alive" segments 687 to test a TCP connection. According to [RFC1122], "keep-alives" are 688 an optional TCP mechanism that is turned off by default, i.e., an 689 application must explicitly enable it for a TCP connection. The 690 interval between "keep-alive" messages must be configurable and it 691 must default to no less than two hours. With this large timeout, TCP 692 keep-alive messages might not always be useful to avoid deletion of 693 filter state records in some middleboxes. However, sending TCP keep- 694 alive probes more frequently risks draining power on energy- 695 constrained devices. 697 6. Security Considerations 699 Best current practise for securing TCP and TCP-based communication 700 also applies to CNN. As example, use of Transport Layer Security 701 (TLS) is strongly recommended if it is applicable. 703 There are also TCP options which can improve TCP security. One 704 example is the TCP Authentication Option (TCP-AO) [RFC5925]. 705 However, this option adds overhead and complexity. TCP-AO typically 706 has a size of 16-20 bytes. 708 For the mechanisms discussed in this document, the corresponding 709 considerations apply. For instance, if TFO is used, the security 710 considerations of [RFC7413] apply. 712 Constrained devices are expected to support smaller TCP window sizes 713 than less limited devices. In such conditions, segment 714 retransmission triggered by RTO expiration is expected to be 715 relatively frequent, due to lack of (enough) duplicate ACKs, 716 especially when a constrained device uses a single-MSS window size. 717 For this reason, constrained devices running TCP may appear as 718 particularly appealing victims of the so-called "shrew" Denial of 719 Service (DoS) attack [shrew], whereby one or more sources generate a 720 packet spike targetted to coincide with consecutive RTO-expiration- 721 triggered retry attempts of a victim node. Note that the attack may 722 be performed by Internet-connected devices, including constrained 723 devices in the same CNN as the victim, as well as remote ones. 724 Mitigation techniques include RTO randomization and attack blocking 725 by routers able to detect shrew attacks based on their traffic 726 pattern. 728 7. Acknowledgments 730 Carles Gomez has been funded in part by the Spanish Government 731 (Ministerio de Educacion, Cultura y Deporte) through the Jose 732 Castillejo grants CAS15/00336 and and CAS18/00170, and by European 733 Regional Development Fund (ERDF) and the Spanish Government through 734 project TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to 735 this work has been carried out during his stays as a visiting scholar 736 at the Computer Laboratory of the University of Cambridge. 738 The authors appreciate the feedback received for this document. The 739 following folks provided comments that helped improve the document: 740 Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan 741 Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred 742 Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes 743 Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen, Emmanuel 744 Baccelli, and Stuart Cheshire. Simon Brummer provided details, and 745 kindly performed RAM and ROM usage measurements, on the RIOT TCP 746 implementation. Xavi Vilajosana provided details on the OpenWSN TCP 747 implementation. Rahul Jadhav kindly performed code size measurements 748 on the Contiki-NG and lwIP 2.1.2 TCP implementations. He also 749 provided details on the uIP TCP implementation. 751 8. Annex. TCP implementations for constrained devices 753 This section overviews the main features of TCP implementations for 754 constrained devices. The survey is limited to open source stacks 755 with small footprint. It is not meant to be all-encompassing. For 756 more powerful embedded systems (e.g., with 32-bit processors), there 757 are further stacks that comprehensively implement TCP. On the other 758 hand, please be aware that this Annex is based on information 759 available as of the writing. 761 8.1. uIP 763 uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers, 764 which pioneered TCP/IP implementations for constrained devices. uIP 765 has been deployed with Contiki and the Arduino Ethernet shield. A 766 code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) 767 has been reported for uIP [Dunk]. 769 uIP uses the same global buffer for both incoming and outgoing 770 traffic, which has a size of a single packet. In case of a 771 retransmission, an application must be able to reproduce the same 772 user data that had been transmitted. Multiple connections are 773 supported, but need to share the global buffer. 775 The MSS is announced via the MSS option on connection establishment 776 and the receive window size (of one MSS) is not modified during a 777 connection. Stop-and-wait operation is used for sending data. Among 778 other optimizations, this allows to avoid sliding window operations, 779 which use 32-bit arithmetic extensively and are expensive on 8-bit 780 CPUs. 782 Contiki uses the "split hack" technique (see Section 4.2.3) to avoid 783 Delayed ACKs for senders using a single segment. 785 The code size of the TCP implementation in Contiki-NG has been 786 measured to be of 3.2 kB on CC2538DK, cross-compiling on Linux. 788 8.2. lwIP 790 lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. 791 lwIP has a total code size of ~14 kB to ~22 kB (which comprises 792 memory management, checksumming, network interfaces, IP, ICMP and 793 TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. 795 In contrast with uIP, lwIP decouples applications from the network 796 stack. lwIP supports a TCP transmission window greater than a single 797 segment, as well as buffering of incoming and outcoming data. Other 798 implemented mechanisms comprise slow start, congestion avoidance, 799 fast retransmit and fast recovery. SACK and Window Scale support has 800 been recently added to lwIP. 802 8.3. RIOT 804 The RIOT TCP implementation (called GNRC TCP) has been designed for 805 Class 1 devices [RFC 7228]. The main target platforms are 8- and 806 16-bit microcontrollers, with 32-bit platforms also supported. GNRC 807 TCP offers a similar function set as uIP, but it provides and 808 maintains an independent receive buffer for each connection. In 809 contrast to uIP, retransmission is also handled by GNRC TCP. GNRC 810 TCP uses a single-MSS window size, which simplifies the 811 implementation. The application programmer does not need to know 812 anything about the TCP internals, therefore GNRC TCP can be seen as a 813 user-friendly uIP TCP implementation. 815 The MSS is set on connections establishment and cannot be changed 816 during connection lifetime. GNRC TCP allows multiple connections in 817 parallel, but each TCB must be allocated somewhere in the system. By 818 default there is only enough memory allocated for a single TCP 819 connection, but it can be increased at compile time if the user needs 820 multiple parallel connections. 822 The RIOT TCP implementation offers an optional POSIX socket wrapper 823 that enables POSIX compliance, if needed. 825 Further details on RIOT and GNRC can be found in the literature 826 [RIOT], [GNRC]. 828 8.4. TinyOS 830 TinyOS was important as platform for early constrained devices. 831 TinyOS has an experimental TCP stack that uses a simple nonblocking 832 library-based implementation of TCP, which provides a subset of the 833 socket interface primitives. The application is responsible for 834 buffering. The TCP library does not do any receive-side buffering. 835 Instead, it will immediately dispatch new, in-order data to the 836 application and otherwise drop the segment. A send buffer is 837 provided by the application. Multiple TCP connections are possible. 838 Recently there has been little further work on the stack. 840 8.5. FreeRTOS 842 FreeRTOS is a real-time operating system kernel for embedded devices 843 that is supported by 16- and 32-bit microprocessors. Its TCP 844 implementation is based on multiple-segment window size, although a 845 'Tiny-TCP' option, which is a single-MSS variant, can be enabled. 846 Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a 847 technique intended 'to gain performance'. 849 8.6. uC/OS 851 uC/OS is a real-time operating system kernel for embedded devices, 852 which is maintained by Micrium. uC/OS is intended for 8-, 16- and 853 32-bit microprocessors. The uC/OS TCP implementation supports a 854 multiple-segment window size. 856 8.7. Summary 858 +---+---------+--------+----+------+--------+-----+ 859 |uIP|lwIP orig|lwIP 2.1|RIOT|TinyOS|FreeRTOS|uC/OS| 860 +------+-------------+---+---------+--------+----+------+--------+-----+ 861 |Memory|Code size(kB)| <5|~9 to ~14| 38 | <7 | N/A | <9.2 | N/A | 862 | | |(a)| (T1) | (T4) |(T3)| | (T2) | | 863 +------+-------------+---+---------+--------+----+------+--------+-----+ 864 | | Single-Segm.|Yes| No | No | Yes| No | No | No | 865 | +-------------+---+---------+--------+----+------+--------+-----+ 866 | | Slow start | No| Yes | Yes | No | Yes | No | Yes | 867 | T +-------------+---+---------+--------+----+------+--------+-----+ 868 | C |Fast rec/retx| No| Yes | Yes | No | Yes | No | Yes | 869 | P +-------------+---+---------+--------+----+------+--------+-----+ 870 | | Keep-alive | No| No | Yes | No | No | Yes | Yes | 871 | +-------------+---+---------+--------+----+------+--------+-----+ 872 | f | Win. Scale | No| No | Yes | No | No | Yes | No | 873 | e +-------------+---+---------+--------+----+------+--------+-----+ 874 | a | TCP timest.| No| No | Yes | No | No | Yes | No | 875 | t +-------------+---+---------+--------+----+------+--------+-----+ 876 | u | SACK | No| No | Yes | No | No | Yes | No | 877 | r +-------------+---+---------+--------+----+------+--------+-----+ 878 | e | Del. ACKs | No| Yes | Yes | No | No | Yes | Yes | 879 | s +-------------+---+---------+--------+----+------+--------+-----+ 880 | | Socket | No| No |Optional|(I) |Subset| Yes | Yes | 881 | +-------------+---+---------+--------+----+------+--------+-----+ 882 | |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes | 883 +------+-------------+---+---------+--------+----+------+--------+-----+ 884 | TLS supported | No| No | Yes | Yes| Yes | Yes | Yes | 885 +--------------------+---+---------+--------+----+------+--------+-----+ 887 (T1) = TCP-only, on x86 and AVR platforms 888 (T2) = TCP-only, on ARM Cortex-M platform 889 (T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same platform 890 is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional connection) 891 (T4) = TCP-only, on CC2538DK, cross-compiling on Linux 892 (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 893 (I) = optional POSIX socket wrapper which enables POSIX compliance if needed 894 Mult. = Multiple 895 N/A = Not Available 897 Figure 2: Summary of TCP features for differrent lightweight TCP 898 implementations. None of the implementations considered in this 899 Annex support ECN or TFO. 901 9. Annex. Changes compared to previous versions 903 RFC Editor: To be removed prior to publication 905 9.1. Changes between -00 and -01 907 o Changed title and abstract 909 o Clarification that communcation with standard-compliant TCP 910 endpoints is required, based on feedback from Joe Touch 912 o Additional discussion on communication patters 914 o Numerous changes to address a comprehensive review from Hannes 915 Tschofenig 917 o Reworded security considerations 919 o Additional references and better distinction between normative and 920 informative entries 922 o Feedback from Rahul Jadhav on the uIP TCP implementation 924 o Basic data for the TinyOS TCP implementation added, based on 925 source code analysis 927 9.2. Changes between -01 and -02 929 o Added text to the Introduction section, and a reference, on 930 traditional bad perception of TCP for IoT 932 o Added sections on FreeRTOS and uC/OS 934 o Updated TinyOS section 936 o Updated summary table 938 o Reorganized Section 4 (single-MSS vs multiple-MSS window size), 939 some content now also in new Section 5 941 9.3. Changes between -02 and -03 943 o Rewording to better explain the benefit of ECN 945 o Additional context information on the surveyed implementations 947 o Added details, but removed "Data size" raw, in the summary table 948 o Added discussion on shrew attacks 950 9.4. Changes between -03 and -04 952 o Addressing the remaining TODOs 954 o Alignment of the wording on TCP "keep-alives" with related 955 discussions in the IETF transport area 957 o Added further discussion on delayed ACKs 959 o Removed OpenWSN subsection from the Annex 961 9.5. Changes between -04 and -05 963 o Addressing comments by Yoshifumi Nishida 965 o Removed mentioning MD5 as an example (comment by David Black) 967 o Added memory footprint details of TCP implementations (Contiki-NG 968 and lwIP 2.1.2) provided by Rahul Jadhav in the Annex 970 o Addressed comments by Ilpo Jarvinen throughout the whole document 972 o Improved the RIOT section in the Annex, based on feedback from 973 Emmanuel Baccelli 975 9.6. Changes between -05 and -06 977 o Incorporated suggestions by Stuart Cheshire 979 9.7. Changes between -06 and -07 981 o Addressed comments by Gorry Fairhurst 983 10. References 985 10.1. Normative References 987 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 988 RFC 793, DOI 10.17487/RFC0793, September 1981, 989 . 991 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 992 Communication Layers", STD 3, RFC 1122, 993 DOI 10.17487/RFC1122, October 1989, 994 . 996 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 997 Selective Acknowledgment Options", RFC 2018, 998 DOI 10.17487/RFC2018, October 1996, 999 . 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, 1003 DOI 10.17487/RFC2119, March 1997, 1004 . 1006 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1007 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1008 December 1998, . 1010 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 1011 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 1012 DOI 10.17487/RFC3042, January 2001, 1013 . 1015 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1016 of Explicit Congestion Notification (ECN) to IP", 1017 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1018 . 1020 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1021 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1022 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1023 RFC 3819, DOI 10.17487/RFC3819, July 2004, 1024 . 1026 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1027 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1028 . 1030 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1031 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1032 June 2010, . 1034 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1035 "Computing TCP's Retransmission Timer", RFC 6298, 1036 DOI 10.17487/RFC6298, June 2011, 1037 . 1039 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1040 Constrained-Node Networks", RFC 7228, 1041 DOI 10.17487/RFC7228, May 2014, 1042 . 1044 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1045 Scheffenegger, Ed., "TCP Extensions for High Performance", 1046 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1047 . 1049 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1050 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1051 . 1053 10.2. Informative References 1055 [Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP 1056 Congestion Control for the Internet of Things", IEEE 1057 Communications Magazine, June 2016. 1059 [Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003. 1061 [ETEN] R. Krishnan et al, "Explicit transport error notification 1062 (ETEN) for error-prone wireless and satellite networks", 1063 Computer Networks 2004. 1065 [GNRC] M. Lenders et al., "Connecting the World of Embedded 1066 Mobiles: The RIOTApproach to Ubiquitous Networking for the 1067 IoT", 2018. 1069 [HomeGateway] 1070 Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., 1071 Sarolahti, P., and M. Kojo, "An Experimental Study of Home 1072 Gateway Characteristics", Proceedings of the 10th ACM 1073 SIGCOMM conference on Internet measurement 2010. 1075 [I-D.delcarpio-6lo-wlanah] 1076 Vega, L., Robles, I., and R. Morabito, "IPv6 over 1077 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 1078 progress), October 2015. 1080 [I-D.ietf-core-cocoa] 1081 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1082 "CoAP Simple Congestion Control/Advanced", draft-ietf- 1083 core-cocoa-03 (work in progress), February 2018. 1085 [I-D.ietf-tcpm-rto-consider] 1086 Allman, M., "Retransmission Timeout Requirements", draft- 1087 ietf-tcpm-rto-consider-08 (work in progress), February 1088 2019. 1090 [IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the 1091 Internet of Things: from ostracism to prominence", IEEE 1092 Internet Computing, January-February 2018. 1094 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 1095 Vaidya, "Long Thin Networks", RFC 2757, 1096 DOI 10.17487/RFC2757, January 2000, 1097 . 1099 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 1100 Explicit Congestion Notification (ECN) in IP Networks", 1101 RFC 2884, DOI 10.17487/RFC2884, July 2000, 1102 . 1104 [RFC3481] Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov, 1105 A., and F. Khafizov, "TCP over Second (2.5G) and Third 1106 (3G) Generation Wireless Networks", BCP 71, RFC 3481, 1107 DOI 10.17487/RFC3481, February 2003, 1108 . 1110 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1111 "Transmission of IPv6 Packets over IEEE 802.15.4 1112 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1113 . 1115 [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. 1116 Briscoe, "Open Research Issues in Internet Congestion 1117 Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, 1118 . 1120 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1121 Capabilities in Customer Premises Equipment (CPE) for 1122 Providing Residential IPv6 Internet Service", RFC 6092, 1123 DOI 10.17487/RFC6092, January 2011, 1124 . 1126 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1127 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1128 March 2011, . 1130 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1131 Statement and Requirements for IPv6 over Low-Power 1132 Wireless Personal Area Network (6LoWPAN) Routing", 1133 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1134 . 1136 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1137 Protocol (HTTP/1.1): Message Syntax and Routing", 1138 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1139 . 1141 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1142 Application Protocol (CoAP)", RFC 7252, 1143 DOI 10.17487/RFC7252, June 2014, 1144 . 1146 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1147 Zimmermann, "A Roadmap for Transmission Control Protocol 1148 (TCP) Specification Documents", RFC 7414, 1149 DOI 10.17487/RFC7414, February 2015, 1150 . 1152 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1153 over ITU-T G.9959 Networks", RFC 7428, 1154 DOI 10.17487/RFC7428, February 2015, 1155 . 1157 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1158 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1159 DOI 10.17487/RFC7540, May 2015, 1160 . 1162 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1163 Recommendations Regarding Active Queue Management", 1164 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1165 . 1167 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1168 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1169 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1170 . 1172 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1173 Explicit Congestion Notification (ECN)", RFC 8087, 1174 DOI 10.17487/RFC8087, March 2017, 1175 . 1177 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1178 M., and D. Barthel, "Transmission of IPv6 Packets over 1179 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1180 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1181 2017, . 1183 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1184 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1185 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1186 May 2017, . 1188 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1189 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1190 DOI 10.17487/RFC8201, July 2017, 1191 . 1193 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1194 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1195 Application Protocol) over TCP, TLS, and WebSockets", 1196 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1197 . 1199 [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., 1200 "Energy-Efficient Features of Internet of Things 1201 Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, 1202 . 1204 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1205 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1206 . 1208 [RIOT] E. Baccelli et al., "RIOT: an Open Source Operating 1209 Systemfor Low-end Embedded Devices in the IoT", 2018. 1211 [shrew] A. Kuzmanovic, E. Knightly, "Low-Rate TCP-Targeted Denial 1212 of Service Attacks", SIGCOMM'03 2003. 1214 Authors' Addresses 1216 Carles Gomez 1217 UPC 1218 C/Esteve Terradas, 7 1219 Castelldefels 08860 1220 Spain 1222 Email: carlesgo@entel.upc.edu 1223 Jon Crowcroft 1224 University of Cambridge 1225 JJ Thomson Avenue 1226 Cambridge, CB3 0FD 1227 United Kingdom 1229 Email: jon.crowcroft@cl.cam.ac.uk 1231 Michael Scharf 1232 Hochschule Esslingen 1233 Flandernstr. 101 1234 Esslingen 73732 1235 Germany 1237 Email: michael.scharf@hs-esslingen.de