Re: [Bloat] Does 5g have the bloat problems of WiFi?

[Dave Taht <dave.taht@gmail.com>]

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

Informative post, thank you!

On Thu, Aug 1, 2019 at 5:43 PM Kirn Gill <segin2005@gmail.com> wrote:
>
> Replying to Dave Taht,
>
> There's a few considerations here:
>
>  - What is "5G"?
>
> Strictly speaking, 5G is ITU-T's IMT-2020 standard(s). So far, there
> is only one system under this standard, 3GPP's New Radio (NR). NR is
> what is meant as 5G in layspeak.

I think I will try to talk directly to "NR" in the future rather than
the overloaded term 5G.

> The NR air interface is defined in 3GPP TS 38.xxx series documents.
>
> Against point 2, about operators simply wanting more active SIMs to
> charge for, it's worth noting that NR can be deployed for private
> operation; the company that's using the service could itself own the
> entire network it's using. There are companies using private LTE
> networks for V2x and remote sensing, see for example:
> https://steelguru.com/mining/l/532247, or contract a third party to
> build a dedicated network:
> https://www.zdnet.com/article/telstra-deploys-private-lte-network-in-png-volcanic-crater-gold-mine/

I agree that for a large company in these circumstances it makes sense
to think about deploying LTE
on their own. It's not just the latency

In terms of

>
> NR operates over commercial and unlicensed frequency bands. The
> specific frequency bands defined for the system are listed in 3GPP TS
> 38.104 (Rel. 15) section 5.2
>
> 802.11a/b/g/n/ac/ad use CSMA/CA - Carrier Sense Multiple Access with
> Collison Avoidance - as their multiple access scheme, same as 802.3.
> Each transmitter completely owns the medium when transmitting.
>
> 802.11ax, LTE, and NR use OFDMA - Orthogonal Frequency Division
> Multiple Access - as their multiple access scheme. Instead of the
> transmitter having the full channel for the duration it is
> transmitting, OFDMA takes OFDM modulation and divides not only across
> timeslots/timed transmission frames, but also by subdividing the full
> channel into simpler "resource blocks" with a fixed number of OFDM
> tones.

There are a ton of folk here that would really like to get their hands
dirty on both these techs but our hands are tied by the lack of open
source drivers and firmware.

>
> LTE and NR have many features that Wi-Fi lacks which results in a far
> superior user experience. OFDMA, only recently adopted for 802.11ax

As for the "far superior user experience"... multiplexing any amount
of data over
present day LTE on every network I've ever tried has been a miserable
experience.

The context of the article was robots, moving it back to
bufferbloat... attached are two test runs of flent (up and down) on my
t-mobile tether taken just now. 1000ms of induced latency (baseline of
40) one way, 256ms the other. That's worse than comcast... a far cry
from the 20ms I get under load on wifi today.

My usb-lte stick doesn't even come close to this good,

All the lte-network gateways I've tried to date are a separate double
natting full ip stack box in the 300+ dollar range. The last one I
tried
crashed every other day. It had pretty lights though.

I've yet to have a tethered box actually do dhcp-v6pd, and being
behind cgnat is not a superior internet experience. Having a dedicated
static IPv4/v6 would be nice.

Admittedly to fix both the ipv6 and cgnat issues I just run a
wireguard tunnel. But we'd need to debate what is meant by user
experience. And/or someone identify a NR box a geek could love?

> ("Wi-Fi 6"), generally results in far superior throughput rates than
> CSMA/CA when many users are involved.

Still waiting to test decent examples of both standards. This year is
looking promising.

> In LTE and NR, this is also
> optimized further with centralized (at the eNB/gNB) MAC scheduling for
> all traffic on both uplink and downlink.
>
> Inter-cell handover in all cellular systems is much better than in
> Wi-Fi; Wi-Fi is a mobile-only system where the mobile station is in
> full control of the process, and it's a "break before make", that is,
> the mobile station fully disassociates from the first access point
> before associating with the next access point, even in the case of a
> shared BSSID and background Ethernet network. It's like unplugging
> from one Ethernet port and plugging into another one rather quickly,
> complete with the brief hiccup in network applications.

For about 10 years now, I've run the babel adhoc routing protocol,
there's no break before make there either. But I concede most of this
point on normal wifi AP's with crypto on.

However, celluar backhaul's stuff often quite a long ways - 40ms
in my example case, wifi "mobile" IP (moving within a warehouse) on wifi
being pretty fast (4ms) relative to the local network.

> Cellular is a lot better; the mobile station scans for neighboring
> cells to the one it's connected to in it's spare time, and sends this
> list to the network, so that the base station can "see" the different
> signal strength's from the mobile station's perspective. The network
> then instructs the mobile station to make a blind jump to whichever
> cell it feels will best serve the mobile station and reduce power
> consumption on that end. "Association" is with the network itself, not
> with individual base stations, so there's no need to do the "break
> before make" dance of Wi-Fi.

While I strongly agree that the NR mac is better even than wifi6, the
cell makers
have gotta tackle the bufferbloat and IPv6 issues. I have some hope some
have paid attention.

>
> --
> Kirn Gill II
> Mobile (SMS only): +1 813-300-2330
> VoIP: +1 813-704-0420
> Email: segin2005@gmail.com
> LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

[-- Attachment #2: tcp_nup-2019-08-01T185508.928118.flent.gz --]
[-- Type: application/x-gzip, Size: 25633 bytes --]

[-- Attachment #3: tcp_ndown-2019-08-01T190615.902589.t-mobile.flent.gz --]
[-- Type: application/x-gzip, Size: 36573 bytes --]

[-- Attachment #4: tcp_ndown_-_t-mobile.png --]
[-- Type: image/png, Size: 106443 bytes --]

[-- Attachment #5: tcp_nup_-_2019-08-01_18:55:08.png --]
[-- Type: image/png, Size: 85541 bytes --]

[-- Attachment #6: tcp_ndown-2019-08-01T190454.526223.t-mobile.flent.gz --]
[-- Type: application/x-gzip, Size: 193253 bytes --]