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 DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id EB38221F0F0 for ; Tue, 14 Oct 2014 05:21:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DEA9318035B; Tue, 14 Oct 2014 08:21:47 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 51B2E180394; Tue, 14 Oct 2014 08:21:47 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [10.189.89.104] (215.sub-70-192-11.myvzw.com [70.192.11.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.2.13); Tue, 14 Oct 2014 12:21:47 GMT User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: References: <1412864720.98961528@apps.rackspace.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DHYJ8AMOZZGJF4G6XO79GIP4J8LO1X" Content-Transfer-Encoding: 7bit From: "David P. Reed" Date: Tue, 14 Oct 2014 08:21:43 -0400 To: David Lang Message-ID: <5d5cd292-2270-4f49-b254-432bd8ed3570@reed.com> Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] wifi over narrow channels 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: Tue, 14 Oct 2014 12:22:18 -0000 ------DHYJ8AMOZZGJF4G6XO79GIP4J8LO1X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David - 1) you are right that LBT fails because propagation does not allow= a transmitter to hear the stations that might be transmitting on the same = channel=2E But LBT need not be the optimal approach for the general idea of= packet multiplexing=2E A better decentralized approach is rts/cts=2E Thin= k about it=2E Start with that idea and improve it=2E=2E=2E I'm leaving it t= here as a learning moment=2E You'll learn more by improving it than by havi= ng me tell you=2E 2) co channel separation was hard before computing and s= ampling became good=2E It is no longer hard unless you handicap your thinki= ng by thinking it is hard=2E 3) spread spectrum is the first non- narrowba= nd modulation technique=2E It is far from the best=2E Consider very wideba= nd wavelet coding=2E=2E=2E 4) subdivision of space time is wasteful in th= e extreme=2E Why try to create walls when the space around the walls become= s useless? The denser the walls in space time and frequency the more waste= =2E=2E=2E Radio is not the sin or cos function=2E There is nothing in ei= ther Maxwell or QED that invokes Fourier=2E Nothing=2E On Oct 14, 2014, D= avid Lang wrote: >The problem is that you really have tro= uble with different transmitters >sharing >one channel over a wide area=2E= By having more channels and smaller areas >that >each one covers you end = up with better coverage overall, less >interference and >greater throughpu= t=2E > >If it was really possible to have different transmitters talking at= the >same >time on the same channel, this wouldn't be a problem, but we r= eally >can't in >practice [*], so it is a problem=2E > >The key problems s= how up because you can have two mobile stations on >opposite >sides of the= AP that can't hear each other, but can hear the AP just >fine=2E When >th= ey both transmit, the AP can't listen to both at once (it's >technically >= possible if the two signals are very close to the same strength, but if >on= e is >significantly more powerful than the other, the weaker one gets lost= in >the >noise) > >So in practice, you are better off with more APs on di= fferent channels >with the >APs connected together than you are with fewer= , faster channels >covering a >larger area per channel=2E > >Things like a= fixed "listen before transmit" wait time just emphisise >this >because th= ey mean that as the bit rate of the channel goes up, you are >wasting >a h= igher percentage of the capability when you are transmitting the >same amou= nt >of data=2E > >If you wait 4ms and then transmit for 28ms, you are wast= ing 1/8 of the >channel >bandwidth, but if you can transmit the same data = in 12ms, you are >wasting 1/4 of >the channel bandwidth=2E > >Now, shorter= transmissions do mean that there is less chance that >someone else >who y= ou can't hear will transmit, but having that other station on a >different = >channel talking to an AP that's closer to it will do even better=2E > > >= [*] In theory, spread spectrum transmission allows you to have >different = >stations talking on the same wideband channel without interfering with >ea= ch >other=2E > >In practice there are a few problems with this=2E > >1=2E = the different sets of transmissions need to have different >transmission >= patterns (keys), and these patterns need to be distributed to all the >stat= ions >using a particular key=2E > >2=2E not all keys are equally good, esp= ecially when combined with other >keys in >use, so coordination of the key= s is needed=2E > >3=2E timing on all the different radios in the network is= critical so >that they >all start looking at the same time=2E This is som= ething that is very hard >to get >in practice without some external timeke= eping being provided (some >equipment >would use the broadcast TV sync tim= ing before it went digital for >example) > >4=2E You still have the problem= of not being able to transmit and receive >at the >same time=2E > >5=2E T= he RF signal gets amplified by a variable amount to make the >resulting >s= ignal a constant strength before it's decoded=2E The RF signal from >differ= ent >transmitters is falling off at roughly the cube of the distance, and = >the >decoders have 12-14 bits of resolution=2E If a more distant station = is >transmitting at the same time as a nearby station, this makes the >dis= tant staton >unreadable because it's signal ends up being represented by t= oo few >bits in the >decoder=2E > >David Lang > >On Thu, 9 Oct 2014, dpree= d@reed=2Ecom wrote: > >> Wideband is far better for scaling than narrowband= , though=2E This may >seem >> counterintuitive, but narrowband systems ar= e extremely inefficient=2E >They >> appeal to 0/1 thinking intuitively, b= ut in actual fact the wider the >bandwidth >> the more sharing and the mor= e scaling is possible (and not be >"balkanization" >> or "exclusive channe= l negotiation")=2E >> >> Two Internets are far worse than a single Interne= t that combines >both=2E >> That's because you have more degrees of freedo= m in a single network >than you >> can in two distinct networks, by a comb= inatorial factor=2E >> >> The analogy holds that one wide band is far bett= er than two disjoint >bands in >> terms of scaling and adaptation=2E The s= ituation only gets better >because of the >> physics of "multipath", which= creates more problems the more >narrowband the >> signal, and when the si= gnal is a single frequency, multipath is >disastrous=2E >> >> The same is = true if you try to divide space into disjoint "channels" >(as >> cellular = tries to)=2E >> >> So in the near term, narrowband wifi might be a short-t= erm benefit, >but >> long-term it is 180 degress away from where you want = to go=2E >> >> (the listen-before-talk protocol in WiFi is pragmatic becau= se it is >built into >> hardware today, but terrible for wideband signals,= because you can't >shorten >> the 4 usec=2E pre-transmit delay, and proba= bly need to lengthen it, >since 4 >> usec=2E is about 1=2E25 km or 0=2E8 m= iles, and holds 40 bits at 10 Mb/s, or >4000 >> bits at 1 Gb/sec)=2E >> >= > Either for distance or for rate, the "Ethernet MAC+PHY" was designed >for= short >> "coax" or "hub" domains=2E Its not good for digital wireless Int= ernet, >except >> for one thing: it is based on distributed control that d= oes not >require any >> advance planning=2E >> >> If you want to improve = open wireless, you have to a) go wide, b) >maintain >> distributed control= , c) get rid of listen-before-talk to replace it >with a >> mixture of co-= channel decoding and propagation negotiation=2E Then you >can beat >> cel= lular trivially=2E >> >> I wish I could attract investment away from the "= short term" WiFi >thinking, >> but in the last 15 years, I've failed=2E M= eanwhile WiFi also attracts >those >> people who want to add bufferbloat i= nto the routers because they >don't >> understand congestion control=2E >>= >> Sad=2E >> >> >> On Wednesday, October 8, 2014 6:14pm, "Dave Taht" > said: >> >> >> >>> >https://www=2Eusenix=2Eorg/syste= m/files/conference/nsdi12/nsdi12-final142=2Epdf >>> >>> I've had 5mhz chan= nels working in the ath9k at various points in >>> cerowrt's lifetime=2E (u= sing it for meshy stuff) After digesting most >of >>> the 802=2E11ac standa= rd I do find myself wishing they'd gone towards >>> narrower channels rathe= r than wider=2E >>> >>> The netgear x4 defaults to a 160mhz wide channel= =2E :sigh: >>> >>> The above paper has some nifty ideas in it=2E >>> >>> = -- >>> Dave T=C3=A4ht >>> >>> https://www=2Ebufferbloat=2Enet/projects/mak= e-wifi-fast >>> _______________________________________________ >>> Cerowrt= -devel mailing list >>> Cerowrt-devel@lists=2Ebufferbloat=2Enet >>> https:/= /lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel >>> > >------------------= ------------------------------------------------------ > >_________________= ______________________________ >Cerowrt-devel mailing list >Cerowrt-devel@l= ists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/cerowr= t-devel -- Sent from my Android device with K-@ Mail=2E Please excuse my b= revity=2E ------DHYJ8AMOZZGJF4G6XO79GIP4J8LO1X Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable David -

1) = you are right that LBT fails because propagation does not allow a transmitt= er to hear the stations that might be transmitting on the same channel=2E B= ut LBT need not be the optimal approach for the general idea of packet = ; multiplexing=2E A better decentralized approach is rts/cts=2E Think about= it=2E Start with that idea and improve it=2E=2E=2E I'm leaving it there as= a learning moment=2E You'll learn more by improving it than by having me t= ell you=2E

