> I thought about doing that for IHUs, since they're conceptually unicast, > but actually sent as multicast: this is inefficient when multicast is > emulated. But the optimisation is probably not worth it for a realistic > number of neighbours.
It's already implemented, actually: http://git.wifi.pps.univ-paris-diderot.fr/?p=babeld.git;a=blob;f=message.c;h=99c3008b7d8c2ca55b5fb0987128769c7411ab73#l1443 It's not worth it in general, since sending IHUs over unicast prevents aggregation. Currently, 100 IHUs are sent in a single multicast packet; if sent over unicast, they would require 100 distinct packets. We're currently very conservative, we only send a unicast IHU if we already know we're going to send a unicast packet to that particular neighbour in the near future. I'm sure a better heuristic can be devised. > regarding updates, I don't quite understand. Don't we want to send them > to *all* neighbours anyway? Yes, but for small numbers of neighbours it's not clear that sending one multicast is cheaper than sending n unicast packets. It depends on the link layer: on a broadcast Ethernet, a multicast is just as cheap as a unicast; on a switched Ethernet, it depends on the topology, while on WiFi or Tinc, multicasts are excessively expensive. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
