draft-ietf-lwig-tcp-constrained-node-networks-06.txt   draft-ietf-lwig-tcp-constrained-node-networks-07.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: September 28, 2019 University of Cambridge Expires: September 30, 2019 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
March 27, 2019 March 29, 2019
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-06 draft-ietf-lwig-tcp-constrained-node-networks-07
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 September 28, 2019. This Internet-Draft will expire on September 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 6 4.1. Path properties . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7 4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7
4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 8 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 8
4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 9
4.2. TCP guidance for single-MSS windows and buffers . . . . . 9 4.2. TCP guidance for single-MSS windows and buffers . . . . . 9
4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 9 4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 9
4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9 4.2.2. TCP options for single-MSS stacks . . . . . . . . . . 9
4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 10 4.2.3. Delayed Acknowledgments for single-MSS stacks . . . . 10
4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 10 4.2.4. RTO estimation for single-MSS stacks . . . . . . . . 11
4.3. General recommendations for TCP in CNNs . . . . . . . . . 11 4.3. General recommendations for TCP in CNNs . . . . . . . . . 11
4.3.1. Loss recovery and congestion/flow control . . . . . . 11 4.3.1. Loss recovery and congestion/flow control . . . . . . 11
4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 11 4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 12
4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12 4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 12 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 13
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 13 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 13
5.2. Number of concurrent connections . . . . . . . . . . . . 13 5.2. Number of concurrent connections . . . . . . . . . . . . 13
5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Annex. TCP implementations for constrained devices . . . . . 16 8. Annex. TCP implementations for constrained devices . . . . . 16
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Annex. Changes compared to previous versions . . . . . . . . 20 9. Annex. Changes compared to previous versions . . . . . . . . 20
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20
9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20
9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21
9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21 9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21
9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 21 9.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 21
9.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 4, line 6 skipping to change at page 4, line 9
HTTP/2 and even HTTP/1.1, both of which run over TCP by default HTTP/2 and even HTTP/1.1, both of which run over TCP by default
[RFC7230] [RFC7540], and the Extensible Messaging and Presence [RFC7230] [RFC7540], and the Extensible Messaging and Presence
Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application- Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application-
layer protocols in the IoT space such as the Message 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 memory requirements. Many TCP extensions are not required for
interoperability with other standard-compliant TCP endpoints. Given interoperability with other standard-compliant TCP endpoints. Given
the limited resources on constrained devices, careful "tuning" of the the limited resources on constrained devices, careful "tuning" of the
TCP implementation can make an implementation more lightweight. TCP implementation can make an implementation more lightweight.
This document provides guidance on how to implement and use TCP in This document provides guidance on how to implement and use TCP in
CNNs. The overarching goal is to offer simple measures to allow for CNNs. The overarching goal is to offer simple measures to allow for
lightweight TCP implementation and suitable operation in such lightweight TCP implementation and suitable operation in such
environments. A TCP implementation following the guidance in this environments. A TCP implementation following the guidance in this
document is intended to be compatible with a TCP endpoint that is document is intended to be compatible with a TCP endpoint that is
compliant to the TCP standards, albeit possibly with a lower compliant to the TCP standards, albeit possibly with a lower
skipping to change at page 7, line 4 skipping to change at page 7, line 6
also possible that constrained devices communicate amongst also possible that constrained devices communicate amongst
themselves. themselves.
4. TCP implementation and configuration in CNNs 4. TCP implementation and configuration in CNNs
This section explains how a TCP stack can deal with typical This section explains how a TCP stack can deal with typical
constraints in CNN. The guidance in this section relates to the TCP constraints in CNN. The guidance in this section relates to the TCP
implementation and its configuration. implementation and its configuration.
4.1. Path properties 4.1. Path properties
4.1.1. Maximum Segment Size (MSS) 4.1.1. Maximum Segment Size (MSS)
For the sake of lightweight implementation and operation, unless Assuming that IPv6 is used, and for the sake of lightweight
applications require handling large data units (i.e. leading to an implementation and operation, unless applications require handling
IPv6 datagram size greater than 1280 bytes), it may be desirable to large data units (i.e. leading to an IPv6 datagram size greater than
limit the MTU to 1280 bytes in order to avoid the need to support 1280 bytes), it may be desirable to limit the MTU to 1280 bytes in
Path MTU Discovery [RFC8201]. order to avoid the need to support Path MTU Discovery [RFC8201].
An IPv6 datagram size exceeding 1280 bytes can be avoided by setting An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is the TCP MSS not larger than 1220 bytes. This assumes that the remote
assumed.) This assumes that the remote sender will use no TCP sender will use no TCP options, aside from possibly the MSS option,
options, aside from possibly the MSS option, which is only used in which is only used in the initial TCP SYN packet. In order to
the initial TCP SYN packet. In order to accommodate unrequested TCP accommodate unrequested TCP options that may be used by some TCP
options that may be used by some TCP implementations, a constrained implementations, a constrained device may advertise an MSS not larger
device may advertise an MSS not larger than 1200 bytes. than 1200 bytes.
Note that setting the MTU to 1280 bytes is possible for link layer Note that setting the MTU to 1280 bytes is possible for link layer
technologies in the CNN space, even if some of them are characterized technologies in the CNN space, even if some of them are characterized
by a short data unit payload size, e.g. up to a few tens or hundreds by a 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 of bytes. For example, the maximum frame size in IEEE 802.15.4 is
127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over 127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over
IEEE 802.15.4 networks. The adaptation layer includes a IEEE 802.15.4 networks. The adaptation layer includes a
fragmentation mechanism, since IPv6 requires the layer below to fragmentation mechanism, since IPv6 requires the layer below to
support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked
fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU
skipping to change at page 7, line 45 skipping to change at page 7, line 48
On the other hand, there exist technologies also used in the CNN On the other hand, there exist technologies also used in the CNN
space, such as Master Slave / Token Passing (TP) [RFC8163], space, such as Master Slave / Token Passing (TP) [RFC8163],
Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah Narrowband IoT (NB-IoT) [RFC8376] or IEEE 802.11ah
[I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of [I-D.delcarpio-6lo-wlanah], that do not suffer the same degree of
frame size limitations as the technologies mentioned above. The MTU frame size limitations as the technologies mentioned above. The MTU
for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB- for MS/TP is recommended to be 1500 bytes [RFC8163], the MTU in NB-
IoT is 1600 bytes, and the maximum frame payload size for IEEE IoT is 1600 bytes, and the maximum frame payload size for IEEE
802.11ah is 7991 bytes. 802.11ah is 7991 bytes.
While IPv6 is the main IP version used in IP-based IoT environments,
some IoT scenarios use IPv4. In IPv4, the MTU is 576 bytes. In
order to avoid exceeding the IPv4 MTU, the MSS needs to be set to a
value not larger than 536 bytes. Similarly to the recommendations
given above for IPv6, a constrained device using IPv4 may advertise
an MSS not larger than 516 bytes in order to accommodate unrequested
TCP options.
Finally, note that using larger MSS (to a suitable extent) may be Finally, note that using larger MSS (to a suitable extent) may be
beneficial, especially when transferring large payloads, as it beneficial, especially when transferring large payloads, as it
reduces the number of packets (and packet headers) required for a reduces the number of packets (and packet headers) required for a
given payload. given payload.
4.1.2. Explicit Congestion Notification (ECN) 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router
to signal in the IP header of a packet that congestion is arising, to signal in the IP header of a packet that congestion is arising,
for example when a queue size reaches a certain threshold. An ECN- for example when a queue size reaches a certain threshold. An ECN-
skipping to change at page 9, line 22 skipping to change at page 9, line 26
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.
4.2. TCP guidance for single-MSS windows and buffers 4.2. TCP guidance for single-MSS windows and buffers
This section discusses TCP stacks that focus on transferring a single This section discusses TCP stacks that focus on transferring a single
MSS. More general guidance is provided in Section 4.3. MSS. More general guidance is provided in Section 4.3.
4.2.1. Single-MSS stacks - benefits and issues 4.2.1. Single-MSS stacks - benefits and issues
A TCP stack can reduce the RAM requirements by advertising a TCP A TCP stack can reduce the memory requirements by advertising a 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. In that case, both congestion and flow control unacknowledged data. In that case, both congestion and flow control
implementation is quite simple. Such a small receive and send window implementation is quite simple. Such a small receive and send window
may be sufficient for simple message exchanges in the CNN space. may be sufficient for simple message exchanges in the CNN space.
However, only using a window of one MSS can significantly affect However, only using a window of one MSS can significantly affect
performance. A stop-and-wait operation results in low throughput for performance. A stop-and-wait operation results in low throughput for
transfers that exceed the lengths of one MSS, e.g., a firmware transfers that exceed the length of one MSS, e.g., a firmware
download. download. Furthermore, a single-MSS solution relies solely on timer-
based loss recovery, therefore missing the performance gain of Fast
Retransmit and Fast Recovery (which require a larger window size, see
Subsection 4.3.1).
If CoAP is used over TCP with the default setting for NSTART in 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 [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 until a response for the previous message sent to that
destination has been received. This is equivalent to an application- destination has been received. This is equivalent to an application-
layer window size of 1. For this use of CoAP, a maximum TCP window layer window size of 1. For this use of CoAP, a maximum TCP window
of one MSS will be sufficient. of one MSS will be sufficient.
4.2.2. TCP options for single-MSS stacks 4.2.2. TCP options for single-MSS stacks
skipping to change at page 10, line 34 skipping to change at page 10, line 41
A device that advertises a single-MSS receive window should avoid use A device that advertises a single-MSS receive window should avoid use
of Delayed ACKs in order to avoid contributing unnecessary delay (of of Delayed ACKs in order to avoid contributing unnecessary delay (of
up to 500 ms) to the RTT [RFC5681], which limits the throughput and up to 500 ms) to the RTT [RFC5681], which limits the throughput and
can increase the data delivery time. can increase the data delivery time.
A device that can send at most one MSS of data is significantly A device that can send at most one MSS of data is significantly
affected if the receiver uses Delayed ACKs, e.g., if a TCP server or affected if the receiver uses Delayed ACKs, e.g., if a TCP server or
receiver is outside the CNN. One known workaround is to split the receiver is outside the CNN. One known workaround is to split the
data to be sent into two segments of smaller size. A standard data to be sent into two segments of smaller size. A standard
compliant TCP receiver will then immediately acknowledge the second compliant TCP receiver will acknowledge the second MSS of data, which
segment, which can improve throughput. This "split hack" works if can improve throughput. This "split hack" works if the TCP receiver
the TCP receiver uses Delayed ACKs, but the downside is the overhead uses Delayed ACKs, but the downside is the overhead of sending two IP
of sending two IP packets instead of one. packets instead of one.
Similar issues happen when the sender uses the Nagle algorithm. Similar issues happen when the sender uses the Nagle algorithm.
Disabling the algorithm will not have impact if the sender can only Disabling the algorithm will not have impact if the sender can only
handle stop-and-wait operation. handle stop-and-wait operation.
4.2.4. RTO estimation for single-MSS stacks 4.2.4. RTO estimation for single-MSS stacks
The Retransmission Timeout (RTO) estimation is one of the fundamental The Retransmission Timeout (RTO) estimation is one of the fundamental
TCP algorithms. There is a fundamental trade-off: A short, TCP algorithms. There is a fundamental trade-off: A short,
aggressive RTO behavior reduces wait time before retransmissions, but aggressive RTO behavior reduces wait time before retransmissions, but
skipping to change at page 11, line 27 skipping to change at page 11, line 38
4.3. General recommendations for TCP in CNNs 4.3. General recommendations for TCP in CNNs
This section summarizes some widely used techniques to improve TCP, This section summarizes some widely used techniques to improve TCP,
with a focus on their use in CNNs. The TCP extensions discussed here with a focus on their use in CNNs. The TCP extensions discussed here
are useful in a wide range of network scenarios, including CNNs. are useful in a wide range of network scenarios, including CNNs.
This section is not comprehensive. A comprehensive survey of TCP This section is not comprehensive. A comprehensive survey of TCP
extensions is published in [RFC7414]. extensions is published in [RFC7414].
4.3.1. Loss recovery and congestion/flow control 4.3.1. Loss recovery and congestion/flow control
Devices that have enough memory to allow larger TCP window size can Devices that have enough memory to allow a larger (i.e. more than 3
leverage a more efficient loss recovery using Fast Retransmit and MSS of data) TCP window size can leverage a more efficient loss
Fast Recovery [RFC5681], at the expense of slightly greater recovery than the timer-based approach used for smaller TCP window
complexity and TCB size. Assuming that Delayed ACKs are used by the size (see Subsection 3.2.1) by using Fast Retransmit and Fast
receiver, the mentioned algorithms work efficiently for window sizes Recovery [RFC5681], at the expense of slightly greater complexity and
of at least 5 MSS: If in a given TCP transmission of segments TCB size. Assuming that Delayed ACKs are used by the receiver, the
1,2,3,4,5, and 6 the segment 2 gets lost, the sender should get an mentioned algorithms work efficiently for window sizes of at least 5
ACK for segment 1 when 3 arrives and duplicate acknowledgements when MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6
4, 5, and 6 arrive. It will retransmit segment 2 when the third the segment 2 gets lost, the sender should get an ACK for segment 1
duplicate ACK arrives. In order to have segment 2, 3, 4, 5, and 6 when 3 arrives and duplicate acknowledgements when 4, 5, and 6
sent, the window has to be at least five. With an MSS of 1220 byte, arrive. It will retransmit segment 2 when the third duplicate ACK
a buffer of the size of 5 MSS would require 6100 bytes. arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window
has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the
size of 5 MSS would require 6100 bytes.
For bulk data transfers further TCP improvements may also be useful, For bulk data transfers further TCP improvements may also be useful,
such as limited transmit [RFC3042]. such as limited transmit [RFC3042].
4.3.1.1. Selective Acknowledgments (SACK) 4.3.1.1. Selective Acknowledgments (SACK)
If a device with less severe memory and processing constraints can If a device with less severe memory and processing constraints can
afford advertising a TCP window size of several MSS, it makes sense afford advertising a TCP window size of several MSS, it makes sense
to support the SACK option to improve performance. SACK allows a to support the SACK option to improve performance. SACK allows a
data receiver to inform the data sender of non-contiguous data blocks data receiver to inform the data sender of non-contiguous data blocks
skipping to change at page 13, line 14 skipping to change at page 13, line 23
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. Number of concurrent connections 5.2. Number of concurrent connections
TCP endpoints with a small amount of RAM may only support a small TCP endpoints with a small amount of memory may only support a small
number of connections. Each TCP connection requires storing a number number of connections. Each TCP connection requires storing a number
of variables in the Transmission Control Block (TCB). Depending on of variables in the Transmission Control Block (TCB). Depending on
the internal TCP implementation, each connection may result in the internal TCP implementation, each connection may result in
further memory overhead, and connections may compete for scarce further memory overhead, and connections may compete for scarce
resources (e.g. further memory overhead for send and receive buffers, resources (e.g. further memory overhead for send and receive buffers,
etc). etc).
A careful application design may try to keep the number of concurrent A careful application design may try to keep the number of concurrent
connections as small as possible. A client can for instance limit connections as small as possible. A client can for instance limit
the number of simultaneous open connections that it maintains to a the number of simultaneous open connections that it maintains to a
skipping to change at page 13, line 45 skipping to change at page 14, line 6
particular importance in Constrained-Node Networks. particular importance in Constrained-Node Networks.
5.3. TCP connection lifetime 5.3. TCP connection lifetime
In order to minimize message overhead, it makes sense to keep a TCP 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 connection open as long as the two TCP endpoints have more data to
send. If applications exchange data rather infrequently, i.e., if send. If applications exchange data rather infrequently, i.e., if
TCP connections would stay idle for a long time, the idle time can TCP connections would stay idle for a long time, the idle time can
result in problems. For instance, certain middleboxes such as result in problems. For instance, certain middleboxes such as
firewalls or NAT devices are known to delete state records after an firewalls or NAT devices are known to delete state records after an
inactivity interval typically in the order of a few minutes inactivity interval. RFC 5382 specifies a minimum value for such
[RFC6092]. The timeout duration used by a middlebox implementation interval of 124 minutes. A mean TCP NAT binding timeout of 386
may not be known to the TCP endpoints. minutes has been reported, while in some cases, inactivity timeouts
are in the order of a few minutes [HomeGateway]. The timeout
duration used by a middlebox implementation may not be known to the
TCP endpoints.
In CNNs, such middleboxes may e.g. be present at the boundary between In CNNs, such middleboxes may e.g. be present at the boundary between
the CNN and other networks. If the middlebox can be optimized for the CNN and other networks. If the middlebox can be optimized for
CNN use cases, it makes sense to increase the initial value for CNN use cases, it makes sense to increase the initial value for
filter state inactivity timers to avoid problems with idle filter state inactivity timers to avoid problems with idle
connections. Apart from that, this problem can be dealt with by connections. Apart from that, this problem can be dealt with by
different connection handling strategies, each having pros and cons. different connection handling strategies, each having pros and cons.
One approach for infrequent data transfer is to use short-lived TCP One approach for infrequent data transfer is to use short-lived TCP
connections. Instead of trying to maintain a TCP connection for long connections. Instead of trying to maintain a TCP connection for long
skipping to change at page 14, line 40 skipping to change at page 15, line 7
handshake, as long as the cookie can be reused in subsequent handshake, as long as the cookie can be reused in subsequent
connections. However, as stated in RFC 7413, TFO deviates from the connections. However, as stated in RFC 7413, TFO deviates from the
standard TCP semantics, since the data in the SYN could be replayed standard TCP semantics, since the data in the SYN could be replayed
to an application in some rare circumstances. Applications should to an application in some rare circumstances. Applications should
not use TFO unless they can tolerate this issue, e.g., by using not use TFO unless they can tolerate this issue, e.g., by using
Transport Layer Security (TLS) [RFC7413]. A comprehensive discussion Transport Layer Security (TLS) [RFC7413]. A comprehensive discussion
on TFO can be found at RFC 7413. on TFO can be found at RFC 7413.
Another approach is to use long-lived TCP connections with Another approach is to use long-lived TCP connections with
application-layer heartbeat messages. Various application protocols application-layer heartbeat messages. Various application protocols
support such heartbeat messages. Periodic heartbeats requires support such heartbeat messages (e.g. CoAP over TCP [RFC8323]).
transmission of packets, but they also allow aliveness checks at Periodic application-layer heartbeats can prevent early filter state
application level. In addition, they can prevent early filter state record deletion in middleboxes. If the TCP binding timeout for a
record deletion in middleboxes. In general, it makes sense realize middlebox to be traversed by a given connection is known, middlebox
aliveness checks at the highest protocol layer possible that is filter state deletion will be avoided if the heartbeat period is
meaningful to the application, in order to maximize the depth of the lower than the middlebox TCP binding timeout. Otherwise, the
aliveness check. In addition, timely detection of a dead peer may implementer needs to take into account that middlebox TCP binding
allow savings in terms of TCB memory use. timeouts fall in a wide range of possible values [HomeGateway]. One
specific advantage of Heartbeat messages is that they also allow
aliveness checks at the application level. In general, it makes
sense to 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. In addition, timely detection of a
dead peer may allow savings in terms of TCB memory use. However, the
transmission of heartbeat messages consumes resources. This aspect
needs to be assessed carefully, considering the characteristics of
each specific CNN.
A TCP implementation may also be able to send "keep-alive" segments A TCP implementation may also be able to send "keep-alive" segments
to test a TCP connection. According to [RFC1122], "keep-alives" are to test a TCP connection. According to [RFC1122], "keep-alives" are
an optional TCP mechanism that is turned off by default, i.e., an an optional TCP mechanism that is turned off by default, i.e., an
application must explicitly enable it for a TCP connection. The application must explicitly enable it for a TCP connection. The
interval between "keep-alive" messages must be configurable and it interval between "keep-alive" messages must be configurable and it
must default to no less than two hours. With this large timeout, TCP 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 keep-alive messages might not always be useful to avoid deletion of
state records in middleboxes such as firewalls. However, sending TCP filter state records in some middleboxes. However, sending TCP keep-
keep-alive probes more frequently risks draining power on energy- alive probes more frequently risks draining power on energy-
constrained devices. constrained devices.
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. One There are also TCP options which can improve TCP security. One
example is the TCP Authentication Option (TCP-AO) [RFC5925]. example is the TCP Authentication Option (TCP-AO) [RFC5925].
skipping to change at page 21, line 35 skipping to change at page 21, line 35
o Addressed comments by Ilpo Jarvinen throughout the whole document o Addressed comments by Ilpo Jarvinen throughout the whole document
o Improved the RIOT section in the Annex, based on feedback from o Improved the RIOT section in the Annex, based on feedback from
Emmanuel Baccelli Emmanuel Baccelli
9.6. Changes between -05 and -06 9.6. Changes between -05 and -06
o Incorporated suggestions by Stuart Cheshire o Incorporated suggestions by Stuart Cheshire
9.7. Changes between -06 and -07
o Addressed comments by Gorry Fairhurst
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 23, line 25 skipping to change at page 23, line 30
[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.
[GNRC] M. Lenders et al., "Connecting the World of Embedded [GNRC] M. Lenders et al., "Connecting the World of Embedded
Mobiles: The RIOTApproach to Ubiquitous Networking for the Mobiles: The RIOTApproach to Ubiquitous Networking for the
IoT", 2018. IoT", 2018.
[HomeGateway]
Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An Experimental Study of Home
Gateway Characteristics", Proceedings of the 10th ACM
SIGCOMM conference on Internet measurement 2010.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-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-03 (work in progress), February 2018. core-cocoa-03 (work in progress), February 2018.
 End of changes. 28 change blocks. 
58 lines changed or deleted 95 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/