Re: [Cerowrt-devel] closing up my make-wifi-fast lab

Re: [Cerowrt-devel] closing up my make-wifi-fast lab

[David P. Reed]

Baran: I got the year wrong. I remember it as 1993, but it was 1994 CNGN speech he made, which is resurrected here:
https://www.eff.org/pages/false-scarcity-baran-cngn-94

Paul was educated in EE, as was I. So radio made sense to him. Unlike kids brought up on the idea that bits are and must be physically discrete spatial and temporal mechanical things.

You know, one can have 1/10 of a bit of information, and store it in 1/10 of a bit of storage. Or transmit a symbol that passes through local noise and comes out the other side uncorrupted.

But kids trained in fancy CS depts. assume that bits require clear, empty, noiseless, pristine paths. Pure Bullshit. But CS and now many EE depts. and the FCC all proselytize such crap 

So scarcity is inventedand sustained.

There is a reigning Supreme Court opinion, the law of the land, that says that there is by law a "finite number" of usable frequencies, and only one transmitter can be allowed to use it at a time. Like legislating that pi = 3 in a state, to make math easier.

Except it is totally designed to create scarcity. And the State/Industry Nexus maintains it at every turn. It's why lunatic economists claim that spectrum is a form of property that can be auctioned. Like creating property rights to each acre of the sea, allowing owners to block shipping by buying a connected path down the mid Atlantic.

We live in a Science Ignorant world. Intentionally. Even trained pH D. Engineers testify before the FCC to preserve these lies.

Yeah, I sound nuts. Check it out.


-----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Sat, Aug 25, 2018 at 5:22 pm
To: dpreed@deepplum.com
Cc: bloat-announce@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, "Make-Wifi-fast" <make-wifi-fast@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] closing up my make-wifi-fast lab

On Sat, Aug 25, 2018 at 1:04 PM David P. Reed  wrote:
>
> WiFi is a bit harder than IP. But you know that.
>
> I truly believe that we need to fix the phy/waveform/modulation space to really scale up open wireless networking capability. LBT is the basic bug in WiFi, and it is at that layer, melow the MAC.
>
> I have tried for 20 years now to find a way to begin work at that project, by the way. There is also no major donor anywhere to be found for that work. Instead, any funds that seem to be appearing get attacked and sucked into projects that miss the point, being controlled by folks who oppose openness (e.g. WISPs wanting exclusive ownership of a market, such as so called SuperWiFi or whitespaces). I did once come close to a useful award when I was at MIT Media Lab, from NSF. But after the award, the funding was cut by 90%, leaving just enough to support a Master's thesis on co-channel sharing, using two 1st Gen USRPs. Using my own funds, spare time, and bubblegum and baling wire, I've slowly begun work on extra wideband FPGA based sounding-centric sharing in the 10 GHz Ham band. (500 MHz wide modulation), where I can self certify multiple stations in a network.
>
> But the point is, I've failed, because there is less than zero support. There is active opposition, on top of cluelessness.
>
> Paul Baran tried in 1993 to push forward a similar agenda, famously. 99% of his concepts died.

Cite?

One of the things that bothers me about packet processing is that
Donald Davies (the oft uncredited other founder of the concept) wrote
11 volumes on this subject. So far as I know, those have vanished to
history.

Periodically, when I get stuck on something in this field, I fantasize
that scribbled in the margin of volume 9 was the solution to the
problem.

> Thanks to Apple, and lots of others, we got WiFi, barely. Industry hated that, and vow never to let that ever happen again.

It really was a strange convolution of circumstances that led to wifi.
When i first got it working in 1998, metricom ruled the world. They
failed. After that, nobody thought it was feasible at scale until the
concept of a mac retry emerged to fix the packet loss problem, and APs
to provide a central clock (best we could do with the DSPs then).  So
a window emerged (and yes, hugely driven by apple, but also by huge
popular demand for "wireless freedom") to put "buggy" wireless tech on
the crap 2.4 band in the hands of the people, it got established and
made the coffee shop a workplace, and bigcos attempting to wipe it out
(and largely, in the last few years, succeeding in dislodging it) have
had an uphill battle.

If metricom had succeeded, or the celluar folk got their
implementations working only a few years faster, it would be a very
different world.

(this history is all covered in my MIT preso here:
https://www.youtube.com/watch?v=Wksh2DPHCDI&t=2007s - david was at
that one)

>
> So Dave, I salute you and Toke and the others. I salute Tim Shepard, who also moved the ball in his PhD thesis, only to hit the same wall of opposition.

Soooo many others involved, felix feitkau in particular comes to mind.

Still, I think fixing the "wifi anomaly" is the greatest achievement
of my career... and toke's hasn't even officially started yet! Someday
perhaps that will be worth a medal, or an small entry for us in
wikipedia.

> It's so sad. We get shit like the "Obama band" proposed by PCAST, and are told to be thankful.

Let's not get started on that or whitespaces today.

> UWB failed miserably, too.

I wish that could be resurrected.

> My advice to any young smart innovator: don't touch wireless unless you are working for an incumbent. Expect the incumbents and governments to close and destroy wireless innovation.

I agree. Well, I do have some hope and interest in spacex's
constellation, but I remember teledesic's failure too well.

>
> Really. You will be in a world of hurt, and NO ONE will support anything. Not even VCs.
>
> Very sorry to say this. I had hoped Make WiFi Fast would have gone somewhere. I mourn its passing.

It's not dead, I'm just closing my lab.

In the document I cited for more wifi fixes, things like dynamically
scaling down the announced txop under contention, lowering retries,
offering a little less protection for packets when overloaded, a "tx
is almost done" interrupt, etc, are all things I expect vendors and
open source folk to try. I keep hoping minstrel-blues will land. Etc.
Outside the US there's still a lot of positive activity. Products like
eero and google wifi continue to sell like hotcakes, as well as tons
of cheaper gear, and iot, etc, etc.

And there's some good progress in 802.11ax.

fq_codel for wifi + these mods will make wifi continue to be more than
competitive with the upcoming 5G stuff.

But i don't need to be the one to implement or test them. I should
have shut things down when the shuttleworth grant didn't come through.
When you can no longer get up in the morning to work, nor able to hold
the wifi standard and related code in your head, it's time to move on.

It is bothersome to me that the ISPs don't seem to realize that their
business will fail unless they have good wifi, but the big ones are
out there merging with the LTE folk and don't care either.

Wifi's had a great run. I think here - with 5 years of work - we've
extended its life another 5 years - at least. Still, unless
applications emerge again that need good low latency (like vr) over
wifi, nothings going to drive those down further to compete with 5g.

>
> -----Original Message-----
> From: "Dave Taht" 
> Sent: Fri, Aug 24, 2018 at 4:10 pm
> To: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" , cerowrt-devel@lists.bufferbloat.net
> Cc: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" , cerowrt-devel@lists.bufferbloat.net
> Subject: [Cerowrt-devel] closing up my make-wifi-fast lab
>
> All:
>
> It is with some regret that I am announcing the closing of my
> make-wifi-fast lab at the end of this month.
>
> Over the years we have relied on the donation of lab space from
> ISC.org, georgia tech, the LINCs, and the University of Karstadt and
> elsewhere - but my main base of operation has always been the
> "yurtlab", in a campground deep in the los gatos hills where I could
> both experiment and deploy wifi fixes[0] at scale. CeroWrt, in
> particular, was made here.
>
> During the peak of the make-wifi-fast effort I rented additional space
> on the same site, which at peak had over 30 routers in a crowded
> space, competing. Which I (foolishly) kept, despite the additional
> expense. Having heat in the winter and aircond in the summer was
> helpful.
>
> With ongoing donations running at $90/month[1] - which doesn't even
> cover bufferbloat.net's servers in the cloud - my biggest expense has
> been keeping the lab at lupin open at $1800/mo.
>
> I kept the lab going through the sch_cake and openwrt 18.06 release
> process, and I'm now several months behind on rent[3], and given how
> things have gone for the past 2 years I don't see much use for it in
> the future. Keeping it open, heated and dry in the winter has always
> been a problem also. I'm also aware of a few larger, much better
> equipped wifi labs that have thoroughly tested our "fq_codel for
> wifi"[4] work that finally ends the "wifi performance anomaly". it's
> in multiple commercial products now, we're seeing airtime fairness
> being actually *marketed* as a wifi feature, and I kind of expect
> deployment be universal across all mediatek mt76, and qualcomm ath9k
> and ath10k based products in the next year or two. We won, big, on
> wifi. Knocked it out of the park. Thanks all!
>
> Despite identifying all kinds of other work[5] that can be done to
> make wifi better, no major (or even minor) direct sponsor has ever
> emerged[2] for the make-wifi-fast project. We had a small grant from
> comcast, a bit of support from nlnet also, I subsidized what I did
> here from other work sources, toke had his PHD support, and all the
> wonderful volunteers here... and that's it.
>
> Without me being able, also, to hire someone to keep the lab going, as
> I freely admit to burnout and PTSD on perpetually reflashing and
> reconfiguring routers...
>
> I'm closing up shop here to gather enough energy, finances, and time
> for the next project, whatever it is.
>
> The make-wifi-fast mailing list and project will continue, efforts to
> make more generic the new API also, and hopefully there's enough users
> out there to
> keep it all going forward without the kind of comprehensive testing I
> used to do here.
>
> If anyone feels like reflashing, oh, 30 bricked routers of 8 different
> models, from serial ports (in multiple cases, like the 6 uap-ac-lites,
> via soldiering on headers), I'll gladly toss all the extra equipment
> in the lab in a big box and ship them to you. Suggestions for a
> suitable donation target are also of interest.
>
> The yurtlab has been an amazing, totally unique, unusual (and
> sometimes embarrassing [6]) place to work and think, but it's time to
> go.
>
> Perhaps I'll convince my amazingly supportive landlord to let me leave
> behind a plaque:
>
> "On this spot bufferbloat on the internet and in WiFi was fixed, 2011-2018".
>
> Sincerely,
> Dave Taht
>
> [0] https://lwn.net/Articles/705884/ "How we made wifi fast again"
> [1] https://www.patreon.com/dtaht
> [2] Like adrian chadd's infamous flameout - I too, give up on wifi.
> There's gotta be some other tech worth working on. What we shipped is
> "good enough" to carry a few years though.
> [3] This is not a passive-aggressive request for help making rent next
> month, given all the other problems I have, it's best to close up shop
> while I look for a new gig.
> [4] https://arxiv.org/pdf/1703.00064.pdf "ending the wifi anomaly"
> [5] https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
> [6] https://www.cringely.com/2012/10/01/clothing-may-be-optional-but-bufferbloat-isnt/
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 13377 bytes --]

