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