On Sun, May 29, 2011 at 9:21 AM, Juliusz Chroboczek
<jch@pps.jussieu.fr> 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