Re: [TF-AP]: Using CoAP for bi-directional communication

Hi Claes,

Resource requirements for a CoAP+UDP server depend on the library but with the libraries I’m familiar with, 64K of flash and 16K of RAM seems about minimum comfortable for a very basic CoAP device. 128K Flash and 32K RAM should accommodate a small application with DTLS security and a collection of CoAP resources. YMMV, some communication stacks need more memory than others.

I use CoAP and UDP through firewalls, and find >60 seconds to be pretty common for the UDP reverse NAT tunnel timeout. I have a Resource Directory server outside the firewall that I refresh periodically to keep the tunnel open. There is no problem reusing the UDP port for incoming messages, and when using Resource Directory the port is transmitted on updates. I find that for powered devices this can be reliable.

Using CoRE Resource Directory, you have the option to specify a different IP address and port when registering resources. This would enable management of an incoming UPD proxy address as you describe below. 

CoAP Pubsub is a new draft in progress which allows an always-on CoAP device to function as a lightweight broker. A sleepy CoAP device can wake up and push data to the broker occasionally, which can then in turn maintain an open firewall tunnel for communication of the data with the outside world. 

Another mechanism for sleepy devices in in OMW LWM2M, where the device wakes up occasionally and sends an update to a Resource Directory server through the firewall. This provides enough time for the application to go back through the firewall tunnel and interact with the CoAP device to perform any pending transactions.

TCP has a longer timeout but may not be a solution for battery powered devices.

There is ongoing work in OMA LWM2M and in IETF to provide improved firewall traversal mechanisms. STUN, TURN, and ICE are some IETF protocols that use a proxy to keep a firewall port open when the endpoints are not reachable.

Best regards,

Michael


On Sep 13, 2015, at 10:58 AM, Dave Raggett <dsr@w3.org> wrote:

> Hi Claes,
> 
> My comments below ...
> 
> 
>> On 13 Sep 2015, at 14:46, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com> wrote:
>> 
>> Hi TF-AP,
>>  
>> Sorry for being quiet on this list for a while.
>>  
>> I have been experimenting with CoAP using the node coap library, https://github.com/mcollina/node-coap. Many IoT use cases require both peers to act as both client and server that expose REST APIs to be called by the other peer. However, if an IoT device is behind a NAT/firewall we have problems. The IoT device can anytime execute a REST call over CoAP to a cloud server. However, the ability for the cloud server to call a REST API in the IoT device is limited. The IoT device must initiate the communication. To keep the NAT/firewall open for requests from the cloud server to the IoT device a CoAP request from the cloud server, now acting as CoAP client, must be sent over the same IP-address/portnr quadruple (source/dest address/port) as was used for the initiating request from the IoT device in order for the NAT to accept the request from the server.
>>  
>> With the node coap library it is possible to achieve “bi-directional” CoAP with a trick using a local proxy to achieve a constant IP-address/portnr quadruple as long as the UDP traffic is opened in the NAT. However, it may not be possible to achieve this in all CoAP implementations as it might not be possible to set the same portnr as was used as source port to the port that is used for listening on requests on (when the IoT device switches from CoAP client to CoAP server). Furthermore, NAT timeouts for UDP traffic are typically between 30 and 180 seconds, http://mobilesociety.typepad.com/mobile_life/2008/08/nokia-research-center-on-impact-of-keep-alive-messaging-on-power-consumption.html, so a keep-alive from the IoT device to the cloud server is needed if the server should be able to make a REST call to the IoT device “anytime”. And, keep-alives consume battery so better is some kind of “wake up/push” method.
>>  
>> Of course, Web Sockets is a better choice as it solves the bidirectional issue and NAT issue. However, HW requirements are higher for Web Sockets than for CoAP and for really cheap devices CoAP might be the only alternative? I am correct?
>>  
>> I am now interested in hearing the views and experiences from members in this IG on the issues I describe above. I would also like to hear views on minimal HW requirements (memory etc) for CoAP versus Web Sockets and possible other alternatives, e.g. XMPP.
> 
> 
> For my experiments with supporting the Web of Things on low end devices, I have been exploring lightweight libraries for current networking chips, e.g. the Wiznet W5100 which is used for the Arduino Ethernet shield.  This chip and similar ones, such as the ENC28J60, include on-chip memory for network buffers and additional hardware that reduces the burden for implementing TCP, as well as enabling the use of UDP and multicast packets.
> 
> The W5100, for example, has 16 Kbytes of internal memory and enables you to trade  a reduced number of local sockets for an increase in the memory allocated per socket. The IoT microcontroller (MCU) itself has limited memory.  A traditional API would require you to use the MCU’s RAM to prepare the messages you want to send, then copy each message to the network controller.  Likewise, when a packet is received, you would need to copy the message from the network controller to the MCU RAM.   This memory overhead can be avoided by using a higher level API that allows you to prepare the messages using the network controller’s internal memory, and likewise when parsing a received message.  Of course, this necessitates writing a new library for a specific network controller, but my experiments have shown that this is actually relatively easy given the network controller data sheet and the vendor’s example code.
> 
> UDP can be used in an equivalent way to TCP for bidirectional messaging by using message sequence numbers together with retransmissions and acknowledgements.  The overhead for this is fairly small provided you restrict the API to only handle one send message at a time. In other words, if you are limited to a single (re)send buffer held on-chip in the network controller. Short keep alive packets can be used to refresh the firewall so that it allows incoming packets through. However, this may not be practical for battery operated IoT devices that spend a lot of their time asleep. For such devices, the server can queue messages until such time as the IoT device wakes up.
> 
> Web Sockets incurs a much bigger overhead, but is still doable on the more powerful MCU’s. However, there are further complications when it comes to security.   I am exploring the use of specialised crypto hardware that offloads this complexity from the MCU to dedicated chips e.g. for NIST ECC profiles. Such chips are inexpensive and look rather promising when it comes to supporting strong security on low end IoT systems.
> 
> Best regards,
> —
>    Dave Raggett <dsr@w3.org>