[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
draft-ietf-lwig-tcp-constrained-node-networks
LWIG Working Group C. Gomez
Internet-Draft UPC/i2CAT
Intended status: Best Current Practice J. Crowcroft
Expires: May 4, 2017 University of Cambridge
October 31, 2016
TCP over Constrained-Node Networks
draft-gomez-lwig-tcp-constrained-node-networks-01
Abstract
This document provides a profile for the Transmission Control
Protocol (TCP) over Constrained-Node Networks (CNNs). The
overarching goal is to offer simple measures to allow for lightweight
TCP implementation and suitable operation in such environments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gomez & Crowcroft Expires May 4, 2017 [Page 1]
Internet-Draft TCP over CNNs October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Characteristics of CNNs relevant for TCP . . . . . . . . . . 3
3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. TCP over CNNs . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. TCP connection initiation . . . . . . . . . . . . . . . . 4
4.2. Maximum Segment Size (MSS) . . . . . . . . . . . . . . . 4
4.3. Window Size . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. RTO estimation . . . . . . . . . . . . . . . . . . . . . 5
4.5. TCP connection lifetime . . . . . . . . . . . . . . . . . 6
4.5.1. Long TCP connection lifetime . . . . . . . . . . . . 6
4.5.2. Short TCP connection lifetime . . . . . . . . . . . . 6
4.6. Explicit congestion notification . . . . . . . . . . . . 7
4.7. TCP options . . . . . . . . . . . . . . . . . . . . . . . 7
4.8. Delayed Acknowledgments . . . . . . . . . . . . . . . . . 8
4.9. Explicit loss notifications . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Annex. TCP implementations for constrained devices . . . . . 9
7.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. RIOT . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The Internet Protocol suite is being used for connecting Constrained-
Node Networks (CNNs) to the Internet, enabling the so-called Internet
of Things (IoT) [RFC7228]. In order to meet the requirements that
stem from CNNs, the IETF has produced a suite of protocols
specifically designed for such environments
[I-D.ietf-lwig-energy-efficient].
At the application layer, the Constrained Application Protocol (CoAP)
was developed over UDP [RFC7252]. However, the integration of some
CoAP deployments with existing infrastructure is being challenged by
middleboxes such as firewalls, which may limit and even block UDP-
based communications. This the main reason why a CoAP over TCP
specification is being developed [I-D.tschofenig-core-coap-tcp-tls].
On the other hand, other application layer protocols not specifically
designed for CNNs are also being considered for the IoT space. Some
examples include HTTP/2 and even HTTP/1.1, both of which run over TCP
Gomez & Crowcroft Expires May 4, 2017 [Page 2]
Internet-Draft TCP over CNNs October 2016
by default [RFC7540][RFC2616], and the Extensible Messaging and
Presence Protocol (XMPP) [RFC 6120]. TCP is also used by non-IETF
application-layer protocols in the IoT space such as MQTT and its
lightweight variants [MQTTS].
This document provides a profile for TCP over CNNs. The overarching
goal is to offer simple measures to allow for lightweight TCP
implementation and suitable operation in such environments.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]
2. Characteristics of CNNs relevant for TCP
Constrained nodes are characterized by significant limitations on
processing, memory, and energy resources [RFC7228]. The first two
dimensions pose constraints on the complexity and on the memory
footprint of the protocols that constrained nodes can support. The
latter requires techniques to save energy, such as radio duty-cycling
in wireless devices [I-D.ietf-lwig-energy-efficient], as well as
minimization of the number of messages transmitted/received (and
their size).
Constrained nodes often use physical/link layer technologies that
have been characterized as 'lossy'. Many such technologies are
wireless, therefore exhibiting a relatively high bit error rate.
However, some wired technologies used in the CNN space are also lossy
(e.g. Power Line Communication). Transmission rates of CNN radio or
wired interfaces are typically low (e.g. below 1 Mbps).
Some CNNs follow the star topology, whereby one or several hosts are
linked to a central device that acts as a router connecting the CNN
to the Internet. CNNs may also follow the multihop topology
[RFC6606].
3. Scenario
The main scenario for use of TCP over CNNs comprises a constrained
device and an unconstrained device that communicate over the Internet
using TCP, possibly traversing a middlebox (e.g. a firewall, NAT,
etc.). Figure 1 illustrates such scenario. Note that the scenario
is asymmetric, as the unconstrained device will typically not suffer
the severe constraints of the constrained device. The unconstrained
device is expected to be mains-powered, to have high amount of memory
and processing power, and to be connected to a resource-rich network.
Gomez & Crowcroft Expires May 4, 2017 [Page 3]
Internet-Draft TCP over CNNs October 2016
Assuming that a majority of constrained devices will correspond to
sensor nodes, the amount of data traffic sent by constrained devices
(e.g. sensor node measurements) is expected to be higher than the
amount of data traffic in the opposite direction. Nevertheless,
constrained devices may receive requests (to which they may respond),
commands (for configuration purposes and for constrained devices
including actuators) and relatively infrequent firmware/software
updates.
+---------------+
o o <--------- TCP communication ------> | |
o o | |
o o | Unconstrained |
o o +-----------+ | device |
o o o ------ | Middlebox | ------- | |
o o +-----------+ | (e.g. cloud) |
o o o | |
+---------------+
constrained devices
Figure 1: TCP communication between a constrained device and an
unconstrained device, traversing a middlebox.
4. TCP over CNNs
4.1. TCP connection initiation
In the constrained device to unconstrained device scenario
illustrated above, a TCP connection is typically initiated by the
constrained device, in order for this device to support possible
sleep periods to save energy.
4.2. Maximum Segment Size (MSS)
Some link layer technologies in the CNN space are characterized by a
short data unit payload size, e.g. up to a few tens or hundreds of
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 [I-D.ietf-6lo-dect-ule], also use
6LoWPAN-based adaptation layers in order to enable IPv6 support.
Gomez & Crowcroft Expires May 4, 2017 [Page 4]
Internet-Draft TCP over CNNs October 2016
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.
For devices using technologies with a link MTU of 1280 bytes (e.g.
defined by a 6LoWPAN-based adaptation layer), in order to avoid IP
layer fragmentation, the TCP MSS must not be set to a value greater
than 1220 bytes in CNNs. (Note: IP version 6 is assumed.) In any
case, the TCP MSS must not be set to a value leading to an IPv6
datagram size exceeding 1280 bytes.
If a link layer technology used by a constrained device offers a link
layer MTU greater than 1280 bytes, it is still useful to set the MSS
so that IPv6 datagram size does not exceed 1280 bytes, in order to
avoid issues due to Internet links that do not support greater MTUs.
4.3. Window Size
This document recommends that constrained devices advertise a TCP
window size of one MSS, and also transmit at most one MSS of
unacknowledged data. This value for receive and send window is
appropriate for simple message exchanges in the CNN space, reduces
implementation complexity and memory requirements, and reduces
overhead (see section 4.7).
A TCP window size of one MSS follows the same rationale as the
default setting for NSTART in [RFC7252], leading to equivalent
operation when CoAP is used over TCP.
For devices that can afford greater TCP window size, it may be useful
to use window sizes of at least five MSSs, in order to allow Fast
Retransmit and Fast Recovery [RFC5681].
4.4. RTO estimation
Traditionally, TCP has used the well known RTO estimation algorithm
defined in [RFC6298]. However, experimental studies have shown that
another algorithm such as the RTO estimator defined in
[I-D.ietf-core-cocoa] (hereinafter, CoCoA RTO) outperforms state-of-
art algorithms designed as improvements to RFC 6298 for TCP, in terms
of packet delivery ratio, settling time after a burst of messages,
and fairness (the latter is specially relevant in multihop networks
connected to the Internet through a single device, such as a 6LoWPAN
Border Router (6LBR) configured as a RPL root) [Commag]. In fact,
CoCoA RTO has been designed specifically considering the challenges
of CNNs, in contrast with the RFC 6298 RTO.
Gomez & Crowcroft Expires May 4, 2017 [Page 5]
Internet-Draft TCP over CNNs October 2016
TBD: devise approaches for use of CoCoA for TCP by constrained
devices, as currently its use would conflict with several TCP MUSTs
(RFC 6298, Karn algorithm, etc.). If the unconstrained device is
dedicated for communication with constrained devices, CoCoA would be
suitable as well.
4.5. TCP connection lifetime
4.5.1. Long TCP connection lifetime
In CNNs, in order to minimize message overhead, a TCP connection
should be kept open as long as the two TCP endpoints have more data
to exchange or it is envisaged that further segment exchanges will
take place within an interval of two hours since the last segment has
been sent. A greater interval may be used in scenarios where
applications exchange data infrequently.
TCP keep-alive messages [RFC1122] may be supported by a server, to
check whether a TCP connection is active, in order to release state
of inactive connections. This may be useful for servers running on
memory-constrained devices.
Since the keep-alive timer may not be set to a value lower than two
hours [RFC1122], TCP keep-alive messages are not useful to guarantee
that filter state records in middleboxes such as firewalls will not
be deleted after an inactivity interval typically in the order of a
few minutes [RFC6092]. In scenarios where such middleboxes are
present, alternative measures to avoid early deletion of filter state
records (which might lead to frequent establishment of new TCP
connections between the two involved endpoints) include increasing
the initial value for the filter state inactivity timers (if
possible), and using application layer heartbeat messages.
4.5.2. Short TCP connection lifetime
A different approach to addressing the problem of traversing
middleboxes that perform early filter state record deletion relies on
using TCP Fast Open (TFO) [RFC7413]. In this case, instead of trying
to maintain a TCP connection for long time, possibly short-lived
connections can be opened between two endpoints while incurring low
overhead. In fact, TFO allows data to be carried in SYN (and SYN-
ACK) packets, and to be consumed immediately by the receceiving
endpoint, thus reducing overhead compared with the traditional three-
way handshake required to establish a TCP connection.
For security reasons, TFO requires the TCP endpoint that will open
the TCP connection (which in CNNs will typically be the constrained
device) to request a cookie from the other endpoint. The cookie,
Gomez & Crowcroft Expires May 4, 2017 [Page 6]
Internet-Draft TCP over CNNs October 2016
with a size of 4 or 16 bytes, is then included in SYN packets of
subsequent connections. The cookie needs to be refreshed (and
obtained by the client) after a certain amount of time.
Nevertheless, TFO is more efficient than frequently opening new TCP
connections (by using the traditional three-way handshake) for
transmitting new data, as long as the cookie update rate is well
below the data new connection rate.
4.6. Explicit congestion notification
Explicit Congestion Notification (ECN) [RFC3168] may be used in CNNs.
ECN allows a router to signal in the IP header of a packet that
congestion is arising, for example when queue size reaches a certain
threshold. If such a packet encapsulates a TCP data packet, an ECN-
enabled TCP receiver will echo back the congestion signal to the TCP
sender by setting a flag in its next TCP ACK. The sender triggers
congestion control measures as if a packet loss had happened. In
that case, when the congestion window of a TCP sender has a size of
one segment, the TCP sender resets the retransmit timer, and will
only be able to send a new packet when the retransmit timer expires
[RFC3168]. Effectively, the TCP sender reduces at that moment its
sending rate from 1 segment per Round Trip Time (RTT) to 1 segment
per default RTO.
ECN can reduce packet losses, since congestion control measures can
be applied earlier than after the reception of three duplicate ACKs
(if the TCP sender window is large enough) or upon TCP sender RTO
expiration [RFC2884]. Therefore, the number of retries decreases,
which is particularly beneficial in CNNs, where energy and bandwidth
resources are typically limited. Furthermore, latency and jitter are
also reduced.
ECN is particularly appropriate in CNNs, since in these environments
transactional type interactions are a dominant traffic pattern. As
transactional data size decreases, the probability of detecting
congestion by the presence of three duplicate ACKs decreases. In
contrast, ECN can still activate congestion control measures without
requiring three duplicate ACKs.
4.7. TCP options
A TCP implementation needs to support options 0, 1 and 2 [RFC793]. A
TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size will benefit from not supporting,
and ignoring if received, the following TCP options: Window scale
[RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements
(SACK) and SACK-Permitted [RFC2018]. Other TCP options SHOULD NOT be
used, in keeping with the principle of lightweight operation.
Gomez & Crowcroft Expires May 4, 2017 [Page 7]
Internet-Draft TCP over CNNs October 2016
Other TCP options should not be supported by a constrained device, in
keeping with the principle of lightweight implementation and
operation.
If a device, with less severe memory and processing constraints, can
afford advertising a TCP window size of several MSSs, it may support
the SACK option to improve performance. SACK allows a data receiver
to inform the data sender of non-contiguous data blocks received,
thus a sender (having previously sent the SACK-Permitted option) can
avoid performing unnecessary retransmissions, saving energy and
bandwidth, as well as reducing latency. The receiver supporting SACK
will need to manage the reception of possible out-of-order received
segments, requiring sufficient buffer space.
SACK adds 8*n+2 bytes to the TCP header, where n denotes the number
of data blocks received, up to 4 blocks. For a low number of out-of-
order segments, the header overhead penalty of SACK is compensated by
avoiding unnecessary retransmissions.
4.8. Delayed Acknowledgments
A device that advertises a single-MSS receive window needs to avoid
use of delayed ACKs in order to avoid contributing unnecessary delay
(of up to 500 ms) to the RTT [RFC5681].
Since traffic over CNNs is expected to be mostly of transactional
type, with transaction size typically below one MSS, delayed ACKs are
not recommended for TCP over CNNs. (Note: delayed ACKs could be
useful to reduce the number of ACKs in bulk transfer type of traffic,
e.g. for firmware/software updates; however, it is assumed that these
will be infrequent in comparison with transactional type exchanges.)
4.9. Explicit loss notifications
There has been a significant body of research on solutions capable of
explicitly indicating whether a TCP segment loss is due to
corruption, in order to avoid activation of congestion control
mechanisms [ETEN] [RFC2757]. While such solutions may provide
significant improvement, they have not been widely deployed and
remain as experimental work. In fact, as of today, the IETF has not
standardized any such solution.
5. Security Considerations
If TFO is used, the security considerations of RFC 7413 apply.
Gomez & Crowcroft Expires May 4, 2017 [Page 8]
Internet-Draft TCP over CNNs October 2016
6. Acknowledgments
Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336. Part of his contribution to this work
has been carried out during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge.
The authors appreciate the feedback received for this document. The
following folks provided comments that helped improve the document:
Carsten Bormann, Zhen Cao, Wei Genyu, Michael Scharf, Ari Keranen,
Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe
Touch, Fred Baker, Nik Sultana, Simon Brummer.
7. Annex. TCP implementations for constrained devices
This section overviews the main features of TCP implementations for
constrained devices.
7.1. uIP
uIP is a TCP/IP stack, targetted for 8 and 16-bit microcontrollers.
uIP has been deployed with Contiki and the Arduino Ethernet shield.
A code size of ~5 kB (which comprises checksumming, IP, ICMP and TCP)
has been reported for uIP [Dunk].
uIP provides a global buffer for incoming packets, of single-packet
size. A buffer for outgoing data is not provided. In case of a
retransmission, an application must be able to reproduce the same
packet that had been transmitted.
The MSS is announced via the MSS option on connection establishment
and the receive window size (of one MSS) is not modified during a
connection. Stop-and-wait operation is used for sending data. Among
other optimizations, this allows to avoid sliding window operations,
which use 32-bit arithmetic extensively and are expensive on 8-bit
CPUs.
7.2. lwIP
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
memory management, checksumming, network interfaces, IP, ICMP and
TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk].
In contrast with uIP, lwIP decouples applications from the network
stack. lwIP supports a TCP transmission window greater than a single
segment, as well as buffering of incoming and outcoming data. Other
Gomez & Crowcroft Expires May 4, 2017 [Page 9]
Internet-Draft TCP over CNNs October 2016
implemented mechanisms comprise slow start, congestion avoidance,
fast retransmit and fast recovery. SACK and Window Scale are not
implemented.
7.3. RIOT
TBD
8. References
8.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://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, <http://www.rfc-editor.org/info/rfc1323>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
Vaidya, "Long Thin Networks", RFC 2757,
DOI 10.17487/RFC2757, January 2000,
<http://www.rfc-editor.org/info/rfc2757>.
Gomez & Crowcroft Expires May 4, 2017 [Page 10]
Internet-Draft TCP over CNNs October 2016
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000,
<http://www.rfc-editor.org/info/rfc2884>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<http://www.rfc-editor.org/info/rfc6606>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
Gomez & Crowcroft Expires May 4, 2017 [Page 11]
Internet-Draft TCP over CNNs October 2016
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
8.2. Informative References
[Commag] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP
Congestion Control for the Internet of Things", IEEE
Communications Magazine, June 2016.
[Dunk] A. Dunkels, "Full TCP/IP for 8-Bit Architectures", 2003.
[ETEN] R. Krishnan et al, "Explicit transport error notification
(ETEN) for error-prone wireless and satellite networks",
Computer Networks 2004.
[I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-07 (work in progress),
October 2016.
[I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-00 (work in progress), October 2016.
[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-05 (work in progress),
October 2016.
Gomez & Crowcroft Expires May 4, 2017 [Page 12]
Internet-Draft TCP over CNNs October 2016
[I-D.tschofenig-core-coap-tcp-tls]
Bormann, C., Lemay, S., Technologies, Z., and H.
Tschofenig, "A TCP and TLS Transport for the Constrained
Application Protocol (CoAP)", draft-tschofenig-core-coap-
tcp-tls-05 (work in progress), November 2015.
[MQTTS] U. Hunkeler, H.-L. Truong, A. Stanford-Clark, "MQTT-S: A
Publish/Subscribe Protocol For Wireless Sensor Networks",
2008.
Authors' Addresses
Carles Gomez
UPC/i2CAT
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Jon Crowcroft
University of Cambridge
JJ Thomson Avenue
Cambridge, CB3 0FD
United Kingdom
Email: jon.crowcroft@cl.cam.ac.uk
Gomez & Crowcroft Expires May 4, 2017 [Page 13]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/