<br><br><div class="gmail_quote">On Sun, May 29, 2011 at 9:21 AM, Juliusz Chroboczek <span dir="ltr"><<a href="mailto:jch@pps.jussieu.fr">jch@pps.jussieu.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> And the irony is that the lower speed is specifically chosen for<br>
> multicast in order to make sure all clients in range can hear them<br>
> reliably.<br>
<br>
</div>It was my understanding that it was done for compatibility with older<br>
devices, since 2 Mbit/s is the fastest rate supported by pre-B<br>
spread-spectrum hardware.<br>
<div class="im"><br></div></blockquote><div><br>And thus, everybody loses. I doubt there is much 802.11b gear still active in the field.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> 2) Unicast the packet to each attached host in turn,<br>
<br>
</div>Both DVMR and the multicast part of BATMAN-adv do that for router-router<br>
links.<br>
<br>
A better link-layer solution, IMHO, would be to multicast (with ARQ) the<br>
packet at a reasonably high rate (say, the median of the STAs subscribed<br>
to the multicast group), </blockquote><div><br>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. <br>
<br>I did start building uftp which I think I understand, and lets me have very tunable rates, and definately uses igmp.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
and then unicast it to all STAs that failed to<br>
return an ACK.  Interestingly, if the new multicast frame format is<br>
incompatible with the normal 802.11 format, then this scheme is<br>
compatible with legacy devices, which won't ever see the multicast frame<br>
and hence won't return an ACK.<br>
<div class="im"><br></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> So the workaround is to isolate the broadcast domains of wired<br>
> networks and wireless networks by making the home router into...<br>
> a router.  Wireless on one subnet, wired on another, and so ARP<br>
> between the two turns into ARP to the router alone - much more<br>
> scalable.<br>
<br>
</div>OpenWRT is your friend.<br>
<br></blockquote><div><br>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.<br>
<br>Future directions are becoming apparent, rapidly.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
-- Juliusz<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>