idnits 2.17.1 draft-ietf-lwig-tcp-constrained-node-networks-01.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 27 instances of too long lines in the document, the longest one being 12 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 14, 2017) is 2386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7228' is mentioned on line 600, but not defined ** 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) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-09 == Outdated reference: A later version (-03) exists of draft-ietf-core-cocoa-01 == Outdated reference: A later version (-10) exists of draft-ietf-lpwan-overview-07 == Outdated reference: A later version (-08) exists of draft-ietf-lwig-energy-efficient-07 -- 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 (~~), 7 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/i2CAT 4 Intended status: Informational J. Crowcroft 5 Expires: April 17, 2018 University of Cambridge 6 M. Scharf 7 Nokia 8 October 14, 2017 10 TCP Usage Guidance in the Internet of Things (IoT) 11 draft-ietf-lwig-tcp-constrained-node-networks-01 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 17, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Communication and traffic patterns . . . . . . . . . . . 5 64 4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. TCP connection initiation . . . . . . . . . . . . . . . . 6 66 4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 6 67 4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 8 70 4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 8 71 4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 9 72 4.6. Explicit congestion notification . . . . . . . . . . . . 9 73 4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 11 75 4.9. Explicit loss notifications . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. Annex. TCP implementations for constrained devices . . . . . 12 79 7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 8. Annex. Changes compared to previous versions . . . . . . . . 15 86 8.1. Changes compared to -00 . . . . . . . . . . . . . . . . . 15 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 9.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 The Internet Protocol suite is being used for connecting Constrained- 95 Node Networks (CNNs) to the Internet, enabling the so-called Internet 96 of Things (IoT) [RFC7228]. In order to meet the requirements that 97 stem from CNNs, the IETF has produced a suite of new protocols 98 specifically designed for such environments (see e.g. 99 [I-D.ietf-lwig-energy-efficient]). 101 At the application layer, the Constrained Application Protocol (CoAP) 102 was developed over UDP [RFC7252]. However, the integration of some 103 CoAP deployments with existing infrastructure is being challenged by 104 middleboxes such as firewalls, which may limit and even block UDP- 105 based communications. This the main reason why a CoAP over TCP 106 specification is being developed [I-D.ietf-core-coap-tcp-tls]. 108 Other application layer protocols not specifically designed for CNNs 109 are also being considered for the IoT space. Some examples include 110 HTTP/2 and even HTTP/1.1, both of which run over TCP by default 111 [RFC7540] [RFC2616], and the Extensible Messaging and Presence 112 Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application- 113 layer protocols in the IoT space such as the Message Queue Telemetry 114 Transport (MQTT) and its lightweight variants. 116 TCP is a sophisticated transport protocol that includes many optional 117 functionality and TCP options that improve performance. Many 118 optional TCP extensions require complex logic inside the TCP stack 119 and increase the codesize and the RAM requirements. However, many 120 TCP extensions are not required for interoperability with other 121 standard-compliant TCP endpoints. Given the limited resources on 122 constrained devices, careful "tuning" of the TCP implementation can 123 make an implementation more lightweight. 125 This document provides guidance on how to implement and use TCP in 126 CNNs. The overarching goal is to offer simple measures to allow for 127 lightweight TCP implementation and suitable operation in such 128 environments. A TCP implementation following the guidance in this 129 document is intended to be compatible with a TCP endpoint that is 130 compliant to the TCP standards, albeit possibly with a lower 131 performance. This implies that such a TCP client would always be 132 able to connect with a standard-compliant TCP server, and a 133 corresponding TCP server would always be able to connect with a 134 standard-compliant TCP client. 136 This document assumes that the reader is familiar with TCP. A 137 comprehensive survey of the TCP standards can be found in [RFC7414]. 138 Similar guidance regarding the use of TCP in special environments has 139 been published before, e.g., for cellular wireless networks 140 [RFC3481]. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. Characteristics of CNNs relevant for TCP 150 3.1. Network and link properties 152 CNNs are defined in [RFC7228] as networks whose characteristics are 153 influenced by being composed of a significant portion of constrained 154 nodes. The latter are characterized by significant limitations on 155 processing, memory, and energy resources, among others [RFC7228]. 156 The first two dimensions pose constraints on the complexity and on 157 the memory footprint of the protocols that constrained nodes can 158 support. The latter requires techniques to save energy, such as 159 radio duty-cycling in wireless devices 160 [I-D.ietf-lwig-energy-efficient], as well as minimization of the 161 number of messages transmitted/received (and their size). 163 [RFC7228] lists typical network constraints in CNN, including low 164 achievable bitrate/throughput, high packet loss and high variability 165 of packet loss, highly asymmetric link characteristics, severe 166 penalties for using larger packets, limits on reachability over time, 167 etc. CNN may use wireless or wired technologies (e.g., Power Line 168 Communication), and the transmission rates are typically low (e.g. 169 below 1 Mbps). 171 For use of TCP, one challenge is that not all technologies in CNN may 172 be aligned with typical Internet subnetwork design principles 173 [RFC3819]. For instance, constrained nodes often use physical/link 174 layer technologies that have been characterized as 'lossy', i.e., 175 exhibit a relatively high bit error rate. Dealing with corruption 176 loss is one of the open issues in the Internet [RFC6077]. 178 3.2. Usage scenarios 180 There are different deployment and usage scenarios for CNNs. Some 181 CNNs follow the star topology, whereby one or several hosts are 182 linked to a central device that acts as a router connecting the CNN 183 to the Internet. CNNs may also follow the multihop topology 184 [RFC6606]. One key use case for the use of TCP is a model where 185 constrained devices connect to unconstrained servers in the Internet. 186 But it is also possible that both TCP endpoints run on constrained 187 devices. 189 In constrained environments, there can be different types of devices 190 [RFC7228]. For example, there can be devices with single combined 191 send/receive buffer, devices with a separate send and receive buffer, 192 or devices with a pool of multiple send/receive buffers. In the 193 latter case, it is possible that buffers also be shared for other 194 protocols. 196 When a CNN comprising one or more constrained devices and an 197 unconstrained device communicate over the Internet using TCP, the 198 communication possibly has to traverse a middlebox (e.g. a firewall, 199 NAT, etc.). Figure 1 illustrates such scenario. Note that the 200 scenario is asymmetric, as the unconstrained device will typically 201 not suffer the severe constraints of the constrained device. The 202 unconstrained device is expected to be mains-powered, to have high 203 amount of memory and processing power, and to be connected to a 204 resource-rich network. 206 Assuming that a majority of constrained devices will correspond to 207 sensor nodes, the amount of data traffic sent by constrained devices 208 (e.g. sensor node measurements) is expected to be higher than the 209 amount of data traffic in the opposite direction. Nevertheless, 210 constrained devices may receive requests (to which they may respond), 211 commands (for configuration purposes and for constrained devices 212 including actuators) and relatively infrequent firmware/software 213 updates. 215 +---------------+ 216 o o <-------- TCP communication -----> | | 217 o o | | 218 o o | Unconstrained | 219 o o +-----------+ | device | 220 o o o ------ | Middlebox | ------- | | 221 o o +-----------+ | (e.g. cloud) | 222 o o o | | 223 +---------------+ 224 constrained devices 226 Figure 1: TCP communication between a constrained device and an 227 unconstrained device, traversing a middlebox. 229 3.3. Communication and traffic patterns 231 IoT applications are characterized by a number of different 232 communication patterns. The following non-comprehensive list 233 explains some typical examples: 235 o Unidirectional transfers: An IoT device (e.g. a sensor) can send 236 (repeatedly) updates to the other endpoint. Not in every case 237 there is a need for an application response back to the IoT 238 device. 240 o Request-response patterns: An IoT device receiving a request from 241 the other endpoint, which triggers a response from the IoT device. 243 o Bulk data transfers: A typical example for a long file transfer 244 would be an IoT device firmware update. 246 A typical communication pattern is that a constrained device 247 communicates with an unconstrained device (cf. Figure 1). But it is 248 also possible that constrained devices communicate amongst 249 themselves. 251 4. TCP over CNNs 253 4.1. TCP connection initiation 255 In the constrained device to unconstrained device scenario 256 illustrated above, a TCP connection is typically initiated by the 257 constrained device, in order for this device to support possible 258 sleep periods to save energy. 260 4.2. Maximum Segment Size (MSS) 262 Some link layer technologies in the CNN space are characterized by a 263 short data unit payload size, e.g. up to a few tens or hundreds of 264 bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 265 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE 266 802.15.4 networks. The adaptation layer includes a fragmentation 267 mechanism, since IPv6 requires the layer below to support an MTU of 268 1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation 269 mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes 270 [RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T 271 G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based 272 adaptation layers in order to enable IPv6 support. These 273 technologies do support link layer fragmentation. By exploiting this 274 functionality, the adaptation layers that enable IPv6 over such 275 technologies also define an MTU of 1280 bytes. 277 On the other hand, there exist technologies also used in the CNN 278 space, such as Master Slave / Token Passing (TP) [RFC8163], 279 Narrowband IoT (NB-IoT) [I-D.ietf-lpwan-overview] or IEEE 802.11ah 280 [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of 281 frame size limitations as the technologies mentioned above. The MTU 282 for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- 283 IoT is 1600 bytes, and the maximum frame payload size for IEEE 284 802.11ah is 7991 bytes. 286 For the sake of lightweight implementation and operation, unless 287 applications require handling large data units (i.e. leading to an 288 IPv6 datagram size greater than 1280 bytes), it may be desirable to 289 limit the MTU to 1280 bytes in order to avoid the need to support 290 Path MTU Discovery [RFC1981]. 292 An IPv6 datagram size exceeding 1280 bytes can be avoided by setting 293 the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is 294 assumed.) 296 4.3. Window Size 298 A TCP stack can reduce the RAM requirements by advertising a TCP 299 window size of one MSS, and also transmit at most one MSS of 300 unacknowledged data. In that case, both congestion and flow control 301 implementation is quite simple. Such a small receive and send window 302 may be sufficient for simple message exchanges in the CNN space. 303 However, only using a window of one MSS can significantly affect 304 performance. A stop-and-wait operation results in low throughput for 305 transfers that exceed the lengths of one MSS, e.g., a firmware 306 download. In addition, there can be interactions with the delayed 307 acknowledgements (see Section 4.8). 309 Devices that have enough memory to allow larger TCP window size can 310 leverage a more efficient error recovery using Fast Retransmit and 311 Fast Recovery [RFC5681]. These algorithms work efficiently for 312 window sizes of at least 5 MSS: If in a given TCP transmission of 313 segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should 314 get an acknowledgement for segment 1 when 3 arrives and duplicate 315 acknowledgements when 4, 5, and 6 arrive. It will retransmit segment 316 2 when the third duplicate ack arrives. In order to have segment 2, 317 3, 4, 5, and 6 sent, the window has to be at least five. With an MSS 318 of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte. 320 For bulk data transfers further TCP improvements may also be useful, 321 such as limited transmit [RFC3402]. 323 If CoAP is used over TCP with the default setting for NSTART in 324 [RFC7252], a CoAP endpoint is not allowed to send a new message to a 325 destination until a response for the previous message sent to that 326 destination has been received. This is equivalent to an application- 327 layer window size of 1. For this use of CoAP, a maximum TCP window 328 of one MSS will be sufficient. 330 4.4. RTO estimation 332 The Retransmission Timeout (RTO) estimation is one of the fundamental 333 TCP algorithms. There is a fundamental trade-off: A short, 334 aggressive RTO behavior reduces wait time before retransmissions, but 335 it also increases the probability of spurious timeouts. The latter 336 lead to unnecessary waste of potentially scarce resources in CNNs 337 such as energy and bandwidth. In contrast, a conservative timeout 338 can result in long error recovery times and thus needlessly delay 339 data delivery. 341 [RFC6298] describes the standard TCP RTO algorithm. If a TCP sender 342 uses very small window size and cannot use Fast Retransmit/Fast 343 Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a 344 larger impact on performance than for a more powerful TCP stack. In 345 that case, RTO algorithm tuning may be considered, although careful 346 assessment of possible drawbacks is recommended. 348 As an example, an adaptive RTO algorithm for CoAP over UDP has been 349 defined [I-D.ietf-core-cocoa] that has been found to perform well in 350 CNN scenarios [Commag]. 352 4.5. TCP connection lifetime 354 [[Note: future revisions will better separate what a TCP stack should 355 support, or not, and how the TCP stack should be used by 356 applications, e.g., whether to close connections or not.]] 358 4.5.1. Long TCP connection lifetime 360 In CNNs, in order to minimize message overhead, a TCP connection 361 should be kept open as long as the two TCP endpoints have more data 362 to exchange or it is envisaged that further segment exchanges will 363 take place within an interval of two hours since the last segment has 364 been sent. A greater interval may be used in scenarios where 365 applications exchange data infrequently. 367 TCP keep-alive messages [RFC1122] may be supported by a server, to 368 check whether a TCP connection is active, in order to release state 369 of inactive connections. This may be useful for servers running on 370 memory-constrained devices. 372 Since the keep-alive timer may not be set to a value lower than two 373 hours [RFC1122], TCP keep-alive messages are not useful to guarantee 374 that filter state records in middleboxes such as firewalls will not 375 be deleted after an inactivity interval typically in the order of a 376 few minutes [RFC6092]. In scenarios where such middleboxes are 377 present, alternative measures to avoid early deletion of filter state 378 records (which might lead to frequent establishment of new TCP 379 connections between the two involved endpoints) include increasing 380 the initial value for the filter state inactivity timers (if 381 possible), and using application layer heartbeat messages. 383 4.5.2. Short TCP connection lifetime 385 A different approach to addressing the problem of traversing 386 middleboxes that perform early filter state record deletion relies on 387 using TCP Fast Open (TFO) [RFC7413]. In this case, instead of trying 388 to maintain a TCP connection for long time, possibly short-lived 389 connections can be opened between two endpoints while incurring low 390 overhead. In fact, TFO allows data to be carried in SYN (and SYN- 391 ACK) packets, and to be consumed immediately by the receceiving 392 endpoint, thus reducing overhead compared with the traditional three- 393 way handshake required to establish a TCP connection. 395 For security reasons, TFO requires the TCP endpoint that will open 396 the TCP connection (which in CNNs will typically be the constrained 397 device) to request a cookie from the other endpoint. The cookie, 398 with a size of 4 or 16 bytes, is then included in SYN packets of 399 subsequent connections. The cookie needs to be refreshed (and 400 obtained by the client) after a certain amount of time. 401 Nevertheless, TFO is more efficient than frequently opening new TCP 402 connections (by using the traditional three-way handshake) for 403 transmitting new data, as long as the cookie update rate is well 404 below the data new connection rate. 406 4.6. Explicit congestion notification 408 Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs. 409 ECN allows a router to signal in the IP header of a packet that 410 congestion is arising, for example when queue size reaches a certain 411 threshold. If such a packet encapsulates a TCP data packet, an ECN- 412 enabled TCP receiver will echo back the congestion signal to the TCP 413 sender by setting a flag in its next TCP ACK. The sender triggers 414 congestion control measures as if a packet loss had happened. In 415 that case, when the congestion window of a TCP sender has a size of 416 one segment, the TCP sender resets the retransmit timer, and will 417 only be able to send a new packet when the retransmit timer expires 418 [RFC3168]. Effectively, the TCP sender reduces at that moment its 419 sending rate from 1 segment per Round Trip Time (RTT) to 1 segment 420 per default RTO. 422 ECN can reduce packet losses, since congestion control measures can 423 be applied earlier than after the reception of three duplicate ACKs 424 (if the TCP sender window is large enough) or upon TCP sender RTO 425 expiration [RFC2884]. Therefore, the number of retries decreases, 426 which is particularly beneficial in CNNs, where energy and bandwidth 427 resources are typically limited. Furthermore, latency and jitter are 428 also reduced. 430 ECN is particularly appropriate in CNNs, since in these environments 431 transactional type interactions are a dominant traffic pattern. As 432 transactional data size decreases, the probability of detecting 433 congestion by the presence of three duplicate ACKs decreases. In 434 contrast, ECN can still activate congestion control measures without 435 requiring three duplicate ACKs. 437 4.7. TCP options 439 A TCP implementation needs to support options 0, 1 and 2 [RFC0793]. 440 These options are sufficient for interoperability with a standard- 441 compliant TCP endpoint, albeit many TCP stacks support additional 442 options and can negotiate their use. 444 A TCP implementation for a constrained device that uses a single-MSS 445 TCP receive or transmit window size may not benefit from supporting 446 the following TCP options: Window scale [RFC1323], TCP Timestamps 447 [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted 448 [RFC2018]. Also other TCP options may not be required on a 449 constrained device with a very lightweight implementation. 451 If a device with less severe memory and processing constraints can 452 afford advertising a TCP window size of several MSSs, it makes sense 453 to support the SACK option to improve performance. SACK allows a 454 data receiver to inform the data sender of non-contiguous data blocks 455 received, thus a sender (having previously sent the SACK-Permitted 456 option) can avoid performing unnecessary retransmissions, saving 457 energy and bandwidth, as well as reducing latency. SACK is 458 particularly useful for bulk data transfers. The receiver supporting 459 SACK will need to manage the reception of possible out-of-order 460 received segments, requiring sufficient buffer space. SACK adds 461 8*n+2 bytes to the TCP header, where n denotes the number of data 462 blocks received, up to 4 blocks. For a low number of out-of- order 463 segments, the header overhead penalty of SACK is compensated by 464 avoiding unnecessary retransmissions. 466 Another potentially relevant TCP option in the context of CNNs is 467 (TFO) [RFC7413]. As described in Section 4.5.2, TFO can be used to 468 address the problem of traversing middleboxes that perform early 469 filter state record deletion. 471 4.8. Delayed Acknowledgments 473 TCP Delayed Acknowledgements reduce the number of transferred bytes 474 within a TCP connection, but they may increase the time until a 475 sender may receive an ACK. For certain traffic patterns Delayed 476 Acknowledgements may have a detrimental effect. Advanced TCP stacks 477 may use heuristics to determine the maximum delay for an ACK. For 478 CNNs, the recommendation depends on the expected communication 479 patterns. 481 A device that advertises a single-MSS receive window should avoid use 482 of delayed ACKs in order to avoid contributing unnecessary delay (of 483 up to 500 ms) to the RTT [RFC5681], which limits the throughput and 484 can increase the data delivery time. 486 A device that can send at most one MSS of data is significantly 487 affected if the receiver uses delayed ACKs, e.g., if a TCP server or 488 receiver is outside the CNN. One known workaround is to split the 489 data to be sent into two segments of smaller size. A standard 490 compliant TCP receiver will then immediately acknowledge the second 491 segment, which can improve throughput. This "split hack" works if 492 the TCP receiver uses Delayed Acks, but the downside is the overhead 493 of sending two IP packets instead of one. 495 Also for larger windows, it may make sense to use a small timeout or 496 disable delayed ACKs when traffic over a CNN is expected to mostly be 497 small messages with a size typically below one MSS. For request- 498 response traffic between a constrained device and a peer (e.g. 499 backend infrastructure) that uses delayed ACKs, the maximum ACK rate 500 of the peer will be typically of one ACK every 200 ms (or even 501 lower). If in such conditions the peer device is administered by the 502 same entity managing the constrained device, it is recommended to 503 disable delayed ACKs at the peer side. 505 In contrast, delayed ACKs allow to reduce the number of ACKs in bulk 506 transfer type of traffic, e.g. for firmware/software updates or for 507 transferring larger data units containing a batch of sensor readings. 509 4.9. Explicit loss notifications 511 There has been a significant body of research on solutions capable of 512 explicitly indicating whether a TCP segment loss is due to 513 corruption, in order to avoid activation of congestion control 514 mechanisms [ETEN] [RFC2757]. While such solutions may provide 515 significant improvement, they have not been widely deployed and 516 remain as experimental work. In fact, as of today, the IETF has not 517 standardized any such solution. 519 5. Security Considerations 521 Best current practise for securing TCP and TCP-based communication 522 also applies to CNN. As example, use of Transport Layer Security 523 (TLS) is strongly recommended if it is applicable. 525 There are also TCP options which can improve TCP security. Examples 526 include the TCP MD5 signature option [RFC2385] and the TCP 527 Authentication Option (TCP-AO) [RFC5925]. However, both options add 528 overhead and complexity. The TCP MD5 signature option adds 18 bytes 529 to every segment of a connection. TCP-AO typically has a size of 530 16-20 bytes. 532 For the mechanisms discussed in this document, the corresponding 533 considerations apply. For instance, if TFO is used, the security 534 considerations of [RFC7413] apply. 536 6. Acknowledgments 538 Carles Gomez has been funded in part by the Spanish Government 539 (Ministerio de Educacion, Cultura y Deporte) through the Jose 540 Castillejo grant CAS15/00336 and by European Regional Development 541 Fund (ERDF) and the Spanish Government through project 542 TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this 543 work has been carried out during his stay as a visiting scholar at 544 the Computer Laboratory of the University of Cambridge. 546 The authors appreciate the feedback received for this document. The 547 following folks provided comments that helped improve the document: 548 Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan 549 Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred 550 Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and 551 Hannes Tschofenig. Simon Brummer provided details on the RIOT TCP 552 implementation. Xavi Vilajosana provided details on the OpenWSN TCP 553 implementation. Rahul Jadhav provided details on the uIP TCP 554 implementation. 556 7. Annex. TCP implementations for constrained devices 558 This section overviews the main features of TCP implementations for 559 constrained devices. 561 7.1. uIP 563 uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers. 564 uIP has been deployed with Contiki and the Arduino Ethernet shield. 565 A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) 566 has been reported for uIP [Dunk]. 568 uIP uses same buffer both incoming and outgoing traffic, with has a 569 size of a single packet. In case of a retransmission, an application 570 must be able to reproduce the same user data that had been 571 transmitted. 573 The MSS is announced via the MSS option on connection establishment 574 and the receive window size (of one MSS) is not modified during a 575 connection. Stop-and-wait operation is used for sending data. Among 576 other optimizations, this allows to avoid sliding window operations, 577 which use 32-bit arithmetic extensively and are expensive on 8-bit 578 CPUs. 580 Contiki uses the "split hack" technique (see Section 4.8) to avoid 581 delayed ACKs for senders using a single MSS. 583 7.2. lwIP 585 lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. 586 lwIP has a total code size of ~14 kB to ~22 kB (which comprises 587 memory management, checksumming, network interfaces, IP, ICMP and 588 TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. 590 In contrast with uIP, lwIP decouples applications from the network 591 stack. lwIP supports a TCP transmission window greater than a single 592 segment, as well as buffering of incoming and outcoming data. Other 593 implemented mechanisms comprise slow start, congestion avoidance, 594 fast retransmit and fast recovery. SACK and Window Scale have been 595 recently added to lwIP. 597 7.3. RIOT 599 The RIOT TCP implementation (called GNRC TCP) has been designed for 600 Class 1 devices [RFC 7228]. The main target platforms are 8- and 601 16-bit microcontrollers. GNRC TCP offers a similar function set as 602 uIP, but it provides and maintains an independent receive buffer for 603 each connection. In contrast to uIP, retransmission is also handled 604 by GNRC TCP. GNRC TCP uses a single-MSS window size, which 605 simplifies the implementation. The application programmer does not 606 need to know anything about the TCP internals, therefore GNRC TCP can 607 be seen as a user-friendly uIP TCP implementation. 609 The MSS is set on connections establishment and cannot be changed 610 during connection lifetime. GNRC TCP allows multiple connections in 611 parallel, but each TCB must be allocated somewhere in the system. By 612 default there is only enough memory allocated for a single TCP 613 connection, but it can be increased at compile time if the user needs 614 multiple parallel connections. 616 7.4. OpenWSN 618 The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP 619 implementation. OpenWSN TCP implementation only supports the minimum 620 state machine functionality required. For example, it does not 621 perform retransmissions. 623 7.5. TinyOS 625 TODO: To be verified 627 TinyOS has an experimental TCP stack that uses a simple nonblocking 628 library-based implementation of TCP. The application is responsible 629 for buffering. The TCP library does not do any receive-side 630 buffering. Instead, it will immediately dispatch new, in-order data 631 to the application and otherwise drop the segment. A send buffer is 632 provided so that the TCP implementation can automatically retransmit 633 missing segments. 635 7.6. Summary 636 +-------+---------+---------+------+---------+--------+ 637 | uIP |lwIP orig|lwIP 2.0 | RIOT | OpenWSN | TinyOS | 638 +--------+----------------+-------+---------+---------+------+---------+--------+ 639 | | Data size | * | * | * | * | * | * | 640 | Memory +----------------+-------+---------+---------+------+---------+--------+ 641 | | Code size (kB) | < 5 |~9 to ~14| * | * | * | * | 642 +--------+----------------+-------+---------+---------+------+---------+--------+ 643 | |Window size(MSS)| 1 | Multiple| Multiple| 1 | 1 |Multiple| 644 | +----------------+-------+---------+---------+------+---------+--------+ 645 | | Slow start | No | Yes | Yes | No | No | Yes | 646 | T +----------------+-------+---------+---------+------+---------+--------+ 647 | C | Fast rec/retx | No | Yes | Yes | No | No | Yes | 648 | P +----------------+-------+---------+---------+------+---------+--------+ 649 | | Keep-alive | No | * | * | No | No | No | 650 | +----------------+-------+---------+---------+------+---------+--------+ 651 | f | TFO | No | No | * | No | No | No | 652 | e +----------------+-------+---------+---------+------+---------+--------+ 653 | a | ECN | No | No | * | No | No | No | 654 | t +----------------+-------+---------+---------+------+---------+--------+ 655 | u | Window Scale | No | No | Yes | No | No | No | 656 | r +----------------+-------+---------+---------+------+---------+--------+ 657 | e | TCP timestamps | No | No | Yes | No | No | No | 658 | s +----------------+-------+---------+---------+------+---------+--------+ 659 | | SACK | No | No | Yes | No | No | No | 660 | +----------------+-------+---------+---------+------+---------+--------+ 661 | | Delayed ACKs | No | Yes | Yes | No | No | No | 662 +--------+----------------+-------+---------+---------+------+---------+--------+ 664 Figure 2: Summary of TCP features for differrent lightweight TCP 665 implementations. 667 TODO: Add information about RAM requirements (in addition to 668 codesize) 670 8. Annex. Changes compared to previous versions 672 RFC Editor: To be removed prior to publication 674 8.1. Changes compared to -00 676 o Changed title and abstract 678 o Clarification that communcation with standard-compliant TCP 679 endpoints is required, based on feedback from Joe Touch 681 o Additional discussion on communication patters 682 o Numerous changes to address a comprehensive review from Hannes 683 Tschofenig 685 o Reworded security considerations 687 o Additional references and better distinction between normative and 688 informative entries 690 o Feedback from Rahul Jadhav on the uIP TCP implementation 692 o Basic data for the TinyOS TCP implementation added, based on 693 source code analysis 695 9. References 697 9.1. Normative References 699 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 700 RFC 793, DOI 10.17487/RFC0793, September 1981, 701 . 703 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 704 Communication Layers", STD 3, RFC 1122, 705 DOI 10.17487/RFC1122, October 1989, 706 . 708 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 709 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 710 1992, . 712 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 713 Selective Acknowledgment Options", RFC 2018, 714 DOI 10.17487/RFC2018, October 1996, 715 . 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 723 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 724 December 1998, . 726 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 727 of Explicit Congestion Notification (ECN) to IP", 728 RFC 3168, DOI 10.17487/RFC3168, September 2001, 729 . 731 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 732 Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402, 733 October 2002, . 735 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 736 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 737 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 738 RFC 3819, DOI 10.17487/RFC3819, July 2004, 739 . 741 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 742 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 743 . 745 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 746 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 747 June 2010, . 749 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 750 "Computing TCP's Retransmission Timer", RFC 6298, 751 DOI 10.17487/RFC6298, June 2011, 752 . 754 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 755 Constrained-Node Networks", RFC 7228, 756 DOI 10.17487/RFC7228, May 2014, 757 . 759 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 760 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 761 . 763 9.2. Informative References 765 [Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP 766 Congestion Control for the Internet of Things", IEEE 767 Communications Magazine, June 2016. 769 [Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003. 771 [ETEN] R. Krishnan et al, "Explicit transport error notification 772 (ETEN) for error-prone wireless and satellite networks", 773 Computer Networks 2004. 775 [I-D.delcarpio-6lo-wlanah] 776 Vega, L., Robles, I., and R. Morabito, "IPv6 over 777 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 778 progress), October 2015. 780 [I-D.ietf-core-coap-tcp-tls] 781 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 782 Silverajan, B., and B. Raymor, "CoAP (Constrained 783 Application Protocol) over TCP, TLS, and WebSockets", 784 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 785 2017. 787 [I-D.ietf-core-cocoa] 788 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 789 "CoAP Simple Congestion Control/Advanced", draft-ietf- 790 core-cocoa-01 (work in progress), March 2017. 792 [I-D.ietf-lpwan-overview] 793 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 794 overview-07 (work in progress), October 2017. 796 [I-D.ietf-lwig-energy-efficient] 797 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 798 Efficient Features of Internet of Things Protocols", 799 draft-ietf-lwig-energy-efficient-07 (work in progress), 800 March 2017. 802 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 803 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 804 1996, . 806 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 807 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 808 1998, . 810 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 811 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 812 Transfer Protocol -- HTTP/1.1", RFC 2616, 813 DOI 10.17487/RFC2616, June 1999, 814 . 816 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 817 Vaidya, "Long Thin Networks", RFC 2757, 818 DOI 10.17487/RFC2757, January 2000, 819 . 821 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 822 Explicit Congestion Notification (ECN) in IP Networks", 823 RFC 2884, DOI 10.17487/RFC2884, July 2000, 824 . 826 [RFC3481] Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov, 827 A., and F. Khafizov, "TCP over Second (2.5G) and Third 828 (3G) Generation Wireless Networks", BCP 71, RFC 3481, 829 DOI 10.17487/RFC3481, February 2003, 830 . 832 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 833 "Transmission of IPv6 Packets over IEEE 802.15.4 834 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 835 . 837 [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. 838 Briscoe, "Open Research Issues in Internet Congestion 839 Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, 840 . 842 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 843 Capabilities in Customer Premises Equipment (CPE) for 844 Providing Residential IPv6 Internet Service", RFC 6092, 845 DOI 10.17487/RFC6092, January 2011, 846 . 848 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 849 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 850 March 2011, . 852 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 853 Statement and Requirements for IPv6 over Low-Power 854 Wireless Personal Area Network (6LoWPAN) Routing", 855 RFC 6606, DOI 10.17487/RFC6606, May 2012, 856 . 858 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 859 Application Protocol (CoAP)", RFC 7252, 860 DOI 10.17487/RFC7252, June 2014, 861 . 863 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 864 Zimmermann, "A Roadmap for Transmission Control Protocol 865 (TCP) Specification Documents", RFC 7414, 866 DOI 10.17487/RFC7414, February 2015, 867 . 869 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 870 over ITU-T G.9959 Networks", RFC 7428, 871 DOI 10.17487/RFC7428, February 2015, 872 . 874 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 875 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 876 DOI 10.17487/RFC7540, May 2015, 877 . 879 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 880 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 881 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 882 . 884 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 885 M., and D. Barthel, "Transmission of IPv6 Packets over 886 Digital Enhanced Cordless Telecommunications (DECT) Ultra 887 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 888 2017, . 890 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 891 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 892 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 893 May 2017, . 895 Authors' Addresses 897 Carles Gomez 898 UPC/i2CAT 899 C/Esteve Terradas, 7 900 Castelldefels 08860 901 Spain 903 Email: carlesgo@entel.upc.edu 905 Jon Crowcroft 906 University of Cambridge 907 JJ Thomson Avenue 908 Cambridge, CB3 0FD 909 United Kingdom 911 Email: jon.crowcroft@cl.cam.ac.uk 913 Michael Scharf 914 Nokia 915 Lorenzstrasse 10 916 Stuttgart, 70435 917 Germany 919 Email: michael.scharf@nokia.com