Hey Andrew,
thank you for your comments and the review!
On Wed, Dec 08, 2010 at 08:29:15AM +0100, Andrew Lunn wrote:
[...]
Do you think you could do a search/replace with "multicast MAC address"?
You've got a point, we can change that.
[...]
Is this symmetric assumption a problem? Depends one the use case. Your PIM gateway into the multicast cloud should be a member of the group. It has to receive the packets from the local hosts, so it can forward them upstream to the RP, the root of the distribution tree. So your traffic coming from upstream should be O.K. However if you have a webcam which is multicasting a video stream, it might not be a member of the group, since it is not interesting in receiving video streams, just sending them. So in this use case you won't have any benefit from your scheme.
The symmetric assumption is a nice simplification to get started, but i think you need to have a good plan for allowing none members to send multicast traffic.
Yup, we had a "symmetric" application in mind when designing this algorithm, but we have discussed ideas to improve the algorithm to a more general scheme. For example we could detect if a multicast MAC address is sent to through the soft interface, and then start sending tracker packets accordingly - this method might need some tuning however, the build up might take some time, and maybe we should avoid building it up for single packets.
Detecting non-local receivers (like SNMP snooping) appears to be the harder task IMHO to become more general - you will most likely not receive your webcam stream with your WiFi AP. :)
Have you considered handing broadcast packets as multicast packets? Broadcast is just a special case of multicast.
That is right, but I don't think this is a good idea to use this multicast approach for broadcast in this case. From a theoretical point of view, this algorithm is a group aware one for "sparse" mesh networks, where the number of group members is quite small (< 50% of all mesh nodes). If all nodes were in a group (as it would be the case for broadcast), the overhead of the tracker packets would most likely nullify any gain. Non-group-aware algorithm like MPR and its variations [1] are probably more suited for this case. But maybe someone will find a clever workaround. ;)
best regards, Simon
[1] http://tools.ietf.org/html/draft-ietf-manet-smf-10 Appendices A to C