Sun Nov 28 17:17:38 CET 2010
Your event-based marking compared to our timeout-based approach for marking forwarding nodes sounds interesting. We had been argueing about how large to set such timeouts in our case, but of course that can depend on the scenario, too and therefore could need extra effort for tweaking for the user in some (special) scenarios, which usually is not desirable. What I was wondering, do you think the event based approach could make the multicast transimission less reliable? How likely do you consider the following: A node is on the edge of being a node for forwarding mulicast data for a certain originator, the path qualities of this node and another one are very similiar, resulting in frequent route flapping. Couldn't it happen quite often, that in such a case a node might get mcast-discovery packets disabling the forwarding, but miss the enabling packets? How likely do you think that could be?
For the unicast vs. broadcast forwarding, we were actually peeking at the olsr-bmf a little. They are also using this mcast-fanout to dynamically decide on how to forward the packet, depending on the number of receiving next hop nodes. Ok, I think you are right that in the case of the default 1/2 mbit/s multicast rate, it does not make that much sense to forward packets via broadcast (unless you have >20 neighbours that'd like to receive it on the next hop). For our use-case however we had decided on using higher multicast rates, as that should usually be reliable enough with our 3x broadcast but still needing less airtime, even if there were just a few neighbours interested in the packets.
I'm very interested in hearing your point of view on these aspects. Please correct me if I misunderstood something about your concept or if I'm missing something important. I'd also be curious about what you think how similar/different our approaches are and where you see the advantages and disadvantages of each.
More information about the B.A.T.M.A.N