From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 48D9F201210 for ; Sun, 29 May 2011 07:54:47 -0700 (PDT) Received: by iyi20 with SMTP id 20so3795624iyi.16 for ; Sun, 29 May 2011 08:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PXIIdZZjCHwt0/fLU4xSIApT33Ek2REf2SdA7MmQJdY=; b=hVuWYRnDmEQgpIJaVjBG1Lvbhh0A2e/SuZMTZnunQlVuVOnrG5ehzmn3WTQwt96pWz 4RXLp9fCSkcN8Yvw4QHnia1TTpQCF4wP/kcXxzqtAfbAv4iWK7iQd2UKaSrvTp4m1mXf zlydFlO5vu9yhXgCWVr24teP6ItI7/z4PKMFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=siFcVf8wWNDRuzS77te10a84gK26gz7+V2v20LkiL2BI+js6aTe+mMQJrG5VbNVfLe 05UHkTAfaUIj5iizUE/4dsr+SoMV4vZLP6wB5mtGJ9j4dFnaa9h6yKapH3ONRUpnJiN2 afIM/TnuC/CVDj+hF5gLBNvoUq967WxVhRX3U= MIME-Version: 1.0 Received: by 10.231.253.87 with SMTP id mz23mr4734658ibb.197.1306681834790; Sun, 29 May 2011 08:10:34 -0700 (PDT) Received: by 10.231.39.203 with HTTP; Sun, 29 May 2011 08:10:34 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 May 2011 09:10:34 -0600 Message-ID: From: Dave Taht To: bloat Content-Type: multipart/alternative; boundary=00032555dc3698ded104a46b9205 Subject: Re: [Bloat] tiny monsters: multicast packets 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: Sun, 29 May 2011 14:54:47 -0000 --00032555dc3698ded104a46b9205 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 29, 2011 at 8:10 AM, Jonathan Morton wrote: > > 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. > 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]. Result - 130+Mbit performance on iperf on the lan (up from 60Mbit), which is still pretty low - [2] AND multicast stopped failing, in the limited testing I'd done so far. Yea... [3] Yes, I think home routers should route, not bridge between widely disparate network types. 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. Switching to routing throughout does induce more complexity in the network (3 or more subnets, rather than 1), and for the end-user... ... 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 ?) 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. > - Jonathan > > 1: http://www.bufferbloat.net/issues/186 2: I'm still seeing enormous delays in the switch, however 3: http://www.bufferbloat.net/projects/bismark-testbed/wiki/Experiment_-_QoS --00032555dc3698ded104a46b9205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 29, 2011 at 8:10 AM, Jonathan Morton <ch= romatix99@gmail.com> wrote:

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

> In my last 2 months of travel, I have seen multicast packets, such=20 as ARP, DHCP, MDNS, and now babel, all failing far, far, far more often=20 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=20 multicast in order to make sure all clients in range can hear them=20 reliably. =A0Broadcast packets are not supposed to be large ones, but=20 wireless framing must add a lot of fixed overhead.

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

1) Broadcast the packet at the lowest link rate for all known attached host= s.

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

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

But presumably the brokenness is now baked firmly into the standard, and is therefore inescapable. =A0So the workaround is to isolate the=20 broadcast domains of wired networks and wireless networks by making the=20 home router into... =A0a router. =A0Wireless on one subnet, wired on=20 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.

I just managed (after fighting with the switch in the wndr3700, and=20 having to disable vlan support) to treat the wireless and wired lans=20 separately [1].

Result - 130+Mbit performance on iperf on the lan (up from 60Mbit), whi= ch is still pretty low - [2]

AND multicast stopped failing, in the l= imited testing I'd done so far. Yea... [3]

Yes, I think home rou= ters should route, not bridge between widely disparate network types.

Bridging between a gige interface, a wireless N 5.x gigE interface,=20 and a 2.4 ghz interface in compatability mode is just begging for=20 trouble. Especially with a switch on the gigE interface that is also=20 doing buffering itself.

Switching to routing throughout does induce more complexity in the=20 network (3 or more subnets, rather than 1), and for the end-user...

= ... and all the multicast-isms that have arisen in the last decade such as=20 mdns and daap would need to be looked at, to see if they can actually be made to work... (IGMPv2 ?)

but I can no longer think of a better solution to the nearly=20 intolerable performance of today's wireless networks than starting to= =20 route them, and dealing with the consequences above.



=A0- Jonathan



1: http://www.bufferbl= oat.net/issues/186
2: I'm still seeing enormous delays in = the switch, however
3: http://www.bufferbloat.net/projects/bismark= -testbed/wiki/Experiment_-_QoS
--00032555dc3698ded104a46b9205--