2) co channel separation = was hard before computing and sampling became good=2E It is no longer hard = unless you handicap your thinking by thinking it is hard=2E

3) spread spectrum is the first non- narrowband mod= ulation technique=2E It is far from the best=2E  Consider very wideban= d wavelet coding=2E=2E=2E

4) subdiv= ision of space time is wasteful in the extreme=2E Why try to create walls w= hen the space around the walls becomes useless? The denser the walls in spa= ce time and frequency the more waste=2E=2E=2E

Radio is not the sin or cos function=2E  There is nothing i= n either Maxwell or QED  that invokes Fourier=2E Nothing=2E

On Oct 14, 2014, Da= vid Lang <david@lang=2Ehm> wrote:
The problem is that you rea=
lly have trouble with different transmitters sharing 
one=
 channel over a wide area=2E By having more channels and smaller areas that=
 
each one covers you end up with better coverage overall=
, less interference and 
greater throughput=2E

If it was really possible to have different tr=
ansmitters talking at the same 
time on the same channel,=
 this wouldn't be a problem, but we really can't in 
prac=
tice [*], so it is a problem=2E

The ke=
y problems show up because you can have two mobile stations on opposite sides of the AP that can't hear each other, but can hear th=
e AP just fine=2E When 
they both transmit, the AP can't =
listen to both at once (it's technically 
possible if the=
 two signals are very close to the same strength, but if one is 
significantly more powerful than the other, the weaker one gets l=
ost in the 
noise)

