[Starlink] [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point

[Bob McMahon]

Hi All,

I do appreciate this thread as well. As a test & measurement guy here are
my conclusions around network performance. Thanks in advance for any
comments.

Congestion can be mitigated the following ways
o) Size queues properly to minimize/negate bloat (easier said than done
with tech like WiFi)
o) Use faster links on the service side such that a queues' service rates
exceeds the arrival rate, no congestion even in bursts, if possible
o) Drop entries during oversubscribed states (queue processing can't "speed
up" like water flow through a constricted pipe, must drop)
o) Identify aggressor flows per congestion if possible
o) Forwarding planes can signal back the the sources "earlier" to minimize
queue build ups per a "control loop request" asking sources to pace their
writes
o) transport layers use techniques a la BBR
o) Use "home gateways" that support tech like FQ_CODEL

Latency can be mitigated the following ways
o) Mitigate or eliminate congestion, particularly around queueing delays
o) End host apps can use TCP_NOTSENT_LOWAT along with write()/select() to
reduce host sends of "better never than late" messages
o) Move servers closer to the clients per fundamental limit of the speed of
light (i.e. propagation delay of energy over the wave guides), a la CDNs
(Except if you're a HFT, separate servers across geography and make sure to
have exclusive user rights over the lowest latency links)

Transport control loop(s)
o) Transport layer control loops are non linear systems so network tooling
will struggle to emulate "end user experience"
o) 1/2 RTT does not equal OWD used to compute the bandwidth delay product,
imbalance and effects need to be measured
o) forwarding planes signaling congestion to sources wasn't designed in TCP
originally but the industry trend seems to be to moving towards this per
things like L4S

Photons, radio & antenna design
o) Find experts who have experience & knowledge, e.g. many do here
o) Photons don't really have mass nor size, at least per my limited
understanding of particle physics and QED though, I must admit, came from
reading things on the internet

Bob

On Mon, Sep 20, 2021 at 7:40 PM Vint Cerf <vint at google.com> wrote:

> see https://mediatrust.com/
> v
>
>
> On Mon, Sep 20, 2021 at 10:28 AM Steve Crocker <steve at shinkuro.com> wrote:
>
>> Related but slightly different: Attached is a slide some of my colleagues
>> put together a decade ago showing the number of DNS lookups involved in
>> displaying CNN's front page.
>>
>> Steve
>>
>>
>> On Mon, Sep 20, 2021 at 8:18 AM Valdis Klētnieks <valdis.kletnieks at vt.edu>
>> wrote:
>>
>>> On Sun, 19 Sep 2021 18:21:56 -0700, Dave Taht said:
>>> > what actually happens during a web page load,
>>>
>>> I'm pretty sure that nobody actually understands that anymore, in any
>>> more than handwaving levels.
>>>
>>> I have a nice Chrome extension called IPvFoo that actually tracks the IP
>>> addresses contacted during the load of the displayed page. I'll let you
>>> make
>>> a guess as to how many unique IP addresses were contacted during a load
>>> of https://www.cnn.com
>>>
>>> ...
>>>
>>>
>>> ...
>>>
>>>
>>> ...
>>>
>>>
>>> 145, at least half of which appeared to be analytics.  And that's only
>>> the
>>> hosts that were contacted by my laptop for HTTP, and doesn't count DNS,
>>> or
>>> load-balancing front ends, or all the back-end boxes.  As I commented
>>> over on
>>> NANOG, we've gotten to a point similar to that of AT&T long distance,
>>> where 60%
>>> of the effort of connecting a long distance phone call was the cost of
>>> accounting and billing for the call.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> 1435 Woodhurst Blvd
> McLean, VA 22102
> 703-448-0965
>
> until further notice
>
>
>
>

-- 
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/cerowrt-devel/attachments/20210923/2e1041ec/attachment.html>