Feedbacks about CoAP-over-TCP

[boaks]

contrained-node networks

=>

constrained-node networks

[sbernard31]

Thx @boaks :pray: I fixed it.

I'm not sure but I think you can edit wiki by yourself. If I'm right, do not hesitate to fix this kind of typo directly.

Except the typo, do you see anything which seems wrong/strange to you ?

Let's use this issue for others feedback about : https://github.com/eclipse/leshan/wiki/CoAP-over-TCP

[boaks]

I'm not sure but I think you can edit wiki by yourself.

You're right.

do you see anything which seems wrong/strange to you ?

Not sure, if that fits "anything":

• in my experience, the statement "low code footprint" is much more just repeated, than really achieved. In many designs, the IP-stack is in a "out-of-the-box" module with both, TCP and UDP, and there is no difference in the custom code size.

• networks not only block "UDP", many corporate networks blocks everything else than "HTTP(S)". That results either in CoAP over WebSocket or a CoAP-HTTP-cross-proxy. Therefore we will see, how often CoAP over TCP helps. (Just as idea: using LTE-M/NB-IoT doesn't use a local-network and therefore also doesn't compromise the security of that local network.)

• NAT "the mean for TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP)." the nasty point is, that if your "HomeGateway" uses other times, you need to use these. Also, if a cloud component uses other times, you need to use these. In the case, that back-channel (server => device) is important, more frequent alive traffic must be used anyway. So the advantage of the "mean longer timeout" may be much smaller, than expected.

Anyway, it will be really very interesting, if TCP really helps to improve the usability.

So, hands up,

• who really saves "code".
• who's network blocks UDP but CoAP over TCP works
• which alive-time you really use

[sbernard31]

You sounds very skeptical about CoAP over TCP. :sweat_smile:

On my side, I haven't strong opinion, my current feeling is that UDP should be used as default like explained in the wiki page. Then I tried just to summarize the "literature" about it and see how it could fit to LWM2M use case. I currently have no production experience about that.

in my experience, the statement "low code footprint" is much more just repeated, than really achieved. In many designs, the IP-stack is in a "out-of-the-box" module with both, TCP and UDP, and there is no difference in the custom code size.

Maybe I'm wrong but I understand "low code footprint" as a kind of general idea which means that an UDP stack will probably required less disk , ram or CPU usage (maybe not all but at least some of them). But I agree this is not very clear

networks not only block "UDP", many corporate networks blocks everything else than "HTTP(S)".

I understand the idea is just to say : use UDP but if UDP is blocked and TCP is not, you can fall back on CoAP over TCP.

In the case, that back-channel (server => device) is important, more frequent alive traffic must be used anyway. So the advantage of the "mean longer timeout" may be much smaller, than expected.

I'm not sure to get you ? :thinking:

[boaks]

You sounds very skeptical about CoAP over TCP

I would rather say, I'm looking forward to the results.

I'm not sure to get you ?

If no messages are exchanged, because a large NAT timeout is assumed, the probability, that the client is not aware of a stale connection, gets larger. If that "back-channel" is important, the client needs to test the connection frequently, if it is still valid.

[davidahoward]

It's my recollection that TCP was originally introduced to deal with lack of support by cloud hyperscalers for UDP on their load balancers. It was also to deal with the very short UDP TIMEOUT on firewalls (30-90S) and issues with DTLS security context being lost pre-CID support. I think most of the issues have been dealt with - other than the very short UDP TIMEOUT (which can result in the client becoming unreachable from the server perspective). TCP has a very long timeout by comparison, so the LwM2M client remains reachable from the server for a much longer period of time between client sends or reg updates.

[sbernard31]

Here some input about benefits of coap+tcp : https://github.com/eclipse-californium/californium/issues/2092#issuecomment-1434734463