S=
o in practice, you are better off with more APs on different channels with =
the 
APs connected together than you are with fewer, fast=
er channels covering a 
larger area per channel=2E

Things like a fixed "listen before tran=
smit" wait time just emphisise this 
because they me=
an that as the bit rate of the channel goes up, you are wasting 
a higher percentage of the capability when you are transmitting t=
he same amount 
of data=2E

If you wait 4ms and then transmit for 28ms, you are wasting 1/8 of t=
he channel 
bandwidth, but if you can transmit the same d=
ata in 12ms, you are wasting 1/4 of 
the channel bandwidt=
h=2E

Now, shorter transmissions do mea=
n that there is less chance that someone else 
who you ca=
n't hear will transmit, but having that other station on a different 
channel talking to an AP that's closer to it will do even bett=
er=2E


[*] In theory=
, spread spectrum transmission allows you to have different 
stations talking on the same wideband channel without interfering with =
each 
other=2E

In pr=
actice there are a few problems with this=2E

1=2E the different sets of transmissions need to have different tran=
smission 
patterns (keys), and these patterns need to be =
distributed to all the stations 
using a particular key=
=2E

2=2E not all keys are equally good=
, especially when combined with other keys in 
use, so co=
ordination of the keys is needed=2E

3=
=2E timing on all the different radios in the network is critical so that t=
hey 
all start looking at the same time=2E This is someth=
ing that is very hard to get 
in practice without some ex=
ternal timekeeping being provided (some equipment 
would =
use the broadcast TV sync timing before it went digital for example)

4=2E You still have the problem of not being=
 able to transmit and receive at the 
same time=2E

