3 ms·
I wonder if multicast could be reclaimed as a layer in application-specific overlay networks. E.g. if a videoconference tool wanted to join a session, it would
by zajio1am 7y ago
I wonder if multicast could be reclaimed as a layer in application-specific overlay networks. E.g. if a videoconference tool wanted to join a session, it would create stateless IP tunnel to an access point, and then just run regular multicast RTP over that.
It would allow to use existing tools and infrastructure to scale that and remove forwarding and distribution from applications to a common layer. But it has a disadvantage that there is no common API for applications to setup ad-hoc transient IP tunnnels, as that is usually a privileged operation.
- saber6 7y agoDecent idea - one I've had before - but I can to the conclusion that I really wasn't solving a tangible problem. The real issue is you've just created an overlay tunnel architecture and have negated the benefits of native IP multicast. The idea is to reduce N number of duplicate unicast streams into 1 multicast stream tree - primarily to save bandwidth.
- convolvatron 7y agothat's kind of what the mbone was, a tunnel overlay. it just look a lot of fussing around for too many years. the only reason that a tunnel is privileged is that it creates a kernel interface. given that we can't really use tcp anyways, there isn't any reason why the whole stack can't live in user space on a generic UDP port. you would have to have pim or torrent style discovery/rendezvous machinery aside from efficiency, I wonder what the use case is?