Hi to all of you again. Thank you for your great project!
There is an idea for implementing p2p connections with openziti for increasing speed of huge data transfers between openziti clients and reduce traffic on edge nodes.
If it’ll be possible to implement WebRTC for example and use edge server as STUN/TURN, it’ll be great!
You could just run a client to edge router with the link listener on … this would require inbound ports on the edge router side which we do not really like.
More important, I would go back to your original requirements and figure out what we can do within the desired architecture of OpenZiti:
We utilise a distributed mesh overlay for a few reasons;
(1) it allows outbound only on both side so that you do not get issues where UDP is blocked (wireguard has this issues, that’s why Tailscale built their DERP feature) while offering more inherent security and removes need for complexity of FW etc.
(2) Smart routing of the fabric means that if we make it diverse enough we can find paths which give lower E2E latency by jumping across different underlay networks
While OpenZiti operates on TLS today, we have plans after HA is delivered to move the outer connection to UDP; this will help in use cases that need huge data transfer.
After switching to UDP, we will implement Transwarp/Dilithium (ziti/transwarp_b1.md at v0.19.8 · openziti/ziti · GitHub) which is a high-performance data plane for OpenZiti. T/D is pretty much built and documented quite a while ago, only we chose to prioritise other features and functions before implementing it.
Taking this all together, I personally do not see what a p2p connection will give us except in a few very edge use cases… would be great to get yours and other thoughts on this.
Hi @Wild ,
Thank you, your appreciation is appreciated
P2P (direct SDK <-> SDK) is something we’ve talked about doing and we’ll hopefully have a chance to investigate it in the next round of routing improvements. We currently working on wrapping up HA control and after that we’ll be looking at improving routing. We’d like to be able to support multi-path routing from the SDK. If we could offer that and direct SDK-to-SDK you’d be able to pick between performance and resilience on the one hand and low cost on the other. There is a lot of things on the list, between multi-path, pushing the fabric to the sdk, DTLS links and SDK P2P, a lot of which are orthogonal to each other, but I’m personally looking forward to getting started, lots of interesting work there. It’s going to be challenging to prioritize.