idnits 2.17.1 draft-ietf-lwig-tcp-constrained-node-networks-03.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 28 instances of too long lines in the document, the longest one being 19 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 (June 10, 2018) is 2147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7228' is mentioned on line 699, but not defined == Unused Reference: 'I-D.ietf-core-coap-tcp-tls' is defined on line 934, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: December 12, 2018 University of Cambridge 6 M. Scharf 7 Nokia 8 June 10, 2018 10 TCP Usage Guidance in the Internet of Things (IoT) 11 draft-ietf-lwig-tcp-constrained-node-networks-03 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 December 12, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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) . . . . . . . 7 68 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8 69 4.2. TCP guidance for small windows and buffers . . . . . . . 8 70 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 8 71 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9 72 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 9 73 4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 10 74 4.3. General recommendations for TCP in CNNs . . . . . . . . . 10 75 4.3.1. Error recovery and congestion/flow control . . . . . 10 76 4.3.2. Selective Acknowledgments (SACK) . . . . . . . . . . 11 77 4.3.3. Delayed Acknowledgments . . . . . . . . . . . . . . . 11 78 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 11 79 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12 80 5.2. TCP connection lifetime . . . . . . . . . . . . . . . . . 12 81 5.2.1. Long TCP connection lifetime . . . . . . . . . . . . 12 82 5.2.2. Short TCP connection lifetime . . . . . . . . . . . . 12 83 5.3. Number of parallel connections . . . . . . . . . . . . . 13 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 86 8. Annex. TCP implementations for constrained devices . . . . . 14 87 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 8.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 8.6. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16 93 8.7. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 8.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 9. Annex. Changes compared to previous versions . . . . . . . . 17 96 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 18 97 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 18 98 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 18 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 10.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 The Internet Protocol suite is being used for connecting Constrained- 107 Node Networks (CNNs) to the Internet, enabling the so-called Internet 108 of Things (IoT) [RFC7228]. In order to meet the requirements that 109 stem from CNNs, the IETF has produced a suite of new protocols 110 specifically designed for such environments (see e.g. 111 [I-D.ietf-lwig-energy-efficient]). New IETF protocol stack 112 components include the IPv6 over Low-power Wireless Personal Area 113 Networks (6LoWPAN) adaptation layer, the IPv6 Routing Protocol for 114 Low-power and lossy networks (RPL) routing protocol, and the 115 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 [RFC7540] [RFC2616], 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 RAM 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 188 [I-D.ietf-lwig-energy-efficient], as well as minimization of the 189 number of messages transmitted/received (and 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 Some link layer technologies in the CNN space are characterized by a 290 short data unit payload size, e.g. up to a few tens or hundreds of 291 bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 292 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE 293 802.15.4 networks. The adaptation layer includes a fragmentation 294 mechanism, since IPv6 requires the layer below to support an MTU of 295 1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation 296 mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes 297 [RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T 298 G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based 299 adaptation layers in order to enable IPv6 support. These 300 technologies do support link layer fragmentation. By exploiting this 301 functionality, the adaptation layers that enable IPv6 over such 302 technologies also define an MTU of 1280 bytes. 304 On the other hand, there exist technologies also used in the CNN 305 space, such as Master Slave / Token Passing (TP) [RFC8163], 306 Narrowband IoT (NB-IoT) [I-D.ietf-lpwan-overview] or IEEE 802.11ah 307 [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of 308 frame size limitations as the technologies mentioned above. The MTU 309 for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- 310 IoT is 1600 bytes, and the maximum frame payload size for IEEE 311 802.11ah is 7991 bytes. 313 For the sake of lightweight implementation and operation, unless 314 applications require handling large data units (i.e. leading to an 315 IPv6 datagram size greater than 1280 bytes), it may be desirable to 316 limit the MTU to 1280 bytes in order to avoid the need to support 317 Path MTU Discovery [RFC1981]. 319 An IPv6 datagram size exceeding 1280 bytes can be avoided by setting 320 the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is 321 assumed.) 323 4.1.2. Explicit Congestion Notification (ECN) 325 Explicit Congestion Notification (ECN) [RFC3168] has a number of 326 benefits that are relevant for CNNs. ECN allows a router to signal 327 in the IP header of a packet that congestion is arising, for example 328 when a queue size reaches a certain threshold. An ECN-enabled TCP 329 receiver will echo back the congestion signal to the TCP sender by 330 setting a flag in its next TCP ACK. The sender triggers congestion 331 control measures as if a packet loss had happened. ECN can be 332 incrementally deployed in the Internet. Guidance on configuration 333 and usage of ECN is provided in [RFC7567]. The document [RFC8087] 334 outlines the principal gains in terms of increased throughput, 335 reduced delay, and other benefits when ECN is used over a network 336 path that includes equipment that supports Congestion Experienced 337 (CE) marking. 339 ECN can reduce packet losses since congestion control measures can be 340 applied earlier [RFC2884]. Less lost packets implies that the number 341 of retransmitted segments decreases, which is particularly beneficial 342 in CNNs, where energy and bandwidth resources are typically limited. 343 Also, it makes sense to try to avoid packet drops for transactional 344 workloads with small data sizes, which are typical for CNNs. In such 345 traffic patterns, it is more difficult to detect packet loss without 346 retransmission timeouts (e.g., as there may be no three duplicate 347 ACKs). Any retransmission timeout slows down the data transfer 348 significantly. When the congestion window of a TCP sender has a size 349 of one segment, the TCP sender resets the retransmit timer, and the 350 sender will only be able to send a new packet when the retransmit 351 timer expires [RFC3168]. Effectively, the TCP sender reduces at that 352 moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 353 segment per RTO, which can result in a very low throughput. In 354 addition to better throughput, ECN can also help reducing latency and 355 jitter. 357 Given the benefits, more and more TCP stacks in the Internet support 358 ECN, and it specifically makes sense to leverage ECN in controlled 359 environments such as CNNs. 361 4.1.3. Explicit loss notifications 363 There has been a significant body of research on solutions capable of 364 explicitly indicating whether a TCP segment loss is due to 365 corruption, in order to avoid activation of congestion control 366 mechanisms [ETEN] [RFC2757]. While such solutions may provide 367 significant improvement, they have not been widely deployed and 368 remain as experimental work. In fact, as of today, the IETF has not 369 standardized any such solution. 371 4.2. TCP guidance for small windows and buffers 373 This section discusses TCP stacks that focus on transferring a single 374 MSS. More general guidance is provided in Section 4.3. 376 4.2.1. Single-MSS stacks - benefits and issues 378 A TCP stack can reduce the RAM requirements by advertising a TCP 379 window size of one MSS, and also transmit at most one MSS of 380 unacknowledged data. In that case, both congestion and flow control 381 implementation is quite simple. Such a small receive and send window 382 may be sufficient for simple message exchanges in the CNN space. 383 However, only using a window of one MSS can significantly affect 384 performance. A stop-and-wait operation results in low throughput for 385 transfers that exceed the lengths of one MSS, e.g., a firmware 386 download. 388 If CoAP is used over TCP with the default setting for NSTART in 389 [RFC7252], a CoAP endpoint is not allowed to send a new message to a 390 destination until a response for the previous message sent to that 391 destination has been received. This is equivalent to an application- 392 layer window size of 1. For this use of CoAP, a maximum TCP window 393 of one MSS will be sufficient. 395 4.2.2. TCP options for single-MSS stacks 397 A TCP implementation needs to support options 0, 1 and 2 [RFC0793]. 398 These options are sufficient for interoperability with a standard- 399 compliant TCP endpoint, albeit many TCP stacks support additional 400 options and can negotiate their use. 402 A TCP implementation for a constrained device that uses a single-MSS 403 TCP receive or transmit window size may not benefit from supporting 404 the following TCP options: Window scale [RFC1323], TCP Timestamps 405 [RFC1323], Selective Acknowledgments (SACK) and SACK-Permitted 406 [RFC2018]. Also other TCP options may not be required on a 407 constrained device with a very lightweight implementation. 409 One potentially relevant TCP option in the context of CNNs is TCP 410 Fast Open (TFO) [RFC7413]. As described in Section 5.2.2, TFO can be 411 used to address the problem of traversing middleboxes that perform 412 early filter state record deletion. 414 4.2.3. Delayed Acknowledgments for single-MSS stacks 416 TCP Delayed Acknowledgments are meant to reduce the number of 417 transferred bytes within a TCP connection, but they may increase the 418 time until a sender may receive an ACK. There can be interactions 419 with stacks that use very small windows. 421 A device that advertises a single-MSS receive window should avoid use 422 of delayed ACKs in order to avoid contributing unnecessary delay (of 423 up to 500 ms) to the RTT [RFC5681], which limits the throughput and 424 can increase the data delivery time. 426 A device that can send at most one MSS of data is significantly 427 affected if the receiver uses delayed ACKs, e.g., if a TCP server or 428 receiver is outside the CNN. One known workaround is to split the 429 data to be sent into two segments of smaller size. A standard 430 compliant TCP receiver will then immediately acknowledge the second 431 segment, which can improve throughput. This "split hack" works if 432 the TCP receiver uses Delayed Acks, but the downside is the overhead 433 of sending two IP packets instead of one. 435 4.2.4. RTO estimation for single-MSS stacks 437 The Retransmission Timeout (RTO) estimation is one of the fundamental 438 TCP algorithms. There is a fundamental trade-off: A short, 439 aggressive RTO behavior reduces wait time before retransmissions, but 440 it also increases the probability of spurious timeouts. The latter 441 lead to unnecessary waste of potentially scarce resources in CNNs 442 such as energy and bandwidth. In contrast, a conservative timeout 443 can result in long error recovery times and thus needlessly delay 444 data delivery. 446 [RFC6298] describes the standard TCP RTO algorithm. If a TCP sender 447 uses very small window size and cannot use Fast Retransmit/Fast 448 Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a 449 larger impact on performance than for a more powerful TCP stack. In 450 that case, RTO algorithm tuning may be considered, although careful 451 assessment of possible drawbacks is recommended. 453 As an example, an adaptive RTO algorithm for CoAP over UDP has been 454 defined [I-D.ietf-core-cocoa] that has been found to perform well in 455 CNN scenarios [Commag]. 457 4.3. General recommendations for TCP in CNNs 459 This section summarizes some widely used techniques to improve TCP, 460 with a focus on their use in CNNs. The TCP extensions discussed here 461 are useful in a wide range of network scenarios, including CNNs. 462 This section is not comprehensive. A comprehensive survey of TCP 463 extensions is published in [RFC7414]. 465 4.3.1. Error recovery and congestion/flow control 467 Devices that have enough memory to allow larger TCP window size can 468 leverage a more efficient error recovery using Fast Retransmit and 469 Fast Recovery [RFC5681]. These algorithms work efficiently for 470 window sizes of at least 5 MSS: If in a given TCP transmission of 471 segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should 472 get an acknowledgement for segment 1 when 3 arrives and duplicate 473 acknowledgements when 4, 5, and 6 arrive. It will retransmit segment 474 2 when the third duplicate ack arrives. In order to have segment 2, 475 3, 4, 5, and 6 sent, the window has to be at least five. With an MSS 476 of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte. 478 For bulk data transfers further TCP improvements may also be useful, 479 such as limited transmit [RFC3042]. 481 4.3.2. Selective Acknowledgments (SACK) 483 If a device with less severe memory and processing constraints can 484 afford advertising a TCP window size of several MSSs, it makes sense 485 to support the SACK option to improve performance. SACK allows a 486 data receiver to inform the data sender of non-contiguous data blocks 487 received, thus a sender (having previously sent the SACK-Permitted 488 option) can avoid performing unnecessary retransmissions, saving 489 energy and bandwidth, as well as reducing latency. SACK is 490 particularly useful for bulk data transfers. The receiver supporting 491 SACK will need to manage the reception of possible out-of-order 492 received segments, requiring sufficient buffer space. SACK adds 493 8*n+2 bytes to the TCP header, where n denotes the number of data 494 blocks received, up to 4 blocks. For a low number of out-of-order 495 segments, the header overhead penalty of SACK is compensated by 496 avoiding unnecessary retransmissions. 498 4.3.3. Delayed Acknowledgments 500 For certain traffic patterns, Delayed Acknowledgements may have a 501 detrimental effect, as already noted in Section 4.2.3. Advanced TCP 502 stacks may use heuristics to determine the maximum delay for an ACK. 503 For CNNs, the recommendation depends on the expected communication 504 patterns. 506 If a stack is able to deal with more than one MSS of data, it may 507 make sense to use a small timeout or disable delayed ACKs when 508 traffic over a CNN is expected to mostly be small messages with a 509 size typically below one MSS. For request-response traffic between a 510 constrained device and a peer (e.g. backend infrastructure) that uses 511 delayed ACKs, the maximum ACK rate of the peer will be typically of 512 one ACK every 200 ms (or even lower). If in such conditions the peer 513 device is administered by the same entity managing the constrained 514 device, it is recommended to disable delayed ACKs at the peer side. 516 In contrast, delayed ACKs allow to reduce the number of ACKs in bulk 517 transfer type of traffic, e.g. for firmware/software updates or for 518 transferring larger data units containing a batch of sensor readings. 520 5. TCP usage recommendations in CNNs 522 This section discusses how a TCP stack can be used by applications 523 that are developed for CNN scenarios. These remarks are by and large 524 independent of how TCP is exactly implemented. 526 5.1. TCP connection initiation 528 In the constrained device to unconstrained device scenario 529 illustrated above, a TCP connection is typically initiated by the 530 constrained device, in order for this device to support possible 531 sleep periods to save energy. 533 5.2. TCP connection lifetime 535 [[TODO: This section may need rewording in the next revision.]] 537 5.2.1. Long TCP connection lifetime 539 In CNNs, in order to minimize message overhead, a TCP connection 540 should be kept open as long as the two TCP endpoints have more data 541 to exchange or it is envisaged that further segment exchanges will 542 take place within an interval of two hours since the last segment has 543 been sent. A greater interval may be used in scenarios where 544 applications exchange data infrequently. 546 TCP keep-alive messages [RFC1122] may be supported by a server, to 547 check whether a TCP connection is active, in order to release state 548 of inactive connections. This may be useful for servers running on 549 memory-constrained devices. 551 Since the keep-alive timer may not be set to a value lower than two 552 hours [RFC1122], TCP keep-alive messages are not useful to guarantee 553 that filter state records in middleboxes such as firewalls will not 554 be deleted after an inactivity interval typically in the order of a 555 few minutes [RFC6092]. In scenarios where such middleboxes are 556 present, alternative measures to avoid early deletion of filter state 557 records (which might lead to frequent establishment of new TCP 558 connections between the two involved endpoints) include increasing 559 the initial value for the filter state inactivity timers (if 560 possible), and using application layer heartbeat messages. 562 5.2.2. Short TCP connection lifetime 564 A different approach to addressing the problem of traversing 565 middleboxes that perform early filter state record deletion relies on 566 using TFO [RFC7413]. In this case, instead of trying to maintain a 567 TCP connection for long time, possibly short-lived connections can be 568 opened between two endpoints while incurring low overhead. In fact, 569 TFO allows data to be carried in SYN (and SYN-ACK) packets, and to be 570 consumed immediately by the receceiving endpoint, thus reducing 571 overhead compared with the traditional three-way handshake required 572 to establish a TCP connection. 574 For security reasons, TFO requires the TCP endpoint that will open 575 the TCP connection (which in CNNs will typically be the constrained 576 device) to request a cookie from the other endpoint. The cookie, 577 with a size of 4 or 16 bytes, is then included in SYN packets of 578 subsequent connections. The cookie needs to be refreshed (and 579 obtained by the client) after a certain amount of time. 580 Nevertheless, TFO is more efficient than frequently opening new TCP 581 connections (by using the traditional three-way handshake) for 582 transmitting new data, as long as the cookie update rate is well 583 below the data new connection rate. 585 5.3. Number of parallel connections 587 [[TODO: This has been added in -02 but needs further alignment]] 589 TCP endpoints with a small amount of RAM may only support a small 590 number of connections. Each connection may result in overhead, and 591 depending on the internal TCP implementation, they may compete for 592 scarce resources. A careful application design may try to keep the 593 number of parallel connections as small as possible. 595 6. Security Considerations 597 Best current practise for securing TCP and TCP-based communication 598 also applies to CNN. As example, use of Transport Layer Security 599 (TLS) is strongly recommended if it is applicable. 601 There are also TCP options which can improve TCP security. Examples 602 include the TCP MD5 signature option [RFC2385] and the TCP 603 Authentication Option (TCP-AO) [RFC5925]. However, both options add 604 overhead and complexity. The TCP MD5 signature option adds 18 bytes 605 to every segment of a connection. TCP-AO typically has a size of 606 16-20 bytes. 608 For the mechanisms discussed in this document, the corresponding 609 considerations apply. For instance, if TFO is used, the security 610 considerations of [RFC7413] apply. 612 Constrained devices are expected to support smaller TCP window sizes 613 than less limited devices. In such conditions, segment 614 retransmission triggered by RTO expiration is expected to be 615 relatively frequent, due to lack of (enough) duplicate ACKs, 616 especially when a constrained device uses a single-MSS window size. 617 For this reason, constrained devices running TCP may appear as 618 particularly appealing victims of the so-called "shrew" Denial of 619 Service (DoS) attack [shrew], whereby one or more sources generate a 620 packet spike targetted to coincide with consecutive RTO-expiration- 621 triggered retry attempts of a victim node. Note that the attack may 622 be performed by Internet-connected devices, including constrained 623 devices in the same CNN as the victim, as well as remote ones. 624 Mitigation techniques include RTO randomization and attack blocking 625 by routers able to detect shrew attacks based on their traffic 626 pattern. 628 7. Acknowledgments 630 Carles Gomez has been funded in part by the Spanish Government 631 (Ministerio de Educacion, Cultura y Deporte) through the Jose 632 Castillejo grant CAS15/00336 and by European Regional Development 633 Fund (ERDF) and the Spanish Government through project 634 TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this 635 work has been carried out during his stay as a visiting scholar at 636 the Computer Laboratory of the University of Cambridge. 638 The authors appreciate the feedback received for this document. The 639 following folks provided comments that helped improve the document: 640 Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan 641 Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred 642 Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and 643 Hannes Tschofenig. Simon Brummer provided details, and kindly 644 performed RAM and ROM usage measurements, on the RIOT TCP 645 implementation. Xavi Vilajosana provided details on the OpenWSN TCP 646 implementation. Rahul Jadhav provided details on the uIP TCP 647 implementation. 649 8. Annex. TCP implementations for constrained devices 651 This section overviews the main features of TCP implementations for 652 constrained devices. The survey is limited to open source stacks 653 with small footprint. It is not meant to be all-encompassing. For 654 more powerful embedded systems (e.g., with 32-bit processors), there 655 are further stacks that comprehensively implement TCP. On the other 656 hand, please be aware that this Annex is based on information 657 available as of the writing. 659 8.1. uIP 661 uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers, 662 which pioneered TCP/IP implementations for constrained devices. uIP 663 has been deployed with Contiki and the Arduino Ethernet shield. A 664 code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) 665 has been reported for uIP [Dunk]. 667 uIP uses same buffer both incoming and outgoing traffic, with has a 668 size of a single packet. In case of a retransmission, an application 669 must be able to reproduce the same user data that had been 670 transmitted. 672 The MSS is announced via the MSS option on connection establishment 673 and the receive window size (of one MSS) is not modified during a 674 connection. Stop-and-wait operation is used for sending data. Among 675 other optimizations, this allows to avoid sliding window operations, 676 which use 32-bit arithmetic extensively and are expensive on 8-bit 677 CPUs. 679 Contiki uses the "split hack" technique (see Section 4.2.3) to avoid 680 delayed ACKs for senders using a single MSS. 682 8.2. lwIP 684 lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. 685 lwIP has a total code size of ~14 kB to ~22 kB (which comprises 686 memory management, checksumming, network interfaces, IP, ICMP and 687 TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. 689 In contrast with uIP, lwIP decouples applications from the network 690 stack. lwIP supports a TCP transmission window greater than a single 691 segment, as well as buffering of incoming and outcoming data. Other 692 implemented mechanisms comprise slow start, congestion avoidance, 693 fast retransmit and fast recovery. SACK and Window Scale have been 694 recently added to lwIP. 696 8.3. RIOT 698 The RIOT TCP implementation (called GNRC TCP) has been designed for 699 Class 1 devices [RFC 7228]. The main target platforms are 8- and 700 16-bit microcontrollers. GNRC TCP offers a similar function set as 701 uIP, but it provides and maintains an independent receive buffer for 702 each connection. In contrast to uIP, retransmission is also handled 703 by GNRC TCP. GNRC TCP uses a single-MSS window size, which 704 simplifies the implementation. The application programmer does not 705 need to know anything about the TCP internals, therefore GNRC TCP can 706 be seen as a user-friendly uIP TCP implementation. 708 The MSS is set on connections establishment and cannot be changed 709 during connection lifetime. GNRC TCP allows multiple connections in 710 parallel, but each TCB must be allocated somewhere in the system. By 711 default there is only enough memory allocated for a single TCP 712 connection, but it can be increased at compile time if the user needs 713 multiple parallel connections. 715 The RIOT TCP implementation does not currently support classic POSIX 716 sockets. However, it supports an interface that has been inspired by 717 POSIX. 719 8.4. OpenWSN 721 The TCP implementation in OpenWSN has similar functionality like the 722 uIP TCP implementation. OpenWSN TCP implementation only supports the 723 minimum state machine functionality required. For example, it does 724 not perform retransmissions. There has not been much recent activity 725 to overcome these limitations. 727 8.5. TinyOS 729 TinyOS was important as platform for early constrained devices. 730 TinyOS has an experimental TCP stack that uses a simple nonblocking 731 library-based implementation of TCP, which provides a subset of the 732 socket interface primitives. The application is responsible for 733 buffering. The TCP library does not do any receive-side buffering. 734 Instead, it will immediately dispatch new, in-order data to the 735 application and otherwise drop the segment. A send buffer is 736 provided so that the TCP implementation can automatically retransmit 737 missing segments. Multiple TCP connections are possible. Recently 738 there has been little further work on the stack. 740 8.6. FreeRTOS 742 FreeRTOS is a real-time operating system kernel for embedded devices 743 that is supported by 16- and 32-bit microprocessors. Its TCP 744 implementation is based on multiple-MSS window size, although a 745 'Tiny-TCP' option, which is a single-MSS variant, can be enabled. 746 Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a 747 technique intended 'to gain performance'. 749 8.7. uC/OS 751 uC/OS is a real-time operating system kernel for embedded devices, 752 which is maintained by Micrium. uC/OS is intended for 8-, 16- and 753 32-bit microprocessors. The uC/OS TCP implementation supports a 754 multiple-MSS window size. 756 8.8. Summary 757 +---+---------+--------+----+-------+------+--------+-----+ 758 |uIP|lwIP orig|lwIP 2.0|RIOT|OpenWSN|TinyOS|FreeRTOS|uC/OS| 759 +------+-------------+---+---------+--------+----+-------+------+--------+-----+ 760 |Memory|Code size(kB)| <5|~9 to ~14| ~40 | <7 | N/A | N/A | <9.2 | N/A | 761 | | |(a)| (T1) | (b) |(T3)| | | (T2) | | 762 +------+-------------+---+---------+--------+----+-------+------+--------+-----+ 763 | |Win size(MSS)| 1 | Mult. | Mult. | 1 | 1 | Mult.| Mult. |Mult.| 764 | +-------------+---+---------+--------+----+-------+------+--------+-----+ 765 | | Slow start | No| Yes | Yes | No | No | Yes | No | Yes | 766 | T +-------------+---+---------+--------+----+-------+------+--------+-----+ 767 | C |Fast rec/retx| No| Yes | Yes | No | No | Yes | No | Yes | 768 | P +-------------+---+---------+--------+----+-------+------+--------+-----+ 769 | | Keep-alive | No| No | Yes | No | No | No | Yes | Yes | 770 | +-------------+---+---------+--------+----+-------+------+--------+-----+ 771 | f | Win. Scale | No| No | Yes | No | No | No | Yes | No | 772 | e +-------------+---+---------+--------+----+-------+------+--------+-----+ 773 | a | TCP timest. | No| No | Yes | No | No | No | Yes | No | 774 | t +-------------+---+---------+--------+----+-------+------+--------+-----+ 775 | u | SACK | No| No | Yes | No | No | No | Yes | No | 776 | r +-------------+---+---------+--------+----+-------+------+--------+-----+ 777 | e | Del. ACKs | No| Yes | Yes | No | No | No | Yes | Yes | 778 | s +-------------+---+---------+--------+----+-------+------+--------+-----+ 779 | | Socket | No| No |Optional|(I) | Yes |Subset| Yes | Yes | 780 | +-------------+---+---------+--------+----+-------+------+--------+-----+ 781 | |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes | Yes | 782 +------+-------------+---+---------+--------+----+-------+------+--------+-----+ 784 (T1) = TCP-only, on x86 and AVR platforms 785 (T2) = TCP-only, on ARM Cortex-M platform 786 (T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same platform 787 is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional connection) 788 (a) = includes IP, ICMP and TCP on x86 and AVR platforms 789 (b) = the whole protocol stack on mbed 790 (I) = interface inspired by POSIX 791 Mult. = Multiple 792 N/A = Not Available 794 Figure 2: Summary of TCP features for differrent lightweight TCP 795 implementations. None of the implementations considered in this 796 Annex support ECN or TFO. 798 9. Annex. Changes compared to previous versions 800 RFC Editor: To be removed prior to publication 802 9.1. Changes between -00 and -01 804 o Changed title and abstract 806 o Clarification that communcation with standard-compliant TCP 807 endpoints is required, based on feedback from Joe Touch 809 o Additional discussion on communication patters 811 o Numerous changes to address a comprehensive review from Hannes 812 Tschofenig 814 o Reworded security considerations 816 o Additional references and better distinction between normative and 817 informative entries 819 o Feedback from Rahul Jadhav on the uIP TCP implementation 821 o Basic data for the TinyOS TCP implementation added, based on 822 source code analysis 824 9.2. Changes between -01 and -02 826 o Added text to the Introduction section, and a reference, on 827 traditional bad perception of TCP for IoT 829 o Added sections on FreeRTOS and uC/OS 831 o Updated TinyOS section 833 o Updated summary table 835 o Reorganized Section 4 (single-MSS vs multiple-MSS window size), 836 some content now also in new Section 5 838 9.3. Changes between -02 and -03 840 o Rewording to better explain the benefit of ECN 842 o Additional context information on the surveyed implementations 844 o Added details, but removed "Data size" raw, in the summary table 846 o Added discussion on shrew attacks 848 10. References 850 10.1. Normative References 852 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 853 RFC 793, DOI 10.17487/RFC0793, September 1981, 854 . 856 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 857 Communication Layers", STD 3, RFC 1122, 858 DOI 10.17487/RFC1122, October 1989, 859 . 861 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 862 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 863 1992, . 865 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 866 Selective Acknowledgment Options", RFC 2018, 867 DOI 10.17487/RFC2018, October 1996, 868 . 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, 872 DOI 10.17487/RFC2119, March 1997, 873 . 875 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 876 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 877 December 1998, . 879 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 880 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 881 DOI 10.17487/RFC3042, January 2001, 882 . 884 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 885 of Explicit Congestion Notification (ECN) to IP", 886 RFC 3168, DOI 10.17487/RFC3168, September 2001, 887 . 889 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 890 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 891 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 892 RFC 3819, DOI 10.17487/RFC3819, July 2004, 893 . 895 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 896 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 897 . 899 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 900 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 901 June 2010, . 903 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 904 "Computing TCP's Retransmission Timer", RFC 6298, 905 DOI 10.17487/RFC6298, June 2011, 906 . 908 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 909 Constrained-Node Networks", RFC 7228, 910 DOI 10.17487/RFC7228, May 2014, 911 . 913 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 914 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 915 . 917 10.2. Informative References 919 [Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP 920 Congestion Control for the Internet of Things", IEEE 921 Communications Magazine, June 2016. 923 [Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003. 925 [ETEN] R. Krishnan et al, "Explicit transport error notification 926 (ETEN) for error-prone wireless and satellite networks", 927 Computer Networks 2004. 929 [I-D.delcarpio-6lo-wlanah] 930 Vega, L., Robles, I., and R. Morabito, "IPv6 over 931 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 932 progress), October 2015. 934 [I-D.ietf-core-coap-tcp-tls] 935 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 936 Silverajan, B., and B. Raymor, "CoAP (Constrained 937 Application Protocol) over TCP, TLS, and WebSockets", 938 draft-ietf-core-coap-tcp-tls-11 (work in progress), 939 December 2017. 941 [I-D.ietf-core-cocoa] 942 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 943 "CoAP Simple Congestion Control/Advanced", draft-ietf- 944 core-cocoa-03 (work in progress), February 2018. 946 [I-D.ietf-lpwan-overview] 947 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 948 overview-10 (work in progress), February 2018. 950 [I-D.ietf-lwig-energy-efficient] 951 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 952 Efficient Features of Internet of Things Protocols", 953 draft-ietf-lwig-energy-efficient-08 (work in progress), 954 October 2017. 956 [IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the 957 Internet of Things: from ostracism to prominence", IEEE 958 Internet Computing, January-February 2018. 960 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 961 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 962 1996, . 964 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 965 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 966 1998, . 968 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 969 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 970 Transfer Protocol -- HTTP/1.1", RFC 2616, 971 DOI 10.17487/RFC2616, June 1999, 972 . 974 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 975 Vaidya, "Long Thin Networks", RFC 2757, 976 DOI 10.17487/RFC2757, January 2000, 977 . 979 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 980 Explicit Congestion Notification (ECN) in IP Networks", 981 RFC 2884, DOI 10.17487/RFC2884, July 2000, 982 . 984 [RFC3481] Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov, 985 A., and F. Khafizov, "TCP over Second (2.5G) and Third 986 (3G) Generation Wireless Networks", BCP 71, RFC 3481, 987 DOI 10.17487/RFC3481, February 2003, 988 . 990 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 991 "Transmission of IPv6 Packets over IEEE 802.15.4 992 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 993 . 995 [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. 996 Briscoe, "Open Research Issues in Internet Congestion 997 Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, 998 . 1000 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1001 Capabilities in Customer Premises Equipment (CPE) for 1002 Providing Residential IPv6 Internet Service", RFC 6092, 1003 DOI 10.17487/RFC6092, January 2011, 1004 . 1006 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1007 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1008 March 2011, . 1010 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1011 Statement and Requirements for IPv6 over Low-Power 1012 Wireless Personal Area Network (6LoWPAN) Routing", 1013 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1014 . 1016 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1017 Application Protocol (CoAP)", RFC 7252, 1018 DOI 10.17487/RFC7252, June 2014, 1019 . 1021 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1022 Zimmermann, "A Roadmap for Transmission Control Protocol 1023 (TCP) Specification Documents", RFC 7414, 1024 DOI 10.17487/RFC7414, February 2015, 1025 . 1027 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1028 over ITU-T G.9959 Networks", RFC 7428, 1029 DOI 10.17487/RFC7428, February 2015, 1030 . 1032 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1033 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1034 DOI 10.17487/RFC7540, May 2015, 1035 . 1037 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1038 Recommendations Regarding Active Queue Management", 1039 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1040 . 1042 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1043 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1044 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1045 . 1047 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1048 Explicit Congestion Notification (ECN)", RFC 8087, 1049 DOI 10.17487/RFC8087, March 2017, 1050 . 1052 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1053 M., and D. Barthel, "Transmission of IPv6 Packets over 1054 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1055 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1056 2017, . 1058 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1059 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1060 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1061 May 2017, . 1063 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1064 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1065 Application Protocol) over TCP, TLS, and WebSockets", 1066 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1067 . 1069 [shrew] A. Kuzmanovic, E. Knightly, "Low-Rate TCP-Targeted Denial 1070 of Service Attacks", SIGCOMM'03 2003. 1072 Authors' Addresses 1074 Carles Gomez 1075 UPC 1076 C/Esteve Terradas, 7 1077 Castelldefels 08860 1078 Spain 1080 Email: carlesgo@entel.upc.edu 1081 Jon Crowcroft 1082 University of Cambridge 1083 JJ Thomson Avenue 1084 Cambridge, CB3 0FD 1085 United Kingdom 1087 Email: jon.crowcroft@cl.cam.ac.uk 1089 Michael Scharf 1090 Nokia 1091 Lorenzstrasse 10 1092 Stuttgart, 70435 1093 Germany 1095 Email: michael.scharf@nokia.com