TCP over Matter/Thread
Any body tried TCP over thread wireless network? I know Thread latency will make TCP complicated, but it would allow to punch home gateway and CGNAT with a keep-alive of 10ich minutes in place of 30sec we need to use over UDP. I'm curious to know if someone tried and tweaked the server TCP stack (RTO, F-RTO..)
2 Replies
@Andru-Khan or @Umesh Lokhande, do you have experience working with the Matter/Thread protocol?
Hey @julien, here are some thoughts from a LI connection:
First off no, I never got my teams to try this but boy did we want to. The idea that I had was to use but torrent seeding for high latency allowed things like pushing out a new firmware image (best with A/B image bootloaders probably)
But from a direct technology standpoint I do not know of anyone trying to pull those things in to the stack. Or how any particular TCP dependent tool/app/seevice would play nicely with the dependencies in the thread stack.
Not much of an answer though admittedly.
“Great idea, not aware anyone has tried, not aware directly of impediments (cause didn’t try), should work (but prepare for makefile fun times and dependency bingo).”
What I imagine folks are doing is writing stateful application gateway software that uses all the tricks of TCP for guaranteed delivery, but is actually queuing and supervising as business logic. Not just giving guaranteed delivery over to the stack.
And especially so because so many of the stacks from Cloud to Ground do not offer meaningful examples of how to use / have any kind of parallel connection that can be more persistent and than basic out of the box MQTT setups (AWS IoT I’m looking at you lol 😂). So if you aren’t solving the QoS problems with your MQTT behavior anyway, many folks application stacks will have had more issues with guaranteed delivery behaviors in reaching the border router in the first place. So TCP on the 802.15.4 mesh in particular doesn’t directly solve an application problem at all system level (I.e. app / user / cloud to device purposeful real world actual things like turn on a light).
I’ll see if I can get him in the server.
More:
"I seriously doubt that the determinism of ACKs thst really do the sequencing reassembly and guaranteed delivery is going to be fun to tune such that it doesn’t flood PANs at the edge.
This is already a problem with MQTT that drives stateful message queuing, but again typically done with stateful biz logic than just letting TCP loose on the routes between PANs and their nodes.
I bet if you do find someone who’s tried they’ll have stories about for lack of a better term, “getting the tcp and udp traffic to ‘play nice.’”
More:
"Were it to go anywhere I hope that ZephyrOS is a place to play.
Getting LF blessing on any stack pieces of something like this matters a lot.
I think some hideous industrial legacy protocols like Profibus and Ughh… Modbus/TCP … eghk… anyways, I can see industrial applications for guaranteed delivery over thread.
But I’d do it at the application layer and then horse race that against truly including TCP. See if it really solves a problem (or creates one).
If end point to end point global relationships ie routing are the real need then look at Google Weave. That stuff is creepy amazing at making immutable endpoints out of like, a parameter.
If you only want your ex girlfriend’s parrot to have rites and perms to the dimming curve on your lightbulb in the bathroom? Hey go for it, and may TLS be with you 🤷♂️
IPv6 name space so big every octet is a whole unicast / multicast universe.
So the highly likely to be globally unique IPv6 short addresses can substitute as literally unique end points in a REST-y / sockets like world.
So you can build deterministic IPv6 based UUID abstracts straight ought of the data model. It’s brilliant."
Cont.
"You could run LDAP and grant perms to like… a single screw on a battleship.
This stuff enables LDAP for all the stuff. Anywhere. Everywhere.
Which combined with DMCA means what?"
@LMtx have you worked w/ thread at all?
More from LI:
"DMCA plus uuids for all the things?
Well when it’s a cloud we’d call it multi-tenant. Same for a building. How about a streaming service?
How about a global policy via opt-in for thermostat set points in a cohort of homes enrolled in demand response programs for energy rebates and
incentives at scale?
You need digital enforceable proof that no one “sudo raise-temperature 76.00”
The full stack is going to rent us the ability to raise the thermostat like it’s a hotel room 😆
QED"
Cont.
(Hypothesis disclaimer, the architectural capability does not imply anyone anywhere’s intent but hey, clearly I’m an open source proponent)
Cont.
"Tl;dr make sure the guaranteed delivery need truly needs someone to side quest TCP, but otherwise it’d have to be some kind of compliance driven use case for a node that’d make me care — like a PCI 3.0 compliant energy meter that can financially transact with the grid — then I’d care enough about wrote application of standard stacks enough to slog through the proof testing that the TCP port performs
Otherwise does Thread need TCP? It’d better be valuable cause it’s gonna be hard"
Nope, it is still on my TODO list :/