<div class="im">On Sun, May 29, 2011 at 8:10 AM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</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><br>
On 29 May, 2011, at 4:23 pm, Dave Taht wrote:<br>
<br>
> 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.<br>

<br>
</div>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.<br>

<br>
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:<br>
<br>
1) Broadcast the packet at the lowest link rate for all known attached hosts.<br>
<br>
2) Unicast the packet to each attached host in turn, at that host's current link rate.<br>
<br>
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.<br>

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

<br>
I should check whether my Airport Base Station already supports that.<br></blockquote></div><div><br>I
 just managed (after fighting with the switch in the wndr3700, and 
having to disable vlan support) to treat the wireless and wired lans 
separately [1]. <br>
<br>Result - 130+Mbit performance on iperf on the lan (up from 60Mbit), which is still pretty low - [2]<br><br>AND multicast stopped failing, in the limited testing I'd done so far. Yea... [3]<br><br>Yes, I think home routers should route, not bridge between widely disparate network types. <br>

<br>Bridging between a gige interface, a wireless N 5.x gigE interface, 
and a 2.4 ghz interface in compatability mode is just begging for 
trouble. Especially with a switch on the gigE interface that is also 
doing buffering itself.<br>
<br>Switching to routing throughout does induce more complexity in the 
network (3 or more subnets, rather than 1), and for the end-user...<br><br>...
 and all the multicast-isms that have arisen in the last decade such as 
mdns and daap would need to be looked at, to see if they can actually be
 made to work... (IGMPv2 ?)<br>
<br>but I can no longer think of a better solution to the nearly 
intolerable performance of today's wireless networks than starting to 
route them, and dealing with the consequences above. <br><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;">

<font color="#888888"><br>
 - Jonathan<br>
<br>
</font></blockquote><div class="im"><br><br clear="all">1: <a href="http://www.bufferbloat.net/issues/186" target="_blank">http://www.bufferbloat.net/issues/186</a><br></div>2: I'm still seeing enormous delays in the switch, however<br>
3: <a href="http://www.bufferbloat.net/projects/bismark-testbed/wiki/Experiment_-_QoS" target="_blank">http://www.bufferbloat.net/projects/bismark-testbed/wiki/Experiment_-_QoS</a><br>