This implies that Ziti layers the stream endpoints on top of a packet switched network, which could mean authentication of each packet and maintaining stream reliability in a different way than TCP does. Is that correct?
Yes. All connections are synthesized over the same connection to the overlay, making all your traffic look like "port 443" (or whatever port you use for the data plane). Inferring traffic from port number is thus made even harder.
OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.
Ok, thanks. The Ziti mesh optimizes for latency. Does it move existing streams around the fabric mesh when it finds a better route or only new streams? Are there plans for multicast?
Yes. If it needs to reroute, it will do so as long as the "terminating" site doesn't go offline. That's the one maintaining the "final" TCP stream so that one can't be rerouted.
Multicast support has been discussed, but it's not at the top of the pile of features that are getting worked at this time that I know of. I'm sort of on the other end, closer to the SDKs than the fabric, but I am pretty sure it's not in the immediate priority list as I recall.
OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.