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

> For battery operated devices, a timer interrupt or a hardware interrupt can be used to wake up the device. You may be able to design the electronics to wake the device up, but to save power, the MCU and network hardware would need to be in a sleep mode. Can you describe the use cases where you think that waiting until the next periodic wakeup to receive new messages would be a serious problem?
>  
> [Claes]: Use cases are when a server or another IoT device sends an alarm or notification that must be acted on immediately.


If this relying on the network connection, it implies that the device doesn’t sleep, so battery operation would normally be inappropriate.  Perhaps you could clarify what you mean by “acted on immediately” as this presumably depends on the use case.  The longer the latency allowed, the longer the battery life.

In some use cases, you don’t need to use a battery since the device can be powered from the building’s electrical supply, e.g. a room light.  Integrating an IoT device with the light can then allow the MCU and radio to be permanently on.


> Given the above info on WebSocket keep-alive, there may not be a significant advantage over a UDP based protocol. In addition, MQTT is based upon TCP and provides an alternative to Web Sockets in that respect. 
>  
> [Claes]: You have learned me that Web Sockets keep-alive messaging may be as frequent as what is needed for CoAP over UDP. However, there are other advantages with Web Sockets compared to CoAP, e.g.
> -        Could probably better pass “troublesome firewalls”

According to Google, this is less of an issue in practice according to their studies.

> TCP supports reliable transmission 


TCP is ultimately very good at adjusting to the current level of network traffic, but UDP and CoAP can readily support reliable transmission with a reasonably small code overhead.

> TCP is more secure than UDP. In TCP it is difficult to inject an arbitrary packet as each packet has a sequence number. In UDP it is simple. A malicious packet could easier pass an open UDP port in the firewall than an open TCP port. By that it is possible to have a TCP port open longer than a UDP port.

Hmm, attackers can monitor and inject TCP packets too, so I not sure about your claim.

> Here is an example of a Web Socket server for IoT devices (ARM mbed): https://developer.mbed.org/cookbook/Websockets-Server <https://developer.mbed.org/cookbook/Websockets-Server>

Thanks for the pointer.  If we ignore low end devices, then TCP and Web Sockets are fine.  Perhaps, low end devices will disappear if the price differential is small enough.  32 bit MCU’s are certainly a lot more flexible than 8 bit ones.  For any given IoT product, you can see whether the price difference is important, but for the Web overall, we may need to cover a broader range of devices, and hence I am interested to see just how far we can push low end devices as a matter of principle. In essence, if we only address the mindset and needs of some communities, we may find that the Web of Things is not appealing to other communities with different perspectives. For this reason, we may need to work on a variety of competing techniques and see which ones enjoy the widest adoption.

> [Claes]: As far as I understand the main security issue with Web Sockets is that the Same Origin Policy is not applied for Web Sockets. Maybe I am naïve but the HW related security solutions you are discussing are they not applicable for use of CoAP, HTTP and MQTT as well? Could the specific security issue of Web Sockets, no Same Origin Policy, be addressable by CSP and CORS? Sorry for my limited knowledge here.


In practice, browsers only allow you to make web socket connections to the same origin as used to load the web page, although the ports may vary.  I believe that CORS headers should work, but haven’t tested that.

Using hardware acceleration for crypto and for secure storage is indeed applicable across protocols, in so far as those protocols are compatible with the crypto algorithms and settings provided by the hardware.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>