draft-ietf-lwig-tcp-constrained-node-networks-03.txt   draft-ietf-lwig-tcp-constrained-node-networks-04.txt 
LWIG Working Group C. Gomez LWIG Working Group C. Gomez
Internet-Draft UPC Internet-Draft UPC
Intended status: Informational J. Crowcroft Intended status: Informational J. Crowcroft
Expires: December 12, 2018 University of Cambridge Expires: April 11, 2019 University of Cambridge
M. Scharf M. Scharf
Nokia Hochschule Esslingen
June 10, 2018 October 8, 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-03 draft-ietf-lwig-tcp-constrained-node-networks-04
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 December 12, 2018. This Internet-Draft will expire on April 11, 2019.
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 . . . . . . . . . . . . . . . . . . . . . 7 4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . 12
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12
5.2. TCP connection lifetime . . . . . . . . . . . . . . . . . 12 5.2. Number of concurrent connections . . . . . . . . . . . . 12
5.2.1. Long TCP connection lifetime . . . . . . . . . . . . 12 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 12
5.2.2. Short TCP connection lifetime . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.3. Number of parallel connections . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Annex. TCP implementations for constrained devices . . . . . 14 8. Annex. TCP implementations for constrained devices . . . . . 15
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16
8.6. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.7. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . 19
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 18 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 19
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 18 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 19
9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 18 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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.
[I-D.ietf-lwig-energy-efficient]). New IETF protocol stack [I-D.ietf-lwig-energy-efficient]). New IETF protocol stack
components include the IPv6 over Low-power Wireless Personal Area components include the IPv6 over Low-power Wireless Personal Area
skipping to change at page 3, line 46 skipping to change at page 3, line 45
At the application layer, CoAP was developed over UDP [RFC7252]. At the application layer, CoAP was developed over UDP [RFC7252].
However, the integration of some CoAP deployments with existing However, the integration of some CoAP deployments with existing
infrastructure is being challenged by middleboxes such as firewalls, infrastructure is being challenged by middleboxes such as firewalls,
which may limit and even block UDP-based communications. This the which may limit and even block UDP-based communications. This the
main reason why a CoAP over TCP specification has been developed main reason why a CoAP over TCP specification has been developed
[RFC8323]. [RFC8323].
Other application layer protocols not specifically designed for CNNs Other application layer protocols not specifically designed for CNNs
are also being considered for the IoT space. Some examples include are also being considered for the IoT space. Some examples include
HTTP/2 and even HTTP/1.1, both of which run over TCP by default HTTP/2 and even HTTP/1.1, both of which run over TCP by default
[RFC7540] [RFC2616], and the Extensible Messaging and Presence [RFC7230] [RFC7540], and the Extensible Messaging and Presence
Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application- Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application-
layer protocols in the IoT space such as the Message Queue Telemetry layer protocols in the IoT space such as the Message Queue Telemetry
Transport (MQTT) and its lightweight variants. Transport (MQTT) and its lightweight variants.
TCP is a sophisticated transport protocol that includes optional TCP is a sophisticated transport protocol that includes optional
functionality (e.g. TCP options) that may improve performance in functionality (e.g. TCP options) that may improve performance in
some environments. However, many optional TCP extensions require some environments. However, many optional TCP extensions require
complex logic inside the TCP stack and increase the codesize and the complex logic inside the TCP stack and increase the codesize and the
RAM requirements. Many TCP extensions are not required for RAM requirements. Many TCP extensions are not required for
interoperability with other standard-compliant TCP endpoints. Given interoperability with other standard-compliant TCP endpoints. Given
skipping to change at page 9, line 33 skipping to change at page 9, line 32
options and can negotiate their use. options and can negotiate their use.
A TCP implementation for a constrained device that uses a single-MSS A TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size may not benefit from supporting TCP receive or transmit window size may not benefit from supporting
the following TCP options: Window scale [RFC1323], TCP Timestamps the following TCP options: Window scale [RFC1323], TCP Timestamps
[RFC1323], Selective Acknowledgments (SACK) and SACK-Permitted [RFC1323], Selective Acknowledgments (SACK) and SACK-Permitted
[RFC2018]. Also other TCP options may not be required on a [RFC2018]. Also other TCP options may not be required on a
constrained device with a very lightweight implementation. constrained device with a very lightweight implementation.
One potentially relevant TCP option in the context of CNNs is TCP One potentially relevant TCP option in the context of CNNs is TCP
Fast Open (TFO) [RFC7413]. As described in Section 5.2.2, TFO can be Fast Open (TFO) [RFC7413]. As described in Section 5.3, TFO can be
used to address the problem of traversing middleboxes that perform used to address the problem of traversing middleboxes that perform
early filter state record deletion. early filter state record deletion.
4.2.3. Delayed Acknowledgments for single-MSS stacks 4.2.3. Delayed Acknowledgments for single-MSS stacks
TCP Delayed Acknowledgments are meant to reduce the number of TCP Delayed Acknowledgments are meant to reduce the number of
transferred bytes within a TCP connection, but they may increase the transferred bytes within a TCP connection, but they may increase the
time until a sender may receive an ACK. There can be interactions time until a sender may receive an ACK. There can be interactions
with stacks that use very small windows. with stacks that use very small windows.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
constrained device and a peer (e.g. backend infrastructure) that uses constrained device and a peer (e.g. backend infrastructure) that uses
delayed ACKs, the maximum ACK rate of the peer will be typically of delayed ACKs, the maximum ACK rate of the peer will be typically of
one ACK every 200 ms (or even lower). If in such conditions the peer one ACK every 200 ms (or even lower). If in such conditions the peer
device is administered by the same entity managing the constrained device is administered by the same entity managing the constrained
device, it is recommended to disable delayed ACKs at the peer side. device, it is recommended to disable delayed ACKs at the peer side.
In contrast, delayed ACKs allow to reduce the number of ACKs in bulk In contrast, delayed ACKs allow to reduce the number of ACKs in bulk
transfer type of traffic, e.g. for firmware/software updates or for transfer type of traffic, e.g. for firmware/software updates or for
transferring larger data units containing a batch of sensor readings. transferring larger data units containing a batch of sensor readings.
Note that, in many scenarios, the peer that a constrained device
communicates with will be a general purpose system that communicates
with both constrained and unconstrained devices. Since delayed ACKs
are often configured through system-wide parameters, delayed ACKs
behavior at the peer will be the same regardless of the nature of the
endpoints it talks to. Such a peer will typically have delayed ACKs
enabled.
5. TCP usage recommendations in CNNs 5. TCP usage recommendations in CNNs
This section discusses how a TCP stack can be used by applications This section discusses how a TCP stack can be used by applications
that are developed for CNN scenarios. These remarks are by and large that are developed for CNN scenarios. These remarks are by and large
independent of how TCP is exactly implemented. independent of how TCP is exactly implemented.
5.1. TCP connection initiation 5.1. TCP connection initiation
In the constrained device to unconstrained device scenario In the constrained device to unconstrained device scenario
illustrated above, a TCP connection is typically initiated by the illustrated above, a TCP connection is typically initiated by the
constrained device, in order for this device to support possible constrained device, in order for this device to support possible
sleep periods to save energy. sleep periods to save energy.
5.2. TCP connection lifetime 5.2. Number of concurrent connections
[[TODO: This section may need rewording in the next revision.]]
5.2.1. Long TCP connection lifetime TCP endpoints with a small amount of RAM may only support a small
number of connections. Each TCP connection requires storing a number
of variables in the Transmission Control Block (TCB). Depending on
the internal TCP implementation, each connection may result in
further overhead, and they may compete for scarce resources.
In CNNs, in order to minimize message overhead, a TCP connection A careful application design may try to keep the number of concurrent
should be kept open as long as the two TCP endpoints have more data connections as small as possible. A client can for instance limit
to exchange or it is envisaged that further segment exchanges will the number of simultaneous open connections that it maintains to a
take place within an interval of two hours since the last segment has given server. Multiple connections could for instance be used to
been sent. A greater interval may be used in scenarios where avoid the "head-of-line blocking" problem in an application transfer.
applications exchange data infrequently. However, in addition to comsuming resources, using multiple
connections can also cause undesirable side effects in congested
networks. As example, the HTTP/1.1 specification encourages clients
to be conservative when opening multiple connections [RFC7230].
TCP keep-alive messages [RFC1122] may be supported by a server, to Being conservative when opening multiple TCP connections is of
check whether a TCP connection is active, in order to release state particular importance in Constrained-Node Networks.
of inactive connections. This may be useful for servers running on
memory-constrained devices.
Since the keep-alive timer may not be set to a value lower than two 5.3. TCP connection lifetime
hours [RFC1122], TCP keep-alive messages are not useful to guarantee
that filter state records in middleboxes such as firewalls will not
be deleted after an inactivity interval typically in the order of a
few minutes [RFC6092]. In scenarios where such middleboxes are
present, alternative measures to avoid early deletion of filter state
records (which might lead to frequent establishment of new TCP
connections between the two involved endpoints) include increasing
the initial value for the filter state inactivity timers (if
possible), and using application layer heartbeat messages.
5.2.2. Short TCP connection lifetime In order to minimize message overhead, it makes sense to keep a TCP
connection open as long as the two TCP endpoints have more data to
send. If applications exchange data rather infrequently, i.e., if
TCP connections would stay idle for a long time, the idle time can
result in problems. For instance, certain middleboxes such as
firewalls or NAT devices are known to delete state records after an
inactivity interval typically in the order of a few minutes
[RFC6092]. The timeout duration used by a middlebox implementation
may not be known to the TCP endpoints.
A different approach to addressing the problem of traversing In CCNs, such middleboxes may e.g. be present at the boundary between
middleboxes that perform early filter state record deletion relies on the CCN and other networks. If the middlebox can be optimized for
using TFO [RFC7413]. In this case, instead of trying to maintain a CCN use cases, it makes sense to increase the initial value for
TCP connection for long time, possibly short-lived connections can be filter state inactivity timers to avoid problems with idle
opened between two endpoints while incurring low overhead. In fact, connections. Apart from that, this problem can be dealt with by
TFO allows data to be carried in SYN (and SYN-ACK) packets, and to be different connection handling strategies, each having pros and cons.
consumed immediately by the receceiving endpoint, thus reducing
overhead compared with the traditional three-way handshake required
to establish a TCP connection.
For security reasons, TFO requires the TCP endpoint that will open One approach for infrequent data transfer is to use short-lived TCP
the TCP connection (which in CNNs will typically be the constrained connections. Instead of trying to maintain a TCP connection for long
device) to request a cookie from the other endpoint. The cookie, time, possibly short-lived connections can be opened between two
with a size of 4 or 16 bytes, is then included in SYN packets of endpoints, which are closed if no more data needs to be exchanged.
subsequent connections. The cookie needs to be refreshed (and For use cases that can cope with the additional messages and the
obtained by the client) after a certain amount of time. latency resulting from starting new connections, it is recommended to
Nevertheless, TFO is more efficient than frequently opening new TCP use a sequence of short-lived connections, instead of maintaining a
connections (by using the traditional three-way handshake) for single long-lived connection.
transmitting new data, as long as the cookie update rate is well
below the data new connection rate.
5.3. Number of parallel connections This overhead could be reduced by TCP Fast Open (TFO) [RFC7413],
which is an experimental TCP extension. TFO allows data to be
carried in SYN (and SYN-ACK) segments, and to be consumed immediately
by the receceiving endpoint. This reduces the overhead compared to
the traditional three-way handshake to establish a TCP connection.
For security reasons, the connection initiator has to request a TFO
cookie from the other endpoint. The cookie, with a size of 4 or 16
bytes, is then included in SYN packets of subsequent connections.
The cookie needs to be refreshed (and obtained by the client) after a
certain amount of time. Nevertheless, TFO is more efficient than
frequently opening new TCP connections with the traditional three-way
handshake, as long as the cookie can be reused in subsequent
connections.
[[TODO: This has been added in -02 but needs further alignment]] Another approach is to use long-lived TCP connections with
application-layer heartbeat messages. Various application protocols
support such heartbeat messages. Periodic heartbeats requires
transmission of packets, but they also allow aliveness checks at
application level. In addition, they can prevent early filter state
record deletion in middleboxes. In general, it makes sense realize
aliveness checks at the highest protocol layer possible that is
meaningful to the application, in order to maximize the depth of the
aliveness check.
TCP endpoints with a small amount of RAM may only support a small A TCP implementation may also be able to send "keep-alive" segments
number of connections. Each connection may result in overhead, and to test a TCP connection. According to [RFC1122], "keep-alives" are
depending on the internal TCP implementation, they may compete for an optional TCP mechanism that is turned off by default, i.e., an
scarce resources. A careful application design may try to keep the application must explicitly enable it for a TCP connection. The
number of parallel connections as small as possible. interval between "keep-alive" messages must be configurable and it
must default to no less than two hours. With this large timeout, TCP
keep-alive messages are not very useful to avoid deletion of filter
state records in middleboxes such as firewalls.
6. Security Considerations 6. Security Considerations
Best current practise for securing TCP and TCP-based communication Best current practise for securing TCP and TCP-based communication
also applies to CNN. As example, use of Transport Layer Security also applies to CNN. As example, use of Transport Layer Security
(TLS) is strongly recommended if it is applicable. (TLS) is strongly recommended if it is applicable.
There are also TCP options which can improve TCP security. Examples There are also TCP options which can improve TCP security. Examples
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
skipping to change at page 16, line 9 skipping to change at page 16, line 32
during connection lifetime. GNRC TCP allows multiple connections in during connection lifetime. GNRC TCP allows multiple connections in
parallel, but each TCB must be allocated somewhere in the system. By parallel, but each TCB must be allocated somewhere in the system. By
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. TinyOS
The TCP implementation in OpenWSN has similar functionality like the
uIP TCP implementation. OpenWSN TCP implementation only supports the
minimum state machine functionality required. For example, it does
not perform retransmissions. There has not been much recent activity
to overcome these limitations.
8.5. TinyOS
TinyOS was important as platform for early constrained devices. 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. Recently missing segments. Multiple TCP connections are possible. Recently
there has been little further work on the stack. there has been little further work on the stack.
8.6. FreeRTOS 8.5. 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'.
8.7. uC/OS 8.6. uC/OS
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.7. Summary
+---+---------+--------+----+-------+------+--------+-----+ +---+---------+--------+----+------+--------+-----+
|uIP|lwIP orig|lwIP 2.0|RIOT|OpenWSN|TinyOS|FreeRTOS|uC/OS| |uIP|lwIP orig|lwIP 2.0|RIOT|TinyOS|FreeRTOS|uC/OS|
+------+-------------+---+---------+--------+----+-------+------+--------+-----+ +------+-------------+---+---------+--------+----+------+--------+-----+
|Memory|Code size(kB)| <5|~9 to ~14| ~40 | <7 | N/A | N/A | <9.2 | N/A | |Memory|Code size(kB)| <5|~9 to ~14| ~40 | <7 | N/A | <9.2 | N/A |
| | |(a)| (T1) | (b) |(T3)| | | (T2) | | | | |(a)| (T1) | (b) |(T3)| | (T2) | |
+------+-------------+---+---------+--------+----+-------+------+--------+-----+ +------+-------------+---+---------+--------+----+------+--------+-----+
| |Win size(MSS)| 1 | Mult. | Mult. | 1 | 1 | Mult.| Mult. |Mult.| | |Win size(MSS)| 1 | Mult. | Mult. | 1 | Mult.| Mult. |Mult.|
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| | Slow start | No| Yes | Yes | No | No | Yes | No | Yes | | | Slow start | No| Yes | Yes | No | Yes | No | Yes |
| T +-------------+---+---------+--------+----+-------+------+--------+-----+ | T +-------------+---+---------+--------+----+------+--------+-----+
| C |Fast rec/retx| No| Yes | Yes | No | No | Yes | No | Yes | | C |Fast rec/retx| No| Yes | Yes | No | Yes | No | Yes |
| P +-------------+---+---------+--------+----+-------+------+--------+-----+ | P +-------------+---+---------+--------+----+------+--------+-----+
| | Keep-alive | No| No | Yes | No | No | No | Yes | Yes | | | Keep-alive | No| No | Yes | No | No | Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| f | Win. Scale | No| No | Yes | No | No | No | Yes | No | | f | Win. Scale | No| No | Yes | 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 | Yes | No |
| t +-------------+---+---------+--------+----+-------+------+--------+-----+ | t +-------------+---+---------+--------+----+------+--------+-----+
| u | SACK | No| No | Yes | No | No | No | Yes | No | | u | SACK | No| No | Yes | 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 | Yes | Yes |
| s +-------------+---+---------+--------+----+-------+------+--------+-----+ | s +-------------+---+---------+--------+----+------+--------+-----+
| | Socket | No| No |Optional|(I) | Yes |Subset| Yes | Yes | | | Socket | No| No |Optional|(I) |Subset| Yes | Yes |
| +-------------+---+---------+--------+----+-------+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes | Yes | | |Concur. Conn.|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 (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) 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 N/A = Not Available
skipping to change at page 19, line 5 skipping to change at page 20, line 5
9.3. Changes between -02 and -03 9.3. Changes between -02 and -03
o Rewording to better explain the benefit of ECN o Rewording to better explain the benefit of ECN
o Additional context information on the surveyed implementations o Additional context information on the surveyed implementations
o Added details, but removed "Data size" raw, in the summary table o Added details, but removed "Data size" raw, in the summary table
o Added discussion on shrew attacks o Added discussion on shrew attacks
9.4. Changes between -03 and -04
o Addressing the remaining TODOs
o Alignment of the wording on TCP "keep-alives" with related
discussions in the IETF transport area
o Added further discussion on delayed ACKs
o Removed OpenWSN subsection from the Annex
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 32 skipping to change at page 22, line 44
Internet Computing, 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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
Vaidya, "Long Thin Networks", RFC 2757, Vaidya, "Long Thin Networks", RFC 2757,
DOI 10.17487/RFC2757, January 2000, DOI 10.17487/RFC2757, January 2000,
<https://www.rfc-editor.org/info/rfc2757>. <https://www.rfc-editor.org/info/rfc2757>.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000, RFC 2884, DOI 10.17487/RFC2884, July 2000,
<https://www.rfc-editor.org/info/rfc2884>. <https://www.rfc-editor.org/info/rfc2884>.
skipping to change at page 22, line 31 skipping to change at page 23, line 37
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012, RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>. <https://www.rfc-editor.org/info/rfc6606>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/info/rfc7414>. <https://www.rfc-editor.org/info/rfc7414>.
skipping to change at page 24, line 4 skipping to change at page 25, line 14
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
UPC 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 Hochschule Esslingen
Lorenzstrasse 10 Flandernstr. 101
Stuttgart, 70435 Esslingen 73732
Germany Germany
Email: michael.scharf@nokia.com Email: michael.scharf@hs-esslingen.de
 End of changes. 34 change blocks. 
128 lines changed or deleted 159 lines changed or added

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