draft-ietf-lwig-tcp-constrained-node-networks-02.txt   draft-ietf-lwig-tcp-constrained-node-networks-03.txt 
LWIG Working Group C. Gomez LWIG Working Group C. Gomez
Internet-Draft UPC/i2CAT Internet-Draft UPC
Intended status: Informational J. Crowcroft Intended status: Informational J. Crowcroft
Expires: August 31, 2018 University of Cambridge Expires: December 12, 2018 University of Cambridge
M. Scharf M. Scharf
Nokia Nokia
February 27, 2018 June 10, 2018
TCP Usage Guidance in the Internet of Things (IoT) TCP Usage Guidance in the Internet of Things (IoT)
draft-ietf-lwig-tcp-constrained-node-networks-02 draft-ietf-lwig-tcp-constrained-node-networks-03
Abstract Abstract
This document provides guidance on how to implement and use the This document provides guidance on how to implement and use the
Transmission Control Protocol (TCP) in Constrained-Node Networks Transmission Control Protocol (TCP) in Constrained-Node Networks
(CNNs), which are a characterstic of the Internet of Things (IoT). (CNNs), which are a characterstic of the Internet of Things (IoT).
Such environments require a lightweight TCP implementation and may Such environments require a lightweight TCP implementation and may
not make use of optional functionality. This document explains a not make use of optional functionality. This document explains a
number of known and deployed techniques to simplify a TCP stack as number of known and deployed techniques to simplify a TCP stack as
well as corresponding tradeoffs. The objective is to help embedded well as corresponding tradeoffs. The objective is to help embedded
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2018. This Internet-Draft will expire on December 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4 3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4
3.1. Network and link properties . . . . . . . . . . . . . . . 4 3.1. Network and link properties . . . . . . . . . . . . . . . 4
3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 5 3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 5
3.3. Communication and traffic patterns . . . . . . . . . . . 6 3.3. Communication and traffic patterns . . . . . . . . . . . 6
4. TCP implementation and configuration in CNNs . . . . . . . . 6 4. TCP implementation and configuration in CNNs . . . . . . . . 6
4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 6 4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7 4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7
4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 7 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 7
4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8
4.2. TCP guidance for small windows and buffers . . . . . . . 8 4.2. TCP guidance for small windows and buffers . . . . . . . 8
4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 8 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 8
4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9
4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 9 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 9
4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 10 4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 10
4.3. General recommendations for TCP in CNNs . . . . . . . . . 10 4.3. General recommendations for TCP in CNNs . . . . . . . . . 10
4.3.1. Error recovery and congestion/flow control . . . . . 10 4.3.1. Error recovery and congestion/flow control . . . . . 10
4.3.2. Selective Acknowledgments (SACK) . . . . . . . . . . 11 4.3.2. Selective Acknowledgments (SACK) . . . . . . . . . . 11
4.3.3. Delayed Acknowledgments . . . . . . . . . . . . . . . 11 4.3.3. Delayed Acknowledgments . . . . . . . . . . . . . . . 11
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 11 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 11
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12
5.2. TCP connection lifetime . . . . . . . . . . . . . . . . . 12 5.2. TCP connection lifetime . . . . . . . . . . . . . . . . . 12
5.2.1. Long TCP connection lifetime . . . . . . . . . . . . 12 5.2.1. Long TCP connection lifetime . . . . . . . . . . . . 12
5.2.2. Short TCP connection lifetime . . . . . . . . . . . . 12 5.2.2. Short TCP connection lifetime . . . . . . . . . . . . 12
5.3. Number of parallel connections . . . . . . . . . . . . . 13 5.3. Number of parallel connections . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Annex. TCP implementations for constrained devices . . . . . 14 8. Annex. TCP implementations for constrained devices . . . . . 14
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.6. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16 8.6. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16
8.7. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.7. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Annex. Changes compared to previous versions . . . . . . . . 18 9. Annex. Changes compared to previous versions . . . . . . . . 17
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 18 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 18
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 18 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Internet Protocol suite is being used for connecting Constrained- The Internet Protocol suite is being used for connecting Constrained-
Node Networks (CNNs) to the Internet, enabling the so-called Internet Node Networks (CNNs) to the Internet, enabling the so-called Internet
of Things (IoT) [RFC7228]. In order to meet the requirements that of Things (IoT) [RFC7228]. In order to meet the requirements that
stem from CNNs, the IETF has produced a suite of new protocols stem from CNNs, the IETF has produced a suite of new protocols
specifically designed for such environments (see e.g. specifically designed for such environments (see e.g.
skipping to change at page 7, line 42 skipping to change at page 7, line 45
IPv6 datagram size greater than 1280 bytes), it may be desirable to IPv6 datagram size greater than 1280 bytes), it may be desirable to
limit the MTU to 1280 bytes in order to avoid the need to support limit the MTU to 1280 bytes in order to avoid the need to support
Path MTU Discovery [RFC1981]. Path MTU Discovery [RFC1981].
An IPv6 datagram size exceeding 1280 bytes can be avoided by setting An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is
assumed.) assumed.)
4.1.2. Explicit Congestion Notification (ECN) 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs. Explicit Congestion Notification (ECN) [RFC3168] has a number of
ECN allows a router to signal in the IP header of a packet that benefits that are relevant for CNNs. ECN allows a router to signal
congestion is arising, for example when queue size reaches a certain in the IP header of a packet that congestion is arising, for example
threshold. If such a packet encapsulates a TCP data packet, an ECN- when a queue size reaches a certain threshold. An ECN-enabled TCP
enabled TCP receiver will echo back the congestion signal to the TCP receiver will echo back the congestion signal to the TCP sender by
sender by setting a flag in its next TCP ACK. The sender triggers setting a flag in its next TCP ACK. The sender triggers congestion
congestion control measures as if a packet loss had happened. In control measures as if a packet loss had happened. ECN can be
that case, when the congestion window of a TCP sender has a size of incrementally deployed in the Internet. Guidance on configuration
one segment, the TCP sender resets the retransmit timer, and will and usage of ECN is provided in [RFC7567]. The document [RFC8087]
only be able to send a new packet when the retransmit timer expires outlines the principal gains in terms of increased throughput,
reduced delay, and other benefits when ECN is used over a network
[RFC3168]. Effectively, the TCP sender reduces at that moment its path that includes equipment that supports Congestion Experienced
sending rate from 1 segment per Round Trip Time (RTT) to 1 segment (CE) marking.
per default RTO.
ECN can reduce packet losses, since congestion control measures can ECN can reduce packet losses since congestion control measures can be
be applied earlier than after the reception of three duplicate ACKs applied earlier [RFC2884]. Less lost packets implies that the number
(if the TCP sender window is large enough) or upon TCP sender RTO of retransmitted segments decreases, which is particularly beneficial
expiration [RFC2884]. Therefore, the number of retries decreases, in CNNs, where energy and bandwidth resources are typically limited.
which is particularly beneficial in CNNs, where energy and bandwidth Also, it makes sense to try to avoid packet drops for transactional
resources are typically limited. Furthermore, latency and jitter are workloads with small data sizes, which are typical for CNNs. In such
also reduced. traffic patterns, it is more difficult to detect packet loss without
retransmission timeouts (e.g., as there may be no three duplicate
ACKs). Any retransmission timeout slows down the data transfer
significantly. When the congestion window of a TCP sender has a size
of one segment, the TCP sender resets the retransmit timer, and the
sender will only be able to send a new packet when the retransmit
timer expires [RFC3168]. Effectively, the TCP sender reduces at that
moment its sending rate from 1 segment per Round Trip Time (RTT) to 1
segment per RTO, which can result in a very low throughput. In
addition to better throughput, ECN can also help reducing latency and
jitter.
ECN is particularly appropriate in CNNs, since in these environments Given the benefits, more and more TCP stacks in the Internet support
transactional type interactions are a dominant traffic pattern. As ECN, and it specifically makes sense to leverage ECN in controlled
transactional data size decreases, the probability of detecting environments such as CNNs.
congestion by the presence of three duplicate ACKs decreases. In
contrast, ECN can still activate congestion control measures without
requiring three duplicate ACKs.
4.1.3. Explicit loss notifications 4.1.3. Explicit loss notifications
There has been a significant body of research on solutions capable of There has been a significant body of research on solutions capable of
explicitly indicating whether a TCP segment loss is due to explicitly indicating whether a TCP segment loss is due to
corruption, in order to avoid activation of congestion control corruption, in order to avoid activation of congestion control
mechanisms [ETEN] [RFC2757]. While such solutions may provide mechanisms [ETEN] [RFC2757]. While such solutions may provide
significant improvement, they have not been widely deployed and significant improvement, they have not been widely deployed and
remain as experimental work. In fact, as of today, the IETF has not remain as experimental work. In fact, as of today, the IETF has not
standardized any such solution. standardized any such solution.
skipping to change at page 13, line 43 skipping to change at page 13, line 43
include the TCP MD5 signature option [RFC2385] and the TCP include the TCP MD5 signature option [RFC2385] and the TCP
Authentication Option (TCP-AO) [RFC5925]. However, both options add Authentication Option (TCP-AO) [RFC5925]. However, both options add
overhead and complexity. The TCP MD5 signature option adds 18 bytes overhead and complexity. The TCP MD5 signature option adds 18 bytes
to every segment of a connection. TCP-AO typically has a size of to every segment of a connection. TCP-AO typically has a size of
16-20 bytes. 16-20 bytes.
For the mechanisms discussed in this document, the corresponding For the mechanisms discussed in this document, the corresponding
considerations apply. For instance, if TFO is used, the security considerations apply. For instance, if TFO is used, the security
considerations of [RFC7413] apply. considerations of [RFC7413] apply.
Constrained devices are expected to support smaller TCP window sizes
than less limited devices. In such conditions, segment
retransmission triggered by RTO expiration is expected to be
relatively frequent, due to lack of (enough) duplicate ACKs,
especially when a constrained device uses a single-MSS window size.
For this reason, constrained devices running TCP may appear as
particularly appealing victims of the so-called "shrew" Denial of
Service (DoS) attack [shrew], whereby one or more sources generate a
packet spike targetted to coincide with consecutive RTO-expiration-
triggered retry attempts of a victim node. Note that the attack may
be performed by Internet-connected devices, including constrained
devices in the same CNN as the victim, as well as remote ones.
Mitigation techniques include RTO randomization and attack blocking
by routers able to detect shrew attacks based on their traffic
pattern.
7. Acknowledgments 7. Acknowledgments
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336 and by European Regional Development Castillejo grant CAS15/00336 and by European Regional Development
Fund (ERDF) and the Spanish Government through project Fund (ERDF) and the Spanish Government through project
TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this
work has been carried out during his stay as a visiting scholar at work has been carried out during his stay as a visiting scholar at
the Computer Laboratory of the University of Cambridge. the Computer Laboratory of the University of Cambridge.
The authors appreciate the feedback received for this document. The The authors appreciate the feedback received for this document. The
following folks provided comments that helped improve the document: following folks provided comments that helped improve the document:
Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan
Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred
Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and
Hannes Tschofenig. Simon Brummer provided details on the RIOT TCP Hannes Tschofenig. Simon Brummer provided details, and kindly
performed RAM and ROM usage measurements, on the RIOT TCP
implementation. Xavi Vilajosana provided details on the OpenWSN TCP implementation. Xavi Vilajosana provided details on the OpenWSN TCP
implementation. Rahul Jadhav provided details on the uIP TCP implementation. Rahul Jadhav provided details on the uIP TCP
implementation. implementation.
8. Annex. TCP implementations for constrained devices 8. Annex. TCP implementations for constrained devices
This section overviews the main features of TCP implementations for This section overviews the main features of TCP implementations for
constrained devices. constrained devices. The survey is limited to open source stacks
with small footprint. It is not meant to be all-encompassing. For
more powerful embedded systems (e.g., with 32-bit processors), there
are further stacks that comprehensively implement TCP. On the other
hand, please be aware that this Annex is based on information
available as of the writing.
8.1. uIP 8.1. uIP
uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers. uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers,
uIP has been deployed with Contiki and the Arduino Ethernet shield. which pioneered TCP/IP implementations for constrained devices. uIP
A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) has been deployed with Contiki and the Arduino Ethernet shield. A
code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP)
has been reported for uIP [Dunk]. has been reported for uIP [Dunk].
uIP uses same buffer both incoming and outgoing traffic, with has a uIP uses same buffer both incoming and outgoing traffic, with has a
size of a single packet. In case of a retransmission, an application size of a single packet. In case of a retransmission, an application
must be able to reproduce the same user data that had been must be able to reproduce the same user data that had been
transmitted. transmitted.
The MSS is announced via the MSS option on connection establishment The MSS is announced via the MSS option on connection establishment
and the receive window size (of one MSS) is not modified during a and the receive window size (of one MSS) is not modified during a
connection. Stop-and-wait operation is used for sending data. Among connection. Stop-and-wait operation is used for sending data. Among
skipping to change at page 15, line 32 skipping to change at page 16, line 11
default there is only enough memory allocated for a single TCP default there is only enough memory allocated for a single TCP
connection, but it can be increased at compile time if the user needs connection, but it can be increased at compile time if the user needs
multiple parallel connections. multiple parallel connections.
The RIOT TCP implementation does not currently support classic POSIX The RIOT TCP implementation does not currently support classic POSIX
sockets. However, it supports an interface that has been inspired by sockets. However, it supports an interface that has been inspired by
POSIX. POSIX.
8.4. OpenWSN 8.4. OpenWSN
The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP The TCP implementation in OpenWSN has similar functionality like the
implementation. OpenWSN TCP implementation only supports the minimum uIP TCP implementation. OpenWSN TCP implementation only supports the
state machine functionality required. For example, it does not minimum state machine functionality required. For example, it does
perform retransmissions. not perform retransmissions. There has not been much recent activity
to overcome these limitations.
8.5. TinyOS 8.5. TinyOS
TinyOS was important as platform for early constrained devices.
TinyOS has an experimental TCP stack that uses a simple nonblocking TinyOS has an experimental TCP stack that uses a simple nonblocking
library-based implementation of TCP, which provides a subset of the library-based implementation of TCP, which provides a subset of the
socket interface primitives. The application is responsible for socket interface primitives. The application is responsible for
buffering. The TCP library does not do any receive-side buffering. buffering. The TCP library does not do any receive-side buffering.
Instead, it will immediately dispatch new, in-order data to the Instead, it will immediately dispatch new, in-order data to the
application and otherwise drop the segment. A send buffer is application and otherwise drop the segment. A send buffer is
provided so that the TCP implementation can automatically retransmit provided so that the TCP implementation can automatically retransmit
missing segments. Multiple TCP connections are possible. missing segments. Multiple TCP connections are possible. Recently
there has been little further work on the stack.
8.6. FreeRTOS 8.6. FreeRTOS
FreeRTOS is a real-time operating system kernel for embedded devices FreeRTOS is a real-time operating system kernel for embedded devices
that is supported by 16- and 32-bit microprocessors. Its TCP that is supported by 16- and 32-bit microprocessors. Its TCP
implementation is based on multiple-MSS window size, although a implementation is based on multiple-MSS window size, although a
'Tiny-TCP' option, which is a single-MSS variant, can be enabled. 'Tiny-TCP' option, which is a single-MSS variant, can be enabled.
Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a
technique intended 'to gain performance'. technique intended 'to gain performance'.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
uC/OS is a real-time operating system kernel for embedded devices, uC/OS is a real-time operating system kernel for embedded devices,
which is maintained by Micrium. uC/OS is intended for 8-, 16- and which is maintained by Micrium. uC/OS is intended for 8-, 16- and
32-bit microprocessors. The uC/OS TCP implementation supports a 32-bit microprocessors. The uC/OS TCP implementation supports a
multiple-MSS window size. multiple-MSS window size.
8.8. Summary 8.8. Summary
+---+---------+--------+----+-------+------+--------+-----+ +---+---------+--------+----+-------+------+--------+-----+
|uIP|lwIP orig|lwIP 2.0|RIOT|OpenWSN|TinyOS|FreeRTOS|uC/OS| |uIP|lwIP orig|lwIP 2.0|RIOT|OpenWSN|TinyOS|FreeRTOS|uC/OS|
+------+-------------+---+---------+--------+----+-------+------+--------+-----+ +------+-------------+---+---------+--------+----+-------+------+--------+-----+
| |Data size(kB)| * | * | * | * | * | * | * | * | |Memory|Code size(kB)| <5|~9 to ~14| ~40 | <7 | N/A | N/A | <9.2 | N/A |
|Memory+-------------+---+---------+--------+----+-------+------+--------+-----+ | | |(a)| (T1) | (b) |(T3)| | | (T2) | |
| |Code size(kB)| <5|~9 to ~14| ~40 | * | * | * | <9.2 | * |
| | |(a)| (T1) | (b) | | | | (T2) | |
+------+-------------+---+---------+--------+----+-------+------+--------+-----+ +------+-------------+---+---------+--------+----+-------+------+--------+-----+
| |Win size(MSS)| 1 | Mult. | Mult. | 1 | 1 | Mult.| Mult. |Mult.| | |Win size(MSS)| 1 | Mult. | Mult. | 1 | 1 | Mult.| Mult. |Mult.|
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+-------+------+--------+-----+
| | Slow start | No| Yes | Yes | No | No | Yes | * | Yes | | | Slow start | No| Yes | Yes | No | No | Yes | No | Yes |
| T +-------------+---+---------+--------+----+-------+------+--------+-----+ | T +-------------+---+---------+--------+----+-------+------+--------+-----+
| C |Fast rec/retx| No| Yes | Yes | No | No | Yes | * | Yes | | C |Fast rec/retx| No| Yes | Yes | No | No | Yes | No | Yes |
| P +-------------+---+---------+--------+----+-------+------+--------+-----+ | P +-------------+---+---------+--------+----+-------+------+--------+-----+
| | Keep-alive | No| No | Yes | No | No | No | Yes | Yes | | | Keep-alive | No| No | Yes | No | No | No | Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+-------+------+--------+-----+
| f | Win. Scale | No| No | Yes | No | No | No | Yes | No | | f | Win. Scale | No| No | Yes | No | No | No | Yes | No |
| e +-------------+---+---------+--------+----+-------+------+--------+-----+ | e +-------------+---+---------+--------+----+-------+------+--------+-----+
| a | TCP timest. | No| No | Yes | No | No | No | Yes | No | | a | TCP timest. | No| No | Yes | No | No | No | Yes | No |
| t +-------------+---+---------+--------+----+-------+------+--------+-----+ | t +-------------+---+---------+--------+----+-------+------+--------+-----+
| u | SACK | No| No | Yes | No | No | No | Yes | No | | u | SACK | No| No | Yes | No | No | No | Yes | No |
| r +-------------+---+---------+--------+----+-------+------+--------+-----+ | r +-------------+---+---------+--------+----+-------+------+--------+-----+
| e | Del. ACKs | No| Yes | Yes | No | No | No | Yes | Yes | | e | Del. ACKs | No| Yes | Yes | No | No | No | Yes | Yes |
| s +-------------+---+---------+--------+----+-------+------+--------+-----+ | s +-------------+---+---------+--------+----+-------+------+--------+-----+
| | Socket | No| No |Optional|(I) | * |Subset| Yes | Yes | | | Socket | No| No |Optional|(I) | Yes |Subset| Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+-------+------+--------+-----+
| |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | * | * | | |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes | Yes |
+------+-------------+---+---------+--------+----+-------+------+--------+-----+ +------+-------------+---+---------+--------+----+-------+------+--------+-----+
(T1) = TCP-only, on x86 and AVR platforms (T1) = TCP-only, on x86 and AVR platforms
(T2) = TCP-only, on ARM Cortex-M platform (T2) = TCP-only, on ARM Cortex-M platform
(T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same platform
is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional connection)
(a) = includes IP, ICMP and TCP on x86 and AVR platforms (a) = includes IP, ICMP and TCP on x86 and AVR platforms
(b) = the whole protocol stack on mbed (b) = the whole protocol stack on mbed
(I) = interface inspired by POSIX (I) = interface inspired by POSIX
Mult. = Multiple Mult. = Multiple
N/A = Not Available
Figure 2: Summary of TCP features for differrent lightweight TCP Figure 2: Summary of TCP features for differrent lightweight TCP
implementations. None of the implementations considered in this implementations. None of the implementations considered in this
Annex support ECN or TFO. Annex support ECN or TFO.
TODO: Add information about RAM requirements (in addition to
codesize)
9. Annex. Changes compared to previous versions 9. Annex. Changes compared to previous versions
RFC Editor: To be removed prior to publication RFC Editor: To be removed prior to publication
9.1. Changes between -00 and -01 9.1. Changes between -00 and -01
o Changed title and abstract o Changed title and abstract
o Clarification that communcation with standard-compliant TCP o Clarification that communcation with standard-compliant TCP
endpoints is required, based on feedback from Joe Touch endpoints is required, based on feedback from Joe Touch
skipping to change at page 18, line 45 skipping to change at page 18, line 41
o Added sections on FreeRTOS and uC/OS o Added sections on FreeRTOS and uC/OS
o Updated TinyOS section o Updated TinyOS section
o Updated summary table o Updated summary table
o Reorganized Section 4 (single-MSS vs multiple-MSS window size), o Reorganized Section 4 (single-MSS vs multiple-MSS window size),
some content now also in new Section 5 some content now also in new Section 5
9.3. Changes between -02 and -03
o Rewording to better explain the benefit of ECN
o Additional context information on the surveyed implementations
o Added details, but removed "Data size" raw, in the summary table
o Added discussion on shrew attacks
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
skipping to change at page 21, line 13 skipping to change at page 21, line 22
overview-10 (work in progress), February 2018. overview-10 (work in progress), February 2018.
[I-D.ietf-lwig-energy-efficient] [I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols", Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-08 (work in progress), draft-ietf-lwig-energy-efficient-08 (work in progress),
October 2017. October 2017.
[IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the [IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the
Internet of Things: from ostracism to prominence", IEEE Internet of Things: from ostracism to prominence", IEEE
Communications Magazine, January-February 2018. Internet Computing, January-February 2018.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <https://www.rfc-editor.org/info/rfc1981>. 1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 22, line 47 skipping to change at page 23, line 5
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<https://www.rfc-editor.org/info/rfc7428>. <https://www.rfc-editor.org/info/rfc7428>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <https://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[shrew] A. Kuzmanovic, E. Knightly, "Low-Rate TCP-Targeted Denial
of Service Attacks", SIGCOMM'03 2003.
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
UPC/i2CAT UPC
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Jon Crowcroft Jon Crowcroft
University of Cambridge University of Cambridge
JJ Thomson Avenue JJ Thomson Avenue
Cambridge, CB3 0FD Cambridge, CB3 0FD
United Kingdom United Kingdom
Email: jon.crowcroft@cl.cam.ac.uk Email: jon.crowcroft@cl.cam.ac.uk
Michael Scharf Michael Scharf
Nokia Nokia
 End of changes. 36 change blocks. 
64 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/