The polling feature should be improved so it can support multicast.
At the moment, the polling mechanism consequently runs on the list of client MACs and sends unicast frames in turn to each list entry (or an empty frame to a client that is passive).
Suggestion: just before sending unicast frames, send the multicast frame(s) into the air. The clients, that have been marked as multicast recipients, listen on the air and receive the frame. If there are N multicast groups defined, then send into the air N frames, each for its group, respectively. After that, proceed to regular unicast-in-turn.
Without proper handling of wireless multicast and IGMP snooping Mikrotik is not operator-grade solution. The world of ISPing is shifting into ESP-ing (entertainment service providing) and therefore IP TV is a challenge. At the moment Mikrotik can not be a platform for building IPTV-ready network. If you think that it is enough for customer to just use “plain Internet”, then you are completely wrong - no one will buy plain Internet after a year and the ISPs that can provide triple-play will outcompete conventional ISPs.
So if you do not add support for these features now, after a year it will be too late.
A great deal of clear-thinking in that post -
I’d agree with the IPTV comments also, we face that right now with some prospective customers.
In-router and airside management of multicast traffic needs to be added, or “lack of market share/penetration” will happen…
… for the excellent RouterOS which really should grow and compete in future markets too.
Just my £0.02’s
Agree’d… we’re going to have to come up with something in the next 8-12 months if we want to maintain our rate of expansion.
one thing that will make a SIGNIFICANT impact on the ability to distribute streaming media reliably is to increase the link reliability by turning off the CSMA/CD subsystem… then those multicast packets will actually get to be transmitted and not sit there in a wait state just because someone turned on his microwave to make some pop-corn…
Multicast packets (also the broadcast packets) are not discriminated. Multicast packets are being sent out just like the unicast packets. For example, 2 clients and 3 streams - one for the first client, second for the second client and the third for multicast; first packet will be for the first client, second packet for the second client and the third packet for multicast and this will repat from the beginning.
To change something you should have a real arguments what isn’t working or working bad…
So does RouterOS actually do multicast on the RF by sending the packet out once and all clients receive it OR does it just emulate multicast by breaking the multicast up into a bunch of unicast packets each destined to one client?
I’d like to see comments here too:
We have this as a “real” problem with CCTV system where the codecs often use multicast.
Users see “multiple copies” on the airside, so we had to do tricks with filtering to block them.
