draft-ietf-lwig-tcp-constrained-node-networks-05.txt   draft-ietf-lwig-tcp-constrained-node-networks-06.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: September 10, 2019 University of Cambridge Expires: September 28, 2019 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
March 9, 2019 March 27, 2019
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-05 draft-ietf-lwig-tcp-constrained-node-networks-06
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 September 10, 2019. This Internet-Draft will expire on September 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . 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) . . . . . . . 8
4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9
4.2. TCP guidance for single-MSS windows and buffers . . . . . 9 4.2. TCP guidance for single-MSS windows and buffers . . . . . 9
4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 9 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 9
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 . . . . 10 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 10
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 . . . . . . . . . 11 4.3. General recommendations for TCP in CNNs . . . . . . . . . 11
4.3.1. Loss recovery and congestion/flow control . . . . . . 11 4.3.1. Loss recovery and congestion/flow control . . . . . . 11
4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 11 4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 11
4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12 4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 12 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 12
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 13
5.2. Number of concurrent connections . . . . . . . . . . . . 12 5.2. Number of concurrent connections . . . . . . . . . . . . 13
5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Annex. TCP implementations for constrained devices . . . . . 16 8. Annex. TCP implementations for constrained devices . . . . . 16
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Annex. Changes compared to previous versions . . . . . . . . 20 9. Annex. Changes compared to previous versions . . . . . . . . 20
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20
9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20
9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21
9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21 9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21
9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
4.1.1. Maximum Segment Size (MSS) 4.1.1. Maximum Segment Size (MSS)
For the sake of lightweight implementation and operation, unless For the sake of lightweight implementation and operation, unless
applications require handling large data units (i.e. leading to an applications require handling large data units (i.e. leading to an
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 [RFC8201]. Path MTU Discovery [RFC8201].
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.) This assumes that the remote sender will use no TCP
options, aside from possibly the MSS option, which is only used in
the initial TCP SYN packet. In order to accommodate unrequested TCP
options that may be used by some TCP implementations, a constrained
device may advertise an MSS not larger than 1200 bytes.
Note that setting the MTU to 1280 bytes is possible for link layer Note that setting the MTU to 1280 bytes is possible for link layer
technologies in the CNN space, even if some of them are characterized technologies in the CNN space, even if some of them are characterized
by a short data unit payload size, e.g. up to a few tens or hundreds by a short data unit payload size, e.g. up to a few tens or hundreds
of bytes. For example, the maximum frame size in IEEE 802.15.4 is of bytes. For example, the maximum frame size in IEEE 802.15.4 is
127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over 127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over
IEEE 802.15.4 networks. The adaptation layer includes a IEEE 802.15.4 networks. The adaptation layer includes a
fragmentation mechanism, since IPv6 requires the layer below to fragmentation mechanism, since IPv6 requires the layer below to
support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked
fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU
skipping to change at page 9, line 31 skipping to change at page 9, line 41
If CoAP is used over TCP with the default setting for NSTART in If CoAP is used over TCP with the default setting for NSTART in
[RFC7252], a CoAP endpoint is not allowed to send a new message to a [RFC7252], a CoAP endpoint is not allowed to send a new message to a
destination until a response for the previous message sent to that destination until a response for the previous message sent to that
destination has been received. This is equivalent to an application- destination has been received. This is equivalent to an application-
layer window size of 1. For this use of CoAP, a maximum TCP window layer window size of 1. For this use of CoAP, a maximum TCP window
of one MSS will be sufficient. of one MSS will be sufficient.
4.2.2. TCP options for single-MSS stacks 4.2.2. TCP options for single-MSS stacks
A TCP implementation needs to support options 0, 1 and 2 [RFC0793]. A TCP implementation needs to support, at a minimum, TCP options 2, 1
These options are sufficient for interoperability with a standard- and 0. These are, respectively, the Maximum Segment Size (MSS)
compliant TCP endpoint, albeit many TCP stacks support additional option, the No-Operation option, and the End Of Option List marker
options and can negotiate their use. [RFC0793]. None of these are a substantial burden to support. These
options are sufficient for interoperability with a standard-compliant
TCP endpoint, albeit many TCP stacks support additional options and
can negotiate their use. A TCP implementation is permitted to
silently ignore all other TCP options.
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 [RFC7323], TCP Timestamps the following TCP options: Window scale [RFC7323], TCP Timestamps
[RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted [RFC7323], 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. With constrained device with a very lightweight implementation. With
regard to the Window scale option, note that it is only useful if a regard to the Window scale option, note that it is only useful if a
window size greater than 64 kB is needed. window size greater than 64 kB is needed.
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.3, 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.
skipping to change at page 12, line 12 skipping to change at page 12, line 18
segments, the header overhead penalty of SACK is compensated by segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions. avoiding unnecessary retransmissions.
4.3.2. Delayed Acknowledgments 4.3.2. Delayed Acknowledgments
For certain traffic patterns, Delayed ACKs may have a detrimental For certain traffic patterns, Delayed ACKs may have a detrimental
effect, as already noted in Section 4.2.3. Advanced TCP stacks may effect, as already noted in Section 4.2.3. Advanced TCP stacks may
use heuristics to determine the maximum delay for an ACK. For CNNs, use heuristics to determine the maximum delay for an ACK. For CNNs,
the recommendation depends on the expected communication patterns. the recommendation depends on the expected communication patterns.
If a stack is able to deal with more than one MSS of data, it may When traffic over a CNN is expected to mostly be unidirectional
make sense to use a small timeout or disable delayed ACKs when messages with a size typically up to one MSS, and the time between
traffic over a CNN is expected to mostly be small messages with a two consecutive message transmissions is greater than the delayed ACK
size typically below one MSS. For request-response traffic between a timeout, it may make sense to use a small timeout or disable delayed
constrained device and a peer (e.g. backend infrastructure) that uses ACKs at the receiver. This avoids incurring additional delay, as
delayed ACKs, the maximum ACK rate of the peer will be typically of well as the energy consumption of the sender (which might e.g. keep
one ACK every 200 ms (or even lower). If in such conditions the peer its radio interface in receive mode) during that time. Note that
device is administered by the same entity managing the constrained disabling delayed ACKs may only be possible if the peer device is
device, it is recommended to disable delayed ACKs at the peer side. administered by the same entity managing the constrained device. For
request-response traffic, enabling delayed ACKs is recommended, in
order to allow combining a response with the ACK into a single
segment, thus increasing efficiency.
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 Note that, in many scenarios, the peer that a constrained device
communicates with will be a general purpose system that communicates communicates with will be a general purpose system that communicates
with both constrained and unconstrained devices. Since delayed ACKs with both constrained and unconstrained devices. Since delayed ACKs
are often configured through system-wide parameters, 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 behavior at the peer will be the same regardless of the nature of the
skipping to change at page 15, line 51 skipping to change at page 16, line 10
Regional Development Fund (ERDF) and the Spanish Government through Regional Development Fund (ERDF) and the Spanish Government through
project TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to project TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to
this work has been carried out during his stays as a visiting scholar this work has been carried out during his stays as a visiting scholar
at the Computer Laboratory of the University of Cambridge. at 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, Hannes Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes
Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen and Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen, Emmanuel
Emmanuel Baccelli. Simon Brummer provided details, and kindly Baccelli, and Stuart Cheshire. Simon Brummer provided details, and
performed RAM and ROM usage measurements, on the RIOT TCP 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 kindly performed code size measurements implementation. Rahul Jadhav kindly performed code size measurements
on the Contiki-NG and lwIP 2.1.2 TCP implementations. He also on the Contiki-NG and lwIP 2.1.2 TCP implementations. He also
provided details on the uIP TCP implementation. provided details on the uIP TCP 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. The survey is limited to open source stacks constrained devices. The survey is limited to open source stacks
with small footprint. It is not meant to be all-encompassing. For with small footprint. It is not meant to be all-encompassing. For
skipping to change at page 21, line 31 skipping to change at page 21, line 31
o Removed mentioning MD5 as an example (comment by David Black) o Removed mentioning MD5 as an example (comment by David Black)
o Added memory footprint details of TCP implementations (Contiki-NG o Added memory footprint details of TCP implementations (Contiki-NG
and lwIP 2.1.2) provided by Rahul Jadhav in the Annex and lwIP 2.1.2) provided by Rahul Jadhav in the Annex
o Addressed comments by Ilpo Jarvinen throughout the whole document o Addressed comments by Ilpo Jarvinen throughout the whole document
o Improved the RIOT section in the Annex, based on feedback from o Improved the RIOT section in the Annex, based on feedback from
Emmanuel Baccelli Emmanuel Baccelli
9.6. Changes between -05 and -06
o Incorporated suggestions by Stuart Cheshire
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,
 End of changes. 14 change blocks. 
26 lines changed or deleted 43 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/