5=2E The RF signal gets amplified by a varia=
ble amount to make the resulting 
signal a constant stren=
gth before it's decoded=2E The RF signal from different 
=
transmitters is falling off at roughly the cube of the distance, and the decoders have 12-14 bits of resolution=2E If a more distan=
t station is 
transmitting at the same time as a nearby s=
tation, this makes the distant staton 
unreadable because=
 it's signal ends up being represented by too few bits in the 
decoder=2E

David Lang

On Thu, 9 Oct 2014, dpreed@reed=2Ecom wrote:
Wideband is far better for scaling than narrowband, though= =2E This may seem
counterintuitive, but narrowband syst= ems are extremely inefficient=2E They
appeal to 0/1 thi= nking intuitively, but in actual fact the wider the bandwidth
the more sharing and the more scaling is possible (and not be "b= alkanization"
or "exclusive channel negotiatio= n")=2E

Two Internets are far wors= e than a single Internet that combines both=2E
That's be= cause you have more degrees of freedom in a single network than you
can in two distinct networks, by a combinatorial factor=2E

The analogy holds that one wide band is fa= r better than two disjoint bands in
terms of scaling and= adaptation=2E The situation only gets better because of the
physics of "multipath", which creates more problems the more= narrowband the
signal, and when the signal is a single = frequency, multipath is disastrous=2E

= The same is true if you try to divide space into disjoint "channels&qu= ot; (as
cellular tries to)=2E

So in the near term, narrowband wifi might be a short-term benef= it, but
long-term it is 180 degress away from where you = want to go=2E

(the listen-before-talk = protocol in WiFi is pragmatic because it is built into
h= ardware today, but terrible for wideband signals, because you can't shorten=
the 4 usec=2E pre-transmit delay, and probably need to = lengthen it, since 4
usec=2E is about 1=2E25 km or 0=2E8= miles, and holds 40 bits at 10 Mb/s, or 4000
bits at 1 = Gb/sec)=2E

Either for distance or for = rate, the "Ethernet MAC+PHY" was designed for short
"coax" or "hub" domains=2E Its not good for digit= al wireless Internet, except
for one thing: it is based = on distributed control that does not require any
advance= planning=2E

If you want to improve op= en wireless, you have to a) go wide, b) maintain
distrib= uted control, c) get rid of listen-before-talk to replace it with a
mixture of co-channel decoding and propagation negotiation=2E = Then you can beat
cellular trivially=2E

I wish I could attract investment away from the "= short term" WiFi thinking,
but in the last 15 years= , I've failed=2E Meanwhile WiFi also attracts those
peo= ple who want to add bufferbloat into the routers because they don't
understand congestion control=2E

Sad=2E


On We= dnesday, October 8, 2014 6:14pm, "Dave Taht" <dave=2Etaht@gmai= l=2Ecom> said:


<= br clear=3D"none">
https://www=2Eusenix=2Eorg/system/files/conference/= nsdi12/nsdi12-final142=2Epdf

I've = had 5mhz channels working in the ath9k at various points in
cerowrt's lifetime=2E (using it for meshy stuff) After digesting most of=
the 802=2E11ac standard I do find myself wishing they'd = gone towards
narrower channels rather than wider=2E

The netgear x4 defaults to a 160mhz wide ch= annel=2E :sigh:

The above paper has so= me nifty ideas in it=2E

--
Dave Täht

https://= www=2Ebufferbloat=2Enet/projects/make-wifi-fast
<= br clear=3D"none">Cerowrt-devel mailing list
Cerowrt-deve= l@lists=2Ebufferbloat=2Enet
https://lists=2Ebuff= erbloat=2Enet/listinfo/cerowrt-devel


=
Cerowrt-devel mailing list
Cerowrt-devel@lists=2Ebufferbl=
oat=2Enet
https://lists=2Ebufferbloat=2Enet/list=
info/cerowrt-devel

-- Sent from my Android device with K-@ Mail=2E Please excuse my brevity=2E


------DHYJ8AMOZZGJF4G6XO79GIP4J8LO1X--