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/