Curious to how LBT can be solved at the PHY level and if the potential
solution sets preserve the end to end principle.

Bob

On Sun, Aug 26, 2018 at 5:26 AM David P. Reed <dpreed@deepplum.com> wrote:

> Baran: I got the year wrong. I remember it as 1993, but it was 1994 CNGN
> speech he made, which is resurrected here:
> https://www.eff.org/pages/false-scarcity-baran-cngn-94
>
> Paul was educated in EE, as was I. So radio made sense to him. Unlike kids
> brought up on the idea that bits are and must be physically discrete
> spatial and temporal mechanical things.
>
> You know, one can have 1/10 of a bit of information, and store it in 1/10
> of a bit of storage. Or transmit a symbol that passes through local noise
> and comes out the other side uncorrupted.
>
> But kids trained in fancy CS depts. assume that bits require clear, empty,
> noiseless, pristine paths. Pure Bullshit. But CS and now many EE depts. and
> the FCC all proselytize such crap
>
> So scarcity is inventedand sustained.
>
> There is a reigning Supreme Court opinion, the law of the land, that says
> that there is by law a "finite number" of usable frequencies, and only one
> transmitter can be allowed to use it at a time. Like legislating that pi =
> 3 in a state, to make math easier.
>
> Except it is totally designed to create scarcity. And the State/Industry
> Nexus maintains it at every turn. It's why lunatic economists claim that
> spectrum is a form of property that can be auctioned. Like creating
> property rights to each acre of the sea, allowing owners to block shipping
> by buying a connected path down the mid Atlantic.
>
> We live in a Science Ignorant world. Intentionally. Even trained pH D.
> Engineers testify before the FCC to preserve these lies.
>
> Yeah, I sound nuts. Check it out.
>
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Sat, Aug 25, 2018 at 5:22 pm
> To: dpreed@deepplum.com
> Cc: bloat-announce@lists.bufferbloat.net, "bloat" <
> bloat@lists.bufferbloat.net>, "Make-Wifi-fast" <
> make-wifi-fast@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] closing up my make-wifi-fast lab
>
> On Sat, Aug 25, 2018 at 1:04 PM David P. Reed  wrote:
> >
> > WiFi is a bit harder than IP. But you know that.
> >
> > I truly believe that we need to fix the phy/waveform/modulation space to
> really scale up open wireless networking capability. LBT is the basic bug
> in WiFi, and it is at that layer, melow the MAC.
> >
> > I have tried for 20 years now to find a way to begin work at that
> project, by the way. There is also no major donor anywhere to be found for
> that work. Instead, any funds that seem to be appearing get attacked and
> sucked into projects that miss the point, being controlled by folks who
> oppose openness (e.g. WISPs wanting exclusive ownership of a market, such
> as so called SuperWiFi or whitespaces). I did once come close to a useful
> award when I was at MIT Media Lab, from NSF. But after the award, the
> funding was cut by 90%, leaving just enough to support a Master's thesis on
> co-channel sharing, using two 1st Gen USRPs. Using my own funds, spare
> time, and bubblegum and baling wire, I've slowly begun work on extra
> wideband FPGA based sounding-centric sharing in the 10 GHz Ham band. (500
> MHz wide modulation), where I can self certify multiple stations in a
> network.
> >
> > But the point is, I've failed, because there is less than zero support.
> There is active opposition, on top of cluelessness.
> >
> > Paul Baran tried in 1993 to push forward a similar agenda, famously. 99%
> of his concepts died.
>
> Cite?
>
> One of the things that bothers me about packet processing is that
> Donald Davies (the oft uncredited other founder of the concept) wrote
> 11 volumes on this subject. So far as I know, those have vanished to
> history.
>
> Periodically, when I get stuck on something in this field, I fantasize
> that scribbled in the margin of volume 9 was the solution to the
> problem.
>
> > Thanks to Apple, and lots of others, we got WiFi, barely. Industry hated
> that, and vow never to let that ever happen again.
>
> It really was a strange convolution of circumstances that led to wifi.
> When i first got it working in 1998, metricom ruled the world. They
> failed. After that, nobody thought it was feasible at scale until the
> concept of a mac retry emerged to fix the packet loss problem, and APs
> to provide a central clock (best we could do with the DSPs then).  So
> a window emerged (and yes, hugely driven by apple, but also by huge
> popular demand for "wireless freedom") to put "buggy" wireless tech on
> the crap 2.4 band in the hands of the people, it got established and
> made the coffee shop a workplace, and bigcos attempting to wipe it out
> (and largely, in the last few years, succeeding in dislodging it) have
> had an uphill battle.
>
> If metricom had succeeded, or the celluar folk got their
> implementations working only a few years faster, it would be a very
> different world.
>
> (this history is all covered in my MIT preso here:
> https://www.youtube.com/watch?v=Wksh2DPHCDI&t=2007s - david was at
> that one)
>
> >
> > So Dave, I salute you and Toke and the others. I salute Tim Shepard, who
> also moved the ball in his PhD thesis, only to hit the same wall of
> opposition.
>
> Soooo many others involved, felix feitkau in particular comes to mind.
>
> Still, I think fixing the "wifi anomaly" is the greatest achievement
> of my career... and toke's hasn't even officially started yet! Someday
> perhaps that will be worth a medal, or an small entry for us in
> wikipedia.
>
> > It's so sad. We get shit like the "Obama band" proposed by PCAST, and
> are told to be thankful.
>
> Let's not get started on that or whitespaces today.
>
> > UWB failed miserably, too.
>
> I wish that could be resurrected.
>
> > My advice to any young smart innovator: don't touch wireless unless you
> are working for an incumbent. Expect the incumbents and governments to
> close and destroy wireless innovation.
>
> I agree. Well, I do have some hope and interest in spacex's
> constellation, but I remember teledesic's failure too well.
>
> >
> > Really. You will be in a world of hurt, and NO ONE will support
> anything. Not even VCs.
> >
> > Very sorry to say this. I had hoped Make WiFi Fast would have gone
> somewhere. I mourn its passing.
>
> It's not dead, I'm just closing my lab.
>
> In the document I cited for more wifi fixes, things like dynamically
> scaling down the announced txop under contention, lowering retries,
> offering a little less protection for packets when overloaded, a "tx
> is almost done" interrupt, etc, are all things I expect vendors and
> open source folk to try. I keep hoping minstrel-blues will land. Etc.
> Outside the US there's still a lot of positive activity. Products like
> eero and google wifi continue to sell like hotcakes, as well as tons
> of cheaper gear, and iot, etc, etc.
>
> And there's some good progress in 802.11ax.
>
> fq_codel for wifi + these mods will make wifi continue to be more than
> competitive with the upcoming 5G stuff.
>
> But i don't need to be the one to implement or test them. I should
> have shut things down when the shuttleworth grant didn't come through.
> When you can no longer get up in the morning to work, nor able to hold
> the wifi standard and related code in your head, it's time to move on.
>
> It is bothersome to me that the ISPs don't seem to realize that their
> business will fail unless they have good wifi, but the big ones are
> out there merging with the LTE folk and don't care either.
>
> Wifi's had a great run. I think here - with 5 years of work - we've
> extended its life another 5 years - at least. Still, unless
> applications emerge again that need good low latency (like vr) over
> wifi, nothings going to drive those down further to compete with 5g.
>
> >
> > -----Original Message-----
> > From: "Dave Taht"
> > Sent: Fri, Aug 24, 2018 at 4:10 pm
> > To: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" ,
> cerowrt-devel@lists.bufferbloat.net
> > Cc: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" ,
> cerowrt-devel@lists.bufferbloat.net
> > Subject: [Cerowrt-devel] closing up my make-wifi-fast lab
> >
> > All:
> >
> > It is with some regret that I am announcing the closing of my
> > make-wifi-fast lab at the end of this month.
> >
> > Over the years we have relied on the donation of lab space from
> > ISC.org, georgia tech, the LINCs, and the University of Karstadt and
> > elsewhere - but my main base of operation has always been the
> > "yurtlab", in a campground deep in the los gatos hills where I could
> > both experiment and deploy wifi fixes[0] at scale. CeroWrt, in
> > particular, was made here.
> >
> > During the peak of the make-wifi-fast effort I rented additional space
> > on the same site, which at peak had over 30 routers in a crowded
> > space, competing. Which I (foolishly) kept, despite the additional
> > expense. Having heat in the winter and aircond in the summer was
> > helpful.
> >
> > With ongoing donations running at $90/month[1] - which doesn't even
> > cover bufferbloat.net's servers in the cloud - my biggest expense has
> > been keeping the lab at lupin open at $1800/mo.
> >
> > I kept the lab going through the sch_cake and openwrt 18.06 release
> > process, and I'm now several months behind on rent[3], and given how
> > things have gone for the past 2 years I don't see much use for it in
> > the future. Keeping it open, heated and dry in the winter has always
> > been a problem also. I'm also aware of a few larger, much better
> > equipped wifi labs that have thoroughly tested our "fq_codel for
> > wifi"[4] work that finally ends the "wifi performance anomaly". it's
> > in multiple commercial products now, we're seeing airtime fairness
> > being actually *marketed* as a wifi feature, and I kind of expect
> > deployment be universal across all mediatek mt76, and qualcomm ath9k
> > and ath10k based products in the next year or two. We won, big, on
> > wifi. Knocked it out of the park. Thanks all!
> >
> > Despite identifying all kinds of other work[5] that can be done to
> > make wifi better, no major (or even minor) direct sponsor has ever
> > emerged[2] for the make-wifi-fast project. We had a small grant from
> > comcast, a bit of support from nlnet also, I subsidized what I did
> > here from other work sources, toke had his PHD support, and all the
> > wonderful volunteers here... and that's it.
> >
> > Without me being able, also, to hire someone to keep the lab going, as
> > I freely admit to burnout and PTSD on perpetually reflashing and
> > reconfiguring routers...
> >
> > I'm closing up shop here to gather enough energy, finances, and time
> > for the next project, whatever it is.
> >
> > The make-wifi-fast mailing list and project will continue, efforts to
> > make more generic the new API also, and hopefully there's enough users
> > out there to
> > keep it all going forward without the kind of comprehensive testing I
> > used to do here.
> >
> > If anyone feels like reflashing, oh, 30 bricked routers of 8 different
> > models, from serial ports (in multiple cases, like the 6 uap-ac-lites,
> > via soldiering on headers), I'll gladly toss all the extra equipment
> > in the lab in a big box and ship them to you. Suggestions for a
> > suitable donation target are also of interest.
> >
> > The yurtlab has been an amazing, totally unique, unusual (and
> > sometimes embarrassing [6]) place to work and think, but it's time to
> > go.
> >
> > Perhaps I'll convince my amazingly supportive landlord to let me leave
> > behind a plaque:
> >
> > "On this spot bufferbloat on the internet and in WiFi was fixed,
> 2011-2018".
> >
> > Sincerely,
> > Dave Taht
> >
> > [0] https://lwn.net/Articles/705884/ "How we made wifi fast again"
> > [1] https://www.patreon.com/dtaht
> > [2] Like adrian chadd's infamous flameout - I too, give up on wifi.
> > There's gotta be some other tech worth working on. What we shipped is
> > "good enough" to carry a few years though.
> > [3] This is not a passive-aggressive request for help making rent next
> > month, given all the other problems I have, it's best to close up shop
> > while I look for a new gig.
> > [4] https://arxiv.org/pdf/1703.00064.pdf "ending the wifi anomaly"
> > [5]
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
> > [6]
> https://www.cringely.com/2012/10/01/clothing-may-be-optional-but-bufferbloat-isnt/
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 16649 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Jonathan Morton]

