draft-ietf-lwig-tcp-constrained-node-networks-10.txt   draft-ietf-lwig-tcp-constrained-node-networks-11.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: March 10, 2021 University of Cambridge Expires: April 11, 2021 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
September 6, 2020 October 8, 2020
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-10 draft-ietf-lwig-tcp-constrained-node-networks-11
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 March 10, 2021. This Internet-Draft will expire on April 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 27 skipping to change at page 2, line 27
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. Addressing path properties . . . . . . . . . . . . . . . 7 4.1. Addressing 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) . . . . . . . 8 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 8
4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9
4.2. TCP guidance for single-MSS stacks . . . . . . . . . . . 9 4.2. TCP guidance for single-MSS stacks . . . . . . . . . . . 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 . . . . . . . . . . 10 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 10
4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 10 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 11
4.2.4. RTO calculation for single-MSS stacks . . . . . . . . 11 4.2.4. RTO calculation for single-MSS stacks . . . . . . . . 11
4.3. General recommendations for TCP in CNNs . . . . . . . . . 12 4.3. General recommendations for TCP in CNNs . . . . . . . . . 12
4.3.1. Loss recovery and congestion/flow control . . . . . . 12 4.3.1. Loss recovery and congestion/flow control . . . . . . 12
4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 12 4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 13
4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 13 4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 13
4.3.3. Initial Window . . . . . . . . . . . . . . . . . . . 14 4.3.3. Initial Window . . . . . . . . . . . . . . . . . . . 14
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 14 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 14
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 14 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 14
5.2. Number of concurrent connections . . . . . . . . . . . . 14 5.2. Number of concurrent connections . . . . . . . . . . . . 15
5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 15 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. Annex. TCP implementations for constrained devices . . . . . 18 8. Annex. TCP implementations for constrained devices . . . . . 18
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 20
8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Annex. Changes compared to previous versions . . . . . . . . 22 9. Annex. Changes compared to previous versions . . . . . . . . 22
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 22 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 22
skipping to change at page 8, line 7 skipping to change at page 8, line 7
On the other hand, there exist technologies also used in the CNN On the other hand, there exist technologies also used in the CNN
space, such as Master Slave / Token Passing (TP) [RFC8163], space, such as Master Slave / Token Passing (TP) [RFC8163],
Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah
[I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of
frame size limitations as the technologies mentioned above. The MTU frame size limitations as the technologies mentioned above. The MTU
for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB-
IoT is 1600 bytes, and the maximum frame payload size for IEEE IoT is 1600 bytes, and the maximum frame payload size for IEEE
802.11ah is 7991 bytes. 802.11ah is 7991 bytes.
Note that using larger MSS (to a suitable extent) may be beneficial, Using larger MSS (to a suitable extent) may be beneficial in some
especially when transferring large payloads, as it reduces the number scenarios, especially when transferring large payloads, as it reduces
of packets (and packet headers) required for a given payload. the number of packets (and packet headers) required for a given
However, use of MTUs that exceed 1280 bytes (including the typical payload. However, the characteristics of the constrained network
1500-byte MTU for communication paths including broader Internet need to be considered. In particular, in a lossy network where
segments) may incur Path MTU Discovery overhead. unreliable fragment delivery is used, the amount of data that TCP
unnecessarily retransmits due to fragment loss increases (and
throughput decreases) quickly with the MSS. This happens because the
loss of a fragment leads to the loss of the whole fragmented packet
being transmitted. Unnecessary data retransmission is particularly
harmful in CNNs due to the resource constraints of such environments.
Note that, while the original 6LoWPAN fragmentation mechanism
[RFC4944] does not offer reliable fragment delivery, fragment
recovery functionality for 6LoWPAN or 6Lo environments is being
standardized as of the writing [I-D.ietf-6lo-fragment-recovery].
4.1.2. Explicit Congestion Notification (ECN) 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router
to signal in the IP header of a packet that congestion is arising, to signal in the IP header of a packet that congestion is arising,
for example when a queue size reaches a certain threshold. An ECN- for example when a queue size reaches a certain threshold. An ECN-
enabled TCP receiver will echo back the congestion signal to the TCP enabled TCP receiver will echo back the congestion signal to the TCP
sender by setting a flag in its next TCP ACK. The sender triggers sender by setting a flag in its next TCP ACK. The sender triggers
congestion control measures as if a packet loss had happened. congestion control measures as if a packet loss had happened.
skipping to change at page 11, line 50 skipping to change at page 12, line 10
needlessly delay data delivery. needlessly delay data delivery.
If a TCP sender uses a very small window size, and it cannot benefit If a TCP sender uses a very small window size, and it cannot benefit
from Fast Retransmit/Fast Recovery or SACK, the RTO algorithm has a from Fast Retransmit/Fast Recovery or SACK, the RTO algorithm has a
large impact on performance. In that case, RTO algorithm tuning may large impact on performance. In that case, RTO algorithm tuning may
be considered, although careful assessment of possible drawbacks is be considered, although careful assessment of possible drawbacks is
recommended [I-D.ietf-tcpm-rto-consider]. recommended [I-D.ietf-tcpm-rto-consider].
As an example, adaptive RTO algorithms defined for CoAP over UDP have As an example, adaptive RTO algorithms defined for CoAP over UDP have
been found to perform well in CNN scenarios [Commag] been found to perform well in CNN scenarios [Commag]
[I-D.jarvinen-core-fasor]. [I-D.ietf-core-fasor].
4.3. General recommendations for TCP in CNNs 4.3. General recommendations for TCP in CNNs
This section summarizes some widely used techniques to improve TCP, This section summarizes some widely used techniques to improve TCP,
with a focus on their use in CNNs. The TCP extensions discussed here with a focus on their use in CNNs. The TCP extensions discussed here
are useful in a wide range of network scenarios, including CNNs. are useful in a wide range of network scenarios, including CNNs.
This section is not comprehensive. A comprehensive survey of TCP This section is not comprehensive. A comprehensive survey of TCP
extensions is published in [RFC7414]. extensions is published in [RFC7414].
4.3.1. Loss recovery and congestion/flow control 4.3.1. Loss recovery and congestion/flow control
skipping to change at page 18, line 13 skipping to change at page 18, line 23
contribution to this work has been carried out during his stays as a contribution to this work has been carried out during his stays as a
visiting scholar at the Computer Laboratory of the University of visiting scholar at the Computer Laboratory of the University of
Cambridge. 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, Emmanuel Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen, Emmanuel
Baccelli, Stuart Cheshire, Gorry Fairhurst, and Ingemar Johansson. Baccelli, Stuart Cheshire, Gorry Fairhurst, Ingemar Johansson, and
Simon Brummer provided details, and kindly performed RAM and ROM Ted Lemon. Simon Brummer provided details, and kindly performed RAM
usage measurements, on the RIOT TCP implementation. Xavi Vilajosana and ROM usage measurements, on the RIOT TCP implementation. Xavi
provided details on the OpenWSN TCP implementation. Rahul Jadhav Vilajosana provided details on the OpenWSN TCP implementation. Rahul
kindly performed code size measurements on the Contiki-NG and lwIP Jadhav kindly performed code size measurements on the Contiki-NG and
2.1.2 TCP implementations. He also provided details on the uIP TCP lwIP 2.1.2 TCP implementations. He also provided details on the uIP
implementation. 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
more powerful embedded systems (e.g., with 32-bit processors), there more powerful embedded systems (e.g., with 32-bit processors), there
are further stacks that comprehensively implement TCP. On the other are further stacks that comprehensively implement TCP. On the other
hand, please be aware that this Annex is based on information hand, please be aware that this Annex is based on information
available as of the writing. available as of the writing.
skipping to change at page 26, line 20 skipping to change at page 26, line 20
Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An Experimental Study of Home Sarolahti, P., and M. Kojo, "An Experimental Study of Home
Gateway Characteristics", Proceedings of the 10th ACM Gateway Characteristics", Proceedings of the 10th ACM
SIGCOMM conference on Internet measurement 2010. SIGCOMM conference on Internet measurement 2010.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-tcpm-rto-consider] [I-D.ietf-6lo-fragment-recovery]
Allman, M., "Requirements for Time-Based Loss Detection", Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
draft-ietf-tcpm-rto-consider-17 (work in progress), July ietf-6lo-fragment-recovery-21 (work in progress), March
2020. 2020.
[I-D.jarvinen-core-fasor] [I-D.ietf-core-fasor]
Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast- Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast-
Slow Retransmission Timeout and Congestion Control Slow Retransmission Timeout and Congestion Control
Algorithm for CoAP", draft-jarvinen-core-fasor-02 (work in Algorithm for CoAP", draft-ietf-core-fasor-00 (work in
progress), July 2019. progress), March 2020.
[I-D.ietf-tcpm-rto-consider]
Allman, M., "Requirements for Time-Based Loss Detection",
draft-ietf-tcpm-rto-consider-17 (work in progress), July
2020.
[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
Internet Computing, January-February 2018. Internet Computing, January-February 2018.
[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>.
 End of changes. 14 change blocks. 
28 lines changed or deleted 42 lines changed or added

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