Re: [B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]