> On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
> 
> Curious to how LBT can be solved at the PHY level and if the potential solution sets preserve the end to end principle.

The usual alternatives include TDM, usually coordinated by a master device (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding; and simply firing off a packet and retrying with exponential backoff if an acknowledgement is not heard.

TDM and diplexing are already used by both DOCSIS and LTE.  They are proven technology.  However, in DOCSIS the diplexing is greatly simplified by the use of a copper channel rather than airwaves, and in LTE the diplexer is fitted only at the tower, not in each client - so the tower can transmit and receive simultaneously, but an individual client cannot, but this is still useful because there are many clients per tower.  Effective diplexers for wireless are expensive.

Orthogonal coding is already used by GPS and, in a rather esoteric form, by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In GPS, it allows all of the satellites in the constellation to transmit on the standard frequency simultaneously, while still being individually distinguishable.  The data rate is very low, however, since each satellite's signal inherently has a negative SNR (because there's a dozen others shouting over it) - that's why it takes a full minute for a receiver to get a fix from cold, because it simply takes that long to download the ephemeris from the first satellite whose signal is found.

A future version of wifi could reasonably use TDM, I think, but not diplexing.  The way this would work is that the AP assigns each station (including itself) a series of time windows in which to transmit as much as they like, and broadcasts this schedule along with its beacon.  Also scheduled would be windows in which the AP listens for new stations, including possibly other nearby APs with which it may mutually coordinate time.  A mesh network could thus be constructed entirely out of mutually coordinating APs if necessary.

The above paragraph is obviously a giant handwave...

 - Jonathan Morton

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

hmm, "going back" to TDM, doesn't that lose the benefits and efficiencies
per statistical multiplexing?   How can a centralized device predict the
many "end stations'" network demand in its time scheduling?

Note: I think with 802.11ax this is happening to some extent per uplink
OFDMA but that requires both time scheduling and transmit power setting so
the AP receives the "simultaneous signals" with similar SINRs.   This is
supposed to help with LBT but not really completely solve it.

Curious if eliminating LBT is possible per a distributed solution (with
partial network awareness) vs having a centralized scheduler (with "full"
network awareness)?

Bob

On Sun, Aug 26, 2018 at 11:26 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > Curious to how LBT can be solved at the PHY level and if the potential
> solution sets preserve the end to end principle.
>
> The usual alternatives include TDM, usually coordinated by a master device
> (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding;
> and simply firing off a packet and retrying with exponential backoff if an
> acknowledgement is not heard.
>
> TDM and diplexing are already used by both DOCSIS and LTE.  They are
> proven technology.  However, in DOCSIS the diplexing is greatly simplified
> by the use of a copper channel rather than airwaves, and in LTE the
> diplexer is fitted only at the tower, not in each client - so the tower can
> transmit and receive simultaneously, but an individual client cannot, but
> this is still useful because there are many clients per tower.  Effective
> diplexers for wireless are expensive.
>
> Orthogonal coding is already used by GPS and, in a rather esoteric form,
> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
> GPS, it allows all of the satellites in the constellation to transmit on
> the standard frequency simultaneously, while still being individually
> distinguishable.  The data rate is very low, however, since each
> satellite's signal inherently has a negative SNR (because there's a dozen
> others shouting over it) - that's why it takes a full minute for a receiver
> to get a fix from cold, because it simply takes that long to download the
> ephemeris from the first satellite whose signal is found.
>
> A future version of wifi could reasonably use TDM, I think, but not
> diplexing.  The way this would work is that the AP assigns each station
> (including itself) a series of time windows in which to transmit as much as
> they like, and broadcasts this schedule along with its beacon.  Also
> scheduled would be windows in which the AP listens for new stations,
> including possibly other nearby APs with which it may mutually coordinate
> time.  A mesh network could thus be constructed entirely out of mutually
> coordinating APs if necessary.
>
> The above paragraph is obviously a giant handwave...
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 3418 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]

Jonathan,

Not that giant handwaving though.
IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost
is necessary as it operates in 2.4/5Ghz bands.
Similar to what you describe, and is coming very soon in shipping products.

RTS/CTS is still a LBT to create a window where TDM can be done.
I don't yet see how a non private spectrum can be shared  w/o LBT.

On the other hand, medium sharing is one thing, the other thing is
capacity.
There is no way to efficiently share a medium if this is used close to its
theoretical capacity.

Capacity as #of stations per band including #SSID per band. Today scaling
can be achieved
with careful radio planning for spatial diversity or dynamic bean forming.

When you approach capacity with WiFi you only see beacon traffic and almost
zero throughput.
Cannot forget Mobile World Congress where you can measure several thousands
of SSIDs on 2.4
and several hundreds of SSID in 5GHz. But even LTE was very close to
capacity.

Dave,
Having air time fairness in open source is a significant achievement. I
don't see a failure.

Luca


On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > Curious to how LBT can be solved at the PHY level and if the potential
> solution sets preserve the end to end principle.
>
> The usual alternatives include TDM, usually coordinated by a master device
> (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding;
> and simply firing off a packet and retrying with exponential backoff if an
> acknowledgement is not heard.
>
> TDM and diplexing are already used by both DOCSIS and LTE.  They are
> proven technology.  However, in DOCSIS the diplexing is greatly simplified
> by the use of a copper channel rather than airwaves, and in LTE the
> diplexer is fitted only at the tower, not in each client - so the tower can
> transmit and receive simultaneously, but an individual client cannot, but
> this is still useful because there are many clients per tower.  Effective
> diplexers for wireless are expensive.
>
> Orthogonal coding is already used by GPS and, in a rather esoteric form,
> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
> GPS, it allows all of the satellites in the constellation to transmit on
> the standard frequency simultaneously, while still being individually
> distinguishable.  The data rate is very low, however, since each
> satellite's signal inherently has a negative SNR (because there's a dozen
> others shouting over it) - that's why it takes a full minute for a receiver
> to get a fix from cold, because it simply takes that long to download the
> ephemeris from the first satellite whose signal is found.
>
> A future version of wifi could reasonably use TDM, I think, but not
> diplexing.  The way this would work is that the AP assigns each station
> (including itself) a series of time windows in which to transmit as much as
> they like, and broadcasts this schedule along with its beacon.  Also
> scheduled would be windows in which the AP listens for new stations,
> including possibly other nearby APs with which it may mutually coordinate
> time.  A mesh network could thus be constructed entirely out of mutually
> coordinating APs if necessary.
>
> The above paragraph is obviously a giant handwave...
>
>  - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4380 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3918 bytes --]

Hi Luca,

What is non private spectrum defined as per  "I don't yet see how a non
private spectrum can be shared  w/o LBT."

Thanks,
Bob




On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
luca.muscariello@gmail.com> wrote:

