General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] tiny monsters: multicast packets
Date: Sun, 29 May 2011 17:10:20 +0300	[thread overview]
Message-ID: <E8AF2E6D-6297-4063-A3E5-6A37C34ECBFC@gmail.com> (raw)
In-Reply-To: <BANLkTimkRWH82Jdu-Bo8gpbqwzXE=ewfzA@mail.gmail.com>


On 29 May, 2011, at 4:23 pm, Dave Taht wrote:

> In my last 2 months of travel, I have seen multicast packets, such as ARP, DHCP, MDNS, and now babel, all failing far, far, far more often than is desirable. I have seen DHCP fail completely for hours at a time, I've seen ARP take dozens of queries to resolve. 

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.  Broadcast packets are not supposed to be large ones, but wireless framing must add a lot of fixed overhead.

Given that the AP surely knows which hosts are attached to it at any given time, and what link rate they are currently sustaining, surely a saner design would have been either:

1) Broadcast the packet at the lowest link rate for all known attached hosts.

2) Unicast the packet to each attached host in turn, at that host's current link rate.

The latter sounds wasteful, but would still be a win on 802.11g in compatibility mode.  It also turns the AP into a star-topology hub, so hosts would send their broadcast packets by unicast to the AP, which would repeat them.

But presumably the brokenness is now baked firmly into the standard, and is therefore inescapable.  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.

I should check whether my Airport Base Station already supports that.

 - Jonathan


  reply	other threads:[~2011-05-29 13:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-29 13:23 Dave Taht
2011-05-29 14:10 ` Jonathan Morton [this message]
2011-05-29 15:10   ` Dave Taht
2011-05-29 15:33     ` Juliusz Chroboczek
2011-05-29 15:44       ` Dave Taht
2011-05-29 15:51         ` Juliusz Chroboczek
2011-05-29 16:07           ` Dave Taht
2011-05-29 16:07             ` Dave Taht
2011-05-29 16:53               ` Dave Taht
2011-05-29 16:33             ` Eric Dumazet
2011-05-29 17:02               ` Dave Taht
2011-05-29 17:17                 ` Eric Dumazet
2011-05-29 17:40                   ` Dave Taht
2011-05-29 17:47                     ` Jonathan Morton
2011-05-29 19:14                     ` Eric Dumazet
2011-05-29 15:21   ` Juliusz Chroboczek
2011-05-29 15:57     ` Dave Taht
2011-05-31 14:58       ` Jim Gettys

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=E8AF2E6D-6297-4063-A3E5-6A37C34ECBFC@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /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