< draft-ietf-lwig-tcp-constrained-node-networks-00.txt		draft-ietf-lwig-tcp-constrained-node-networks-01.txt >
	LWIG Working Group C. Gomez		LWIG Working Group C. Gomez
	Internet-Draft UPC/i2CAT		Internet-Draft UPC/i2CAT
	Intended status: Informational J. Crowcroft		Intended status: Informational J. Crowcroft
	Expires: March 2, 2018 University of Cambridge		Expires: April 17, 2018 University of Cambridge
	M. Scharf		M. Scharf
	Nokia		Nokia
	August 29, 2017		October 14, 2017
	TCP over Constrained-Node Networks		TCP Usage Guidance in the Internet of Things (IoT)
	draft-ietf-lwig-tcp-constrained-node-networks-00		draft-ietf-lwig-tcp-constrained-node-networks-01
	Abstract		Abstract
	This document provides a profile for the Transmission Control		This document provides guidance on how to implement and use the
	Protocol (TCP) over Constrained-Node Networks (CNNs). The		Transmission Control Protocol (TCP) in Constrained-Node Networks
	overarching goal is to offer simple measures to allow for lightweight		(CNNs), which are a characterstic of the Internet of Things (IoT).
	TCP implementation and suitable operation in such environments.		Such environments require a lightweight TCP implementation and may
			not make use of optional functionality. This document explains a
			number of known and deployed techniques to simplify a TCP stack as
			well as corresponding tradeoffs. The objective is to help embedded
			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.
	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 http://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 2, 2018.		This Internet-Draft will expire on April 17, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 4
	2. Characteristics of CNNs relevant for TCP . . . . . . . . . . 3		3. Characteristics of CNNs relevant for TCP . . . . . . . . . . 4
	3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Network and link properties . . . . . . . . . . . . . . . 4
	4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 4
	4.1. TCP connection initiation . . . . . . . . . . . . . . . . 4		3.3. Communication and traffic patterns . . . . . . . . . . . 5
	4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 5		4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. TCP connection initiation . . . . . . . . . . . . . . . . 6
	4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 6		4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 6
	4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 7		4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 7
	4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 7		4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 8
	4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 7		4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 8
	4.6. Explicit congestion notification . . . . . . . . . . . . 8		4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 8
	4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 8		4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 9
	4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 9		4.6. Explicit congestion notification . . . . . . . . . . . . 9
	4.9. Explicit loss notifications . . . . . . . . . . . . . . . 10		4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 11
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		4.9. Explicit loss notifications . . . . . . . . . . . . . . . 11
	7. Annex. TCP implementations for constrained devices . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Annex. TCP implementations for constrained devices . . . . . 12
	7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.4. OpenWSN . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.5. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8. Annex. Changes compared to previous versions . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. Changes compared to -00 . . . . . . . . . . . . . . . . . 15
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
			9.1. Normative References . . . . . . . . . . . . . . . . . . 16
			9.2. Informative References . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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 protocols		stem from CNNs, the IETF has produced a suite of new protocols
	specifically designed for such environments		specifically designed for such environments (see e.g.
	[I-D.ietf-lwig-energy-efficient].		[I-D.ietf-lwig-energy-efficient]).
	At the application layer, the Constrained Application Protocol (CoAP)		At the application layer, the Constrained Application Protocol (CoAP)
	was developed over UDP [RFC7252]. However, the integration of some		was developed over UDP [RFC7252]. However, the integration of some
	CoAP deployments with existing infrastructure is being challenged by		CoAP deployments with existing infrastructure is being challenged by
	middleboxes such as firewalls, which may limit and even block UDP-		middleboxes such as firewalls, which may limit and even block UDP-
	based communications. This the main reason why a CoAP over TCP		based communications. This the main reason why a CoAP over TCP
	specification is being developed [I-D.tschofenig-core-coap-tcp-tls].		specification is being developed [I-D.ietf-core-coap-tcp-tls].
	On the other hand, other application layer protocols not specifically		Other application layer protocols not specifically designed for CNNs
	designed for CNNs are also being considered for the IoT space. Some		are also being considered for the IoT space. Some examples include
	examples include HTTP/2 and even HTTP/1.1, both of which run over TCP		HTTP/2 and even HTTP/1.1, both of which run over TCP by default
	by default [RFC7540][RFC2616], and the Extensible Messaging and		[RFC7540] [RFC2616], and the Extensible Messaging and Presence
	Presence Protocol (XMPP) [RFC 6120]. TCP is also used by non-IETF		Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application-
	application-layer protocols in the IoT space such as MQTT and its		layer protocols in the IoT space such as the Message Queue Telemetry
	lightweight variants [MQTTS].		Transport (MQTT) and its lightweight variants.
	This document provides a profile for TCP over CNNs. The overarching		TCP is a sophisticated transport protocol that includes many optional
	goal is to offer simple measures to allow for lightweight TCP		functionality and TCP options that improve performance. Many
	implementation and suitable operation in such environments.		optional TCP extensions require complex logic inside the TCP stack
			and increase the codesize and the RAM requirements. However, many
			TCP extensions are not required for interoperability with other
			standard-compliant TCP endpoints. Given the limited resources on
			constrained devices, careful "tuning" of the TCP implementation can
			make an implementation more lightweight.
	1.1. Conventions used in this document		This document provides guidance on how to implement and use TCP in
			CNNs. The overarching goal is to offer simple measures to allow for
			lightweight TCP implementation and suitable operation in such
			environments. A TCP implementation following the guidance in this
			document is intended to be compatible with a TCP endpoint that is
			compliant to the TCP standards, albeit possibly with a lower
			performance. This implies that such a TCP client would always be
			able to connect with a standard-compliant TCP server, and a
			corresponding TCP server would always be able to connect with a
			standard-compliant TCP client.
			This document assumes that the reader is familiar with TCP. A
			comprehensive survey of the TCP standards can be found in [RFC7414].
			Similar guidance regarding the use of TCP in special environments has
			been published before, e.g., for cellular wireless networks
			[RFC3481].
			2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]		document are to be interpreted as described in [RFC2119].
	2. Characteristics of CNNs relevant for TCP		3. Characteristics of CNNs relevant for TCP
			3.1. Network and link properties
	CNNs are defined in [RFC7228] as networks whose characteristics are		CNNs are defined in [RFC7228] as networks whose characteristics are
	influenced by being composed of a significant portion of constrained		influenced by being composed of a significant portion of constrained
	nodes. The latter are characterized by significant limitations on		nodes. The latter are characterized by significant limitations on
	processing, memory, and energy resources, among others [RFC7228].		processing, memory, and energy resources, among others [RFC7228].
	The first two dimensions pose constraints on the complexity and on		The first two dimensions pose constraints on the complexity and on
	the memory footprint of the protocols that constrained nodes can		the memory footprint of the protocols that constrained nodes can
	support. The latter requires techniques to save energy, such as		support. The latter requires techniques to save energy, such as
	radio duty-cycling in wireless devices		radio duty-cycling in wireless devices
	[I-D.ietf-lwig-energy-efficient], as well as minimization of the		[I-D.ietf-lwig-energy-efficient], as well as minimization of the
	number of messages transmitted/received (and their size).		number of messages transmitted/received (and their size).
	Constrained nodes often use physical/link layer technologies that		[RFC7228] lists typical network constraints in CNN, including low
	have been characterized as 'lossy'. Many such technologies are		achievable bitrate/throughput, high packet loss and high variability
	wireless, therefore exhibiting a relatively high bit error rate.		of packet loss, highly asymmetric link characteristics, severe
	However, some wired technologies used in the CNN space are also lossy		penalties for using larger packets, limits on reachability over time,
	(e.g. Power Line Communication). Transmission rates of CNN radio or		etc. CNN may use wireless or wired technologies (e.g., Power Line
	wired interfaces are typically low (e.g. below 1 Mbps).		Communication), and the transmission rates are typically low (e.g.
			below 1 Mbps).
	Some CNNs follow the star topology, whereby one or several hosts are		For use of TCP, one challenge is that not all technologies in CNN may
			be aligned with typical Internet subnetwork design principles
			[RFC3819]. For instance, constrained nodes often use physical/link
			layer technologies that have been characterized as 'lossy', i.e.,
			exhibit a relatively high bit error rate. Dealing with corruption
			loss is one of the open issues in the Internet [RFC6077].
			3.2. Usage scenarios
			There are different deployment and usage scenarios for CNNs. Some
			CNNs follow the star topology, whereby one or several hosts are
	linked to a central device that acts as a router connecting the CNN		linked to a central device that acts as a router connecting the CNN
	to the Internet. CNNs may also follow the multihop topology		to the Internet. CNNs may also follow the multihop topology
	[RFC6606].		[RFC6606]. One key use case for the use of TCP is a model where
			constrained devices connect to unconstrained servers in the Internet.
			But it is also possible that both TCP endpoints run on constrained
			devices.
	3. Scenario		In constrained environments, there can be different types of devices
			[RFC7228]. For example, there can be devices with single combined
			send/receive buffer, devices with a separate send and receive buffer,
			or devices with a pool of multiple send/receive buffers. In the
			latter case, it is possible that buffers also be shared for other
			protocols.
	The main scenario for use of TCP over CNNs comprises a constrained		When a CNN comprising one or more constrained devices and an
	device and an unconstrained device that communicate over the Internet		unconstrained device communicate over the Internet using TCP, the
	using TCP, possibly traversing a middlebox (e.g. a firewall, NAT,		communication possibly has to traverse a middlebox (e.g. a firewall,
	etc.). Figure 1 illustrates such scenario. Note that the scenario		NAT, etc.). Figure 1 illustrates such scenario. Note that the
	is asymmetric, as the unconstrained device will typically not suffer		scenario is asymmetric, as the unconstrained device will typically
	the severe constraints of the constrained device. The unconstrained		not suffer the severe constraints of the constrained device. The
	device is expected to be mains-powered, to have high amount of memory		unconstrained device is expected to be mains-powered, to have high
	and processing power, and to be connected to a resource-rich network.		amount of memory and processing power, and to be connected to a
			resource-rich network.
	Assuming that a majority of constrained devices will correspond to		Assuming that a majority of constrained devices will correspond to
	sensor nodes, the amount of data traffic sent by constrained devices		sensor nodes, the amount of data traffic sent by constrained devices
	(e.g. sensor node measurements) is expected to be higher than the		(e.g. sensor node measurements) is expected to be higher than the
	amount of data traffic in the opposite direction. Nevertheless,		amount of data traffic in the opposite direction. Nevertheless,
	constrained devices may receive requests (to which they may respond),		constrained devices may receive requests (to which they may respond),
	commands (for configuration purposes and for constrained devices		commands (for configuration purposes and for constrained devices
	including actuators) and relatively infrequent firmware/software		including actuators) and relatively infrequent firmware/software
	updates.		updates.
	+---------------+		+---------------+
	o o <--------- TCP communication ------> | |		o o <-------- TCP communication -----> | |
	o o | |		o o | |
	o o | Unconstrained |		o o | Unconstrained |
	o o +-----------+ | device |		o o +-----------+ | device |
	o o o ------ | Middlebox | ------- | |		o o o ------ | Middlebox | ------- | |
	o o +-----------+ | (e.g. cloud) |		o o +-----------+ | (e.g. cloud) |
	o o o | |		o o o | |
	+---------------+		+---------------+
	constrained devices		constrained devices
	Figure 1: TCP communication between a constrained device and an		Figure 1: TCP communication between a constrained device and an
	unconstrained device, traversing a middlebox.		unconstrained device, traversing a middlebox.
			3.3. Communication and traffic patterns
			IoT applications are characterized by a number of different
			communication patterns. The following non-comprehensive list
			explains some typical examples:
			o Unidirectional transfers: An IoT device (e.g. a sensor) can send
			(repeatedly) updates to the other endpoint. Not in every case
			there is a need for an application response back to the IoT
			device.
			o Request-response patterns: An IoT device receiving a request from
			the other endpoint, which triggers a response from the IoT device.
			o Bulk data transfers: A typical example for a long file transfer
			would be an IoT device firmware update.
			A typical communication pattern is that a constrained device
			communicates with an unconstrained device (cf. Figure 1). But it is
			also possible that constrained devices communicate amongst
			themselves.
	4. TCP over CNNs		4. TCP over CNNs
	4.1. TCP connection initiation		4.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.
	4.2. Maximum Segment Size (MSS)		4.2. Maximum Segment Size (MSS)
	Some link layer technologies in the CNN space are characterized by a		Some link layer technologies in the CNN space are characterized by a
	short data unit payload size, e.g. up to a few tens or hundreds of		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 127		bytes. For example, the maximum frame size in IEEE 802.15.4 is 127
	bytes.		bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE
	6LoWPAN defined an adaptation layer to support IPv6 over IEEE
	802.15.4 networks. The adaptation layer includes a fragmentation		802.15.4 networks. The adaptation layer includes a fragmentation
	mechanism, since IPv6 requires the layer below to support an MTU of		mechanism, since IPv6 requires the layer below to support an MTU of
	1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation		1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation
	mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes		mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes
	[RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T		[RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T
	G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based		G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based
	adaptation layers in order to enable IPv6 support. These		adaptation layers in order to enable IPv6 support. These
	technologies do support link layer fragmentation. By exploiting this		technologies do support link layer fragmentation. By exploiting this
	functionality, the adaptation layers that enable IPv6 over such		functionality, the adaptation layers that enable IPv6 over such
	technologies also define an MTU of 1280 bytes.		technologies also define an MTU of 1280 bytes.
	For devices using technologies with a link MTU of 1280 bytes (e.g.
	defined by a 6LoWPAN-based adaptation layer), in order to avoid IP
	layer fragmentation, the TCP MSS must not be set to a value greater
	than 1220 bytes in CNNs, and it must not be set to a value leading to
	an IPv6 datagram size exceeding 1280 bytes. (Note: IP version 6 is
	assumed.)
	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) [I-D.ietf-lpwan-overview] or IEEE 802.11ah		Narrowband IoT (NB-IoT) [I-D.ietf-lpwan-overview] 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. Over such technologies, the TCP MSS may be		802.11ah is 7991 bytes.
	set to a value greater than 1220 bytes, as long as IPv6 datagram size
	does not exceed the MTU for each technology. One consideration in		For the sake of lightweight implementation and operation, unless
	this regard is that, when a node supports an MTU greater than 1280		applications require handling large data units (i.e. leading to an
	bytes, it 'SHOULD' then support Path MTU (PMTU) discovery [RFC1981].		IPv6 datagram size greater than 1280 bytes), it may be desirable to
	(Note that, as explained in RFC 1981, a minimal IPv6 implementation		limit the MTU to 1280 bytes in order to avoid the need to support
	may 'choose to omit implementation of Path MTU Discovery'). For the		Path MTU Discovery [RFC1981].
	sake of lightweight implementation and operation, unless applications
	require handling large data units (i.e. leading to an IPv6 datagram		An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
	size greater than 1280 bytes), it may be desirable to limit the MTU		the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is
	to 1280 bytes.		assumed.)
	4.3. Window Size		4.3. Window Size
	A TCP stack can reduce the implementation complexity by advertising a		A TCP stack can reduce the RAM requirements by advertising a TCP
	TCP window size of one MSS, and also transmit at most one MSS of		window size of one MSS, and also transmit at most one MSS of
	unacknowledged data, at the cost of decreased performance. This size		unacknowledged data. In that case, both congestion and flow control
	for receive and send window is appropriate for simple message		implementation is quite simple. Such a small receive and send window
	exchanges in the CNN space, reduces implementation complexity and		may be sufficient for simple message exchanges in the CNN space.
	memory requirements, and reduces overhead (see section 4.7).		However, only using a window of one MSS can significantly affect
			performance. A stop-and-wait operation results in low throughput for
			transfers that exceed the lengths of one MSS, e.g., a firmware
			download. In addition, there can be interactions with the delayed
			acknowledgements (see Section 4.8).
	A TCP window size of one MSS follows the same rationale as the		Devices that have enough memory to allow larger TCP window size can
	default setting for NSTART in [RFC7252], leading to equivalent		leverage a more efficient error recovery using Fast Retransmit and
	operation when CoAP is used over TCP.		Fast Recovery [RFC5681]. These algorithms work efficiently for
			window sizes of at least 5 MSS: If in a given TCP transmission of
			segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should
			get an acknowledgement for segment 1 when 3 arrives and duplicate
			acknowledgements when 4, 5, and 6 arrive. It will retransmit segment
			2 when the third duplicate ack arrives. In order to have segment 2,
			3, 4, 5, and 6 sent, the window has to be at least five. With an MSS
			of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte.
	For devices that can afford greater TCP window size, it may be useful		For bulk data transfers further TCP improvements may also be useful,
	to allow window sizes of at least five MSSs, in order to allow Fast		such as limited transmit [RFC3402].
	Retransmit and Fast Recovery [RFC5681].
			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
			destination until a response for the previous message sent to that
			destination has been received. This is equivalent to an application-
			layer window size of 1. For this use of CoAP, a maximum TCP window
			of one MSS will be sufficient.
	4.4. RTO estimation		4.4. RTO estimation
	If a TCP sender uses very small window size and cannot use Fast		The Retransmission Timeout (RTO) estimation is one of the fundamental
	Retransmit/Fast Recovery or SACK, the RTO algorithm has a larger		TCP algorithms. There is a fundamental trade-off: A short,
	impact on performance than for a more powerful TCP stack. In that		aggressive RTO behavior reduces wait time before retransmissions, but
	case, RTO algorithm tuning may be considered, although careful		it also increases the probability of spurious timeouts. The latter
	assessment of possible drawbacks is recommended. A fundamental		lead to unnecessary waste of potentially scarce resources in CNNs
	trade-off exists between responsiveness and correctness of RTOs		such as energy and bandwidth. In contrast, a conservative timeout
	[I-D.ietf-tcpm-rto-consider]. A more aggressive RTO behavior reduces		can result in long error recovery times and thus needlessly delay
	wait time before retransmissions, but it also increases the		data delivery.
	probability of incurring spurious timeouts. The latter lead to
	unnecessary waste of potentially scarce resources in CNNs such as
	energy and bandwidth.
	On a related note, there has been recent activity in the area of		[RFC6298] describes the standard TCP RTO algorithm. If a TCP sender
	defining an adaptive RTO algorithm for CoAP (over UDP). As shown in		uses very small window size and cannot use Fast Retransmit/Fast
	experimental studies, the RTO estimator for CoAP defined in		Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a
	[I-D.ietf-core-cocoa] (hereinafter, CoCoA RTO) outperforms state-of-		larger impact on performance than for a more powerful TCP stack. In
	art algorithms designed as improvements to RFC 6298 [RFC6298] for		that case, RTO algorithm tuning may be considered, although careful
	TCP, in terms of packet delivery ratio, settling time after a burst		assessment of possible drawbacks is recommended.
	of messages, and fairness (the latter is specially relevant in
	multihop networks connected to the Internet through a single device,		As an example, an adaptive RTO algorithm for CoAP over UDP has been
	such as a 6LoWPAN Border Router (6LBR) configured as a RPL root)		defined [I-D.ietf-core-cocoa] that has been found to perform well in
	[Commag]. In fact, CoCoA RTO has been designed specifically		CNN scenarios [Commag].
	considering the challenges of CNNs, in contrast with the RFC 6298
	RTO.
	4.5. TCP connection lifetime		4.5. TCP connection lifetime
	[[Note: future revisions will better separate what a TCP stack should		[[Note: future revisions will better separate what a TCP stack should
	support, or not, and how the TCP stack should be used by		support, or not, and how the TCP stack should be used by
	applications, e.g., whether to close connections or not.]]		applications, e.g., whether to close connections or not.]]
	4.5.1. Long TCP connection lifetime		4.5.1. Long TCP connection lifetime
	In CNNs, in order to minimize message overhead, a TCP connection		In CNNs, in order to minimize message overhead, a TCP connection
	skipping to change at page 8, line 43 ¶		skipping to change at page 10, line 17 ¶
	ECN is particularly appropriate in CNNs, since in these environments		ECN is particularly appropriate in CNNs, since in these environments
	transactional type interactions are a dominant traffic pattern. As		transactional type interactions are a dominant traffic pattern. As
	transactional data size decreases, the probability of detecting		transactional data size decreases, the probability of detecting
	congestion by the presence of three duplicate ACKs decreases. In		congestion by the presence of three duplicate ACKs decreases. In
	contrast, ECN can still activate congestion control measures without		contrast, ECN can still activate congestion control measures without
	requiring three duplicate ACKs.		requiring three duplicate ACKs.
	4.7. TCP options		4.7. TCP options
	A TCP implementation needs to support options 0, 1 and 2 [RFC793]. A		A TCP implementation needs to support options 0, 1 and 2 [RFC0793].
	TCP implementation for a constrained device that uses a single-MSS		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 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 Acknowledgements (SACK) and SACK-Permitted		[RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted
	[RFC2018]. Other TCP options should not be used, in keeping with the		[RFC2018]. Also other TCP options may not be required on a
	principle of lightweight operation.		constrained device with a very lightweight implementation.
	Other TCP options should not be supported by a constrained device, in
	keeping with the principle of lightweight implementation and
	operation.
	If a device, with less severe memory and processing constraints, can
	afford advertising a TCP window size of several MSSs, it may support
	the SACK option to improve performance. SACK allows a data receiver
	to inform the data sender of non-contiguous data blocks received,
	thus a sender (having previously sent the SACK-Permitted option) can
	avoid performing unnecessary retransmissions, saving energy and
	bandwidth, as well as reducing latency. The receiver supporting SACK
	will need to manage the reception of possible out-of-order received
	segments, requiring sufficient buffer space.
	SACK adds 8*n+2 bytes to the TCP header, where n denotes the number		If a device with less severe memory and processing constraints can
	of data blocks received, up to 4 blocks. For a low number of out-of-		afford advertising a TCP window size of several MSSs, it makes sense
	order segments, the header overhead penalty of SACK is compensated by		to support the SACK option to improve performance. SACK allows a
			data receiver to inform the data sender of non-contiguous data blocks
			received, thus a sender (having previously sent the SACK-Permitted
			option) can avoid performing unnecessary retransmissions, saving
			energy and bandwidth, as well as reducing latency. SACK is
			particularly useful for bulk data transfers. The receiver supporting
			SACK will need to manage the reception of possible out-of-order
			received segments, requiring sufficient buffer space. SACK adds
			8*n+2 bytes to the TCP header, where n denotes the number of data
			blocks received, up to 4 blocks. For a low number of out-of- order
			segments, the header overhead penalty of SACK is compensated by
	avoiding unnecessary retransmissions.		avoiding unnecessary retransmissions.
	Another potentially relevant TCP option in the context of CNNs is		Another potentially relevant TCP option in the context of CNNs is
	(TFO) [RFC7413]. As described in section 4.5.2, TFO can be used to		(TFO) [RFC7413]. As described in Section 4.5.2, TFO can be used to
	address the problem of traversing middleboxes that perform early		address the problem of traversing middleboxes that perform early
	filter state record deletion.		filter state record deletion.
	4.8. Delayed Acknowledgments		4.8. Delayed Acknowledgments
	A device that advertises a single-MSS receive window needs to avoid		TCP Delayed Acknowledgements reduce the number of transferred bytes
	use of delayed ACKs in order to avoid contributing unnecessary delay		within a TCP connection, but they may increase the time until a
	(of up to 500 ms) to the RTT [RFC5681].		sender may receive an ACK. For certain traffic patterns Delayed
			Acknowledgements may have a detrimental effect. Advanced TCP stacks
			may use heuristics to determine the maximum delay for an ACK. For
			CNNs, the recommendation depends on the expected communication
			patterns.
	When traffic over a CNN is expected to be mostly of transactional		A device that advertises a single-MSS receive window should avoid use
	type, with transaction size typically below one MSS, delayed ACKs are		of delayed ACKs in order to avoid contributing unnecessary delay (of
	not recommended. For transactional-type traffic between a		up to 500 ms) to the RTT [RFC5681], which limits the throughput and
	constrained device and a peer (e.g. backend infrastructure) that uses		can increase the data delivery time.
	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
	device is administered by the same entity managing the constrained
	device, it is recommended to disable delayed ACKs at the peer side.
	On the other hand, delayed ACKs allow to reduce the number of ACKs in		A device that can send at most one MSS of data is significantly
	bulk transfer type of traffic, e.g. for firmware/software updates or		affected if the receiver uses delayed ACKs, e.g., if a TCP server or
	for transferring larger data units containing a batch of sensor		receiver is outside the CNN. One known workaround is to split the
	readings.		data to be sent into two segments of smaller size. A standard
			compliant TCP receiver will then immediately acknowledge the second
			segment, which can improve throughput. This "split hack" works if
			the TCP receiver uses Delayed Acks, but the downside is the overhead
			of sending two IP packets instead of one.
			Also for larger windows, it may make sense to use a small timeout or
			disable delayed ACKs when traffic over a CNN is expected to mostly be
			small messages with a size typically below one MSS. For request-
			response traffic between a constrained device and a peer (e.g.
			backend infrastructure) that uses 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 device is administered by the
			same entity managing the constrained 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
			transfer type of traffic, e.g. for firmware/software updates or for
			transferring larger data units containing a batch of sensor readings.
	4.9. Explicit loss notifications		4.9. Explicit loss notifications
	There has been a significant body of research on solutions capable of		There has been a significant body of research on solutions capable of
	explicitly indicating whether a TCP segment loss is due to		explicitly indicating whether a TCP segment loss is due to
	corruption, in order to avoid activation of congestion control		corruption, in order to avoid activation of congestion control
	mechanisms [ETEN] [RFC2757]. While such solutions may provide		mechanisms [ETEN] [RFC2757]. While such solutions may provide
	significant improvement, they have not been widely deployed and		significant improvement, they have not been widely deployed and
	remain as experimental work. In fact, as of today, the IETF has not		remain as experimental work. In fact, as of today, the IETF has not
	standardized any such solution.		standardized any such solution.
	5. Security Considerations		5. Security Considerations
	If TFO is used, the security considerations of RFC 7413 apply.		Best current practise for securing TCP and TCP-based communication
			also applies to CNN. As example, use of Transport Layer Security
			(TLS) is strongly recommended if it is applicable.
	There exist TCP options which improve TCP security. Examples include		There are also TCP options which can improve TCP security. Examples
	the TCP MD5 signature option [RFC2385] and the TCP Authentication		include the TCP MD5 signature option [RFC2385] and the TCP
	Option (TCP-AO) [RFC5925]. However, both options add overhead and		Authentication Option (TCP-AO) [RFC5925]. However, both options add
	complexity. The TCP MD5 signature option adds 18 bytes to every		overhead and complexity. The TCP MD5 signature option adds 18 bytes
	segment of a connection. TCP-AO typically has a size of 16-20 bytes.		to every segment of a connection. TCP-AO typically has a size of
			16-20 bytes.
			For the mechanisms discussed in this document, the corresponding
			considerations apply. For instance, if TFO is used, the security
			considerations of [RFC7413] apply.
	6. Acknowledgments		6. Acknowledgments
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	(Ministerio de Educacion, Cultura y Deporte) through the Jose		(Ministerio de Educacion, Cultura y Deporte) through the Jose
	Castillejo grant CAS15/00336 and by European Regional Development		Castillejo grant CAS15/00336 and by European Regional Development
	Fund (ERDF) and the Spanish Government through project		Fund (ERDF) and the Spanish Government through project
	TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this		TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this
	work has been carried out during his stay as a visiting scholar at		work has been carried out during his stay as a visiting scholar at
	the Computer Laboratory of the University of Cambridge.		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, Michael Scharf, Ari Keranen,		Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan
	Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe		Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred
	Touch, Fred Baker, Nik Sultana, Kerry Lynn, and Erik Nordmark. Simon		Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and
	Brummer provided details on the RIOT TCP implementation. Xavi		Hannes Tschofenig. Simon Brummer provided details on the RIOT TCP
	Vilajosana provided details on the OpenWSN TCP implementation.		implementation. Xavi Vilajosana provided details on the OpenWSN TCP
			implementation. Rahul Jadhav provided details on the uIP TCP
			implementation.
	7. Annex. TCP implementations for constrained devices		7. 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.		constrained devices.
	7.1. uIP		7.1. uIP
	uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers.		uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers.
	uIP has been deployed with Contiki and the Arduino Ethernet shield.		uIP has been deployed with Contiki and the Arduino Ethernet shield.
	skipping to change at page 11, line 4 ¶		skipping to change at page 12, line 51 ¶
	7. Annex. TCP implementations for constrained devices		7. 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.		constrained devices.
	7.1. uIP		7.1. uIP
	uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers.		uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers.
	uIP has been deployed with Contiki and the Arduino Ethernet shield.		uIP has been deployed with Contiki and the Arduino Ethernet shield.
	A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP)		A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP)
	has been reported for uIP [Dunk].		has been reported for uIP [Dunk].
	uIP provides a global buffer for incoming packets, of single-packet		uIP uses same buffer both incoming and outgoing traffic, with has a
	size. A buffer for outgoing data is not provided. In case of a		size of a single packet. In case of a retransmission, an application
	retransmission, an application must be able to reproduce the same		must be able to reproduce the same user data that had been
	packet that had been transmitted.		transmitted.
	The MSS is announced via the MSS option on connection establishment		The MSS is announced via the MSS option on connection establishment
	and the receive window size (of one MSS) is not modified during a		and the receive window size (of one MSS) is not modified during a
	connection. Stop-and-wait operation is used for sending data. Among		connection. Stop-and-wait operation is used for sending data. Among
	other optimizations, this allows to avoid sliding window operations,		other optimizations, this allows to avoid sliding window operations,
	which use 32-bit arithmetic extensively and are expensive on 8-bit		which use 32-bit arithmetic extensively and are expensive on 8-bit
	CPUs.		CPUs.
			Contiki uses the "split hack" technique (see Section 4.8) to avoid
			delayed ACKs for senders using a single MSS.
	7.2. lwIP		7.2. lwIP
	lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers.		lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers.
	lwIP has a total code size of ~14 kB to ~22 kB (which comprises		lwIP has a total code size of ~14 kB to ~22 kB (which comprises
	memory management, checksumming, network interfaces, IP, ICMP and		memory management, checksumming, network interfaces, IP, ICMP and
	TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk].		TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk].
	In contrast with uIP, lwIP decouples applications from the network		In contrast with uIP, lwIP decouples applications from the network
	stack. lwIP supports a TCP transmission window greater than a single		stack. lwIP supports a TCP transmission window greater than a single
	segment, as well as buffering of incoming and outcoming data. Other		segment, as well as buffering of incoming and outcoming data. Other
	skipping to change at page 12, line 14 ¶		skipping to change at page 14, line 14 ¶
	7.4. OpenWSN		7.4. OpenWSN
	The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP		The TCP implementation in OpenWSN is mostly equivalent to the uIP TCP
	implementation. OpenWSN TCP implementation only supports the minimum		implementation. OpenWSN TCP implementation only supports the minimum
	state machine functionality required. For example, it does not		state machine functionality required. For example, it does not
	perform retransmissions.		perform retransmissions.
	7.5. TinyOS		7.5. TinyOS
	TBD		TODO: To be verified
	7.6. Summary		TinyOS has an experimental TCP stack that uses a simple nonblocking
			library-based implementation of TCP. The application is responsible
			for buffering. The TCP library does not do any receive-side
			buffering. Instead, it will immediately dispatch new, in-order data
			to the application and otherwise drop the segment. A send buffer is
			provided so that the TCP implementation can automatically retransmit
			missing segments.
			7.6. Summary
	+-------+---------+---------+------+---------+--------+		+-------+---------+---------+------+---------+--------+
	| uIP |lwIP orig|lwIP 2.0 | RIOT | OpenWSN | TinyOS |		| uIP |lwIP orig|lwIP 2.0 | RIOT | OpenWSN | TinyOS |
	+--------+----------------+-------+---------+---------+------+---------+--------+		+--------+----------------+-------+---------+---------+------+---------+--------+
	| | Data size | * | * | * | * | * | * |		| | Data size | * | * | * | * | * | * |
	| Memory +----------------+-------+---------+---------+------+---------+--------+		| Memory +----------------+-------+---------+---------+------+---------+--------+
	| | Code size (kB) | < 5 |~9 to ~14| * | * | * | * |		| | Code size (kB) | < 5 |~9 to ~14| * | * | * | * |
	+--------+----------------+-------+---------+---------+------+---------+--------+		+--------+----------------+-------+---------+---------+------+---------+--------+
	| |Window size(MSS)| 1 | Multiple| Multiple| 1 | 1 | * |		| |Window size(MSS)| 1 | Multiple| Multiple| 1 | 1 |Multiple|
	| +----------------+-------+---------+---------+------+---------+--------+		| +----------------+-------+---------+---------+------+---------+--------+
	| | Slow start | No | Yes | Yes | No | No | * |		| | Slow start | No | Yes | Yes | No | No | Yes |
	| T +----------------+-------+---------+---------+------+---------+--------+		| T +----------------+-------+---------+---------+------+---------+--------+
	| C | Fast rec/retx | No | Yes | Yes | No | No | * |		| C | Fast rec/retx | No | Yes | Yes | No | No | Yes |
	| P +----------------+-------+---------+---------+------+---------+--------+		| P +----------------+-------+---------+---------+------+---------+--------+
	| | Keep-alive | No | * | * | No | No | * |		| | Keep-alive | No | * | * | No | No | No |
	| +----------------+-------+---------+---------+------+---------+--------+		| +----------------+-------+---------+---------+------+---------+--------+
	| f | TFO | No | No | * | No | No | * |		| f | TFO | No | No | * | No | No | No |
	| e +----------------+-------+---------+---------+------+---------+--------+		| e +----------------+-------+---------+---------+------+---------+--------+
	| a | ECN | No | No | * | No | No | * |		| a | ECN | No | No | * | No | No | No |
	| t +----------------+-------+---------+---------+------+---------+--------+		| t +----------------+-------+---------+---------+------+---------+--------+
	| u | Window Scale | No | No | Yes | No | No | * |		| u | Window Scale | No | No | Yes | No | No | No |
	| r +----------------+-------+---------+---------+------+---------+--------+		| r +----------------+-------+---------+---------+------+---------+--------+
	| e | TCP timestamps | No | No | Yes | No | No | * |		| e | TCP timestamps | No | No | Yes | No | No | No |
	| s +----------------+-------+---------+---------+------+---------+--------+		| s +----------------+-------+---------+---------+------+---------+--------+
	| | SACK | No | No | Yes | No | No | * |		| | SACK | No | No | Yes | No | No | No |
	| +----------------+-------+---------+---------+------+---------+--------+		| +----------------+-------+---------+---------+------+---------+--------+
	| | Delayed ACKs | No | Yes | Yes | No | No | * |		| | Delayed ACKs | No | Yes | Yes | No | No | No |
	+--------+----------------+-------+---------+---------+------+---------+--------+		+--------+----------------+-------+---------+---------+------+---------+--------+
	Figure 2: Summary of TCP features for differrent lightweight TCP		Figure 2: Summary of TCP features for differrent lightweight TCP
	implementations.		implementations.
	8. References		TODO: Add information about RAM requirements (in addition to
			codesize)
	8.1. Normative References		8. Annex. Changes compared to previous versions
			RFC Editor: To be removed prior to publication
			8.1. Changes compared to -00
			o Changed title and abstract
			o Clarification that communcation with standard-compliant TCP
			endpoints is required, based on feedback from Joe Touch
			o Additional discussion on communication patters
			o Numerous changes to address a comprehensive review from Hannes
			Tschofenig
			o Reworded security considerations
			o Additional references and better distinction between normative and
			informative entries
			o Feedback from Rahul Jadhav on the uIP TCP implementation
			o Basic data for the TinyOS TCP implementation added, based on
			source code analysis
			9. References
			9.1. Normative References
			[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
			RFC 793, DOI 10.17487/RFC0793, September 1981,
			<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,
	DOI 10.17487/RFC1122, October 1989, <https://www.rfc-		DOI 10.17487/RFC1122, October 1989,
	editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions		[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
	for High Performance", RFC 1323, DOI 10.17487/RFC1323, May		for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
	1992, <https://www.rfc-editor.org/info/rfc1323>.		1992, <https://www.rfc-editor.org/info/rfc1323>.
	[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
	1996, <https://www.rfc-editor.org/info/rfc1981>.
	[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP		[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
	Selective Acknowledgment Options", RFC 2018,		Selective Acknowledgment Options", RFC 2018,
	DOI 10.17487/RFC2018, October 1996, <https://www.rfc-		DOI 10.17487/RFC2018, October 1996,
	editor.org/info/rfc2018>.		<https://www.rfc-editor.org/info/rfc2018>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	1998, <https://www.rfc-editor.org/info/rfc2385>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[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.
	Vaidya, "Long Thin Networks", RFC 2757,
	DOI 10.17487/RFC2757, January 2000, <https://www.rfc-
	editor.org/info/rfc2757>.
	[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
	Explicit Congestion Notification (ECN) in IP Networks",
	RFC 2884, DOI 10.17487/RFC2884, July 2000,
	<https://www.rfc-editor.org/info/rfc2884>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	"Transmission of IPv6 Packets over IEEE 802.15.4		Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402,
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		October 2002, <https://www.rfc-editor.org/info/rfc3402>.
	<https://www.rfc-editor.org/info/rfc4944>.
			[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
			Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
			Wood, "Advice for Internet Subnetwork Designers", BCP 89,
			RFC 3819, DOI 10.17487/RFC3819, July 2004,
			<https://www.rfc-editor.org/info/rfc3819>.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<https://www.rfc-editor.org/info/rfc5681>.		<https://www.rfc-editor.org/info/rfc5681>.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.		June 2010, <https://www.rfc-editor.org/info/rfc5925>.
	[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
	Capabilities in Customer Premises Equipment (CPE) for
	Providing Residential IPv6 Internet Service", RFC 6092,
	DOI 10.17487/RFC6092, January 2011, <https://www.rfc-
	editor.org/info/rfc6092>.
	[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,		[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
	"Computing TCP's Retransmission Timer", RFC 6298,		"Computing TCP's Retransmission Timer", RFC 6298,
	DOI 10.17487/RFC6298, June 2011, <https://www.rfc-		DOI 10.17487/RFC6298, June 2011,
	editor.org/info/rfc6298>.		<https://www.rfc-editor.org/info/rfc6298>.
	[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
	Statement and Requirements for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Routing",
	RFC 6606, DOI 10.17487/RFC6606, May 2012,
	<https://www.rfc-editor.org/info/rfc6606>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014, <https://www.rfc-		DOI 10.17487/RFC7228, May 2014,
	editor.org/info/rfc7228>.		<https://www.rfc-editor.org/info/rfc7228>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
	editor.org/info/rfc7252>.
	[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,		Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
	<https://www.rfc-editor.org/info/rfc7413>.		<https://www.rfc-editor.org/info/rfc7413>.
	[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets		9.2. Informative References
	over ITU-T G.9959 Networks", RFC 7428,
	DOI 10.17487/RFC7428, February 2015, <https://www.rfc-
	editor.org/info/rfc7428>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
	editor.org/info/rfc7540>.
	[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
	Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
	<https://www.rfc-editor.org/info/rfc7668>.
	[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
	M., and D. Barthel, "Transmission of IPv6 Packets over
	Digital Enhanced Cordless Telecommunications (DECT) Ultra
	Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
	2017, <https://www.rfc-editor.org/info/rfc8105>.
	[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
	Donaldson, "Transmission of IPv6 over Master-Slave/Token-
	Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
	May 2017, <https://www.rfc-editor.org/info/rfc8163>.
	8.2. Informative References
	[Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP		[Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP
	Congestion Control for the Internet of Things", IEEE		Congestion Control for the Internet of Things", IEEE
	Communications Magazine, June 2016.		Communications Magazine, June 2016.
	[Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003.		[Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003.
	[ETEN] R. Krishnan et al, "Explicit transport error notification		[ETEN] R. Krishnan et al, "Explicit transport error notification
	(ETEN) for error-prone wireless and satellite networks",		(ETEN) for error-prone wireless and satellite networks",
	Computer Networks 2004.		Computer Networks 2004.
	[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-core-coap-tcp-tls]
			Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
			Silverajan, B., and B. Raymor, "CoAP (Constrained
			Application Protocol) over TCP, TLS, and WebSockets",
			draft-ietf-core-coap-tcp-tls-09 (work in progress), May
			2017.
	[I-D.ietf-core-cocoa]		[I-D.ietf-core-cocoa]
	Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,		Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
	"CoAP Simple Congestion Control/Advanced", draft-ietf-		"CoAP Simple Congestion Control/Advanced", draft-ietf-
	core-cocoa-01 (work in progress), March 2017.		core-cocoa-01 (work in progress), March 2017.
	[I-D.ietf-lpwan-overview]		[I-D.ietf-lpwan-overview]
	Farrell, S., "LPWAN Overview", draft-ietf-lpwan-		Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
	overview-06 (work in progress), July 2017.		overview-07 (work in progress), October 2017.
	[I-D.ietf-lwig-energy-efficient]		[I-D.ietf-lwig-energy-efficient]
	Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-		Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
	Efficient Features of Internet of Things Protocols",		Efficient Features of Internet of Things Protocols",
	draft-ietf-lwig-energy-efficient-07 (work in progress),		draft-ietf-lwig-energy-efficient-07 (work in progress),
	March 2017.		March 2017.
	[I-D.ietf-tcpm-rto-consider]		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	Allman, M., "Retransmission Timeout Requirements", draft-		for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
	ietf-tcpm-rto-consider-05 (work in progress), March 2017.		1996, <https://www.rfc-editor.org/info/rfc1981>.
	[I-D.tschofenig-core-coap-tcp-tls]		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Bormann, C., Lemay, S., Technologies, Z., and H.		Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	Tschofenig, "A TCP and TLS Transport for the Constrained		1998, <https://www.rfc-editor.org/info/rfc2385>.
	Application Protocol (CoAP)", draft-tschofenig-core-coap-
	tcp-tls-05 (work in progress), November 2015.
	[MQTTS] U. Hunkeler, H.-L. Truong, A. Stanford-Clark, "MQTT-S: A		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Publish/Subscribe Protocol For Wireless Sensor Networks",		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	2008.		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.
			Vaidya, "Long Thin Networks", RFC 2757,
			DOI 10.17487/RFC2757, January 2000,
			<https://www.rfc-editor.org/info/rfc2757>.
			[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
			Explicit Congestion Notification (ECN) in IP Networks",
			RFC 2884, DOI 10.17487/RFC2884, July 2000,
			<https://www.rfc-editor.org/info/rfc2884>.
			[RFC3481] Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov,
			A., and F. Khafizov, "TCP over Second (2.5G) and Third
			(3G) Generation Wireless Networks", BCP 71, RFC 3481,
			DOI 10.17487/RFC3481, February 2003,
			<https://www.rfc-editor.org/info/rfc3481>.
			[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
			"Transmission of IPv6 Packets over IEEE 802.15.4
			Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
			<https://www.rfc-editor.org/info/rfc4944>.
			[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
			Briscoe, "Open Research Issues in Internet Congestion
			Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
			<https://www.rfc-editor.org/info/rfc6077>.
			[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
			Capabilities in Customer Premises Equipment (CPE) for
			Providing Residential IPv6 Internet Service", RFC 6092,
			DOI 10.17487/RFC6092, January 2011,
			<https://www.rfc-editor.org/info/rfc6092>.
			[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
			Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
			March 2011, <https://www.rfc-editor.org/info/rfc6120>.
			[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
			Statement and Requirements for IPv6 over Low-Power
			Wireless Personal Area Network (6LoWPAN) Routing",
			RFC 6606, DOI 10.17487/RFC6606, May 2012,
			<https://www.rfc-editor.org/info/rfc6606>.
			[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
			Application Protocol (CoAP)", RFC 7252,
			DOI 10.17487/RFC7252, June 2014,
			<https://www.rfc-editor.org/info/rfc7252>.
			[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
			Zimmermann, "A Roadmap for Transmission Control Protocol
			(TCP) Specification Documents", RFC 7414,
			DOI 10.17487/RFC7414, February 2015,
			<https://www.rfc-editor.org/info/rfc7414>.
			[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
			over ITU-T G.9959 Networks", RFC 7428,
			DOI 10.17487/RFC7428, February 2015,
			<https://www.rfc-editor.org/info/rfc7428>.
			[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
			Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
			DOI 10.17487/RFC7540, May 2015,
			<https://www.rfc-editor.org/info/rfc7540>.
			[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
			Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
			Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
			<https://www.rfc-editor.org/info/rfc7668>.
			[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
			M., and D. Barthel, "Transmission of IPv6 Packets over
			Digital Enhanced Cordless Telecommunications (DECT) Ultra
			Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
			2017, <https://www.rfc-editor.org/info/rfc8105>.
			[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
			Donaldson, "Transmission of IPv6 over Master-Slave/Token-
			Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
			May 2017, <https://www.rfc-editor.org/info/rfc8163>.
	Authors' Addresses		Authors' Addresses
	Carles Gomez		Carles Gomez
	UPC/i2CAT		UPC/i2CAT
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	Castelldefels 08860		Castelldefels 08860
	Spain		Spain
	Email: carlesgo@entel.upc.edu		Email: carlesgo@entel.upc.edu
End of changes. 73 change blocks.
	301 lines changed or deleted		470 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/