> Jonathan,
>
> Not that giant handwaving though.
> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost
> is necessary as it operates in 2.4/5Ghz bands.
> Similar to what you describe, and is coming very soon in shipping
> products.
>
> RTS/CTS is still a LBT to create a window where TDM can be done.
> I don't yet see how a non private spectrum can be shared  w/o LBT.
>
> On the other hand, medium sharing is one thing, the other thing is
> capacity.
> There is no way to efficiently share a medium if this is used close to its
> theoretical capacity.
>
> Capacity as #of stations per band including #SSID per band. Today scaling
> can be achieved
> with careful radio planning for spatial diversity or dynamic bean forming.
>
> When you approach capacity with WiFi you only see beacon traffic and
> almost zero throughput.
> Cannot forget Mobile World Congress where you can measure several
> thousands of SSIDs on 2.4
> and several hundreds of SSID in 5GHz. But even LTE was very close to
> capacity.
>
> Dave,
> Having air time fairness in open source is a significant achievement. I
> don't see a failure.
>
> Luca
>
>
> On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com>
>> wrote:
>> >
>> > Curious to how LBT can be solved at the PHY level and if the potential
>> solution sets preserve the end to end principle.
>>
>> The usual alternatives include TDM, usually coordinated by a master
>> device (eg. the AP); full-duplex operation via diplexers and/or orthogonal
>> coding; and simply firing off a packet and retrying with exponential
>> backoff if an acknowledgement is not heard.
>>
>> TDM and diplexing are already used by both DOCSIS and LTE.  They are
>> proven technology.  However, in DOCSIS the diplexing is greatly simplified
>> by the use of a copper channel rather than airwaves, and in LTE the
>> diplexer is fitted only at the tower, not in each client - so the tower can
>> transmit and receive simultaneously, but an individual client cannot, but
>> this is still useful because there are many clients per tower.  Effective
>> diplexers for wireless are expensive.
>>
>> Orthogonal coding is already used by GPS and, in a rather esoteric form,
>> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
>> GPS, it allows all of the satellites in the constellation to transmit on
>> the standard frequency simultaneously, while still being individually
>> distinguishable.  The data rate is very low, however, since each
>> satellite's signal inherently has a negative SNR (because there's a dozen
>> others shouting over it) - that's why it takes a full minute for a receiver
>> to get a fix from cold, because it simply takes that long to download the
>> ephemeris from the first satellite whose signal is found.
>>
>> A future version of wifi could reasonably use TDM, I think, but not
>> diplexing.  The way this would work is that the AP assigns each station
>> (including itself) a series of time windows in which to transmit as much as
>> they like, and broadcasts this schedule along with its beacon.  Also
>> scheduled would be windows in which the AP listens for new stations,
>> including possibly other nearby APs with which it may mutually coordinate
>> time.  A mesh network could thus be constructed entirely out of mutually
>> coordinating APs if necessary.
>>
>> The above paragraph is obviously a giant handwave...
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>

[-- Attachment #2: Type: text/html, Size: 4952 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]

Hi Bob,

I meant licensed/unlicensed for private/non private.

Luca

On Mon, Aug 27, 2018 at 9:39 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> Hi Luca,
>
> What is non private spectrum defined as per  "I don't yet see how a non
> private spectrum can be shared  w/o LBT."
>
> Thanks,
> Bob
>
>
>
>
> On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
> luca.muscariello@gmail.com> wrote:
>
>> Jonathan,
>>
>> Not that giant handwaving though.
>> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The
>> almost is necessary as it operates in 2.4/5Ghz bands.
>> Similar to what you describe, and is coming very soon in shipping
>> products.
>>
>> RTS/CTS is still a LBT to create a window where TDM can be done.
>> I don't yet see how a non private spectrum can be shared  w/o LBT.
>>
>> On the other hand, medium sharing is one thing, the other thing is
>> capacity.
>> There is no way to efficiently share a medium if this is used close to
>> its theoretical capacity.
>>
>> Capacity as #of stations per band including #SSID per band. Today scaling
>> can be achieved
>> with careful radio planning for spatial diversity or dynamic bean forming.
>>
>> When you approach capacity with WiFi you only see beacon traffic and
>> almost zero throughput.
>> Cannot forget Mobile World Congress where you can measure several
>> thousands of SSIDs on 2.4
>> and several hundreds of SSID in 5GHz. But even LTE was very close to
>> capacity.
>>
>> Dave,
>> Having air time fairness in open source is a significant achievement. I
>> don't see a failure.
>>
>> Luca
>>
>>
>> On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton <chromatix99@gmail.com>
>> wrote:
>>
>>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com>
>>> wrote:
>>> >
>>> > Curious to how LBT can be solved at the PHY level and if the potential
>>> solution sets preserve the end to end principle.
>>>
>>> The usual alternatives include TDM, usually coordinated by a master
>>> device (eg. the AP); full-duplex operation via diplexers and/or orthogonal
>>> coding; and simply firing off a packet and retrying with exponential
>>> backoff if an acknowledgement is not heard.
>>>
>>> TDM and diplexing are already used by both DOCSIS and LTE.  They are
>>> proven technology.  However, in DOCSIS the diplexing is greatly simplified
>>> by the use of a copper channel rather than airwaves, and in LTE the
>>> diplexer is fitted only at the tower, not in each client - so the tower can
>>> transmit and receive simultaneously, but an individual client cannot, but
>>> this is still useful because there are many clients per tower.  Effective
>>> diplexers for wireless are expensive.
>>>
>>> Orthogonal coding is already used by GPS and, in a rather esoteric form,
>>> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
>>> GPS, it allows all of the satellites in the constellation to transmit on
>>> the standard frequency simultaneously, while still being individually
>>> distinguishable.  The data rate is very low, however, since each
>>> satellite's signal inherently has a negative SNR (because there's a dozen
>>> others shouting over it) - that's why it takes a full minute for a receiver
>>> to get a fix from cold, because it simply takes that long to download the
>>> ephemeris from the first satellite whose signal is found.
>>>
>>> A future version of wifi could reasonably use TDM, I think, but not
>>> diplexing.  The way this would work is that the AP assigns each station
>>> (including itself) a series of time windows in which to transmit as much as
>>> they like, and broadcasts this schedule along with its beacon.  Also
>>> scheduled would be windows in which the AP listens for new stations,
>>> including possibly other nearby APs with which it may mutually coordinate
>>> time.  A mesh network could thus be constructed entirely out of mutually
>>> coordinating APs if necessary.
>>>
>>> The above paragraph is obviously a giant handwave...
>>>
>>>  - Jonathan Morton
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>>

