From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0E3733B2A0 for ; Thu, 28 Apr 2016 09:10:06 -0400 (EDT) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BAC4828040A; Thu, 28 Apr 2016 09:10:06 -0400 (EDT) Received: from app14.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AB139280404; Thu, 28 Apr 2016 09:10:06 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app14.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Thu, 28 Apr 2016 09:10:06 -0400 Received: from reed.com (localhost [127.0.0.1]) by app14.wa-webapps.iad3a (Postfix) with ESMTP id 93B5A6144E; Thu, 28 Apr 2016 09:10:06 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 28 Apr 2016 09:10:06 -0400 (EDT) Date: Thu, 28 Apr 2016 09:10:06 -0400 (EDT) From: dpreed@reed.com To: "Aaron Wood" Cc: "Dave Taht" , make-wifi-fast@lists.bufferbloat.net, "babel-users@lists.alioth.debian.org" , "cerowrt-devel@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: X-Auth-ID: dpreed@reed.com Message-ID: <1461849006.60252745@apps.rackspace.com> X-Mailer: webmail/12.4.1-RC Subject: Re: [Cerowrt-devel] [Make-wifi-fast] perverse powersave bug with sta/ap mode X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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: Thu, 28 Apr 2016 13:10:07 -0000 Interesting stuff. A deeper problem with WiFi-type protocols is that the v= ery idea of "multicast" on the PHY level (air interface) is flawed, based o= n a model of propagation that assumes that every station can be easily addr= essed simultaneously, at the same bitrate, etc. Multicast is seductive to d= esigners who ignore the realities of propagation and channel coding issues,= because they think it works one way, but the reality is quite different.= =0A=0ASo just as years were wasted in the RTP and media streaming world on = router/switch layer multicast (thought to be easy and more efficient), my p= ersonal opinion is that any wireless protocol that tries to solve problems = with multicast at the PHY layer is a fragile, brittle design that will wast= e years of effort trying to make the horse dance on its forelegs.=0A=0ATHe = list of issues is enormous, but the most obvious ones are a) equalization, = b) inability to use MIMO, and c) PHY layer acknowledgment complexity.=0A=0A= The usual argument is that in some special case circumstance, using multica= st is "optimal". But how much better is that "optimal" than the non-multic= ast general solution, and how does that "optimization" make the normal oper= ation worse, in common conditions?=0A=0AWhenever someone says that a "cross= layer optimization" or a complicated special case added into a robust desi= gn is "optimal", I check that my wallet is still in my pocket. Because "op= timal" is a magic word often used to distract one's attention from what rea= lly matters.=0A=0ASo "multicast" considered harmful is my view.=0A=0A=0AOn = Tuesday, April 26, 2016 7:27pm, "Aaron Wood" said:=0A= =0A> _______________________________________________=0A> Make-wifi-fast mai= ling list=0A> Make-wifi-fast@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/make-wifi-fast=0A> Has anyone modeled what the multicast= to multiple-unicast efficiency=0A> threshold is? The point where you go f= rom it being more efficient to send=0A> multicast traffic to individual STA= s instead of sending a monstrous (in=0A> time) multicast-rate packet?=0A> = =0A> 2, 5, 10 STAs?=0A> =0A> The per-STA-queue work should make that relati= vely easy, by allowing the=0A> packet to be dumped into each STA's queue...= =0A> =0A> -Aaron=0A> =0A