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/