[Make-wifi-fast] Fwd: [bbr-dev] BBR performance and optimization in cellular wireless network with high delay jitter

[Bob McMahon]

I'm wondering if the whole idea that throughput as the exclusive vector for
optimization is a bit off. Even low latency high throughput designs has
throughput as a driving vector. We now have high occupancy low latency
(HULL) data center switches. We have to oversubscribe everything (and TCP
is more than happy to oblige.) As a group, we all do this because of
exactly why?

It reminds me of "weight" in the space program. Weight drove most every
decision due the energy cost required to get mass out of the influence of
earth's gravity. Structural integrity be damned - just make sure it has
less mass.

An app setting TCP_NODELAY on a socket could signal the end to end path
that the thing to optimize for this flow is latency, i.e. that the app
writing this socket isn't going to be sending lots of data. In this case,
the TCP feedback loop could adjust its vectors as an example. And TCP has
little clue of what the app is going to do, though it can guess at it (and
can guess wrong.)

I think WiFi/wireless (or no cables to act as wave guides) makes the
problem quite challenging for lots of reasons. I also think the silo'ing of
engineering both within companies and between companies adds to these
engineering limitations. What is the OSI layer but a human abstraction? Why
can't TCP be informed about PHY related things, and MACs be aware about TCP
related things?  I here the call of blasphemy, "It must be end knowledge
only!!"

Even the TCP assumption that a dropped packet is due to congestion is
flawed. It might be due to walking past a microwave that is irradiating a
bag of popcorn. Or the device orientation may change just enough that a new
spatial stream is now available, instantly doubling capacity.  Or more
radios can be used as CMOS radios are trending to abundance.

Just thinking out loud a bit. Sorry for the meandering in thoughts,
Bob






On Wed, Jul 7, 2021 at 1:27 AM Jeremy Harris <jgh at wizmail.org> wrote:

> On 07/07/2021 00:49, Bob McMahon via Make-wifi-fast wrote:
> >  ABC (love the acronym)
>
> Conflict with Approrriate Byte Counting, though.
>
> > Does ABC try to
> > optimize throughput, latency or some combination, e.g. network power
> > (throughput/delay)?
>
> I read it as trying to optimize throughput of one specific link
> (the one next to the detecting location).  They didn't discuss
> what happens when there are two such on the path, and most of the
> presentation assumed that this link was the limiting one.
> --
> Cheers,
>    Jeremy
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20210707/cc4d2398/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20210707/cc4d2398/attachment.bin>