Be aware that, under some circumstances, APs intentionally hold all multicast transmissions and transmit them on a schedule immediately following beacon frames. This can result in multicast delivery being delayed 300 ms or more on top of buffer delays. You probably want to stick to unicast for initial experiments to avoid potential indigestion due to this issue.<div>
<br></div><div>Here's some detail - <a href="http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html" target="_blank">http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html</a></div>
<div><br></div><div><a href="http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html" target="_blank"></a>Kevin Gross<br></div><br><div class="gmail_quote">On Wed, May 11, 2011 at 8:37 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So...<br><br>I think some *more* of the problems can be fixed by packet prioritization on the wireless side.<br clear="all">

<br>So I started working on a set of wireless QoS ideas to see if I could improve the situation. (wilst working on red for external, wired interfaces)<br><br>I started off with a hard case - a broadcast multicast protocol that runs over IPv6 called babel. It has the interesting property in that it sends a broadcast every 20 seconds from an identifiable address (theoretically - see the fe80 discussion also on this list) and thus I can easily (or so I thought) observe, with enough nodes - delays and packet loss.<br>

<br>The idea I'm toying with now is to reserve a few percentage points of the bandwidth to mission critical packets such as those listed so far, using packet marking and a queuing discipline that does more of the "right thing" (hsfc or htb+sfb)<br>

<br>(strict prioritization of things like ping would lead to trivial DDOSes on any of these protocols, so a tiny bandwidth reserve strikes me as a better approach)<br><br>Wireless multicast is additionally weird in that it falls back to a very low rate in order to do its work.<br>

<br>Suggestions? comments? The current build of the "capetown" release of bismark is very usable, has many cool features, including SFB, and supports several off the shelf routers commonly available via best-buy and new-egg.<br>

<br>Anyone that's interested, please join in the effort. Certainly mere qdiscs are something more folk can fiddle with at a scripting and tcpdump level...<br><br>Bismark documentation (supports Netgear wndr3700, wndr3700v2, nanostation M5, buffalo, and I just build an x86 kvm virtual machine that needs love)<br>

<br><a href="http://www.bufferbloat.net/projects/bismark/wiki" target="_blank">http://www.bufferbloat.net/projects/bismark/wiki</a><br><br>Capetown builds:<br><a href="http://huchra.bufferbloat.net/~bismark/" target="_blank">http://huchra.bufferbloat.net/~bismark/</a><br>
<font color="#888888">
<br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: <a href="tel:1-239-829-5608" value="+12398295608" target="_blank">1-239-829-5608</a><br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>

</font><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>
<br></blockquote></div><br>