Subject: [core] New intro to CoAP over TCP

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Oct 2017 18:31:34 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Oct 2017 18:52:26 +0200

> On Oct 13, 2017, at 18:31, Hannes Tschofenig <[email-masked]> wrote:
> 

Nice.  A few comments:

>   [RFC5246] is that some networks drop

s/drop/do not forward/

(I’m not aware of a network that never drops UDP packets, so all networks drop UDP packets.)

> UDP packets.  Complete blocking

These are not exactly side effects — besides complete suppression of UDP, low NAT binding life times are the main reason for CoAP over TCP.  I’d say that these are effects that may be desirable.
>      [HomeGateway] the mean between TCP and UDP NAT binding timeouts is

s/mean between/mean for/

>      mechanisms,

… than the default mechanisms provided by CoAP.

> which is useful for the transfer of larger payloads.
>      updates.  

Unlikely as a reason to deploy CoAP over TCP — if UDP is too slow for those, you really have problems...

> There is, however, ongoing work to add advanced

Right.

>   Emerging standards such as Lightweight Machine to Machine [LWM2M]

Hmm, it’s maybe not that emerging any more after half a decade?

>   in existing CoAP implementations and deployments.

That reads like they need to do a wholesale switch to CoAP over TCP; I’m not aware of that.
(Some deployments may.)

>   WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.

(The advantage of using WebSockets over H2 here is that all CoAP functions stay available, including Observe.)

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Simon Lemay <[email-masked]>
Date: Fri, 13 Oct 2017 17:38:54 +0000

I like it, comment inline

>       additional information about the session life cycle.  UDP, on the

life cycle --> lifecycle

>       In the context of IoT deployments such transfers could be firmware

coma after deployments

>    WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.

this may be a bit heavy (long sentence), a possible rewording:

 Finally, CoAP applications running inside a web browser may be without
access to connectivity other than HTTP.  In this case,  the WebSocket
protocol [RFC6455] may be used to either cross-proxy their CoAP requests
via HTTP to an HTTP-to-CoAP cross-proxy or transport them via the WebSocket
protocol. This would, in turn, provide two-way communication between a
WebSocket client and a WebSocket server after upgrading an HTTP/1.1
[RFC7230] connection.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Oct 2017 10:31:12 +0200

Thanks, Simon. I fixed all the issues you raised.

On 10/13/2017 07:38 PM, Simon Lemay wrote:
> On Fri, Oct 13, 2017 at 9:31 AM Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> via HTTP to an HTTP-to-CoAP cross-proxy or transport them via the
> WebSocket protocol. This would, in turn, provide two-way communication
> between a WebSocket client and a WebSocket server after upgrading an
> HTTP/1.1 [RFC7230] connection.
> 
> 
>     [email-masked] <mailto:[email-masked]>