[-- Attachment #2: Type: text/html, Size: 5410 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Jonathan Morton]

> On 27 Aug, 2018, at 10:06 am, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
> 
> How can a centralized device predict the many "end stations'" network demand in its time scheduling?

DOCSIS does it by initially giving stations a tiny window into which to send requests for time, which are granted by the head-end.  This introduces some latency.  Further requests for time can be appended to a real transmission, which helps efficiency slightly.

Developing from that model, an AP might initially divide time evenly between stations, allowing them to send single large packets or several small packets without an explicit request for time - this is good for latency.  Along with that packet, the station could indicate to the AP that it has a queue of packets waiting, and the AP would take that into account when producing its next schedule.  It would also take into account its own queue.

It may be possible to combine TDM with orthogonal coding.  Here the AP monitors the received signal strength of its stations, and instructs them to change power so as to minimise the difference between them.  This maximises the SNR for each, should two transmit simultaneously.  The tradeoff, of course, is that orthogonal coding permits a reduction in waiting to transmit, but requires a reduction in data rate during the transmission.  I'm sure other people have better data on that than I do.

 - Jonathan Morton

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

Hi Jonathan,
I think in 802.11ax the AP can schedule STAs to some extent so it looks
like that technique is coming soon.  It is a bw tradeoff per the RUs per
user.

Multi-User Uplink Operation

To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a
trigger frame to all users. This frame indicates the number of spatial
streams and/or the OFDMA allocations (frequency and RU sizes) of each user.
It also contains power control information, such that individual users can
increase or reduce their transmitted power, in an effort to equalize the
power that the AP receives from all uplink users and improve reception of
frames from nodes farther away. The AP also instructs all users when to
start and stop transmitting. As Figure 10depicts, the AP sends a multi-user
uplink trigger frame that indicates to all users the exact moment at which
they all start transmitting, and the exact duration of their frame, to
ensure that they all finish transmitting simultaneously as well. Once the
AP receives the frames from all users, it sends them back a block ACK to
finish the operation.



*Figure 10. Coordinating uplink multi-user operation*




On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 27 Aug, 2018, at 10:06 am, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > How can a centralized device predict the many "end stations'" network
> demand in its time scheduling?
>
> DOCSIS does it by initially giving stations a tiny window into which to
> send requests for time, which are granted by the head-end.  This introduces
> some latency.  Further requests for time can be appended to a real
> transmission, which helps efficiency slightly.
>
> Developing from that model, an AP might initially divide time evenly
> between stations, allowing them to send single large packets or several
> small packets without an explicit request for time - this is good for
> latency.  Along with that packet, the station could indicate to the AP that
> it has a queue of packets waiting, and the AP would take that into account
> when producing its next schedule.  It would also take into account its own
> queue.
>
> It may be possible to combine TDM with orthogonal coding.  Here the AP
> monitors the received signal strength of its stations, and instructs them
> to change power so as to minimise the difference between them.  This
> maximises the SNR for each, should two transmit simultaneously.  The
> tradeoff, of course, is that orthogonal coding permits a reduction in
> waiting to transmit, but requires a reduction in data rate during the
> transmission.  I'm sure other people have better data on that than I do.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 4661 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

I guess my question is can a WiFi transmitting device rely on primarily
energy detect and mostly ignore the EDCA probability game and rather search
for (or predict) unused spectrum per a time interval such that its digital
signal has enough power per its observed SNR?   Then detect "collisions"
(or, "superposition cases" per the RX not having sufficient SINR) via
inserting silent gaps in its TX used to sample ED, i.e. run energy detect
throughout the entire transmission?  Or better, no silent gaps, rather
detect if there is superimposed energy on it's own TX and predict a
collision (i.e. RX probably couldn't decode its signal) occurred?  If
doable, this seems simpler than having to realize centralized (or even
distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
token rings, etc. and not require media access coordination by things like
APs.

Bob

On Mon, Aug 27, 2018 at 1:34 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> Hi Jonathan,
> I think in 802.11ax the AP can schedule STAs to some extent so it looks
> like that technique is coming soon.  It is a bw tradeoff per the RUs per
> user.
>
> Multi-User Uplink Operation
>
> To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a
> trigger frame to all users. This frame indicates the number of spatial
> streams and/or the OFDMA allocations (frequency and RU sizes) of each user.
> It also contains power control information, such that individual users can
> increase or reduce their transmitted power, in an effort to equalize the
> power that the AP receives from all uplink users and improve reception of
> frames from nodes farther away. The AP also instructs all users when to
> start and stop transmitting. As Figure 10depicts, the AP sends a multi-user
> uplink trigger frame that indicates to all users the exact moment at which
> they all start transmitting, and the exact duration of their frame, to
> ensure that they all finish transmitting simultaneously as well. Once the
> AP receives the frames from all users, it sends them back a block ACK to
> finish the operation.
>
>
>
> *Figure 10. Coordinating uplink multi-user operation*
>
>
>
>
> On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> > On 27 Aug, 2018, at 10:06 am, Bob McMahon <bob.mcmahon@broadcom.com>
>> wrote:
>> >
>> > How can a centralized device predict the many "end stations'" network
>> demand in its time scheduling?
>>
>> DOCSIS does it by initially giving stations a tiny window into which to
>> send requests for time, which are granted by the head-end.  This introduces
>> some latency.  Further requests for time can be appended to a real
>> transmission, which helps efficiency slightly.
>>
>> Developing from that model, an AP might initially divide time evenly
>> between stations, allowing them to send single large packets or several
>> small packets without an explicit request for time - this is good for
>> latency.  Along with that packet, the station could indicate to the AP that
>> it has a queue of packets waiting, and the AP would take that into account
>> when producing its next schedule.  It would also take into account its own
>> queue.
>>
>> It may be possible to combine TDM with orthogonal coding.  Here the AP
>> monitors the received signal strength of its stations, and instructs them
>> to change power so as to minimise the difference between them.  This
>> maximises the SNR for each, should two transmit simultaneously.  The
>> tradeoff, of course, is that orthogonal coding permits a reduction in
>> waiting to transmit, but requires a reduction in data rate during the
>> transmission.  I'm sure other people have better data on that than I do.
>>
>>  - Jonathan Morton
>>
>>

[-- Attachment #2: Type: text/html, Size: 5915 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Jonathan Morton]

> On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
> 
> I guess my question is can a WiFi transmitting device rely on primarily energy detect and mostly ignore the EDCA probability game and rather search for (or predict) unused spectrum per a time interval such that its digital signal has enough power per its observed SNR?   Then detect "collisions" (or, "superposition cases" per the RX not having sufficient SINR) via inserting silent gaps in its TX used to sample ED, i.e. run energy detect throughout the entire transmission?  Or better, no silent gaps, rather detect if there is superimposed energy on it's own TX and predict a collision (i.e. RX probably couldn't decode its signal) occurred?  If doable, this seems simpler than having to realize centralized (or even distributed) media access algorithms a la, TDM, EDCA with ED, token buses, token rings, etc. and not require media access coordination by things like APs.

The software might be simpler, but the hardware would need to be overspecified to the point of making it unreasonably expensive for consumer devices.

Radio hardware generally has a significant TX/RX turnaround time, required for the RX deafening circuits to disengage.  Without those deafening circuits, the receivers would be damaged by the comparatively vast TX power in the antenna.

So in practice, it's easier to measure SNR at the receiver, or indirectly by observing packet loss by dint of missing acknowledgements returned to the transmitter.

 - Jonathan Morton

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

ok thanks, that's helpful.  I guess I thought if astrophysicists can direct
image exoplanets
<https://www.space.com/30248-young-jupiter-smallest-directly-imaged-exoplanet.html>
a WiFi device should be able to detect superposition  - though, talk about
some giant hand waving! ;)

Bob

On Mon, Aug 27, 2018 at 12:45 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > I guess my question is can a WiFi transmitting device rely on primarily
> energy detect and mostly ignore the EDCA probability game and rather search
> for (or predict) unused spectrum per a time interval such that its digital
> signal has enough power per its observed SNR?   Then detect "collisions"
> (or, "superposition cases" per the RX not having sufficient SINR) via
> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
> throughout the entire transmission?  Or better, no silent gaps, rather
> detect if there is superimposed energy on it's own TX and predict a
> collision (i.e. RX probably couldn't decode its signal) occurred?  If
> doable, this seems simpler than having to realize centralized (or even
> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
> token rings, etc. and not require media access coordination by things like
> APs.
>
> The software might be simpler, but the hardware would need to be
> overspecified to the point of making it unreasonably expensive for consumer
> devices.
>
> Radio hardware generally has a significant TX/RX turnaround time, required
> for the RX deafening circuits to disengage.  Without those deafening
> circuits, the receivers would be damaged by the comparatively vast TX power
> in the antenna.
>
> So in practice, it's easier to measure SNR at the receiver, or indirectly
> by observing packet loss by dint of missing acknowledgements returned to
> the transmitter.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 2340 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

I thought that RTS/CTS would handle the case of hidden nodes, i.e. a device
that fails to successfully transmit can resort to RTS/CTS to get the
receiver to reserve time for it.  Also, lack of a RX ack seems ok to
trigger MAC level retransmits.

It seems the LBT bug is the collision avoidance overheads when it isn't
needed, i.e. no other energy would cause the RX PHY to fail its decode and
the EDCA backoffs had no benefit, stochastic or otherwise.   Optimizing
that out is said to be not possible from local information only and per
"shared" spectrum.

Bob


On Mon, Aug 27, 2018 at 3:33 PM David Lang <david@lang.hm> wrote:

> On Mon, 27 Aug 2018, Jonathan Morton wrote:
>
> > So in practice, it's easier to measure SNR at the receiver, or
> indirectly by
> > observing packet loss by dint of missing acknowledgements returned to
> the
> > transmitter.
>
> Also, there may be other transmitters that the recipient of the packets
> can hear
> that you cannot hear, so it's not possible to detect colliding
> transmissions
> directly in all cases.
>
> This is another trap that digital/wired people fall into that doesn't
> really
> apply in the analog/radio world.
>
> David Lang
>

[-- Attachment #2: Type: text/html, Size: 1650 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

Hmm, not sure I understand the distinction.   CTS per the AP informs those
other transmitters to stay quiet per the CTS NAV.  I may be
misunderstanding things.  Thanks for the continued discussions.  It helps
to better thoroughly understand the issues.

Bob

On Mon, Aug 27, 2018, 6:52 PM David Lang <david@lang.hm> wrote:

> On Mon, 27 Aug 2018, Bob McMahon wrote:
>
> > I thought that RTS/CTS would handle the case of hidden nodes, i.e. a
> device
> > that fails to successfully transmit can resort to RTS/CTS to get the
> > receiver to reserve time for it.  Also, lack of a RX ack seems ok to
> > trigger MAC level retransmits.
>
> the problem isn't getting the receiver to reserve time for it, it's
> getting the
> other transmitter(s) to not step on it when it transmits. Those other
> transmitters may belong to different people, sharing a channel with your
> system
> and nothing else.
>
> David Lang
>
> > It seems the LBT bug is the collision avoidance overheads when it isn't
> > needed, i.e. no other energy would cause the RX PHY to fail its decode
> and
> > the EDCA backoffs had no benefit, stochastic or otherwise.   Optimizing
> > that out is said to be not possible from local information only and per
> > "shared" spectrum.
> >
> > Bob
> >
> >
> > On Mon, Aug 27, 2018 at 3:33 PM David Lang <david@lang.hm> wrote:
> >
> >> On Mon, 27 Aug 2018, Jonathan Morton wrote:
> >>
> >>> So in practice, it's easier to measure SNR at the receiver, or
> >> indirectly by
> >>> observing packet loss by dint of missing acknowledgements returned to
> >> the
> >>> transmitter.
> >>
> >> Also, there may be other transmitters that the recipient of the packets
> >> can hear
> >> that you cannot hear, so it's not possible to detect colliding
> >> transmissions
> >> directly in all cases.
> >>
> >> This is another trap that digital/wired people fall into that doesn't
> >> really
> >> apply in the analog/radio world.
> >>
> >> David Lang
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 2669 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

[-- Attachment #1: Type: text/plain, Size: 14781 bytes --]

I've only skimmed through, but as I see it, many points have already been
addressed. TV went digital, large parts of the spectrum freed up for other
purposes while allowing to transmit in local whitespaces where available:

https://en.wikipedia.org/wiki/IEEE_802.11af#Spectrum_regulation

As a different note, there's also research towards the direction of fully
and efficiently utilizing the TV spectrum everywhere:

https://en.wikipedia.org/wiki/WiB_(Digital_Terrestrial_Television)

They say that CB, despite its numerous channels demised due to overuse and
illegal range extensions.
https://en.wikipedia.org/wiki/CB_radio#21st-century_use

Wifi is already pretty crowded in urban areas, but it is only saved by its
poor propagation. Imagine what happened if people got their hands on UHF
that propagates very well even using very cheap transmitters without any
strings attached. Many would definitely attempt to set up their very own
town-wide stations, happily spoiling the fun for everyone else.

It is interesting that a majority of people who I talk to already ask what
needs to be done or bought if one wants to crank up the power on wifi so
every corner in their house gets excellent coverage. It rarely occurs to
them that instead of trying to beef up a router, they could simply buy two
cheap & standard ones and connect them via cable (/wireless) for a stable
AP (/repeater) configuration. This seems to be the nature of human thinking.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

On Sun, Aug 26, 2018 at 2:26 PM David P. Reed <dpreed@deepplum.com> wrote:

> Baran: I got the year wrong. I remember it as 1993, but it was 1994 CNGN
> speech he made, which is resurrected here:
> https://www.eff.org/pages/false-scarcity-baran-cngn-94
>
> Paul was educated in EE, as was I. So radio made sense to him. Unlike kids
> brought up on the idea that bits are and must be physically discrete
> spatial and temporal mechanical things.
>
> You know, one can have 1/10 of a bit of information, and store it in 1/10
> of a bit of storage. Or transmit a symbol that passes through local noise
> and comes out the other side uncorrupted.
>
> But kids trained in fancy CS depts. assume that bits require clear, empty,
> noiseless, pristine paths. Pure Bullshit. But CS and now many EE depts. and
> the FCC all proselytize such crap
>
> So scarcity is inventedand sustained.
>
> There is a reigning Supreme Court opinion, the law of the land, that says
> that there is by law a "finite number" of usable frequencies, and only one
> transmitter can be allowed to use it at a time. Like legislating that pi =
> 3 in a state, to make math easier.
>
> Except it is totally designed to create scarcity. And the State/Industry
> Nexus maintains it at every turn. It's why lunatic economists claim that
> spectrum is a form of property that can be auctioned. Like creating
> property rights to each acre of the sea, allowing owners to block shipping
> by buying a connected path down the mid Atlantic.
>
> We live in a Science Ignorant world. Intentionally. Even trained pH D.
> Engineers testify before the FCC to preserve these lies.
>
> Yeah, I sound nuts. Check it out.
>
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Sat, Aug 25, 2018 at 5:22 pm
> To: dpreed@deepplum.com
> Cc: bloat-announce@lists.bufferbloat.net, "bloat" <
> bloat@lists.bufferbloat.net>, "Make-Wifi-fast" <
> make-wifi-fast@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] closing up my make-wifi-fast lab
>
> On Sat, Aug 25, 2018 at 1:04 PM David P. Reed  wrote:
> >
> > WiFi is a bit harder than IP. But you know that.
> >
> > I truly believe that we need to fix the phy/waveform/modulation space to
> really scale up open wireless networking capability. LBT is the basic bug
> in WiFi, and it is at that layer, melow the MAC.
> >
> > I have tried for 20 years now to find a way to begin work at that
> project, by the way. There is also no major donor anywhere to be found for
> that work. Instead, any funds that seem to be appearing get attacked and
> sucked into projects that miss the point, being controlled by folks who
> oppose openness (e.g. WISPs wanting exclusive ownership of a market, such
> as so called SuperWiFi or whitespaces). I did once come close to a useful
> award when I was at MIT Media Lab, from NSF. But after the award, the
> funding was cut by 90%, leaving just enough to support a Master's thesis on
> co-channel sharing, using two 1st Gen USRPs. Using my own funds, spare
> time, and bubblegum and baling wire, I've slowly begun work on extra
> wideband FPGA based sounding-centric sharing in the 10 GHz Ham band. (500
> MHz wide modulation), where I can self certify multiple stations in a
> network.
> >
> > But the point is, I've failed, because there is less than zero support.
> There is active opposition, on top of cluelessness.
> >
> > Paul Baran tried in 1993 to push forward a similar agenda, famously. 99%
> of his concepts died.
>
> Cite?
>
> One of the things that bothers me about packet processing is that
> Donald Davies (the oft uncredited other founder of the concept) wrote
> 11 volumes on this subject. So far as I know, those have vanished to
> history.
>
> Periodically, when I get stuck on something in this field, I fantasize
> that scribbled in the margin of volume 9 was the solution to the
> problem.
>
> > Thanks to Apple, and lots of others, we got WiFi, barely. Industry hated
> that, and vow never to let that ever happen again.
>
> It really was a strange convolution of circumstances that led to wifi.
> When i first got it working in 1998, metricom ruled the world. They
> failed. After that, nobody thought it was feasible at scale until the
> concept of a mac retry emerged to fix the packet loss problem, and APs
> to provide a central clock (best we could do with the DSPs then).  So
> a window emerged (and yes, hugely driven by apple, but also by huge
> popular demand for "wireless freedom") to put "buggy" wireless tech on
> the crap 2.4 band in the hands of the people, it got established and
> made the coffee shop a workplace, and bigcos attempting to wipe it out
> (and largely, in the last few years, succeeding in dislodging it) have
> had an uphill battle.
>
> If metricom had succeeded, or the celluar folk got their
> implementations working only a few years faster, it would be a very
> different world.
>
> (this history is all covered in my MIT preso here:
> https://www.youtube.com/watch?v=Wksh2DPHCDI&t=2007s - david was at
> that one)
>
> >
> > So Dave, I salute you and Toke and the others. I salute Tim Shepard, who
> also moved the ball in his PhD thesis, only to hit the same wall of
> opposition.
>
> Soooo many others involved, felix feitkau in particular comes to mind.
>
> Still, I think fixing the "wifi anomaly" is the greatest achievement
> of my career... and toke's hasn't even officially started yet! Someday
> perhaps that will be worth a medal, or an small entry for us in
> wikipedia.
>
> > It's so sad. We get shit like the "Obama band" proposed by PCAST, and
> are told to be thankful.
>
> Let's not get started on that or whitespaces today.
>
> > UWB failed miserably, too.
>
> I wish that could be resurrected.
>
> > My advice to any young smart innovator: don't touch wireless unless you
> are working for an incumbent. Expect the incumbents and governments to
> close and destroy wireless innovation.
>
> I agree. Well, I do have some hope and interest in spacex's
> constellation, but I remember teledesic's failure too well.
>
> >
> > Really. You will be in a world of hurt, and NO ONE will support
> anything. Not even VCs.
> >
> > Very sorry to say this. I had hoped Make WiFi Fast would have gone
> somewhere. I mourn its passing.
>
> It's not dead, I'm just closing my lab.
>
> In the document I cited for more wifi fixes, things like dynamically
> scaling down the announced txop under contention, lowering retries,
> offering a little less protection for packets when overloaded, a "tx
> is almost done" interrupt, etc, are all things I expect vendors and
> open source folk to try. I keep hoping minstrel-blues will land. Etc.
> Outside the US there's still a lot of positive activity. Products like
> eero and google wifi continue to sell like hotcakes, as well as tons
> of cheaper gear, and iot, etc, etc.
>
> And there's some good progress in 802.11ax.
>
> fq_codel for wifi + these mods will make wifi continue to be more than
> competitive with the upcoming 5G stuff.
>
> But i don't need to be the one to implement or test them. I should
> have shut things down when the shuttleworth grant didn't come through.
> When you can no longer get up in the morning to work, nor able to hold
> the wifi standard and related code in your head, it's time to move on.
>
> It is bothersome to me that the ISPs don't seem to realize that their
> business will fail unless they have good wifi, but the big ones are
> out there merging with the LTE folk and don't care either.
>
> Wifi's had a great run. I think here - with 5 years of work - we've
> extended its life another 5 years - at least. Still, unless
> applications emerge again that need good low latency (like vr) over
> wifi, nothings going to drive those down further to compete with 5g.
>
> >
> > -----Original Message-----
> > From: "Dave Taht"
> > Sent: Fri, Aug 24, 2018 at 4:10 pm
> > To: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" ,
> cerowrt-devel@lists.bufferbloat.net
> > Cc: bloat-announce@lists.bufferbloat.net, "bloat" , "Make-Wifi-fast" ,
> cerowrt-devel@lists.bufferbloat.net
> > Subject: [Cerowrt-devel] closing up my make-wifi-fast lab
> >
> > All:
> >
> > It is with some regret that I am announcing the closing of my
> > make-wifi-fast lab at the end of this month.
> >
> > Over the years we have relied on the donation of lab space from
> > ISC.org, georgia tech, the LINCs, and the University of Karstadt and
> > elsewhere - but my main base of operation has always been the
> > "yurtlab", in a campground deep in the los gatos hills where I could
> > both experiment and deploy wifi fixes[0] at scale. CeroWrt, in
> > particular, was made here.
> >
> > During the peak of the make-wifi-fast effort I rented additional space
> > on the same site, which at peak had over 30 routers in a crowded
> > space, competing. Which I (foolishly) kept, despite the additional
> > expense. Having heat in the winter and aircond in the summer was
> > helpful.
> >
> > With ongoing donations running at $90/month[1] - which doesn't even
> > cover bufferbloat.net's servers in the cloud - my biggest expense has
> > been keeping the lab at lupin open at $1800/mo.
> >
> > I kept the lab going through the sch_cake and openwrt 18.06 release
> > process, and I'm now several months behind on rent[3], and given how
> > things have gone for the past 2 years I don't see much use for it in
> > the future. Keeping it open, heated and dry in the winter has always
> > been a problem also. I'm also aware of a few larger, much better
> > equipped wifi labs that have thoroughly tested our "fq_codel for
> > wifi"[4] work that finally ends the "wifi performance anomaly". it's
> > in multiple commercial products now, we're seeing airtime fairness
> > being actually *marketed* as a wifi feature, and I kind of expect
> > deployment be universal across all mediatek mt76, and qualcomm ath9k
> > and ath10k based products in the next year or two. We won, big, on
> > wifi. Knocked it out of the park. Thanks all!
> >
> > Despite identifying all kinds of other work[5] that can be done to
> > make wifi better, no major (or even minor) direct sponsor has ever
> > emerged[2] for the make-wifi-fast project. We had a small grant from
> > comcast, a bit of support from nlnet also, I subsidized what I did
> > here from other work sources, toke had his PHD support, and all the
> > wonderful volunteers here... and that's it.
> >
> > Without me being able, also, to hire someone to keep the lab going, as
> > I freely admit to burnout and PTSD on perpetually reflashing and
> > reconfiguring routers...
> >
> > I'm closing up shop here to gather enough energy, finances, and time
> > for the next project, whatever it is.
> >
> > The make-wifi-fast mailing list and project will continue, efforts to
> > make more generic the new API also, and hopefully there's enough users
> > out there to
> > keep it all going forward without the kind of comprehensive testing I
> > used to do here.
> >
> > If anyone feels like reflashing, oh, 30 bricked routers of 8 different
> > models, from serial ports (in multiple cases, like the 6 uap-ac-lites,
> > via soldiering on headers), I'll gladly toss all the extra equipment
> > in the lab in a big box and ship them to you. Suggestions for a
> > suitable donation target are also of interest.
> >
> > The yurtlab has been an amazing, totally unique, unusual (and
> > sometimes embarrassing [6]) place to work and think, but it's time to
> > go.
> >
> > Perhaps I'll convince my amazingly supportive landlord to let me leave
> > behind a plaque:
> >
> > "On this spot bufferbloat on the internet and in WiFi was fixed,
> 2011-2018".
> >
> > Sincerely,
> > Dave Taht
> >
> > [0] https://lwn.net/Articles/705884/ "How we made wifi fast again"
> > [1] https://www.patreon.com/dtaht
> > [2] Like adrian chadd's infamous flameout - I too, give up on wifi.
> > There's gotta be some other tech worth working on. What we shipped is
> > "good enough" to carry a few years though.
> > [3] This is not a passive-aggressive request for help making rent next
> > month, given all the other problems I have, it's best to close up shop
> > while I look for a new gig.
> > [4] https://arxiv.org/pdf/1703.00064.pdf "ending the wifi anomaly"
> > [5]
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
> > [6]
> https://www.cringely.com/2012/10/01/clothing-may-be-optional-but-bufferbloat-isnt/
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 18555 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

Full-duplex still needs some work, but there is definite progress:
http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
https://sing.stanford.edu/fullduplex/
https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
http://fullduplex.rice.edu/research/

On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > I guess my question is can a WiFi transmitting device rely on primarily
> energy detect and mostly ignore the EDCA probability game and rather search
> for (or predict) unused spectrum per a time interval such that its digital
> signal has enough power per its observed SNR?   Then detect "collisions"
> (or, "superposition cases" per the RX not having sufficient SINR) via
> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
> throughout the entire transmission?  Or better, no silent gaps, rather
> detect if there is superimposed energy on it's own TX and predict a
> collision (i.e. RX probably couldn't decode its signal) occurred?  If
> doable, this seems simpler than having to realize centralized (or even
> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
> token rings, etc. and not require media access coordination by things like
> APs.
>
> The software might be simpler, but the hardware would need to be
> overspecified to the point of making it unreasonably expensive for consumer
> devices.
>
> Radio hardware generally has a significant TX/RX turnaround time, required
> for the RX deafening circuits to disengage.  Without those deafening
> circuits, the receivers would be damaged by the comparatively vast TX power
> in the antenna.
>
> So in practice, it's easier to measure SNR at the receiver, or indirectly
> by observing packet loss by dint of missing acknowledgements returned to
> the transmitter.
>
>  - Jonathan Morton
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 3290 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 4225 bytes --]

Minimizing power is rule #2 per Paul Banan.

SOME KINDERGARTEN RULES (written in 1994)

   To take the fullest advantage of our new technology with its sharing
   of a common resource requires that our smart transmitters and
   receivers cooperate. This may sound complicated, but the rules to make
   maximum effective use of the shared band are simple -- primarily a
   matter of common decency in sharing resources. The rules are somewhat
   similar to those you learned in kindergarten, assuming you lived in a
   tough neighborhood.

   Rule #1. Keep away from the big bullies in the playground. (Avoid the
   strongest signals.)

   Rule #2. Share your toys. (Minimize your transmitted power. Use the
   shortest hop distances feasible. Minimize average power density per
   Hertz.)

   Rule #3. If you have nothing to say, keep quiet.

   Rule #4. Don't pick on the big kids. (Don't step on strong signals.
   You're going to get clobbered.)

   Rule #5. If you feel you absolutely must beat up somebody, be sure to
   pick someone smaller than yourself. (Now this is a less obvious one,
   as weak signals represent far away transmissions; so your signals will
   likely be attenuated the same amount in the reverse direction and
   probably not cause significant interference.)

   Rule #6. Don't get too close to your neighbor. Even the weakest
   signals are very strong when they are shouted in your ear.

   Rule #7. Lastly, don't be a cry baby. (If you insist on using obsolete
   technology that is highly sensitive to interfering signals, don't
   expect much sympathy when you complain about interfering signals in a
   shared band.)

Bob


On Thu, Aug 30, 2018 at 12:12 PM bkil <bkil.hu+Aq@gmail.com> wrote:

> Full-duplex still needs some work, but there is definite progress:
> http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
>
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
> https://sing.stanford.edu/fullduplex/
>
> https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
> http://fullduplex.rice.edu/research/
>
> On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com>
>> wrote:
>> >
>> > I guess my question is can a WiFi transmitting device rely on primarily
>> energy detect and mostly ignore the EDCA probability game and rather search
>> for (or predict) unused spectrum per a time interval such that its digital
>> signal has enough power per its observed SNR?   Then detect "collisions"
>> (or, "superposition cases" per the RX not having sufficient SINR) via
>> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
>> throughout the entire transmission?  Or better, no silent gaps, rather
>> detect if there is superimposed energy on it's own TX and predict a
>> collision (i.e. RX probably couldn't decode its signal) occurred?  If
>> doable, this seems simpler than having to realize centralized (or even
>> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
>> token rings, etc. and not require media access coordination by things like
>> APs.
>>
>> The software might be simpler, but the hardware would need to be
>> overspecified to the point of making it unreasonably expensive for consumer
>> devices.
>>
>> Radio hardware generally has a significant TX/RX turnaround time,
>> required for the RX deafening circuits to disengage.  Without those
>> deafening circuits, the receivers would be damaged by the comparatively
>> vast TX power in the antenna.
>>
>> So in practice, it's easier to measure SNR at the receiver, or indirectly
>> by observing packet loss by dint of missing acknowledgements returned to
>> the transmitter.
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 6409 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

Yes, I've read that part in the past. These are very good rules of
thumb, but there are many inefficiencies to cope with.

Note that not all wireless users are "rude" on purpose. It's just that
if you want to keep in touch with your relatives in the nearby town,
you use the minimal needed power for the given circumstances that
happens to be a large amount (point to point).

1a.
Let's focus on a point to point link first. Omni antennas would
trivially interfere with our own neighborhood as well while working a
long link. However, because not everyone has roof access, space for a
large aerial or money for an expensive one, using an omni would be
considered a local optimum for many.

1b.
Let's assume that we are a good citizen using more expensive highly
directional antennae and we live at the perimeter. Considering that
the reception angle of the most practical ones should be 10-20
degrees, this probably easily illuminates the perimeter of the
neighboring town. That wouldn't be deadly interference from that
distance, but it means that it's not scalable in the sense that not
everyone living at the perimeter could communicate with their
respective relative in the neighboring town. It would need a high
level of sophistication to achieve that. It would be much more
efficient and cost effective if these people cooperated and pooled in
resources to build only a handful of well-placed high power
transcievers that they digitally shared with each other using low
power and inexpensive last mile access technologies. But as the old
saying goes, "The common horse is worst shod." So it is cleanest if we
simply pay for equipment and maintenance, and a new telco is born.
Then as competition intensifies, the spectrum gets clogged up, etc.

1c
If we aren't fortunate enough to live at the perimeter, we need to
cooperate with hops towards the perimeter. It is energetically the
most efficient to have directional links between each of them, but
that requires 2-3 antennae at each node. The ones at the perimeter
definitely need at least two. For one who lives at the perimeter and
only communicates with the neighboring town, it is a local optimum to
not purchase and operate two sets of antennae, cables, radios and
other tools. Without incentives, taking this to the extreme creates a
disconnected ring of perimeter around the town who point outwards. So
in worst case, ones in the middle would again need to up their power
again to work the distance.

2.
To achieve hop optimization, have we reached a level of social
sophistication and digital literacy where we can mesh with everything
and anyone in sight? I feel that to be a stretch, but let's pretend
that we have. Now the "feasible" part is still problematic.
Let's stick with the above scenario of inter-town links or sparsely
populated areas. If there is nobody to mesh with, we need to
artificially deploy and maintain intermediate nodes for this purpose.
Who will pay for this? If nobody, it is not feasible. See above point.
The local optimum of each user is to not deploy intermediate nodes,
and we have reached the tragedy of the commons again.

And we didn't even consider "rude" users analogue to an uninvited
guest who gobbles all your snacks when dropping by. These are only a
minority, but they take plenty. Though UWB wasn't there yet in 1994,
it's feasible today. Just imagine if a school deployed a 1GHz UWB
transciever on UHF to stream their backups or research data all day
over the air because it is less expensive (free) compared to cables.
It would not be feasible to peer with any intermediate hop because
nobody has such expensive and advanced hardware, so they'd happily
operate a point to point link to the nearby town (or partner
institution?). That would definitely spoil the fun for many along the
route and no amount of LBT can fix that. Also they could have decide
to use >100GHz instead, but there is no incentive if the whole
spectrum is free, as higher frequencies propagate worse and equipment
costs more.

So all in all, without incentives, system spectral efficiency doesn't
come naturally - you have to work for it. Hard.
I'm not saying that we should give up, but it takes much more than a
few sentences to come up with rules that really work in real life
situations when scaled up. There are pro and contra in many methods of
spectrum allocations, no doubt about that, but I don't feel that there
exists one clear "best" method that we are purposefully neglecting.

Of course at the same time, scalable unregulated alternatives do
exist, but we were talking radio above:
https://en.wikipedia.org/wiki/RONJA
https://en.wikipedia.org/wiki/Modulated_ultrasound
https://en.wikipedia.org/wiki/Sneakernet

On Thu, Aug 30, 2018 at 9:17 PM Bob McMahon <bob.mcmahon@broadcom.com> wrote:
>
> Minimizing power is rule #2 per Paul Banan.
>
> SOME KINDERGARTEN RULES (written in 1994)
>
>    To take the fullest advantage of our new technology with its sharing
>    of a common resource requires that our smart transmitters and
>    receivers cooperate. This may sound complicated, but the rules to make
>    maximum effective use of the shared band are simple -- primarily a
>    matter of common decency in sharing resources. The rules are somewhat
>    similar to those you learned in kindergarten, assuming you lived in a
>    tough neighborhood.
>
>    Rule #1. Keep away from the big bullies in the playground. (Avoid the
>    strongest signals.)
>
>    Rule #2. Share your toys. (Minimize your transmitted power. Use the
>    shortest hop distances feasible. Minimize average power density per
>    Hertz.)
>
>    Rule #3. If you have nothing to say, keep quiet.
>
>    Rule #4. Don't pick on the big kids. (Don't step on strong signals.
>    You're going to get clobbered.)
>
>    Rule #5. If you feel you absolutely must beat up somebody, be sure to
>    pick someone smaller than yourself. (Now this is a less obvious one,
>    as weak signals represent far away transmissions; so your signals will
>    likely be attenuated the same amount in the reverse direction and
>    probably not cause significant interference.)
>
>    Rule #6. Don't get too close to your neighbor. Even the weakest
>    signals are very strong when they are shouted in your ear.
>
>    Rule #7. Lastly, don't be a cry baby. (If you insist on using obsolete
>    technology that is highly sensitive to interfering signals, don't
>    expect much sympathy when you complain about interfering signals in a
>    shared band.)
>
> Bob
>
>
> On Thu, Aug 30, 2018 at 12:12 PM bkil <bkil.hu+Aq@gmail.com> wrote:
>>
>> Full-duplex still needs some work, but there is definite progress:
>> http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
>> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
>> https://sing.stanford.edu/fullduplex/
>> https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
>> http://fullduplex.rice.edu/research/
>>
>> On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton <chromatix99@gmail.com> wrote:
>>>
>>> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
>>> >
>>> > I guess my question is can a WiFi transmitting device rely on primarily energy detect and mostly ignore the EDCA probability game and rather search for (or predict) unused spectrum per a time interval such that its digital signal has enough power per its observed SNR?   Then detect "collisions" (or, "superposition cases" per the RX not having sufficient SINR) via inserting silent gaps in its TX used to sample ED, i.e. run energy detect throughout the entire transmission?  Or better, no silent gaps, rather detect if there is superimposed energy on it's own TX and predict a collision (i.e. RX probably couldn't decode its signal) occurred?  If doable, this seems simpler than having to realize centralized (or even distributed) media access algorithms a la, TDM, EDCA with ED, token buses, token rings, etc. and not require media access coordination by things like APs.
>>>
>>> The software might be simpler, but the hardware would need to be overspecified to the point of making it unreasonably expensive for consumer devices.
>>>
>>> Radio hardware generally has a significant TX/RX turnaround time, required for the RX deafening circuits to disengage.  Without those deafening circuits, the receivers would be damaged by the comparatively vast TX power in the antenna.
>>>
>>> So in practice, it's easier to measure SNR at the receiver, or indirectly by observing packet loss by dint of missing acknowledgements returned to the transmitter.
>>>
>>>  - Jonathan Morton
>>>
>>> _______________________________________________
>>> Make-wifi-fast mailing list
>>> Make-wifi-fast@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 9770 bytes --]

