Re: [Bloat] [bbr-dev] new paper from Kleinrock on "Power" and to some extent BBR

[Dave Taht]

On Mon, Aug 27, 2018 at 6:02 PM Jonathan Morton  wrote:
>
> > On 28 Aug, 2018, at 3:59 am, Dave Taht  wrote:
> >
> > "Internet congestion control using the power metric: Keep the pipe
> > just full, but no fuller" is quite a good read (appears to be open
> > access pdf, too):
> >
> > https://www.sciencedirect.com/science/article/pii/S1570870518302476
>
> Well it isn't letting *me* download the full text.

I'm sorry, try this:
https://www.lk.cs.ucla.edu/data/files/Kleinrock/Internet%20congestion%20control%20using%20the%20power%20metric%20LK%20Mod%20aug%202%202018.pdf

>  - Jonathan Morton
>


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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  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  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
> >>
> >
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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  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
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [bbr-dev] new paper from Kleinrock on "Power" and to some extent BBR

[Jonathan Morton]

> On 28 Aug, 2018, at 3:59 am, Dave Taht  wrote:
> 
> "Internet congestion control using the power metric: Keep the pipe
> just full, but no fuller" is quite a good read (appears to be open
> access pdf, too):
> 
> https://www.sciencedirect.com/science/article/pii/S1570870518302476

Well it isn't letting *me* download the full text.

 - Jonathan Morton

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] new paper from Kleinrock on "Power" and to some extent BBR

[Dave Taht]

"Internet congestion control using the power metric: Keep the pipe
just full, but no fuller" is quite a good read (appears to be open
access pdf, too):

https://www.sciencedirect.com/science/article/pii/S1570870518302476
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Jonathan Morton]

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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

ok thanks, that's helpful.  I guess I thought if astrophysicists can direct
image exoplanets

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 
wrote:

> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon 
> 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
>
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Jonathan Morton]

> On 27 Aug, 2018, at 10:11 pm, Bob McMahon  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

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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 
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 
> wrote:
>
>> > On 27 Aug, 2018, at 10:06 am, Bob McMahon 
>> 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
>>
>>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Marvell 385

[Mikael Abrahamsson]

On Sun, 26 Aug 2018, Dave Taht wrote:


I was on that thread. It was broken before entirely. As for the single
interrupt on this chip variant - believe it or not, I'm not huge on


When doing 10GE tests on x86-64 I received the highest performance when I 
set interrupt affinity to single core per interface.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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 
wrote:

> > On 27 Aug, 2018, at 10:06 am, Bob McMahon 
> 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
>
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] debloats/day metric?

[Jonathan Morton]

> On 27 Aug, 2018, at 10:44 am, Pete Heist  wrote:
> 
> …request pairs, one given strict priority at the bottleneck and one best 
> effort, then measure the difference between the two (for both RTT and OWD).
> 
> Assuming this yields useful data…

For the overwhelming majority of bloated bottlenecks, it will not - because 
they have zero concept of "strict priority".

 - Jonathan Morton

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Jonathan Morton]

> On 27 Aug, 2018, at 10:06 am, Bob McMahon  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

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Luca Muscariello]

Hi Bob,

I meant licensed/unlicensed for private/non private.

Luca

On Mon, Aug 27, 2018 at 9:39 AM Bob McMahon 
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.muscarie...@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 
>> wrote:
>>
>>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
>>> 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
>>>
>>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] debloats/day metric?

[Pete Heist]

Not sure how to answer exactly, but I’m interested in some way to measure bloat 
more directly both instantaneously and over time. My current plan for 
instantaneous measurement is to modify irtt to send request pairs, one given 
strict priority at the bottleneck and one best effort, then measure the 
difference between the two (for both RTT and OWD).

Assuming this yields useful data, maybe there is a long-term stat that could be 
derived from it that indicates how much bloat there is for a given link, or how 
well it has been mitigated.

For interest, here are abbreviated cake stats from 12 hours at the camp 
(~40Mbit p2p WiFi), so double those for an approximate daily stat:

Egress:
  Tin 0
  pkts 12327019
  bytes  3838819739
  way_inds   903650
  way_miss   261326
  drops 929
  marks   8

Ingress:
  Tin 0
  pkts 28783116
  bytes 36517120801
  way_inds  2031504
  way_miss   250153
  drops   12648
  marks  24

> On Aug 25, 2018, at 6:57 PM, Dave Taht  wrote:
> 
> I'm always casting about for some simple metric, some simple phrase,
> that we can use to describe what we're about. Lately - without
> formally defining it mathematically as yet - I've been talking about
> "badwidth" - what you get from your typical ISP - and "goodwidth",
> what debloating does - which originally sprang from me typo-ing
> "bandwidth".
> 
> More recently I tried combatting the perception that packet
> drops/marks are "bad", by renaming them to "debloats/day".
> 
> Codel kicks in rarely, but I'm pretty sure every time it does it saves
> on a bit of emotional upset and jitter for the user. For example I get
> about 3000 drops/ecn marks a day one inbound 100mbit/20mbit campus
> link (about 12,000 on the wifi links), and outbound a mere ~100 or so.
> 
> But: Every one of those comforts me 'cause I feel like I'm saving a
> ~500ms latency excursion for all the users of this (640ms badwidth
> down/280ms up) comcast link.
> 
> I am kind of curious as to y'all's regular "debloats/day"?

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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.muscarie...@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 
> wrote:
>
>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
>> 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
>>
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Luca Muscariello]

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 
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
> 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
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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 
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
> 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