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

Simon Wunderlich
2010-12-09T21:02:52Z

[-- 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 --]