draft-ietf-lwig-tcp-constrained-node-networks-04.txt   draft-ietf-lwig-tcp-constrained-node-networks-05.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: April 11, 2019 University of Cambridge Expires: September 10, 2019 University of Cambridge
M. Scharf M. Scharf
Hochschule Esslingen Hochschule Esslingen
October 8, 2018 March 9, 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-04 draft-ietf-lwig-tcp-constrained-node-networks-05
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 April 11, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7 4.1.1. Maximum Segment Size (MSS) . . . . . . . . . . . . . 7
4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 7 4.1.2. Explicit Congestion Notification (ECN) . . . . . . . 7
4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8 4.1.3. Explicit loss notifications . . . . . . . . . . . . . 8
4.2. TCP guidance for small windows and buffers . . . . . . . 8 4.2. TCP guidance for single-MSS windows and buffers . . . . . 9
4.2.1. Single-MSS stacks - benefits and issues . . . . . . . 8 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 . . . . 9 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 . . . . . . . . 10
4.3. General recommendations for TCP in CNNs . . . . . . . . . 10 4.3. General recommendations for TCP in CNNs . . . . . . . . . 11
4.3.1. Error recovery and congestion/flow control . . . . . 10 4.3.1. Loss recovery and congestion/flow control . . . . . . 11
4.3.2. Selective Acknowledgments (SACK) . . . . . . . . . . 11 4.3.1.1. Selective Acknowledgments (SACK) . . . . . . . . 11
4.3.3. Delayed Acknowledgments . . . . . . . . . . . . . . . 11 4.3.2. Delayed Acknowledgments . . . . . . . . . . . . . . . 12
5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 12 5. TCP usage recommendations in CNNs . . . . . . . . . . . . . . 12
5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12 5.1. TCP connection initiation . . . . . . . . . . . . . . . . 12
5.2. Number of concurrent connections . . . . . . . . . . . . 12 5.2. Number of concurrent connections . . . . . . . . . . . . 12
5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 12 5.3. TCP connection lifetime . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Annex. TCP implementations for constrained devices . . . . . 15 8. Annex. TCP implementations for constrained devices . . . . . 16
8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.4. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 16 8.5. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.6. uC/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Annex. Changes compared to previous versions . . . . . . . . 18 9. Annex. Changes compared to previous versions . . . . . . . . 20
9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 19 9.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 20
9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 19 9.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 20
9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 19 9.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 20
9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 20 9.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 21
9.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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
stem from CNNs, the IETF has produced a suite of new protocols stem from CNNs, the IETF has produced a suite of new protocols
specifically designed for such environments (see e.g. specifically designed for such environments (see e.g. [RFC8352]).
[I-D.ietf-lwig-energy-efficient]). New IETF protocol stack New IETF protocol stack components include the IPv6 over Low-power
components include the IPv6 over Low-power Wireless Personal Area Wireless Personal Area Networks (6LoWPAN) adaptation layer, the IPv6
Networks (6LoWPAN) adaptation layer, the IPv6 Routing Protocol for Routing Protocol for Low-power and lossy networks (RPL) routing
Low-power and lossy networks (RPL) routing protocol, and the protocol, and the Constrained Application Protocol (CoAP).
Constrained Application Protocol (CoAP).
As of the writing, the main current transport layer protocols in IP- As of the writing, the main current transport layer protocols in IP-
based IoT scenarios are UDP and TCP. However, TCP has been based IoT scenarios are UDP and TCP. However, TCP has been
criticized (often, unfairly) as a protocol for the IoT. In fact, criticized (often, unfairly) as a protocol for the IoT. In fact,
some TCP features are not optimal for IoT scenarios, such as some TCP features are not optimal for IoT scenarios, such as
relatively long header size, unsuitability for multicast, and always- relatively long header size, unsuitability for multicast, and always-
confirmed data delivery. However, many typical claims on TCP confirmed data delivery. However, many typical claims on TCP
unsuitability for IoT (e.g. a high complexity, connection-oriented unsuitability for IoT (e.g. a high complexity, connection-oriented
approach incompatibility with radio duty-cycling, and spurious approach incompatibility with radio duty-cycling, and spurious
congestion control activation in wireless links) are not valid, can congestion control activation in wireless links) are not valid, can
skipping to change at page 4, line 44 skipping to change at page 4, line 44
3.1. Network and link properties 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 [RFC8352], as well as
[I-D.ietf-lwig-energy-efficient], as well as minimization of the minimization of the number of messages transmitted/received (and
number of messages transmitted/received (and their size). their size).
[RFC7228] lists typical network constraints in CNN, including low [RFC7228] lists typical network constraints in CNN, including low
achievable bitrate/throughput, high packet loss and high variability achievable bitrate/throughput, high packet loss and high variability
of packet loss, highly asymmetric link characteristics, severe of packet loss, highly asymmetric link characteristics, severe
penalties for using larger packets, limits on reachability over time, penalties for using larger packets, limits on reachability over time,
etc. CNN may use wireless or wired technologies (e.g., Power Line etc. CNN may use wireless or wired technologies (e.g., Power Line
Communication), and the transmission rates are typically low (e.g. Communication), and the transmission rates are typically low (e.g.
below 1 Mbps). below 1 Mbps).
For use of TCP, one challenge is that not all technologies in CNN may For use of TCP, one challenge is that not all technologies in CNN may
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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)
Some link layer technologies in the CNN space are characterized by a For the sake of lightweight implementation and operation, unless
short data unit payload size, e.g. up to a few tens or hundreds of applications require handling large data units (i.e. leading to an
bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 IPv6 datagram size greater than 1280 bytes), it may be desirable to
bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE limit the MTU to 1280 bytes in order to avoid the need to support
802.15.4 networks. The adaptation layer includes a fragmentation Path MTU Discovery [RFC8201].
mechanism, since IPv6 requires the layer below to support an MTU of
1280 bytes [RFC2460], while IEEE 802.15.4 lacked fragmentation An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is
[RFC4944]. Other technologies, such as Bluetooth LE [RFC7668], ITU-T assumed.)
G.9959 [RFC7428] or DECT-ULE [RFC8105], also use 6LoWPAN-based
adaptation layers in order to enable IPv6 support. These Note that setting the MTU to 1280 bytes is possible for link layer
technologies do support link layer fragmentation. By exploiting this technologies in the CNN space, even if some of them are characterized
functionality, the adaptation layers that enable IPv6 over such by a short data unit payload size, e.g. up to a few tens or hundreds
technologies also define an MTU of 1280 bytes. 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
IEEE 802.15.4 networks. The adaptation layer includes a
fragmentation mechanism, since IPv6 requires the layer below to
support an MTU of 1280 bytes [RFC2460], while IEEE 802.15.4 lacked
fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU
of 1280 bytes [RFC4944]. Other technologies, such as Bluetooth LE
[RFC7668], ITU-T G.9959 [RFC7428] or DECT-ULE [RFC8105], also use
6LoWPAN-based adaptation layers in order to enable IPv6 support.
These technologies do support link layer fragmentation. By
exploiting this functionality, the adaptation layers that enable IPv6
over such technologies also define an MTU of 1280 bytes.
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) [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.
For the sake of lightweight implementation and operation, unless Finally, note that using larger MSS (to a suitable extent) may be
applications require handling large data units (i.e. leading to an beneficial, especially when transferring large payloads, as it
IPv6 datagram size greater than 1280 bytes), it may be desirable to reduces the number of packets (and packet headers) required for a
limit the MTU to 1280 bytes in order to avoid the need to support given payload.
Path MTU Discovery [RFC1981].
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
assumed.)
4.1.2. Explicit Congestion Notification (ECN) 4.1.2. Explicit Congestion Notification (ECN)
Explicit Congestion Notification (ECN) [RFC3168] has a number of Explicit Congestion Notification (ECN) [RFC3168] ECN allows a router
benefits that are relevant for CNNs. ECN allows a router to signal to signal in the IP header of a packet that congestion is arising,
in the IP header of a packet that congestion is arising, for example for example when a queue size reaches a certain threshold. An ECN-
when a queue size reaches a certain threshold. An ECN-enabled TCP enabled TCP receiver will echo back the congestion signal to the TCP
receiver will echo back the congestion signal to the TCP sender by sender by setting a flag in its next TCP ACK. The sender triggers
setting a flag in its next TCP ACK. The sender triggers congestion congestion control measures as if a packet loss had happened.
control measures as if a packet loss had happened. ECN can be
incrementally deployed in the Internet. Guidance on configuration
and usage of ECN is provided in [RFC7567]. The document [RFC8087]
outlines the principal gains in terms of increased throughput,
reduced delay, and other benefits when ECN is used over a network
path that includes equipment that supports Congestion Experienced
(CE) marking.
ECN can reduce packet losses since congestion control measures can be The document [RFC8087] outlines the principal gains in terms of
applied earlier [RFC2884]. Less lost packets implies that the number increased throughput, reduced delay, and other benefits when ECN is
of retransmitted segments decreases, which is particularly beneficial used over a network path that includes equipment that supports
in CNNs, where energy and bandwidth resources are typically limited. Congestion Experienced (CE) marking. In the context of CNNs, a
Also, it makes sense to try to avoid packet drops for transactional remarkable feature of ECN is that congestion can be signalled without
workloads with small data sizes, which are typical for CNNs. In such incurring packet drops (which will lead to retransmissions and
traffic patterns, it is more difficult to detect packet loss without consumption of limited resources such as energy and bandwitdh).
retransmission timeouts (e.g., as there may be no three duplicate
ACKs). Any retransmission timeout slows down the data transfer ECN can further reduce packet losses since congestion control
significantly. When the congestion window of a TCP sender has a size measures can be applied earlier [RFC2884]. Less lost packets implies
of one segment, the TCP sender resets the retransmit timer, and the that the number of retransmitted segments decreases, which is
sender will only be able to send a new packet when the retransmit particularly beneficial in CNNs, where energy and bandwidth resources
are typically limited. Also, it makes sense to try to avoid packet
drops for transactional workloads with small data sizes, which are
typical for CNNs. In such traffic patterns, it is more difficult to
detect packet loss without retransmission timeouts (e.g., as there
may be no three duplicate ACKs). Any retransmission timeout slows
down the data transfer significantly. In addition, if the
constrained device uses power saving techniques, a retransmission
timeout will incur a wake-up action, in contrast to ACK clock-
triggered sending. When the congestion window of a TCP sender has a
size of one segment, the TCP sender resets the retransmit timer, and
the sender will only be able to send a new packet when the retransmit
timer expires [RFC3168]. Effectively, the TCP sender reduces at that timer expires [RFC3168]. Effectively, the TCP sender reduces at that
moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 moment its sending rate from 1 segment per Round Trip Time (RTT) to 1
segment per RTO, which can result in a very low throughput. In segment per RTO, which can result in a very low throughput. In
addition to better throughput, ECN can also help reducing latency and addition to better throughput, ECN can also help reducing latency and
jitter. jitter.
Given the benefits, more and more TCP stacks in the Internet support ECN can be incrementally deployed in the Internet. Guidance on
ECN, and it specifically makes sense to leverage ECN in controlled configuration and usage of ECN is provided in [RFC7567]. Given the
environments such as CNNs. benefits, more and more TCP stacks in the Internet support ECN, and
it specifically makes sense to leverage ECN in controlled
environments such as CNNs. Note, however, that supporting ECN
increases implementation complexity.
4.1.3. Explicit loss notifications 4.1.3. 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.
4.2. TCP guidance for small 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 RAM 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
skipping to change at page 9, line 26 skipping to change at page 9, line 38
4.2.2. TCP options for single-MSS stacks 4.2.2. TCP options for single-MSS stacks
A TCP implementation needs to support options 0, 1 and 2 [RFC0793]. A TCP implementation needs to support options 0, 1 and 2 [RFC0793].
These options are sufficient for interoperability with a standard- These options are sufficient for interoperability with a standard-
compliant TCP endpoint, albeit many TCP stacks support additional compliant TCP endpoint, albeit many TCP stacks support additional
options and can negotiate their use. options and can negotiate their use.
A TCP implementation for a constrained device that uses a single-MSS A TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size may not benefit from supporting TCP receive or transmit window size may not benefit from supporting
the following TCP options: Window scale [RFC1323], TCP Timestamps the following TCP options: Window scale [RFC7323], TCP Timestamps
[RFC1323], Selective Acknowledgments (SACK) and SACK-Permitted [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted
[RFC2018]. Also other TCP options may not be required on a [RFC2018]. Also other TCP options may not be required on a
constrained device with a very lightweight implementation. constrained device with a very lightweight implementation. With
regard to the Window scale option, note that it is only useful if a
window size greater than 64 kB is needed.
One potentially relevant TCP option in the context of CNNs is TCP One potentially relevant TCP option in the context of CNNs is TCP
Fast Open (TFO) [RFC7413]. As described in Section 5.3, TFO can be Fast Open (TFO) [RFC7413]. As described in Section 5.3, TFO can be
used to address the problem of traversing middleboxes that perform used to address the problem of traversing middleboxes that perform
early filter state record deletion. early filter state record deletion.
4.2.3. Delayed Acknowledgments for single-MSS stacks 4.2.3. Delayed Acknowledgments for single-MSS stacks
TCP Delayed Acknowledgments are meant to reduce the number of TCP Delayed Acknowledgments are meant to reduce the number of ACKs
transferred bytes within a TCP connection, but they may increase the sent within a TCP connection, thus reducing network overhead, but
time until a sender may receive an ACK. There can be interactions they may increase the time until a sender may receive an ACK. In
with stacks that use very small windows. general, usefulness of Delayed ACKs depends heavily on the usage
scenario. There can be interactions with stacks that use single-MSS
windows.
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 then immediately acknowledge the second
segment, which can improve throughput. This "split hack" works if segment, which can improve throughput. This "split hack" works if
the TCP receiver uses Delayed Acks, but the downside is the overhead the TCP receiver uses Delayed ACKs, but the downside is the overhead
of sending two IP packets instead of one. of sending two IP packets instead of one.
Similar issues happen when the sender uses the Nagle algorithm.
Disabling the algorithm will not have impact if the sender can only
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
it also increases the probability of spurious timeouts. The latter it also increases the probability of spurious timeouts. The latter
lead to unnecessary waste of potentially scarce resources in CNNs lead to unnecessary waste of potentially scarce resources in CNNs
such as energy and bandwidth. In contrast, a conservative timeout such as energy and bandwidth. In contrast, a conservative timeout
can result in long error recovery times and thus needlessly delay can result in long error recovery times and thus needlessly delay
data delivery. data delivery.
[RFC6298] describes the standard TCP RTO algorithm. If a TCP sender [RFC6298] describes the standard TCP RTO algorithm. If a TCP sender
uses very small window size and cannot use Fast Retransmit/Fast uses very small window size, and it cannot use Fast Retransmit/Fast
Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a Recovery or SACK, the Retransmission Timeout (RTO) algorithm has a
larger impact on performance than for a more powerful TCP stack. In larger impact on performance than for a more powerful TCP stack. In
that case, RTO algorithm tuning may be considered, although careful that case, RTO algorithm tuning may be considered, although careful
assessment of possible drawbacks is recommended. assessment of possible drawbacks is recommended
[I-D.ietf-tcpm-rto-consider].
As an example, an adaptive RTO algorithm for CoAP over UDP has been As an example, an adaptive RTO algorithm for CoAP over UDP has been
defined [I-D.ietf-core-cocoa] that has been found to perform well in defined [I-D.ietf-core-cocoa] that has been found to perform well in
CNN scenarios [Commag]. CNN scenarios [Commag].
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. Error 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 larger TCP window size can
leverage a more efficient error recovery using Fast Retransmit and leverage a more efficient loss recovery using Fast Retransmit and
Fast Recovery [RFC5681]. These algorithms work efficiently for Fast Recovery [RFC5681], at the expense of slightly greater
window sizes of at least 5 MSS: If in a given TCP transmission of complexity and TCB size. Assuming that Delayed ACKs are used by the
segments 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should receiver, the mentioned algorithms work efficiently for window sizes
get an acknowledgement for segment 1 when 3 arrives and duplicate of at least 5 MSS: If in a given TCP transmission of segments
acknowledgements when 4, 5, and 6 arrive. It will retransmit segment 1,2,3,4,5, and 6 the segment 2 gets lost, the sender should get an
2 when the third duplicate ack arrives. In order to have segment 2, ACK for segment 1 when 3 arrives and duplicate acknowledgements when
3, 4, 5, and 6 sent, the window has to be at least five. With an MSS 4, 5, and 6 arrive. It will retransmit segment 2 when the third
of 1220 byte, a buffer of the size of 5 MSS would require 6100 byte. 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 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.2. 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 MSSs, 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
received, thus a sender (having previously sent the SACK-Permitted received, thus a sender (having previously sent the SACK-Permitted
option) can avoid performing unnecessary retransmissions, saving option) can avoid performing unnecessary retransmissions, saving
energy and bandwidth, as well as reducing latency. SACK is energy and bandwidth, as well as reducing latency. SACK is
particularly useful for bulk data transfers. The receiver supporting particularly useful for bulk data transfers. The receiver supporting
SACK will need to manage the reception of possible out-of-order SACK will need to manage the reception of possible out-of-order
received segments, requiring sufficient buffer space. SACK adds received segments, requiring sufficient buffer space. SACK adds
8*n+2 bytes to the TCP header, where n denotes the number of data 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 blocks received, up to 4 blocks. For a low number of out-of-order
segments, the header overhead penalty of SACK is compensated by segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions. avoiding unnecessary retransmissions.
4.3.3. Delayed Acknowledgments 4.3.2. Delayed Acknowledgments
For certain traffic patterns, Delayed Acknowledgements may have a For certain traffic patterns, Delayed ACKs may have a detrimental
detrimental effect, as already noted in Section 4.2.3. Advanced TCP effect, as already noted in Section 4.2.3. Advanced TCP stacks may
stacks may use heuristics to determine the maximum delay for an ACK. use heuristics to determine the maximum delay for an ACK. For CNNs,
For CNNs, the recommendation depends on the expected communication the recommendation depends on the expected communication patterns.
patterns.
If a stack is able to deal with more than one MSS of data, it may If a stack is able to deal with more than one MSS of data, it may
make sense to use a small timeout or disable delayed ACKs when 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 traffic over a CNN is expected to mostly be small messages with a
size typically below one MSS. For request-response traffic between a size typically below one MSS. For request-response traffic between a
constrained device and a peer (e.g. backend infrastructure) that uses constrained device and a peer (e.g. backend infrastructure) that uses
delayed ACKs, the maximum ACK rate of the peer will be typically of delayed ACKs, the maximum ACK rate of the peer will be typically of
one ACK every 200 ms (or even lower). If in such conditions the peer one ACK every 200 ms (or even lower). If in such conditions the peer
device is administered by the same entity managing the constrained device is administered by the same entity managing the constrained
device, it is recommended to disable delayed ACKs at the peer side. device, it is recommended to disable delayed ACKs at the peer side.
In contrast, delayed ACKs allow to reduce the number of ACKs in bulk In contrast, Delayed ACKs allow to reduce the number of ACKs in bulk
transfer type of traffic, e.g. for firmware/software updates or for transfer type of traffic, e.g. for firmware/software updates or for
transferring larger data units containing a batch of sensor readings. transferring larger data units containing a batch of sensor readings.
Note that, in many scenarios, the peer that a constrained device Note that, in many scenarios, the peer that a constrained device
communicates with will be a general purpose system that communicates communicates with will be a general purpose system that communicates
with both constrained and unconstrained devices. Since delayed ACKs with both constrained and unconstrained devices. Since delayed ACKs
are often configured through system-wide parameters, delayed ACKs are often configured through system-wide parameters, delayed ACKs
behavior at the peer will be the same regardless of the nature of the behavior at the peer will be the same regardless of the nature of the
endpoints it talks to. Such a peer will typically have delayed ACKs endpoints it talks to. Such a peer will typically have delayed ACKs
enabled. enabled.
skipping to change at page 12, line 26 skipping to change at page 13, line 4
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 RAM 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 overhead, and they may compete for scarce resources. further memory overhead, and connections may compete for scarce
resources (e.g. further memory overhead for send and receive buffers,
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
given server. Multiple connections could for instance be used to given server. Multiple connections could for instance be used to
avoid the "head-of-line blocking" problem in an application transfer. avoid the "head-of-line blocking" problem in an application transfer.
However, in addition to comsuming resources, using multiple However, in addition to comsuming resources, using multiple
connections can also cause undesirable side effects in congested connections can also cause undesirable side effects in congested
networks. As example, the HTTP/1.1 specification encourages clients networks. For example, the HTTP/1.1 specification encourages clients
to be conservative when opening multiple connections [RFC7230]. to be conservative when opening multiple connections [RFC7230].
Furthermore, each new connection will start with a 3-way handshake,
therefore increasing message overhead.
Being conservative when opening multiple TCP connections is of Being conservative when opening multiple TCP connections is of
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 typically in the order of a few minutes
[RFC6092]. The timeout duration used by a middlebox implementation [RFC6092]. The timeout duration used by a middlebox implementation
may not be known to the TCP endpoints. may not be known to the TCP endpoints.
In CCNs, 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 CCN and other networks. If the middlebox can be optimized for the CNN and other networks. If the middlebox can be optimized for
CCN 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
time, possibly short-lived connections can be opened between two time, possibly short-lived connections can be opened between two
endpoints, which are closed if no more data needs to be exchanged. endpoints, which are closed if no more data needs to be exchanged.
For use cases that can cope with the additional messages and the For use cases that can cope with the additional messages and the
latency resulting from starting new connections, it is recommended to latency resulting from starting new connections, it is recommended to
use a sequence of short-lived connections, instead of maintaining a use a sequence of short-lived connections, instead of maintaining a
single long-lived connection. single long-lived connection.
This overhead could be reduced by TCP Fast Open (TFO) [RFC7413], The message and latency overhead that stems from using a sequence of
which is an experimental TCP extension. TFO allows data to be short-lived connections could be reduced by TCP Fast Open (TFO)
carried in SYN (and SYN-ACK) segments, and to be consumed immediately [RFC7413], which is an experimental TCP extension, at the expense of
by the receceiving endpoint. This reduces the overhead compared to increased implementation complexity and increased TCP Control Block
the traditional three-way handshake to establish a TCP connection. (TCB) size. TFO allows data to be carried in SYN (and SYN-ACK)
For security reasons, the connection initiator has to request a TFO segments, and to be consumed immediately by the receiving endpoint.
This reduces the message and latency overhead compared to the
traditional three-way handshake to establish a TCP connection. For
security reasons, the connection initiator has to request a TFO
cookie from the other endpoint. The cookie, with a size of 4 or 16 cookie from the other endpoint. The cookie, with a size of 4 or 16
bytes, is then included in SYN packets of subsequent connections. bytes, is then included in SYN packets of subsequent connections.
The cookie needs to be refreshed (and obtained by the client) after a The cookie needs to be refreshed (and obtained by the client) after a
certain amount of time. Nevertheless, TFO is more efficient than certain amount of time. Nevertheless, TFO is more efficient than
frequently opening new TCP connections with the traditional three-way frequently opening new TCP connections with the traditional three-way
handshake, as long as the cookie can be reused in subsequent handshake, as long as the cookie can be reused in subsequent
connections. connections. However, as stated in RFC 7413, TFO deviates from the
standard TCP semantics, since the data in the SYN could be replayed
to an application in some rare circumstances. Applications should
not use TFO unless they can tolerate this issue, e.g., by using
Transport Layer Security (TLS) [RFC7413]. A comprehensive discussion
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. Periodic heartbeats requires
transmission of packets, but they also allow aliveness checks at transmission of packets, but they also allow aliveness checks at
application level. In addition, they can prevent early filter state application level. In addition, they can prevent early filter state
record deletion in middleboxes. In general, it makes sense realize record deletion in middleboxes. In general, it makes sense realize
aliveness checks at the highest protocol layer possible that is aliveness checks at the highest protocol layer possible that is
meaningful to the application, in order to maximize the depth of the meaningful to the application, in order to maximize the depth of the
aliveness check. aliveness check. In addition, timely detection of a dead peer may
allow savings in terms of TCB memory use.
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 are not very useful to avoid deletion of filter
state records in middleboxes such as firewalls. state records in middleboxes such as firewalls. However, sending TCP
keep-alive probes more frequently risks draining power on energy-
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. Examples There are also TCP options which can improve TCP security. One
include the TCP MD5 signature option [RFC2385] and the TCP example is the TCP Authentication Option (TCP-AO) [RFC5925].
Authentication Option (TCP-AO) [RFC5925]. However, both options add However, this option adds overhead and complexity. TCP-AO typically
overhead and complexity. The TCP MD5 signature option adds 18 bytes 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 For the mechanisms discussed in this document, the corresponding
considerations apply. For instance, if TFO is used, the security considerations apply. For instance, if TFO is used, the security
considerations of [RFC7413] apply. considerations of [RFC7413] apply.
Constrained devices are expected to support smaller TCP window sizes Constrained devices are expected to support smaller TCP window sizes
than less limited devices. In such conditions, segment than less limited devices. In such conditions, segment
retransmission triggered by RTO expiration is expected to be retransmission triggered by RTO expiration is expected to be
relatively frequent, due to lack of (enough) duplicate ACKs, relatively frequent, due to lack of (enough) duplicate ACKs,
especially when a constrained device uses a single-MSS window size. especially when a constrained device uses a single-MSS window size.
skipping to change at page 14, line 42 skipping to change at page 15, line 40
be performed by Internet-connected devices, including constrained be performed by Internet-connected devices, including constrained
devices in the same CNN as the victim, as well as remote ones. devices in the same CNN as the victim, as well as remote ones.
Mitigation techniques include RTO randomization and attack blocking Mitigation techniques include RTO randomization and attack blocking
by routers able to detect shrew attacks based on their traffic by routers able to detect shrew attacks based on their traffic
pattern. pattern.
7. Acknowledgments 7. 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 grants CAS15/00336 and and CAS18/00170, and by European
Fund (ERDF) and the Spanish Government through project Regional Development Fund (ERDF) and the Spanish Government through
TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to this project TEC2016-79988-P, AEI/FEDER, UE. Part of his contribution to
work has been carried out during his stay as a visiting scholar at this work has been carried out during his stays as a visiting scholar
the Computer Laboratory of the University of Cambridge. at 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, Ari Keranen, Abhijan Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keranen, Abhijan
Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred
Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, and Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes
Hannes Tschofenig. Simon Brummer provided details, and kindly Tschofenig, David Black, Yoshifumi Nishida, Ilpo Jarvinen and
Emmanuel Baccelli. Simon Brummer provided details, and kindly
performed RAM and ROM usage measurements, on the RIOT TCP performed RAM and ROM usage measurements, on the RIOT TCP
implementation. Xavi Vilajosana provided details on the OpenWSN TCP implementation. Xavi Vilajosana provided details on the OpenWSN TCP
implementation. Rahul Jadhav provided details on the uIP TCP implementation. Rahul Jadhav kindly performed code size measurements
implementation. on the Contiki-NG and lwIP 2.1.2 TCP implementations. He also
provided details on the uIP TCP implementation.
8. Annex. TCP implementations for constrained devices 8. 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. The survey is limited to open source stacks constrained devices. The survey is limited to open source stacks
with small footprint. It is not meant to be all-encompassing. For with small footprint. It is not meant to be all-encompassing. For
more powerful embedded systems (e.g., with 32-bit processors), there more powerful embedded systems (e.g., with 32-bit processors), there
are further stacks that comprehensively implement TCP. On the other are further stacks that comprehensively implement TCP. On the other
hand, please be aware that this Annex is based on information hand, please be aware that this Annex is based on information
available as of the writing. available as of the writing.
8.1. uIP 8.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,
which pioneered TCP/IP implementations for constrained devices. uIP which pioneered TCP/IP implementations for constrained devices. uIP
has been deployed with Contiki and the Arduino Ethernet shield. A has been deployed with Contiki and the Arduino Ethernet shield. A
code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP) 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 uses same buffer both incoming and outgoing traffic, with has a uIP uses the same global buffer for both incoming and outgoing
size of a single packet. In case of a retransmission, an application traffic, which has a size of a single packet. In case of a
must be able to reproduce the same user data that had been retransmission, an application must be able to reproduce the same
transmitted. user data that had been transmitted. Multiple connections are
supported, but need to share the global buffer.
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.2.3) to avoid Contiki uses the "split hack" technique (see Section 4.2.3) to avoid
delayed ACKs for senders using a single MSS. Delayed ACKs for senders using a single segment.
The code size of the TCP implementation in Contiki-NG has been
measured to be of 3.2 kB on CC2538DK, cross-compiling on Linux.
8.2. lwIP 8.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
implemented mechanisms comprise slow start, congestion avoidance, implemented mechanisms comprise slow start, congestion avoidance,
fast retransmit and fast recovery. SACK and Window Scale have been fast retransmit and fast recovery. SACK and Window Scale support has
recently added to lwIP. been recently added to lwIP.
8.3. RIOT 8.3. RIOT
The RIOT TCP implementation (called GNRC TCP) has been designed for The RIOT TCP implementation (called GNRC TCP) has been designed for
Class 1 devices [RFC 7228]. The main target platforms are 8- and Class 1 devices [RFC 7228]. The main target platforms are 8- and
16-bit microcontrollers. GNRC TCP offers a similar function set as 16-bit microcontrollers, with 32-bit platforms also supported. GNRC
uIP, but it provides and maintains an independent receive buffer for TCP offers a similar function set as uIP, but it provides and
each connection. In contrast to uIP, retransmission is also handled maintains an independent receive buffer for each connection. In
by GNRC TCP. GNRC TCP uses a single-MSS window size, which contrast to uIP, retransmission is also handled by GNRC TCP. GNRC
simplifies the implementation. The application programmer does not TCP uses a single-MSS window size, which simplifies the
need to know anything about the TCP internals, therefore GNRC TCP can implementation. The application programmer does not need to know
be seen as a user-friendly uIP TCP implementation. anything about the TCP internals, therefore GNRC TCP can be seen as a
user-friendly uIP TCP implementation.
The MSS is set on connections establishment and cannot be changed The MSS is set on connections establishment and cannot be changed
during connection lifetime. GNRC TCP allows multiple connections in during connection lifetime. GNRC TCP allows multiple connections in
parallel, but each TCB must be allocated somewhere in the system. By parallel, but each TCB must be allocated somewhere in the system. By
default there is only enough memory allocated for a single TCP default there is only enough memory allocated for a single TCP
connection, but it can be increased at compile time if the user needs connection, but it can be increased at compile time if the user needs
multiple parallel connections. multiple parallel connections.
The RIOT TCP implementation does not currently support classic POSIX The RIOT TCP implementation offers an optional POSIX socket wrapper
sockets. However, it supports an interface that has been inspired by that enables POSIX compliance, if needed.
POSIX.
Further details on RIOT and GNRC can be found in the literature
[RIOT], [GNRC].
8.4. TinyOS 8.4. TinyOS
TinyOS was important as platform for early constrained devices. TinyOS was important as platform for early constrained devices.
TinyOS has an experimental TCP stack that uses a simple nonblocking TinyOS has an experimental TCP stack that uses a simple nonblocking
library-based implementation of TCP, which provides a subset of the library-based implementation of TCP, which provides a subset of the
socket interface primitives. The application is responsible for socket interface primitives. The application is responsible for
buffering. The TCP library does not do any receive-side buffering. buffering. The TCP library does not do any receive-side buffering.
Instead, it will immediately dispatch new, in-order data to the Instead, it will immediately dispatch new, in-order data to the
application and otherwise drop the segment. A send buffer is application and otherwise drop the segment. A send buffer is
provided so that the TCP implementation can automatically retransmit provided by the application. Multiple TCP connections are possible.
missing segments. Multiple TCP connections are possible. Recently Recently there has been little further work on the stack.
there has been little further work on the stack.
8.5. FreeRTOS 8.5. FreeRTOS
FreeRTOS is a real-time operating system kernel for embedded devices FreeRTOS is a real-time operating system kernel for embedded devices
that is supported by 16- and 32-bit microprocessors. Its TCP that is supported by 16- and 32-bit microprocessors. Its TCP
implementation is based on multiple-MSS window size, although a implementation is based on multiple-segment window size, although a
'Tiny-TCP' option, which is a single-MSS variant, can be enabled. 'Tiny-TCP' option, which is a single-MSS variant, can be enabled.
Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a Delayed ACKs are supported, with a 20-ms Delayed ACK timer as a
technique intended 'to gain performance'. technique intended 'to gain performance'.
8.6. uC/OS 8.6. uC/OS
uC/OS is a real-time operating system kernel for embedded devices, uC/OS is a real-time operating system kernel for embedded devices,
which is maintained by Micrium. uC/OS is intended for 8-, 16- and which is maintained by Micrium. uC/OS is intended for 8-, 16- and
32-bit microprocessors. The uC/OS TCP implementation supports a 32-bit microprocessors. The uC/OS TCP implementation supports a
multiple-MSS window size. multiple-segment window size.
8.7. Summary 8.7. Summary
+---+---------+--------+----+------+--------+-----+ +---+---------+--------+----+------+--------+-----+
|uIP|lwIP orig|lwIP 2.0|RIOT|TinyOS|FreeRTOS|uC/OS| |uIP|lwIP orig|lwIP 2.1|RIOT|TinyOS|FreeRTOS|uC/OS|
+------+-------------+---+---------+--------+----+------+--------+-----+ +------+-------------+---+---------+--------+----+------+--------+-----+
|Memory|Code size(kB)| <5|~9 to ~14| ~40 | <7 | N/A | <9.2 | N/A | |Memory|Code size(kB)| <5|~9 to ~14| 38 | <7 | N/A | <9.2 | N/A |
| | |(a)| (T1) | (b) |(T3)| | (T2) | | | | |(a)| (T1) | (T4) |(T3)| | (T2) | |
+------+-------------+---+---------+--------+----+------+--------+-----+ +------+-------------+---+---------+--------+----+------+--------+-----+
| |Win size(MSS)| 1 | Mult. | Mult. | 1 | Mult.| Mult. |Mult.| | | Single-Segm.|Yes| No | No | Yes| No | No | No |
| +-------------+---+---------+--------+----+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| | Slow start | No| Yes | Yes | No | Yes | No | Yes | | | Slow start | No| Yes | Yes | No | Yes | No | Yes |
| T +-------------+---+---------+--------+----+------+--------+-----+ | T +-------------+---+---------+--------+----+------+--------+-----+
| C |Fast rec/retx| No| Yes | Yes | No | Yes | No | Yes | | C |Fast rec/retx| No| Yes | Yes | No | Yes | No | Yes |
| P +-------------+---+---------+--------+----+------+--------+-----+ | P +-------------+---+---------+--------+----+------+--------+-----+
| | Keep-alive | No| No | Yes | No | No | Yes | Yes | | | Keep-alive | No| No | Yes | No | No | Yes | Yes |
| +-------------+---+---------+--------+----+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| f | Win. Scale | No| No | Yes | No | No | Yes | No | | f | Win. Scale | No| No | Yes | No | No | Yes | No |
| e +-------------+---+---------+--------+----+------+--------+-----+ | e +-------------+---+---------+--------+----+------+--------+-----+
| a | TCP timest. | No| No | Yes | No | No | Yes | No | | a | TCP timest.| No| No | Yes | No | No | Yes | No |
| t +-------------+---+---------+--------+----+------+--------+-----+ | t +-------------+---+---------+--------+----+------+--------+-----+
| u | SACK | No| No | Yes | No | No | Yes | No | | u | SACK | No| No | Yes | No | No | Yes | No |
| r +-------------+---+---------+--------+----+------+--------+-----+ | r +-------------+---+---------+--------+----+------+--------+-----+
| e | Del. ACKs | No| Yes | Yes | No | No | Yes | Yes | | e | Del. ACKs | No| Yes | Yes | No | No | Yes | Yes |
| s +-------------+---+---------+--------+----+------+--------+-----+ | s +-------------+---+---------+--------+----+------+--------+-----+
| | Socket | No| No |Optional|(I) |Subset| Yes | Yes | | | Socket | No| No |Optional|(I) |Subset| Yes | Yes |
| +-------------+---+---------+--------+----+------+--------+-----+ | +-------------+---+---------+--------+----+------+--------+-----+
| |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes | | |Concur. Conn.|Yes| Yes | Yes | Yes| Yes | Yes | Yes |
+------+-------------+---+---------+--------+----+------+--------+-----+ +------+-------------+---+---------+--------+----+------+--------+-----+
| TLS supported | No| No | Yes | Yes| Yes | Yes | Yes |
+--------------------+---+---------+--------+----+------+--------+-----+
(T1) = TCP-only, on x86 and AVR platforms (T1) = TCP-only, on x86 and AVR platforms
(T2) = TCP-only, on ARM Cortex-M platform (T2) = TCP-only, on ARM Cortex-M platform
(T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same platform (T3) = TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the same platform
is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional connection) is ~2.5 kB for one TCP connection plus ~1.2 kB for each additional connection)
(a) = includes IP, ICMP and TCP on x86 and AVR platforms (T4) = TCP-only, on CC2538DK, cross-compiling on Linux
(b) = the whole protocol stack on mbed (a) = includes IP, ICMP and TCP on x86 and AVR platforms. The Contiki-NG TCP implementation has a code size of 3.2 kB on CC2538DK, cross-compiling on Linux
(I) = interface inspired by POSIX (I) = optional POSIX socket wrapper which enables POSIX compliance if needed
Mult. = Multiple Mult. = Multiple
N/A = Not Available N/A = Not Available
Figure 2: Summary of TCP features for differrent lightweight TCP Figure 2: Summary of TCP features for differrent lightweight TCP
implementations. None of the implementations considered in this implementations. None of the implementations considered in this
Annex support ECN or TFO. Annex support ECN or TFO.
9. Annex. Changes compared to previous versions 9. Annex. Changes compared to previous versions
RFC Editor: To be removed prior to publication RFC Editor: To be removed prior to publication
skipping to change at page 20, line 16 skipping to change at page 21, line 17
o Addressing the remaining TODOs o Addressing the remaining TODOs
o Alignment of the wording on TCP "keep-alives" with related o Alignment of the wording on TCP "keep-alives" with related
discussions in the IETF transport area discussions in the IETF transport area
o Added further discussion on delayed ACKs o Added further discussion on delayed ACKs
o Removed OpenWSN subsection from the Annex o Removed OpenWSN subsection from the Annex
9.5. Changes between -04 and -05
o Addressing comments by Yoshifumi Nishida
o Removed mentioning MD5 as an example (comment by David Black)
o Added memory footprint details of TCP implementations (Contiki-NG
and lwIP 2.1.2) provided by Rahul Jadhav in the Annex
o Addressed comments by Ilpo Jarvinen throughout the whole document
o Improved the RIOT section in the Annex, based on feedback from
Emmanuel Baccelli
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,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <https://www.rfc-editor.org/info/rfc1323>.
[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, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 21, line 34 skipping to change at page 22, line 48
[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, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[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, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[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>.
10.2. Informative References 10.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.
[GNRC] M. Lenders et al., "Connecting the World of Embedded
Mobiles: The RIOTApproach to Ubiquitous Networking for the
IoT", 2018.
[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-11 (work in progress),
December 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-03 (work in progress), February 2018. core-cocoa-03 (work in progress), February 2018.
[I-D.ietf-lpwan-overview] [I-D.ietf-tcpm-rto-consider]
Farrell, S., "LPWAN Overview", draft-ietf-lpwan- Allman, M., "Retransmission Timeout Requirements", draft-
overview-10 (work in progress), February 2018. ietf-tcpm-rto-consider-08 (work in progress), February
2019.
[I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-08 (work in progress),
October 2017.
[IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the [IntComp] C. Gomez, A. Arcia-Moret, J. Crowcroft, "TCP in the
Internet of Things: from ostracism to prominence", IEEE Internet of Things: from ostracism to prominence", IEEE
Internet Computing, January-February 2018. Internet Computing, January-February 2018.
[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>.
[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>.
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
Vaidya, "Long Thin Networks", RFC 2757, Vaidya, "Long Thin Networks", RFC 2757,
DOI 10.17487/RFC2757, January 2000, DOI 10.17487/RFC2757, January 2000,
<https://www.rfc-editor.org/info/rfc2757>. <https://www.rfc-editor.org/info/rfc2757>.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000, RFC 2884, DOI 10.17487/RFC2884, July 2000,
<https://www.rfc-editor.org/info/rfc2884>. <https://www.rfc-editor.org/info/rfc2884>.
skipping to change at page 24, line 41 skipping to change at page 25, line 41
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <https://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed.,
"Energy-Efficient Features of Internet of Things
Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018,
<https://www.rfc-editor.org/info/rfc8352>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[RIOT] E. Baccelli et al., "RIOT: an Open Source Operating
Systemfor Low-end Embedded Devices in the IoT", 2018.
[shrew] A. Kuzmanovic, E. Knightly, "Low-Rate TCP-Targeted Denial [shrew] A. Kuzmanovic, E. Knightly, "Low-Rate TCP-Targeted Denial
of Service Attacks", SIGCOMM'03 2003. of Service Attacks", SIGCOMM'03 2003.
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
UPC UPC
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
 End of changes. 75 change blocks. 
219 lines changed or deleted 279 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/