On Sun, May 29, 2011 at 9:21 AM, Juliusz Chroboczek wrote: > > And the irony is that the lower speed is specifically chosen for > > multicast in order to make sure all clients in range can hear them > > reliably. > > It was my understanding that it was done for compatibility with older > devices, since 2 Mbit/s is the fastest rate supported by pre-B > spread-spectrum hardware. > > And thus, everybody loses. I doubt there is much 802.11b gear still active in the field. > > 2) Unicast the packet to each attached host in turn, > > Both DVMR and the multicast part of BATMAN-adv do that for router-router > links. > > A better link-layer solution, IMHO, would be to multicast (with ARQ) the > packet at a reasonably high rate (say, the median of the STAs subscribed > to the multicast group), I'm not deeply familiar with many of the multicast protocols in use today, such as MDNS. I AM under the impression that IGMP has not been well used or tested recently. I did start building uftp which I think I understand, and lets me have very tunable rates, and definately uses igmp. > and then unicast it to all STAs that failed to > return an ACK. Interestingly, if the new multicast frame format is > incompatible with the normal 802.11 format, then this scheme is > compatible with legacy devices, which won't ever see the multicast frame > and hence won't return an ACK. > > While I can see this helping for many protocols ARP seems a problem, in that you'd like to stop broadcasting after you get a good response, and that's at a higher layer. > So the workaround is to isolate the broadcast domains of wired > > networks and wireless networks by making the home router into... > > a router. Wireless on one subnet, wired on another, and so ARP > > between the two turns into ARP to the router alone - much more > > scalable. > > OpenWRT is your friend. > > It certainly is! I would never have got this much insight into these problems, so fast, had I not poked into the depths of the linux kernel, patched it up (with the help of many here on this list) and tried to build a version of openwrt based on everything we've learned about bufferbloat so far, and setup a lab to stress it out. Future directions are becoming apparent, rapidly. > -- Juliusz > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com