[B.A.T.M.A.N.] Alternative Multicast Optimizations

Linus Lüssing linus.luessing at web.de
Thu Dec 16 09:41:31 CET 2010


Hi Chris,

thanks a lot for publishing your patches here. It's obvious, that you also put quite some work into this. I don't really wanna discuss how you've implemented things here, but I'm more interested in the conceptual part for now, so more the "what" and not the "how". Let me try to describe first how I'm understanding your concept and please correct me if I understood something wrong or if I'm missing important parts.

It looks like the basic idea is similar to Simon's and my approach so far: You are also sending packets to mark the path so that a node knows if it has to forward a certain multicast data packet later or not. You're also sending one bundled packet with the originator's adresses to the according next-hop nodes which are responsible for forwarding the traffic. You are doing this proactively, too, currently at an interval of once per second.

What looks different to me is that you are so far non-group specific: You are building up a single tree for each originator towards all other nodes. Because an originator's mcast-discovery packet (usually) reaches every other node in the network, you are not using timeouts for invalidating the marking, but a new mcast-discovery packet deletes are adds the marking. Another thing that seems different is, that you are always sending any multicast/broadcast packet via unicast directly to each next hop router in charge.

One thing I didn't quite get from the code is, why are you memorizing a next hop router's TQ value? Could you explain that a little more?


Finally I'd have some questions about your conceptual decisions and would like to explain, why we decided to do things differently in those ones and what our point of view was.
 
As Simon already pointed out in response to Andrew, we've mainly been focussing on networks which are sparse in terms of multicast nodes in relation to all nodes. We wanted to minimize the amount of traffic in this case where only a few of all nodes really want to receive certain multicast packets for one thing, and only a few nodes sending multicast data for another. And I also especially have large scale metropolitan area (community) mesh networks in mind, where it is usually very unlikely that for instance all participants in the mesh would like to listen to the same radio station at the same time - or would like to listen to the radio station of all other mesh nodes all at once. May I ask what kind of scenario/topology you had in mind for your case? How many nodes will want to receive the same multicast stream, how many senders do you expect (relatively to all nodes in the mesh)?



More information about the B.A.T.M.A.N mailing list