From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by huchra.bufferbloat.net (Postfix) with SMTP id 32098201AD0 for ; Thu, 12 May 2011 21:58:49 -0700 (PDT) Received: (qmail 29342 invoked by uid 0); 13 May 2011 05:06:53 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 13 May 2011 05:06:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=avanw.com; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From:To:Content-Type:X-Identified-User; b=KVuQCN9SBLAb4QeFdFQjHU3lYBAz84V8vwCdtqwj5VoyBQfrs6F2DeCWUWzEWckKV0L0lXiN0xhX+UDnjEizMCXuydcTjMvJDQDqpmlDrMdoZSubmVk7yEfiNiu7T7xb; Received: from mail-fx0-f43.google.com ([209.85.161.43]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1QKkaS-0008IR-Mz for bloat@lists.bufferbloat.net; Thu, 12 May 2011 23:06:53 -0600 Received: by fxm3 with SMTP id 3so2511325fxm.16 for ; Thu, 12 May 2011 22:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.7 with SMTP id h7mr1190717fab.72.1305263211199; Thu, 12 May 2011 22:06:51 -0700 (PDT) Received: by 10.223.117.209 with HTTP; Thu, 12 May 2011 22:06:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2011 23:06:51 -0600 Message-ID: From: Kevin Gross To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=0015174412200abd4f04a32146a1 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.43 authed with kevin.gross@avanw.com} Subject: Re: [Bloat] QoS for mission critical packets on wireless networks X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 04:58:50 -0000 --0015174412200abd4f04a32146a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 delaye= d 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. Here's some detail - http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html = Kevin Gross On Wed, May 11, 2011 at 8:37 AM, Dave Taht wrote: > So... > > I think some *more* of the problems can be fixed by packet prioritization > on the wireless side. > > 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 interfac= es) > > 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. > > 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 thin= g" > (hsfc or htb+sfb) > > (strict prioritization of things like ping would lead to trivial DDOSes o= n > any of these protocols, so a tiny bandwidth reserve strikes me as a bette= r > approach) > > Wireless multicast is additionally weird in that it falls back to a very > low rate in order to do its work. > > Suggestions? comments? The current build of the "capetown" release of > bismark is very usable, has many cool features, including SFB, and suppor= ts > several off the shelf routers commonly available via best-buy and new-egg= . > > Anyone that's interested, please join in the effort. Certainly mere qdisc= s > are something more folk can fiddle with at a scripting and tcpdump level.= .. > > Bismark documentation (supports Netgear wndr3700, wndr3700v2, nanostation > M5, buffalo, and I just build an x86 kvm virtual machine that needs love) > > http://www.bufferbloat.net/projects/bismark/wiki > > Capetown builds: > http://huchra.bufferbloat.net/~bismark/ > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --0015174412200abd4f04a32146a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Be aware that, under some circumstances, APs=A0intentionally=A0hold all mul= ticast transmissions and=A0transmit=A0them on a schedule immediately follow= ing=A0beacon=A0frames. This can result in multicast delivery being delayed = 300 ms or more on top of buffer delays. You probably want to stick to unica= st for=A0initial=A0experiments to avoid=A0potential=A0indigestion due to th= is issue.

Here's some detail -=A0http= ://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html

Kevin Gross
<= br>
On Wed, May 11, 2011 at 8:37 AM, Dave Taht <dave.taht@gmail.= com> wrote:
So...

I think some *more* of the pro= blems can be fixed by packet prioritization on the wireless side.

So I started working on a set of wireless QoS ideas to see if I could i= mprove the situation. (wilst working on red for external, wired interfaces)=

I started off with a hard case - a broadcast multicast protocol tha= t runs over IPv6 called babel. It has the interesting property in that it s= ends a broadcast every 20 seconds from an identifiable address (theoretical= ly - see the fe80 discussion also on this list) and thus I can easily (or s= o I thought) observe, with enough nodes - delays and packet loss.

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, u= sing packet marking and a queuing discipline that does more of the "ri= ght thing" (hsfc or htb+sfb)

(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 bet= ter approach)

Wireless multicast is additionally weird in that it fa= lls back to a very low rate in order to do its work.

Suggestions? comments? The current build of the "capetown" re= lease 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.

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...

Bismark documentation (supports Netgear wndr3700, wndr3700v= 2, nanostation M5, buffalo, and I just build an x86 kvm virtual machine tha= t needs love)

http://www.bufferbloat.net/projects/bismark/wiki

Capetow= n builds:
http://huchra.bufferbloat.net/~bismark/

--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blo= gspot.com

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat


--0015174412200abd4f04a32146a1--