From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 9377521F390 for ; Mon, 2 Feb 2015 07:25:46 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so5465327obc.1 for ; Mon, 02 Feb 2015 07:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Hj5hp/uMHCZVYWhB9zIJms516bO1PD2KCttcU0NGh/M=; b=TL3lAPl9RFq3dwOE2BFpUaiLzz2T7OsUunOnAw7Ob4qoJzfux45/IeCLqfLATyxvGF OzydWY6PTO4fNOFrWlSHrjwb0+hquPG6Gz/QVsqEe/XfJ8y4nqsv4VOS1mZIpLBULmho ezlRI9Ah2mIkFDwOpvnD1tRZhMDomV/PFfS53c1aV011b3y7kxHGNzRSoNNrFUjXyZs+ dW9cDzTiqXtj58cJ/CtZpFVWQKvtk7ckl8zjWIpASkCCV+wUTGw2F0HgJdWAlOQaXt1N 5tZ4zU2L4f5mkY+lpfVpIn2RFVYGc/7PZrsPXca1KxOJ3eWacjQzQLnPb9Ea8G5vMvm4 0lqw== MIME-Version: 1.0 X-Received: by 10.60.23.99 with SMTP id l3mr12323654oef.66.1422890745310; Mon, 02 Feb 2015 07:25:45 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.76.5 with HTTP; Mon, 2 Feb 2015 07:25:45 -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> Date: Mon, 2 Feb 2015 10:25:45 -0500 X-Google-Sender-Auth: XoYPVN3FHIfFkNGiZcdstBTuBoc Message-ID: From: Jim Gettys To: Avery Pennarun Content-Type: text/plain; charset=UTF-8 Cc: "dstanley@arubanetworks.com" , Andrew McGregor , 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 15:26:14 -0000 On Sun, Feb 1, 2015 at 11:04 PM, Avery Pennarun wrote: > 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 gather some Windows drivers from some vendors do this unicast fanout (claim made by one of their engineers in an early homenet meeting). > > 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. So long as it times out in some very small, finite time. We don't want a repeat of the infinite retry bugs Dave found in drivers a few years back... "Reliable multicast" ultimately is an oxymoron, particularly on a medium with hundreds/one bandwidth variation. One remote low bandwidth station cannot be allowed to drag the entire network to the basement. - Jim