idnits 2.17.1 draft-gomez-lwig-tcp-constrained-node-networks-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 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 (June 29, 2017) is 2491 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6120' is mentioned on line 104, but not defined == Missing Reference: 'RFC793' is mentioned on line 362, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC 7228' is mentioned on line 494, but not defined ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == 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-04 == Outdated reference: A later version (-08) exists of draft-ietf-lwig-energy-efficient-07 == Outdated reference: A later version (-17) exists of draft-ietf-tcpm-rto-consider-05 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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: December 31, 2017 University of Cambridge 6 M. Scharf 7 Nokia 8 June 29, 2017 10 TCP over Constrained-Node Networks 11 draft-gomez-lwig-tcp-constrained-node-networks-03 13 Abstract 15 This document provides a profile for the Transmission Control 16 Protocol (TCP) over Constrained-Node Networks (CNNs). The 17 overarching goal is to offer simple measures to allow for lightweight 18 TCP implementation and suitable operation in such environments. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 31, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions used in this document . . . . . . . . . . . . 3 56 2. Characteristics of CNNs relevant for TCP . . . . . . . . . . 3 57 3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. TCP connection initiation . . . . . . . . . . . . . . . . 4 60 4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 5 61 4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 6 63 4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 7 64 4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 7 65 4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 7 66 4.6. Explicit congestion notification . . . . . . . . . . . . 8 67 4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 9 69 4.9. Explicit loss notifications . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. Annex. TCP implementations for constrained devices . . . . . 10 73 7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 8.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 The Internet Protocol suite is being used for connecting Constrained- 87 Node Networks (CNNs) to the Internet, enabling the so-called Internet 88 of Things (IoT) [RFC7228]. In order to meet the requirements that 89 stem from CNNs, the IETF has produced a suite of protocols 90 specifically designed for such environments 91 [I-D.ietf-lwig-energy-efficient]. 93 At the application layer, the Constrained Application Protocol (CoAP) 94 was developed over UDP [RFC7252]. However, the integration of some 95 CoAP deployments with existing infrastructure is being challenged by 96 middleboxes such as firewalls, which may limit and even block UDP- 97 based communications. This the main reason why a CoAP over TCP 98 specification is being developed [I-D.tschofenig-core-coap-tcp-tls]. 100 On the other hand, other application layer protocols not specifically 101 designed for CNNs are also being considered for the IoT space. Some 102 examples include HTTP/2 and even HTTP/1.1, both of which run over TCP 103 by default [RFC7540][RFC2616], and the Extensible Messaging and 104 Presence Protocol (XMPP) [RFC 6120]. TCP is also used by non-IETF 105 application-layer protocols in the IoT space such as MQTT and its 106 lightweight variants [MQTTS]. 108 This document provides a profile for TCP over CNNs. The overarching 109 goal is to offer simple measures to allow for lightweight TCP 110 implementation and suitable operation in such environments. 112 1.1. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119] 118 2. Characteristics of CNNs relevant for TCP 120 CNNs are defined in [RFC7228] as networks whose characteristics are 121 influenced by being composed of a significant portion of constrained 122 nodes. The latter are characterized by significant limitations on 123 processing, memory, and energy resources, among others [RFC7228]. 124 The first two dimensions pose constraints on the complexity and on 125 the memory footprint of the protocols that constrained nodes can 126 support. The latter requires techniques to save energy, such as 127 radio duty-cycling in wireless devices 128 [I-D.ietf-lwig-energy-efficient], as well as minimization of the 129 number of messages transmitted/received (and their size). 131 Constrained nodes often use physical/link layer technologies that 132 have been characterized as 'lossy'. Many such technologies are 133 wireless, therefore exhibiting a relatively high bit error rate. 134 However, some wired technologies used in the CNN space are also lossy 135 (e.g. Power Line Communication). Transmission rates of CNN radio or 136 wired interfaces are typically low (e.g. below 1 Mbps). 138 Some CNNs follow the star topology, whereby one or several hosts are 139 linked to a central device that acts as a router connecting the CNN 140 to the Internet. CNNs may also follow the multihop topology 141 [RFC6606]. 143 3. Scenario 145 The main scenario for use of TCP over CNNs comprises a constrained 146 device and an unconstrained device that communicate over the Internet 147 using TCP, possibly traversing a middlebox (e.g. a firewall, NAT, 148 etc.). Figure 1 illustrates such scenario. Note that the scenario 149 is asymmetric, as the unconstrained device will typically not suffer 150 the severe constraints of the constrained device. The unconstrained 151 device is expected to be mains-powered, to have high amount of memory 152 and processing power, and to be connected to a resource-rich network. 154 Assuming that a majority of constrained devices will correspond to 155 sensor nodes, the amount of data traffic sent by constrained devices 156 (e.g. sensor node measurements) is expected to be higher than the 157 amount of data traffic in the opposite direction. Nevertheless, 158 constrained devices may receive requests (to which they may respond), 159 commands (for configuration purposes and for constrained devices 160 including actuators) and relatively infrequent firmware/software 161 updates. 163 +---------------+ 164 o o <--------- TCP communication ------> | | 165 o o | | 166 o o | Unconstrained | 167 o o +-----------+ | device | 168 o o o ------ | Middlebox | ------- | | 169 o o +-----------+ | (e.g. cloud) | 170 o o o | | 171 +---------------+ 172 constrained devices 174 Figure 1: TCP communication between a constrained device and an 175 unconstrained device, traversing a middlebox. 177 4. TCP over CNNs 179 4.1. TCP connection initiation 181 In the constrained device to unconstrained device scenario 182 illustrated above, a TCP connection is typically initiated by the 183 constrained device, in order for this device to support possible 184 sleep periods to save energy. 186 4.2. Maximum Segment Size (MSS) 188 Some link layer technologies in the CNN space are characterized by a 189 short data unit payload size, e.g. up to a few tens or hundreds of 190 bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 191 bytes. 193 6LoWPAN defined an adaptation layer to support IPv6 over IEEE 194 802.15.4 networks. The adaptation layer includes a fragmentation 195 mechanism, since IPv6 requires the layer below to support an MTU of 196 1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation 197 mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes 198 [RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T 199 G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based 200 adaptation layers in order to enable IPv6 support. These 201 technologies do support link layer fragmentation. By exploiting this 202 functionality, the adaptation layers that enable IPv6 over such 203 technologies also define an MTU of 1280 bytes. 205 For devices using technologies with a link MTU of 1280 bytes (e.g. 206 defined by a 6LoWPAN-based adaptation layer), in order to avoid IP 207 layer fragmentation, the TCP MSS must not be set to a value greater 208 than 1220 bytes in CNNs, and it must not be set to a value leading to 209 an IPv6 datagram size exceeding 1280 bytes. (Note: IP version 6 is 210 assumed.) 212 On the other hand, there exist technologies also used in the CNN 213 space, such as Master Slave / Token Passing (TP) [RFC8163], 214 Narrowband IoT (NB-IoT) [I-D.ietf-lpwan-overview] or IEEE 802.11ah 215 [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of 216 frame size limitations as the technologies mentioned above. The MTU 217 for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- 218 IoT is 1600 bytes, and the maximum frame payload size for IEEE 219 802.11ah is 7991 bytes. Over such technologies, the TCP MSS may be 220 set to a value greater than 1220 bytes, as long as IPv6 datagram size 221 does not exceed the MTU for each technology. One consideration in 222 this regard is that, when a node supports an MTU greater than 1280 223 bytes, it 'SHOULD' then support Path MTU (PMTU) discovery [RFC1981]. 224 (Note that, as explained in RFC 1981, a minimal IPv6 implementation 225 may 'choose to omit implementation of Path MTU Discovery'). For the 226 sake of lightweight implementation and operation, unless applications 227 require handling large data units (i.e. leading to an IPv6 datagram 228 size greater than 1280 bytes), it may be desirable to limit the MTU 229 to 1280 bytes. 231 4.3. Window Size 233 A TCP stack can reduce the implementation complexity by advertising a 234 TCP window size of one MSS, and also transmit at most one MSS of 235 unacknowledged data, at the cost of decreased performance. This size 236 for receive and send window is appropriate for simple message 237 exchanges in the CNN space, reduces implementation complexity and 238 memory requirements, and reduces overhead (see section 4.7). 240 A TCP window size of one MSS follows the same rationale as the 241 default setting for NSTART in [RFC7252], leading to equivalent 242 operation when CoAP is used over TCP. 244 For devices that can afford greater TCP window size, it may be useful 245 to allow window sizes of at least five MSSs, in order to allow Fast 246 Retransmit and Fast Recovery [RFC5681]. 248 4.4. RTO estimation 250 If a TCP sender uses very small window size and cannot use Fast 251 Retransmit/Fast Recovery or SACK, the RTO algorithm has a larger 252 impact on performance than for a more powerful TCP stack. In that 253 case, RTO algorithm tuning may be considered, although careful 254 assessment of possible drawbacks is recommended. A fundamental 255 trade-off exists between responsiveness and correctness of RTOs 256 [I-D.ietf-tcpm-rto-consider]. A more aggressive RTO behavior reduces 257 wait time before retransmissions, but it also increases the 258 probability of incurring spurious timeouts. The latter lead to 259 unnecessary waste of potentially scarce resources in CNNs such as 260 energy and bandwidth. 262 On a related note, there has been recent activity in the area of 263 defining an adaptive RTO algorithm for CoAP (over UDP). As shown in 264 experimental studies, the RTO estimator for CoAP defined in 265 [I-D.ietf-core-cocoa] (hereinafter, CoCoA RTO) outperforms state-of- 266 art algorithms designed as improvements to RFC 6298 [RFC6298] for 267 TCP, in terms of packet delivery ratio, settling time after a burst 268 of messages, and fairness (the latter is specially relevant in 269 multihop networks connected to the Internet through a single device, 270 such as a 6LoWPAN Border Router (6LBR) configured as a RPL root) 271 [Commag]. In fact, CoCoA RTO has been designed specifically 272 considering the challenges of CNNs, in contrast with the RFC 6298 273 RTO. 275 4.5. TCP connection lifetime 277 [[Note: future revisions will better separate what a TCP stack should 278 support, or not, and how the TCP stack should be used by 279 applications, e.g., whether to close connections or not.]] 281 4.5.1. Long TCP connection lifetime 283 In CNNs, in order to minimize message overhead, a TCP connection 284 should be kept open as long as the two TCP endpoints have more data 285 to exchange or it is envisaged that further segment exchanges will 286 take place within an interval of two hours since the last segment has 287 been sent. A greater interval may be used in scenarios where 288 applications exchange data infrequently. 290 TCP keep-alive messages [RFC1122] may be supported by a server, to 291 check whether a TCP connection is active, in order to release state 292 of inactive connections. This may be useful for servers running on 293 memory-constrained devices. 295 Since the keep-alive timer may not be set to a value lower than two 296 hours [RFC1122], TCP keep-alive messages are not useful to guarantee 297 that filter state records in middleboxes such as firewalls will not 298 be deleted after an inactivity interval typically in the order of a 299 few minutes [RFC6092]. In scenarios where such middleboxes are 300 present, alternative measures to avoid early deletion of filter state 301 records (which might lead to frequent establishment of new TCP 302 connections between the two involved endpoints) include increasing 303 the initial value for the filter state inactivity timers (if 304 possible), and using application layer heartbeat messages. 306 4.5.2. Short TCP connection lifetime 308 A different approach to addressing the problem of traversing 309 middleboxes that perform early filter state record deletion relies on 310 using TCP Fast Open (TFO) [RFC7413]. In this case, instead of trying 311 to maintain a TCP connection for long time, possibly short-lived 312 connections can be opened between two endpoints while incurring low 313 overhead. In fact, TFO allows data to be carried in SYN (and SYN- 314 ACK) packets, and to be consumed immediately by the receceiving 315 endpoint, thus reducing overhead compared with the traditional three- 316 way handshake required to establish a TCP connection. 318 For security reasons, TFO requires the TCP endpoint that will open 319 the TCP connection (which in CNNs will typically be the constrained 320 device) to request a cookie from the other endpoint. The cookie, 321 with a size of 4 or 16 bytes, is then included in SYN packets of 322 subsequent connections. The cookie needs to be refreshed (and 323 obtained by the client) after a certain amount of time. 324 Nevertheless, TFO is more efficient than frequently opening new TCP 325 connections (by using the traditional three-way handshake) for 326 transmitting new data, as long as the cookie update rate is well 327 below the data new connection rate. 329 4.6. Explicit congestion notification 331 Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs. 332 ECN allows a router to signal in the IP header of a packet that 333 congestion is arising, for example when queue size reaches a certain 334 threshold. If such a packet encapsulates a TCP data packet, an ECN- 335 enabled TCP receiver will echo back the congestion signal to the TCP 336 sender by setting a flag in its next TCP ACK. The sender triggers 337 congestion control measures as if a packet loss had happened. In 338 that case, when the congestion window of a TCP sender has a size of 339 one segment, the TCP sender resets the retransmit timer, and will 340 only be able to send a new packet when the retransmit timer expires 341 [RFC3168]. Effectively, the TCP sender reduces at that moment its 342 sending rate from 1 segment per Round Trip Time (RTT) to 1 segment 343 per default RTO. 345 ECN can reduce packet losses, since congestion control measures can 346 be applied earlier than after the reception of three duplicate ACKs 347 (if the TCP sender window is large enough) or upon TCP sender RTO 348 expiration [RFC2884]. Therefore, the number of retries decreases, 349 which is particularly beneficial in CNNs, where energy and bandwidth 350 resources are typically limited. Furthermore, latency and jitter are 351 also reduced. 353 ECN is particularly appropriate in CNNs, since in these environments 354 transactional type interactions are a dominant traffic pattern. As 355 transactional data size decreases, the probability of detecting 356 congestion by the presence of three duplicate ACKs decreases. In 357 contrast, ECN can still activate congestion control measures without 358 requiring three duplicate ACKs. 360 4.7. TCP options 362 A TCP implementation needs to support options 0, 1 and 2 [RFC793]. A 363 TCP implementation for a constrained device that uses a single-MSS 364 TCP receive or transmit window size may not benefit from supporting 365 the following TCP options: Window scale [RFC1323], TCP Timestamps 366 [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted 367 [RFC2018]. Other TCP options should not be used, in keeping with the 368 principle of lightweight operation. 370 Other TCP options should not be supported by a constrained device, in 371 keeping with the principle of lightweight implementation and 372 operation. 374 If a device, with less severe memory and processing constraints, can 375 afford advertising a TCP window size of several MSSs, it may support 376 the SACK option to improve performance. SACK allows a data receiver 377 to inform the data sender of non-contiguous data blocks received, 378 thus a sender (having previously sent the SACK-Permitted option) can 379 avoid performing unnecessary retransmissions, saving energy and 380 bandwidth, as well as reducing latency. The receiver supporting SACK 381 will need to manage the reception of possible out-of-order received 382 segments, requiring sufficient buffer space. 384 SACK adds 8*n+2 bytes to the TCP header, where n denotes the number 385 of data blocks received, up to 4 blocks. For a low number of out-of- 386 order segments, the header overhead penalty of SACK is compensated by 387 avoiding unnecessary retransmissions. 389 Another potentially relevant TCP option in the context of CNNs is 390 (TFO) [RFC7413]. As described in section 4.5.2, TFO can be used to 391 address the problem of traversing middleboxes that perform early 392 filter state record deletion. 394 4.8. Delayed Acknowledgments 396 A device that advertises a single-MSS receive window needs to avoid 397 use of delayed ACKs in order to avoid contributing unnecessary delay 398 (of up to 500 ms) to the RTT [RFC5681]. 400 When traffic over a CNN is expected to be mostly of transactional 401 type, with transaction size typically below one MSS, delayed ACKs are 402 not recommended. For transactional-type traffic between a 403 constrained device and a peer (e.g. backend infrastructure) that uses 404 delayed ACKs, the maximum ACK rate of the peer will be typically of 405 one ACK every 200 ms (or even lower). If in such conditions the peer 406 device is administered by the same entity managing the constrained 407 device, it is recommended to disable delayed ACKs at the peer side. 409 On the other hand, delayed ACKs allow to reduce the number of ACKs in 410 bulk transfer type of traffic, e.g. for firmware/software updates or 411 for transferring larger data units containing a batch of sensor 412 readings. 414 4.9. Explicit loss notifications 416 There has been a significant body of research on solutions capable of 417 explicitly indicating whether a TCP segment loss is due to 418 corruption, in order to avoid activation of congestion control 419 mechanisms [ETEN] [RFC2757]. While such solutions may provide 420 significant improvement, they have not been widely deployed and 421 remain as experimental work. In fact, as of today, the IETF has not 422 standardized any such solution. 424 5. Security Considerations 426 If TFO is used, the security considerations of RFC 7413 apply. 428 There exist TCP options which improve TCP security. Examples include 429 the TCP MD5 signature option [RFC2385] and the TCP Authentication 430 Option (TCP-AO) [RFC5925]. However, both options add overhead and 431 complexity. The TCP MD5 signature option adds 18 bytes to every 432 segment of a connection. TCP-AO typically has a size of 16-20 bytes. 434 6. Acknowledgments 436 Carles Gomez has been funded in part by the Spanish Government 437 (Ministerio de Educacion, Cultura y Deporte) through the Jose 438 Castillejo grant CAS15/00336 and by European Regional Development 439 Fund (ERDF) and the Spanish Government through project 440 TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this 441 work has been carried out during his stay as a visiting scholar at 442 the Computer Laboratory of the University of Cambridge. 444 The authors appreciate the feedback received for this document. The 445 following folks provided comments that helped improve the document: 446 Carsten Bormann, Zhen Cao, Wei Genyu, Michael Scharf, Ari Keranen, 447 Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe 448 Touch, Fred Baker, Nik Sultana, Kerry Lynn, and Erik Nordmark. Simon 449 Brummer provided details on the RIOT TCP implementation. Xavi 450 Vilajosana provided details on the OpenWSN TCP implementation. 452 7. Annex. TCP implementations for constrained devices 454 This section overviews the main features of TCP implementations for 455 constrained devices. 457 7.1. uIP 459 uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers. 460 uIP has been deployed with Contiki and the Arduino Ethernet shield. 462 A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) 463 has been reported for uIP [Dunk]. 465 uIP provides a global buffer for incoming packets, of single-packet 466 size. A buffer for outgoing data is not provided. In case of a 467 retransmission, an application must be able to reproduce the same 468 packet that had been transmitted. 470 The MSS is announced via the MSS option on connection establishment 471 and the receive window size (of one MSS) is not modified during a 472 connection. Stop-and-wait operation is used for sending data. Among 473 other optimizations, this allows to avoid sliding window operations, 474 which use 32-bit arithmetic extensively and are expensive on 8-bit 475 CPUs. 477 7.2. lwIP 479 lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. 480 lwIP has a total code size of ~14 kB to ~22 kB (which comprises 481 memory management, checksumming, network interfaces, IP, ICMP and 482 TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. 484 In contrast with uIP, lwIP decouples applications from the network 485 stack. lwIP supports a TCP transmission window greater than a single 486 segment, as well as buffering of incoming and outcoming data. Other 487 implemented mechanisms comprise slow start, congestion avoidance, 488 fast retransmit and fast recovery. SACK and Window Scale have been 489 recently added to lwIP. 491 7.3. RIOT 493 The RIOT TCP implementation (called GNRC TCP) has been designed for 494 Class 1 devices [RFC 7228]. The main target platforms are 8- and 495 16-bit microcontrollers. GNRC TCP offers a similar function set as 496 uIP, but it provides and maintains an independent receive buffer for 497 each connection. In contrast to uIP, retransmission is also handled 498 by GNRC TCP. GNRC TCP uses a single-MSS window size, which 499 simplifies the implementation. The application programmer does not 500 need to know anything about the TCP internals, therefore GNRC TCP can 501 be seen as a user-friendly uIP TCP implementation. 503 The MSS is set on connections establishment and cannot be changed 504 during connection lifetime. GNRC TCP allows multiple connections in 505 parallel, but each TCB must be allocated somewhere in the system. By 506 default there is only enough memory allocated for a single TCP 507 connection, but it can be increased at compile time if the user needs 508 multiple parallel connections. 510 7.4. OpenWSN 512 The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP 513 implementation. OpenWSN TCP implementation only supports the minimum 514 state machine functionality required. For example, it does not 515 perform retransmissions. 517 7.5. TinyOS 519 TBD 521 7.6. Summary 523 +-------+---------+---------+------+---------+--------+ 524 | uIP |lwIP orig|lwIP 2.0 | RIOT | OpenWSN | TinyOS | 525 +--------+----------------+-------+---------+---------+------+---------+--------+ 526 | | Data size | * | * | * | * | * | * | 527 | Memory +----------------+-------+---------+---------+------+---------+--------+ 528 | | Code size (kB) | < 5 |~9 to ~14| * | * | * | * | 529 +--------+----------------+-------+---------+---------+------+---------+--------+ 530 | |Window size(MSS)| 1 | Multiple| Multiple| 1 | 1 | * | 531 | +----------------+-------+---------+---------+------+---------+--------+ 532 | | Slow start | No | Yes | Yes | No | No | * | 533 | T +----------------+-------+---------+---------+------+---------+--------+ 534 | C | Fast rec/retx | No | Yes | Yes | No | No | * | 535 | P +----------------+-------+---------+---------+------+---------+--------+ 536 | | Keep-alive | No | * | * | No | No | * | 537 | +----------------+-------+---------+---------+------+---------+--------+ 538 | f | TFO | No | No | * | No | No | * | 539 | e +----------------+-------+---------+---------+------+---------+--------+ 540 | a | ECN | No | No | * | No | No | * | 541 | t +----------------+-------+---------+---------+------+---------+--------+ 542 | u | Window Scale | No | No | Yes | No | No | * | 543 | r +----------------+-------+---------+---------+------+---------+--------+ 544 | e | TCP timestamps | No | No | Yes | No | No | * | 545 | s +----------------+-------+---------+---------+------+---------+--------+ 546 | | SACK | No | No | Yes | No | No | * | 547 | +----------------+-------+---------+---------+------+---------+--------+ 548 | | Delayed ACKs | No | Yes | Yes | No | No | * | 549 +--------+----------------+-------+---------+---------+------+---------+--------+ 551 Figure 2: Summary of TCP features for differrent lightweight TCP 552 implementations. 554 8. References 556 8.1. Normative References 558 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 559 Communication Layers", STD 3, RFC 1122, 560 DOI 10.17487/RFC1122, October 1989, 561 . 563 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 564 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 565 1992, . 567 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 568 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 569 1996, . 571 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 572 Selective Acknowledgment Options", RFC 2018, 573 DOI 10.17487/RFC2018, October 1996, 574 . 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, 579 . 581 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 582 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 583 1998, . 585 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 586 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 587 December 1998, . 589 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 590 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 591 Transfer Protocol -- HTTP/1.1", RFC 2616, 592 DOI 10.17487/RFC2616, June 1999, 593 . 595 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 596 Vaidya, "Long Thin Networks", RFC 2757, 597 DOI 10.17487/RFC2757, January 2000, 598 . 600 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 601 Explicit Congestion Notification (ECN) in IP Networks", 602 RFC 2884, DOI 10.17487/RFC2884, July 2000, 603 . 605 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 606 of Explicit Congestion Notification (ECN) to IP", 607 RFC 3168, DOI 10.17487/RFC3168, September 2001, 608 . 610 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 611 "Transmission of IPv6 Packets over IEEE 802.15.4 612 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 613 . 615 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 616 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 617 . 619 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 620 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 621 June 2010, . 623 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 624 Capabilities in Customer Premises Equipment (CPE) for 625 Providing Residential IPv6 Internet Service", RFC 6092, 626 DOI 10.17487/RFC6092, January 2011, 627 . 629 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 630 "Computing TCP's Retransmission Timer", RFC 6298, 631 DOI 10.17487/RFC6298, June 2011, 632 . 634 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 635 Statement and Requirements for IPv6 over Low-Power 636 Wireless Personal Area Network (6LoWPAN) Routing", 637 RFC 6606, DOI 10.17487/RFC6606, May 2012, 638 . 640 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 641 Constrained-Node Networks", RFC 7228, 642 DOI 10.17487/RFC7228, May 2014, 643 . 645 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 646 Application Protocol (CoAP)", RFC 7252, 647 DOI 10.17487/RFC7252, June 2014, 648 . 650 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 651 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 652 . 654 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 655 over ITU-T G.9959 Networks", RFC 7428, 656 DOI 10.17487/RFC7428, February 2015, 657 . 659 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 660 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 661 DOI 10.17487/RFC7540, May 2015, 662 . 664 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 665 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 666 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 667 . 669 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 670 M., and D. Barthel, "Transmission of IPv6 Packets over 671 Digital Enhanced Cordless Telecommunications (DECT) Ultra 672 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 673 2017, . 675 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 676 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 677 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 678 May 2017, . 680 8.2. Informative References 682 [Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP 683 Congestion Control for the Internet of Things", IEEE 684 Communications Magazine, June 2016. 686 [Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003. 688 [ETEN] R. Krishnan et al, "Explicit transport error notification 689 (ETEN) for error-prone wireless and satellite networks", 690 Computer Networks 2004. 692 [I-D.delcarpio-6lo-wlanah] 693 Vega, L., Robles, I., and R. Morabito, "IPv6 over 694 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 695 progress), October 2015. 697 [I-D.ietf-core-cocoa] 698 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 699 "CoAP Simple Congestion Control/Advanced", draft-ietf- 700 core-cocoa-01 (work in progress), March 2017. 702 [I-D.ietf-lpwan-overview] 703 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 704 overview-04 (work in progress), June 2017. 706 [I-D.ietf-lwig-energy-efficient] 707 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 708 Efficient Features of Internet of Things Protocols", 709 draft-ietf-lwig-energy-efficient-07 (work in progress), 710 March 2017. 712 [I-D.ietf-tcpm-rto-consider] 713 Allman, M., "Retransmission Timeout Requirements", draft- 714 ietf-tcpm-rto-consider-05 (work in progress), March 2017. 716 [I-D.tschofenig-core-coap-tcp-tls] 717 Bormann, C., Lemay, S., Technologies, Z., and H. 718 Tschofenig, "A TCP and TLS Transport for the Constrained 719 Application Protocol (CoAP)", draft-tschofenig-core-coap- 720 tcp-tls-05 (work in progress), November 2015. 722 [MQTTS] U. Hunkeler, H.-L. Truong, A. Stanford-Clark, "MQTT-S: A 723 Publish/Subscribe Protocol For Wireless Sensor Networks", 724 2008. 726 Authors' Addresses 728 Carles Gomez 729 UPC/i2CAT 730 C/Esteve Terradas, 7 731 Castelldefels 08860 732 Spain 734 Email: carlesgo@entel.upc.edu 735 Jon Crowcroft 736 University of Cambridge 737 JJ Thomson Avenue 738 Cambridge, CB3 0FD 739 United Kingdom 741 Email: jon.crowcroft@cl.cam.ac.uk 743 Michael Scharf 744 Nokia 745 Lorenzstrasse 10 746 Stuttgart, 70435 747 Germany 749 Email: michael.scharf@nokia.com