From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2517E21F36B for ; Sun, 1 Feb 2015 20:05:03 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id q107so45879375qgd.4 for ; Sun, 01 Feb 2015 20:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/wQ88ZPPHb2OJlk1hiay+LQMw16fFk2P37+BKgiTMhQ=; b=a7FVfGvV7/RcErejgUowrnZgT5M0aOgGFCJDDB7MR9rr69OONcXkOkX38Vw052tNHS TDzk1XzjpIgGFacfXyAm6t69lqDSM8iHVNgZT0gLYiZo+zjaRolRn8hkuhX3apTKzYpz isF7F6sxrhPH8Sm94yqb5wefs1KMwPrmtAnHy9ofYlDEQu14r2aj7Th69AWtRGPI3y5p a1ylVujU64QxpMHPbDMwv0CZyWQYvt7AOG9ci+7v+hIcbYUk+/fIssY/kXTcT3m8REBX 0f3O4AIdHlGMW8OBe3dUBNwEypcIdZ1Qk9MYjp8JvS+45QId/5e8nq0VAFa2AvcPpK6q wJcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/wQ88ZPPHb2OJlk1hiay+LQMw16fFk2P37+BKgiTMhQ=; b=BXfPbxMuaBy3IRrHTwRTNxoIAslKBGvZ9Ert0d5arP2pnCslDPpGffLygbsql0TYFr eMPU++IoS9N2CIfWzMpz8qe8egHbezRTyA5urhuYoXWsN28Rezt7Lr536agPQtuuA2QE CrXwmSWmeKrbD0+Xs8k8zwYw1PHupY3Bz6zfyOfmGMc9JVhSguiLmVqGkhAQ/ZlYQ/49 +1Gdb9rwLudBCMtlZm8pOoGke16kiaXYsX24qgpWc6wEzu3/01CLDqBj35pFhXNpNLSm hStyIEaNudq6ym8XS/5sa4Ps/19AZjn5gZPOHECZAB82VNwpRtrxwTsO03DrEOZnmMTY Q72w== X-Gm-Message-State: ALoCoQneNTTELQWkX7aYzZ9s0ov1PMb1PCsqfO7FU7Fux3T1Df+08tzsncaIzrZY6s9zyFPNf0Tb X-Received: by 10.140.49.5 with SMTP id p5mr32544909qga.15.1422849902240; Sun, 01 Feb 2015 20:05:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.165.193 with HTTP; Sun, 1 Feb 2015 20:04:41 -0800 (PST) In-Reply-To: References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <54CB5D08.2070906@broadcom.com> <1422623975.21689.77.camel@edumazet-glaptop2.roam.corp.google.com> <54CB8B69.1070807@broadcom.com> <1422741065.199624134@apps.rackspace.com> <1422801814.796219699@apps.rackspace.com> From: Avery Pennarun Date: Sun, 1 Feb 2015 23:04:41 -0500 Message-ID: To: Andrew McGregor Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 01 Feb 2015 22:36:12 -0800 Cc: dstanley@arubanetworks.com, Stig Thormodsrud , netdev@vger.kernel.org, linux-wireless , Jesper Dangaard Brouer , "cerowrt-devel@lists.bufferbloat.net" , Matt Mathis , Derrick Pallas , Kathy Giori , Mahesh Paolini-Subramanya , Jonathan Morton , Tim Shepard Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing` X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 04:05:32 -0000 On Sun, Feb 1, 2015 at 6:34 PM, Andrew McGregor wrote: > I missed one item in my list of potential improvements: the most braindead > thing 802.11 has to say about rates is that broadcast and multicast packets > should be sent at 'the lowest basic rate in the current supported rate set', > which is really wasteful. There are a couple of ways of dealing with this: > one, ignore the standard and pick the rate that is most likely to get the > frame to as many neighbours as possible (by a scan of the Minstrel tables). > Or two, fan it out as unicast, which might well take less airtime (due to > aggregation) as well as being much more likely to be delivered, since you > get ACKs and retries by doing that. As far as I can see, the only sensible thing to do with multicast/broadcast is some variation of the unicast fanout, unless you've got a truly huge number of nodes. I don't know of any protocols (certainly not video streams) that actually work well with the kind of packet loss you see at medium/long range with wifi if retransmits aren't used. I've heard that openwrt already has a patch included that does this kind of fanout at the bridge layer. I've also heard of a new "reliable multicast" in some newer 802.11 variant, which essentially sends out a single multicast packet and expects an ACK from each intended recipient. Other than adding complexity, it seems like the best of both worlds.