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