Hannes Tschofenig
2017-10-13 16:31:34 UTC
After a discussion with Jaime I wrote a new introduction for the CoAP
over TCP draft. Below is the new text. What do you think?
-----
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] was designed
for Internet of Things (IoT) deployments, assuming that UDP [RFC0768]
and DTLS [RFC6347] over UDP can be used unimpeded. The use of CoAP
over UDP is focused on simplicity, has a low code footprint, and a
small over-the-wire message size.
The primary reason for introducing CoAP over TCP [RFC0793] and TLS
[RFC5246] is that some networks drop UDP packets. Complete blocking
of UDP happens in between about 2% and 4% of terrestrial access
networks, according to [EK2016]. UDP impairment is especially
concentrated in enterprise networks and networks in geographic
regions with otherwise challenged connectivity. Some networks also
rate-limit UDP traffic, as reported in [BK2015] and deployment
investigations related to the standardization of QUIC revealed
numbers around 0.3 % [SW2016].
The introduction of CoAP over TCP also leads to some side effects,
namely
o Where NATs are present along the communication path, CoAP over TCP
leads to different NAT traversal behavior than CoAP over UDP.
NATs often calculate expiration timers based on the transport
layer protocol being used by application protocols. Many NATs
maintain TCP-based NAT bindings for longer periods based on the
assumption that a transport layer protocol, such as TCP, offers
additional information about the session life cycle. UDP, on the
other hand, does not provide such information to a NAT and
timeouts tend to be much shorter [HomeGateway]. According to
[HomeGateway] the mean between TCP and UDP NAT binding timeouts is
386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values
require keepalive messages to be sent more frequently. Hence, the
use of CoAP over TCP requires less frequent transmission of keep-
alive messages.
o TCP utilizes more sophisticated congestion and flow control
mechanisms, which is useful for the transfer of larger payloads.
In the context of IoT deployments such transfers could be firmware
updates. There is, however, ongoing work to add advanced
congestion control to CoAP as well, see [I-D.ietf-core-cocoa].
Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is
still the recommended transport for use constrained node networks,
particularly when used in concert with blockwise transfer. CoAP over
TCP is applicable for those cases where the networking infrastructure
leaves no other choice. The use of CoAP over TCP leads to a larger
code size, more roundtrips, increased RAM requirements and larger
packet sizes. Developers implementing CoAP over TCP are encouraged
to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance
on low-footprint TCP implementations for IoT devices.
Emerging standards such as Lightweight Machine to Machine [LWM2M]
currently use CoAP over UDP as a transport and require support for
CoAP over TCP to address the issues above and to protect investments
in existing CoAP implementations and deployments.
Although HTTP/2 could also potentially address the need for
enterprise firewall traversal, there would be additional costs and
delays introduced by such a transition from CoAP to HTTP/2.
Currently, there are also fewer HTTP/2 implementations available for
constrained devices in comparison to CoAP. Since CoAP also support
group communication using IP layer multicast and unreliable
communication IoT devices would have to support HTTP/2 in addition to
CoAP.
Furthermore, CoAP may be integrated into a Web environment where the
front-end uses CoAP over UDP from IoT devices to a cloud
infrastructure and then CoAP over TCP between the back-end services.
A TCP-to-UDP gateway can be used at the cloud boundary to communicate
with the UDP-based IoT device.
Finally, CoAP applications running inside a web browser without
access to connectivity other than HTTP and the WebSocket protocol
[RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to-
CoAP cross-proxy or transport them via the the WebSocket protocol,
which provides two-way communication between a WebSocket client and a
WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
To address the above-mentioned deployment requirements, this document
defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over
WebSockets. For these cases, the reliability offered by the
transport protocol subsumes the reliability functions of the message
layer used for CoAP over UDP. (Note that both for a reliable
transport and the CoAP over UDP message layer, the reliability
offered is per transport hop: where proxies -- see Sections 5.7 and
10 of [RFC7252] -- are involved, that layer's reliability function
does not extend end-to-end.) Figure 1 illustrates the layering:
+--------------------------------+
| Application |
+--------------------------------+
+--------------------------------+
| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
|--------------------------------|
| Message Framing | This Document
+--------------------------------+
| Reliable Transport |
+--------------------------------+
Figure 1: Layering of CoAP over Reliable Transports
This document specifies how to access resources using CoAP requests
and responses over the TCP, TLS and WebSocket protocols. This allows
connectivity-limited applications to obtain end-to-end CoAP
connectivity either by communicating CoAP directly with a CoAP server
accessible over a TCP, TLS or WebSocket connection or via a CoAP
intermediary that proxies CoAP requests and responses between
different transports, such as between WebSockets and UDP.
Appendix A updates the "Observing Resources in the Constrained
Application Protocol" [RFC7641] specification for use with CoAP over
reliable transports. [RFC7641] is an extension to the CoAP protocol
that enables CoAP clients to "observe" a resource on a CoAP server.
(The CoAP client retrieves a representation of a resource and
registers to be notified by the CoAP server when the representation
is updated.)
-----
The pull request is here:
https://github.com/core-wg/coap-tcp-tls/pull/187
over TCP draft. Below is the new text. What do you think?
-----
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] was designed
for Internet of Things (IoT) deployments, assuming that UDP [RFC0768]
and DTLS [RFC6347] over UDP can be used unimpeded. The use of CoAP
over UDP is focused on simplicity, has a low code footprint, and a
small over-the-wire message size.
The primary reason for introducing CoAP over TCP [RFC0793] and TLS
[RFC5246] is that some networks drop UDP packets. Complete blocking
of UDP happens in between about 2% and 4% of terrestrial access
networks, according to [EK2016]. UDP impairment is especially
concentrated in enterprise networks and networks in geographic
regions with otherwise challenged connectivity. Some networks also
rate-limit UDP traffic, as reported in [BK2015] and deployment
investigations related to the standardization of QUIC revealed
numbers around 0.3 % [SW2016].
The introduction of CoAP over TCP also leads to some side effects,
namely
o Where NATs are present along the communication path, CoAP over TCP
leads to different NAT traversal behavior than CoAP over UDP.
NATs often calculate expiration timers based on the transport
layer protocol being used by application protocols. Many NATs
maintain TCP-based NAT bindings for longer periods based on the
assumption that a transport layer protocol, such as TCP, offers
additional information about the session life cycle. UDP, on the
other hand, does not provide such information to a NAT and
timeouts tend to be much shorter [HomeGateway]. According to
[HomeGateway] the mean between TCP and UDP NAT binding timeouts is
386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values
require keepalive messages to be sent more frequently. Hence, the
use of CoAP over TCP requires less frequent transmission of keep-
alive messages.
o TCP utilizes more sophisticated congestion and flow control
mechanisms, which is useful for the transfer of larger payloads.
In the context of IoT deployments such transfers could be firmware
updates. There is, however, ongoing work to add advanced
congestion control to CoAP as well, see [I-D.ietf-core-cocoa].
Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is
still the recommended transport for use constrained node networks,
particularly when used in concert with blockwise transfer. CoAP over
TCP is applicable for those cases where the networking infrastructure
leaves no other choice. The use of CoAP over TCP leads to a larger
code size, more roundtrips, increased RAM requirements and larger
packet sizes. Developers implementing CoAP over TCP are encouraged
to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance
on low-footprint TCP implementations for IoT devices.
Emerging standards such as Lightweight Machine to Machine [LWM2M]
currently use CoAP over UDP as a transport and require support for
CoAP over TCP to address the issues above and to protect investments
in existing CoAP implementations and deployments.
Although HTTP/2 could also potentially address the need for
enterprise firewall traversal, there would be additional costs and
delays introduced by such a transition from CoAP to HTTP/2.
Currently, there are also fewer HTTP/2 implementations available for
constrained devices in comparison to CoAP. Since CoAP also support
group communication using IP layer multicast and unreliable
communication IoT devices would have to support HTTP/2 in addition to
CoAP.
Furthermore, CoAP may be integrated into a Web environment where the
front-end uses CoAP over UDP from IoT devices to a cloud
infrastructure and then CoAP over TCP between the back-end services.
A TCP-to-UDP gateway can be used at the cloud boundary to communicate
with the UDP-based IoT device.
Finally, CoAP applications running inside a web browser without
access to connectivity other than HTTP and the WebSocket protocol
[RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to-
CoAP cross-proxy or transport them via the the WebSocket protocol,
which provides two-way communication between a WebSocket client and a
WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
To address the above-mentioned deployment requirements, this document
defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over
WebSockets. For these cases, the reliability offered by the
transport protocol subsumes the reliability functions of the message
layer used for CoAP over UDP. (Note that both for a reliable
transport and the CoAP over UDP message layer, the reliability
offered is per transport hop: where proxies -- see Sections 5.7 and
10 of [RFC7252] -- are involved, that layer's reliability function
does not extend end-to-end.) Figure 1 illustrates the layering:
+--------------------------------+
| Application |
+--------------------------------+
+--------------------------------+
| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
|--------------------------------|
| Message Framing | This Document
+--------------------------------+
| Reliable Transport |
+--------------------------------+
Figure 1: Layering of CoAP over Reliable Transports
This document specifies how to access resources using CoAP requests
and responses over the TCP, TLS and WebSocket protocols. This allows
connectivity-limited applications to obtain end-to-end CoAP
connectivity either by communicating CoAP directly with a CoAP server
accessible over a TCP, TLS or WebSocket connection or via a CoAP
intermediary that proxies CoAP requests and responses between
different transports, such as between WebSockets and UDP.
Appendix A updates the "Observing Resources in the Constrained
Application Protocol" [RFC7641] specification for use with CoAP over
reliable transports. [RFC7641] is an extension to the CoAP protocol
that enables CoAP clients to "observe" a resource on a CoAP server.
(The CoAP client retrieves a representation of a resource and
registers to be notified by the CoAP server when the representation
is updated.)
-----
The pull request is here:
https://github.com/core-wg/coap-tcp-tls/pull/187