Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07

[Carsten Bormann <[e-mail]>]

On Apr 12, 2017, at 04:42, Mark Nottingham <[e-mail]> wrote:
> 
> So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.

Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.

I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case.  (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)

> Also, the assertions about firewalls are interesting; we're hearing very different assertions in the discussions of QUIC (e.g,. 90%+ success rates for UDP protocols).

Apart from the backend motivation, the main motivation for CoAP over TCP was easier NAT traversal (UDP bindings are timed out much faster in most NATs).  This may extend to other middleboxes, including firewalls that build (and then time out) UDP-based state.

I’m not sure the QUIC numbers transfer to this use case very well, as QUIC is mostly used for web page access from browsers, so short NAT binding timeouts don’t matter that much.  For a sensor that needs to be accessed every 30 minutes, these are much more of an issue.

Grüße, Carsten