draft-ietf-lwig-tcp-constrained-node-networks-12.txt   draft-ietf-lwig-tcp-constrained-node-networks-13.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: May 3, 2021 University of Cambridge Expires: May 3, 2021 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
October 30, 2020 October 30, 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-12 draft-ietf-lwig-tcp-constrained-node-networks-13
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 characteristic 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
developers with decisions on which TCP features to use. developers with decisions on which TCP features to use.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 3, line 12 skipping to change at page 3, line 12
8.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 22 8.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 22
8.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 23 8.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 23
8.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 23 8.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 23
8.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 23 8.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 23
8.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 23 8.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 23
8.8. Changes between -07 and -08 . . . . . . . . . . . . . . . 23 8.8. Changes between -07 and -08 . . . . . . . . . . . . . . . 23
8.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 23 8.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 23
8.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 24 8.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 24
8.11. Changes between -10 and -11 . . . . . . . . . . . . . . . 24 8.11. Changes between -10 and -11 . . . . . . . . . . . . . . . 24
8.12. Changes between -11 and -12 . . . . . . . . . . . . . . . 24 8.12. Changes between -11 and -12 . . . . . . . . . . . . . . . 24
8.13. Changes between -12 and -13 . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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. [RFC8352]). specifically designed for such environments (see e.g. [RFC8352]).
New IETF protocol stack components include the IPv6 over Low-power New IETF protocol stack components include the IPv6 over Low-power
Wireless Personal Area Networks (6LoWPAN) adaptation layer Wireless Personal Area Networks (6LoWPAN) adaptation layer
[RFC4944][RFC6282][RFC6775], the IPv6 Routing Protocol for Low-power [RFC4944][RFC6282][RFC6775], the IPv6 Routing Protocol for Low-power
and lossy networks (RPL) routing protocol [RFC6550], and the and lossy networks (RPL) routing protocol [RFC6550], and the
Constrained Application Protocol (CoAP) [RFC7252]. Constrained Application Protocol (CoAP) [RFC7252].
As of the writing, the main current transport layer protocols in IP- As of the writing, the main current transport layer protocols in IP-
based IoT scenarios are UDP and TCP. TCP has been criticized (often, based IoT scenarios are UDP and TCP. TCP has been criticized, often
unfairly) as a protocol for the IoT. It is true that some TCP unfairly, as a protocol that is unsuitable for the IoT. It is true
features, such as relatively long header size, unsuitability for that some TCP features, such as relatively long header size,
multicast, and always-confirmed data delivery, are not optimal for unsuitability for multicast, and always-confirmed data delivery, are
IoT scenarios. However, many typical claims on TCP unsuitability for not optimal for IoT scenarios. However, many typical claims on TCP
IoT (e.g. a high complexity, connection-oriented approach unsuitability for IoT (e.g. a high complexity, connection-oriented
incompatibility with radio duty-cycling, and spurious congestion approach incompatibility with radio duty-cycling, and spurious
control activation in wireless links) are not valid, can be solved, congestion control activation in wireless links) are not valid, can
or are also found in well accepted IoT end-to-end reliability be solved, or are also found in well accepted IoT end-to-end
mechanisms (see [IntComp] for a detailed analysis). reliability mechanisms (see [IntComp] for a detailed analysis).
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 is the which may limit and even block UDP-based communications. This is 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
skipping to change at page 4, line 4 skipping to change at page 4, line 5
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 is the which may limit and even block UDP-based communications. This is 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
[RFC7230] [RFC7540], 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 Queuing layer protocols in the IoT space such as the Message Queuing
Telemetry Transport (MQTT) [MQTT] and its lightweight variants. Telemetry Transport (MQTT) [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 code size and the
memory requirements. Many TCP extensions are not required for memory requirements. Many TCP extensions are not required for
interoperability with other standard-compliant TCP endpoints. Given interoperability with other standard-compliant TCP endpoints. Given
the limited resources on constrained devices, careful selection of the limited resources on constrained devices, careful selection of
optional TCP features can make an implementation more lightweight. optional TCP features can make an implementation more lightweight.
This document provides guidance on how to implement and configure This document provides guidance on how to implement and configure
TCP, as well as on how TCP is advisable to be used by applications, TCP, as well as on how TCP is advisable to be used by applications,
in CNNs. The overarching goal is to offer simple measures to allow in CNNs. The overarching goal is to offer simple measures to allow
for lightweight TCP implementation and suitable operation in such for lightweight TCP implementation and suitable operation in such
environments. A TCP implementation following the guidance in this environments. A TCP implementation following the guidance in this
skipping to change at page 24, line 19 skipping to change at page 24, line 19
o Addressed a comment by Markku Kojo on advice given in RFC 6691. o Addressed a comment by Markku Kojo on advice given in RFC 6691.
8.11. Changes between -10 and -11 8.11. Changes between -10 and -11
o Addressed a comment by Ted Lemon on MSS advice. o Addressed a comment by Ted Lemon on MSS advice.
8.12. Changes between -11 and -12 8.12. Changes between -11 and -12
o Addressed comments from IESG and various directorates. o Addressed comments from IESG and various directorates.
8.13. Changes between -12 and -13
o Fixed two typos.
o Addressed a comment by Barry Leiba.
9. References 9. References
9.1. Normative References 9.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. 7 change blocks. 
14 lines changed or deleted 20 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/