From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.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 A81B0201728 for ; Sun, 29 May 2011 08:41:35 -0700 (PDT) Received: by iwn8 with SMTP id 8so3731707iwn.16 for ; Sun, 29 May 2011 08:57:24 -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:cc:content-type; bh=TukLOcKvxKSMdqqExyzoNoT+41HxDrb6fo7Azykg8BQ=; b=QyxrCov/9PgjRobvG8snBKcNZtaWbp56fh3DSv5B5IDOcUYCW16KR4qUFhPv4V9LgD ac7Ei48TVUWUGJprxElPgcoJJn60FZPyEDxN+hyyyyiyamQknXDyN/4MRTQ6EUvJ/7+S TKtlKqqWdgI0Ny1q8PP2nxdq0dB1ZFiHpIXvk= 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 :cc:content-type; b=w+2pAR/wB8lZwXCMWCAYc+5qtUMFBEzLqK/LN/RZ07KnhuVJAl9zV/QtEPbEuqSYv1 x3xH2G4fQEqquDlrtOCck4xjeX5q/lKSv3/9mzuvvswLDAeN8uFIaEJ1GlyW3QcHngzX SW+ZbwK1VwOnDASIXZFGtjCOSJe6zo/CKYwh8= MIME-Version: 1.0 Received: by 10.42.94.6 with SMTP id z6mr6064539icm.91.1306684644193; Sun, 29 May 2011 08:57:24 -0700 (PDT) Received: by 10.231.39.203 with HTTP; Sun, 29 May 2011 08:57:24 -0700 (PDT) In-Reply-To: <7ipqn1bkhy.fsf@lanthane.pps.jussieu.fr> References: <7ipqn1bkhy.fsf@lanthane.pps.jussieu.fr> Date: Sun, 29 May 2011 09:57:24 -0600 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=20cf3036405f0cf3e604a46c3ac7 Cc: bloat 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 15:41:35 -0000 --20cf3036405f0cf3e604a46c3ac7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2011 at 9:21 AM, Juliusz Chroboczek wro= te: > > 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. > > It was my understanding that it was done for compatibility with older > devices, since 2 Mbit/s is the fastest rate supported by pre-B > spread-spectrum hardware. > > And thus, everybody loses. I doubt there is much 802.11b gear still active in the field. > > 2) Unicast the packet to each attached host in turn, > > Both DVMR and the multicast part of BATMAN-adv do that for router-router > links. > > A better link-layer solution, IMHO, would be to multicast (with ARQ) the > packet at a reasonably high rate (say, the median of the STAs subscribed > to the multicast group), I'm not deeply familiar with many of the multicast protocols in use today, such as MDNS. I AM under the impression that IGMP has not been well used or tested recently. I did start building uftp which I think I understand, and lets me have very tunable rates, and definately uses igmp. > and then unicast it to all STAs that failed to > return an ACK. Interestingly, if the new multicast frame format is > incompatible with the normal 802.11 format, then this scheme is > compatible with legacy devices, which won't ever see the multicast frame > and hence won't return an ACK. > > While I can see this helping for many protocols ARP seems a problem, in tha= t you'd like to stop broadcasting after you get a good response, and that's a= t a higher layer. > 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. > > OpenWRT is your friend. > > It certainly is! I would never have got this much insight into these problems, so fast, had I not poked into the depths of the linux kernel, patched it up (with the help of many here on this list) and tried to build = a version of openwrt based on everything we've learned about bufferbloat so far, and setup a lab to stress it out. Future directions are becoming apparent, rapidly. > -- Juliusz > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --20cf3036405f0cf3e604a46c3ac7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, May 29, 2011 at 9:21 AM, Juliusz= Chroboczek <jch= @pps.jussieu.fr> wrote:
> And the irony is that the lower speed is specificall= y chosen for
> multicast in order to make sure all clients in range can hear them
> reliably.

It was my understanding that it was done for compatibility with older=
devices, since 2 Mbit/s is the fastest rate supported by pre-B
spread-spectrum hardware.


And thus, everybody loses= . I doubt there is much 802.11b gear still active in the field.
=A0
<= /div>
> 2) Unicast the packet to each attached host in turn,

Both DVMR and the multicast part of BATMAN-adv do that for router-rou= ter
links.

A better link-layer solution, IMHO, would be to multicast (with ARQ) the packet at a reasonably high rate (say, the median of the STAs subscribed to the multicast group),

I'm not deeply familiar = with many of the=A0 multicast protocols in use today, such as MDNS. I AM un= der the impression that IGMP has not been well used or tested recently.
I did start building uftp which I think I understand, and lets me have = very tunable rates, and definately uses igmp.
=A0
and then unicast it to all STAs that failed to
return an ACK. =A0Interestingly, if the new multicast frame format is
incompatible with the normal 802.11 format, then this scheme is
compatible with legacy devices, which won't ever see the multicast fram= e
and hence won't return an ACK.


While I can see this help= ing for many protocols ARP seems a problem, in that you'd like to stop = broadcasting after you get a good response, and that's at a higher laye= r.

> So the workaround is to isolate the broadcast domains of wired
> networks and wireless networks by making the home router into...
> a router. =A0Wireless on one subnet, wired on another, and so ARP
> between the two turns into ARP to the router alone - much more
> scalable.

OpenWRT is your friend.


It certainly is! I would never have got this much= insight into these problems, so fast, had I not poked into the depths of t= he linux kernel, patched it up (with the help of many here on this list) an= d tried to build a version of openwrt based on everything we've learned= about bufferbloat so far, and setup a lab to stress it out.

Future directions are becoming apparent, rapidly.
=A0
-- Juliusz
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat



--
Dave T=E4ht
SKYPE: d= avetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--20cf3036405f0cf3e604a46c3ac7--