Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedbacks about CoAP-over-TCP #1343

Open
boaks opened this issue Nov 7, 2022 · 6 comments
Open

Feedbacks about CoAP-over-TCP #1343

boaks opened this issue Nov 7, 2022 · 6 comments
Labels
discussion Discussion about anything

Comments

@boaks
Copy link

boaks commented Nov 7, 2022

contrained-node networks

=>

constrained-node networks

@sbernard31
Copy link
Contributor

sbernard31 commented Nov 8, 2022

Thx @boaks 🙏 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

@sbernard31 sbernard31 changed the title wiki/CoAP-over-TCP - typo Feedbacks about CoAP-over-TCP Nov 8, 2022
@sbernard31 sbernard31 added the discussion Discussion about anything label Nov 8, 2022
@boaks
Copy link
Author

boaks commented Nov 8, 2022

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
Copy link
Contributor

You sounds very skeptical about CoAP over TCP. 😅

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 ? 🤔

@boaks
Copy link
Author

boaks commented Nov 8, 2022

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
Copy link

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
Copy link
Contributor

Here some input about benefits of coap+tcp : eclipse-californium/californium#2092 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about anything
Projects
None yet
Development

No branches or pull requests

3 participants