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

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 --]

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] [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

[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] [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: 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 --]