Agreed that incentives are non trivial.   I found this article about bike
share redistribution interesting:

New York's bike share system pays rider to make it run better
<http://www.slate.com/blogs/moneybox/2017/02/09/new_york_s_citi_bike_pays_riders_to_make_it_run_better.html>

Bob

On Thu, Aug 30, 2018 at 1:36 PM bkil <bkil.hu+Aq@gmail.com> wrote:

> Yes, I've read that part in the past. These are very good rules of
> thumb, but there are many inefficiencies to cope with.
>
> Note that not all wireless users are "rude" on purpose. It's just that
> if you want to keep in touch with your relatives in the nearby town,
> you use the minimal needed power for the given circumstances that
> happens to be a large amount (point to point).
>
> 1a.
> Let's focus on a point to point link first. Omni antennas would
> trivially interfere with our own neighborhood as well while working a
> long link. However, because not everyone has roof access, space for a
> large aerial or money for an expensive one, using an omni would be
> considered a local optimum for many.
>
> 1b.
> Let's assume that we are a good citizen using more expensive highly
> directional antennae and we live at the perimeter. Considering that
> the reception angle of the most practical ones should be 10-20
> degrees, this probably easily illuminates the perimeter of the
> neighboring town. That wouldn't be deadly interference from that
> distance, but it means that it's not scalable in the sense that not
> everyone living at the perimeter could communicate with their
> respective relative in the neighboring town. It would need a high
> level of sophistication to achieve that. It would be much more
> efficient and cost effective if these people cooperated and pooled in
> resources to build only a handful of well-placed high power
> transcievers that they digitally shared with each other using low
> power and inexpensive last mile access technologies. But as the old
> saying goes, "The common horse is worst shod." So it is cleanest if we
> simply pay for equipment and maintenance, and a new telco is born.
> Then as competition intensifies, the spectrum gets clogged up, etc.
>
> 1c
> If we aren't fortunate enough to live at the perimeter, we need to
> cooperate with hops towards the perimeter. It is energetically the
> most efficient to have directional links between each of them, but
> that requires 2-3 antennae at each node. The ones at the perimeter
> definitely need at least two. For one who lives at the perimeter and
> only communicates with the neighboring town, it is a local optimum to
> not purchase and operate two sets of antennae, cables, radios and
> other tools. Without incentives, taking this to the extreme creates a
> disconnected ring of perimeter around the town who point outwards. So
> in worst case, ones in the middle would again need to up their power
> again to work the distance.
>
> 2.
> To achieve hop optimization, have we reached a level of social
> sophistication and digital literacy where we can mesh with everything
> and anyone in sight? I feel that to be a stretch, but let's pretend
> that we have. Now the "feasible" part is still problematic.
> Let's stick with the above scenario of inter-town links or sparsely
> populated areas. If there is nobody to mesh with, we need to
> artificially deploy and maintain intermediate nodes for this purpose.
> Who will pay for this? If nobody, it is not feasible. See above point.
> The local optimum of each user is to not deploy intermediate nodes,
> and we have reached the tragedy of the commons again.
>
> And we didn't even consider "rude" users analogue to an uninvited
> guest who gobbles all your snacks when dropping by. These are only a
> minority, but they take plenty. Though UWB wasn't there yet in 1994,
> it's feasible today. Just imagine if a school deployed a 1GHz UWB
> transciever on UHF to stream their backups or research data all day
> over the air because it is less expensive (free) compared to cables.
> It would not be feasible to peer with any intermediate hop because
> nobody has such expensive and advanced hardware, so they'd happily
> operate a point to point link to the nearby town (or partner
> institution?). That would definitely spoil the fun for many along the
> route and no amount of LBT can fix that. Also they could have decide
> to use >100GHz instead, but there is no incentive if the whole
> spectrum is free, as higher frequencies propagate worse and equipment
> costs more.
>
> So all in all, without incentives, system spectral efficiency doesn't
> come naturally - you have to work for it. Hard.
> I'm not saying that we should give up, but it takes much more than a
> few sentences to come up with rules that really work in real life
> situations when scaled up. There are pro and contra in many methods of
> spectrum allocations, no doubt about that, but I don't feel that there
> exists one clear "best" method that we are purposefully neglecting.
>
> Of course at the same time, scalable unregulated alternatives do
> exist, but we were talking radio above:
> https://en.wikipedia.org/wiki/RONJA
> https://en.wikipedia.org/wiki/Modulated_ultrasound
> https://en.wikipedia.org/wiki/Sneakernet
>
> On Thu, Aug 30, 2018 at 9:17 PM Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > Minimizing power is rule #2 per Paul Banan.
> >
> > SOME KINDERGARTEN RULES (written in 1994)
> >
> >    To take the fullest advantage of our new technology with its sharing
> >    of a common resource requires that our smart transmitters and
> >    receivers cooperate. This may sound complicated, but the rules to make
> >    maximum effective use of the shared band are simple -- primarily a
> >    matter of common decency in sharing resources. The rules are somewhat
> >    similar to those you learned in kindergarten, assuming you lived in a
> >    tough neighborhood.
> >
> >    Rule #1. Keep away from the big bullies in the playground. (Avoid the
> >    strongest signals.)
> >
> >    Rule #2. Share your toys. (Minimize your transmitted power. Use the
> >    shortest hop distances feasible. Minimize average power density per
> >    Hertz.)
> >
> >    Rule #3. If you have nothing to say, keep quiet.
> >
> >    Rule #4. Don't pick on the big kids. (Don't step on strong signals.
> >    You're going to get clobbered.)
> >
> >    Rule #5. If you feel you absolutely must beat up somebody, be sure to
> >    pick someone smaller than yourself. (Now this is a less obvious one,
> >    as weak signals represent far away transmissions; so your signals will
> >    likely be attenuated the same amount in the reverse direction and
> >    probably not cause significant interference.)
> >
> >    Rule #6. Don't get too close to your neighbor. Even the weakest
> >    signals are very strong when they are shouted in your ear.
> >
> >    Rule #7. Lastly, don't be a cry baby. (If you insist on using obsolete
> >    technology that is highly sensitive to interfering signals, don't
> >    expect much sympathy when you complain about interfering signals in a
> >    shared band.)
> >
> > Bob
> >
> >
> > On Thu, Aug 30, 2018 at 12:12 PM bkil <bkil.hu+Aq@gmail.com> wrote:
> >>
> >> Full-duplex still needs some work, but there is definite progress:
> >> http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
> >>
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
> >> https://sing.stanford.edu/fullduplex/
> >>
> https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
> >> http://fullduplex.rice.edu/research/
> >>
> >> On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton <chromatix99@gmail.com>
> wrote:
> >>>
> >>> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >>> >
> >>> > I guess my question is can a WiFi transmitting device rely on
> primarily energy detect and mostly ignore the EDCA probability game and
> rather search for (or predict) unused spectrum per a time interval such
> that its digital signal has enough power per its observed SNR?   Then
> detect "collisions" (or, "superposition cases" per the RX not having
> sufficient SINR) via inserting silent gaps in its TX used to sample ED,
> i.e. run energy detect throughout the entire transmission?  Or better, no
> silent gaps, rather detect if there is superimposed energy on it's own TX
> and predict a collision (i.e. RX probably couldn't decode its signal)
> occurred?  If doable, this seems simpler than having to realize centralized
> (or even distributed) media access algorithms a la, TDM, EDCA with ED,
> token buses, token rings, etc. and not require media access coordination by
> things like APs.
> >>>
> >>> The software might be simpler, but the hardware would need to be
> overspecified to the point of making it unreasonably expensive for consumer
> devices.
> >>>
> >>> Radio hardware generally has a significant TX/RX turnaround time,
> required for the RX deafening circuits to disengage.  Without those
> deafening circuits, the receivers would be damaged by the comparatively
> vast TX power in the antenna.
> >>>
> >>> So in practice, it's easier to measure SNR at the receiver, or
> indirectly by observing packet loss by dint of missing acknowledgements
> returned to the transmitter.
> >>>
> >>>  - Jonathan Morton
> >>>
> >>> _______________________________________________
> >>> Make-wifi-fast mailing list
> >>> Make-wifi-fast@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>
> >> _______________________________________________
> >> Make-wifi-fast mailing list
> >> Make-wifi-fast@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 12641 bytes --]

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

Indeed - and conversely, there may be interference that the transmitter can
hear clearly but which is irrelevant to the intended receiver.  In that
case, any form of LBT will be needlessly conservative.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 265 bytes --]