General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Kevin Gross <kevin.gross@avanw.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] QoS for mission critical packets on wireless networks
Date: Thu, 12 May 2011 23:06:51 -0600	[thread overview]
Message-ID: <BANLkTikzM=s-xBowWhoik5_GixALqzXBbw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimGyr_n48XDu89EZR6RPt2+CuUacw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

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.

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

<http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html>Kevin
Gross

On Wed, May 11, 2011 at 8:37 AM, Dave Taht <dave.taht@gmail.com> 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 interfaces)
>
> 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 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 better
> 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 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, 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äht
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3642 bytes --]

      reply	other threads:[~2011-05-13  4:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 14:37 Dave Taht
2011-05-13  5:06 ` Kevin Gross [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTikzM=s-xBowWhoik5_GixALqzXBbw@mail.gmail.com' \
    --to=kevin.gross@avanw.com \
    --cc=bloat@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox