From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 52BA43B25D for ; Thu, 28 Apr 2016 10:16:49 -0400 (EDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0D67F38037D; Thu, 28 Apr 2016 10:16:49 -0400 (EDT) Received: from app42.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F0E42380268; Thu, 28 Apr 2016 10:16:48 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app42.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 10:16:49 -0400 Received: from reed.com (localhost [127.0.0.1]) by app42.wa-webapps.iad3a (Postfix) with ESMTP id DA33320086; Thu, 28 Apr 2016 10:16:48 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 28 Apr 2016 10:16:48 -0400 (EDT) Date: Thu, 28 Apr 2016 10:16:48 -0400 (EDT) From: dpreed@reed.com To: "=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=" Cc: "Juliusz Chroboczek" , 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: <878tzx4zno.fsf@toke.dk> References: <1461849006.60252745@apps.rackspace.com> <87oa8tyhug.wl-jch@pps.univ-paris-diderot.fr> <878tzx4zno.fsf@toke.dk> X-Auth-ID: dpreed@reed.com Message-ID: <1461853008.891910506@apps.rackspace.com> X-Mailer: webmail/12.4.1-RC Subject: Re: [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:16:49 -0000 Discovery is a special case, that is not quite multicast. Discovery is "not= icing". A node wishing to be discovered must be noticed by one (or maybe m= ore) already existent stations in a group (groups are noticed by any member= being noticed by a member of another group).=0A=0ASo you don't need any fa= cility to "reach all" in one message. It's sufficient to "reach any". From= that point on, it's a higher level problem of "association management" (tr= acking members and their reachability). I use these general terms in quote= s to step outside the frame limited to 802.11 and its rigid culture.=0A=0AS= o the key to discovery is *anycast* not multicast.=0A=0ASo for example, a s= tation that is not yet associated could follow some predictable sequence of= transmissions, using a variety of MI transmissions (multiple input, i.e. m= ultiple antennas transmitting simultaneously) with a variety of waveforms, = where that sequence was determined to have a high probability of being noti= ced by at least one member of the group to be joined. A station noticing su= ch a signal could then use the signal's form itself to respond and begin to= bring that station into the group of stations that can hear each other, di= scovering further information (like mutual propagation characteristics (mul= tipath/MIMO coefficients, attenuation (for equalization), noise)).=0A=0ABy = conflating discovery with multicast, one loses design options for discovery= and cooperative transmission. So yes, the "normative" centralized access p= oint discovery now practiced in 802.11 nets assumes a sort of "multicast", = but that is because we have "centralized" architectures, not mesh at the ph= y level.=0A=0AOn Thursday, April 28, 2016 9:43am, "Toke H=C3=B8iland-J=C3= =B8rgensen" said:=0A=0A> Juliusz Chroboczek writes:=0A> =0A>> For discovery, multicast is unavoidable -= - there's simply no way you're=0A>> going to send a unicast to a node that = you haven't discovered yet.=0A> =0A> Presumably the access point could tran= sparently turn IP-level multicast=0A> into a unicast frame to each associat= ed station? Not sure how that would=0A> work in an IBSS network, though... = Does the driver (or mac80211 stack)=0A> maintain a list of neighbours at th= e mac/phy level?=0A> =0A> -Toke=0A> =0A