From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 71ED73CB42 for ; Thu, 23 Sep 2021 13:47:00 -0400 (EDT) Received: by mail-ed1-x52f.google.com with SMTP id v10so21227897edj.10 for ; Thu, 23 Sep 2021 10:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S4qV5Q0jO++wKxAxtWFCt0NsoPPeCGHBmx9yskT/hF4=; b=GUEwatmnKUZ2ae3OzT/DlcLkzAQ7U9p9HnQhz/o2k8FlPpppMtykJveAcpy9FPNpH0 6C6eqpWz5ofGDEsIBE5Npqeu2U6urjviQkJXHDigx8sVwkxh+dgWFX4QCDpgXsZo0HFN knDX6Z/iVxo4YPZjJgiHo8Kal+3TSEKIYa18w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S4qV5Q0jO++wKxAxtWFCt0NsoPPeCGHBmx9yskT/hF4=; b=DIri0vHBy9eIG8S/noiM/B2uy0VAhvGi9n3ekGqD3NQhoOUSMdXL698hwzZF4BqZ0B qn5Eeynjn3Tu5cc+cJodyvcE3wlk/d6b6Sbr1YLNBhez6zw/vnpStD1YkErthAYdi8J+ Y2LmyG5gr83BnyGAtrcH9/0vsdKzrb/VU06j6E05T8MCVknIpwOEMQHccSQwhlmbaqJ5 uN0c1EN3JxKOB4jaMS6/uZV3kEjz4oM8clMdkzc+Wstuygvw22CGH2zuZ+rT4GDPVKw0 FodDGXfZtiOevl9WjNbrc8rvK2PvNCU+jKP6RmWQRf+3LBOdM06ypSCzwTm2MuHcertc 99DQ== X-Gm-Message-State: AOAM530hEFW+vsktOxbwTS5JLmrBZpkEZ5jX1K+3mzJ/7l1iUxweiQTK 6OQfoWSOOU3Hp8KVTMtrfRNl6Rd59ESW+XuFrlt/U0vbLlcK+evKg5TN0hKfTpSDWXcpIxlb3zy KPn+htcAswwOrLntdpqlpcu7ChWG4nDkIbcGirqOF X-Google-Smtp-Source: ABdhPJwY0teGh0HvdsXQwcXECmTbaC0Sj4NQzrD5UO8RAe76cgIhU3U27ELuebIw96q73ed35I0sQTSNh8qNfmUoS0I= X-Received: by 2002:a17:906:4093:: with SMTP id u19mr6638990ejj.110.1632419218858; Thu, 23 Sep 2021 10:46:58 -0700 (PDT) MIME-Version: 1.0 References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> <1625773080.94974089@apps.rackspace.com> <1625859083.09751240@apps.rackspace.com> <257851.1632110422@turing-police> In-Reply-To: From: Bob McMahon Date: Thu, 23 Sep 2021 10:46:48 -0700 Message-ID: Subject: Re: [Starlink] [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point To: Vint Cerf Cc: Steve Crocker , =?UTF-8?Q?Valdis_Kl=C4=93tnieks?= , starlink@lists.bufferbloat.net, Make-Wifi-fast , "David P. Reed" , Cake List , codel , cerowrt-devel , bloat Content-Type: multipart/alternative; boundary="000000000000aade5605ccad37d6" X-List-Received-Date: Thu, 23 Sep 2021 17:47:00 -0000 --000000000000aade5605ccad37d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > see https://mediatrust.com/ > v > > > On Mon, Sep 20, 2021 at 10:28 AM Steve Crocker wrote= : > >> Related but slightly different: Attached is a slide some of my colleague= s >> 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=C4=93tnieks >> 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 I= P >>> 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@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >>> >> _______________________________________________ >> Starlink mailing list >> Starlink@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 > > > > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --000000000000aade5605ccad37d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

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

Congestion can be= mitigated the following=C2=A0ways
o) Size queues properly to min= imize/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=C2=A0the arrival rate, no congestion=C2=A0even in bursts, if possi= ble
o) Drop entries during oversubscribed states (queue processing can&#= 39;t "speed up" like water flow through a constricted pipe, must = drop)
o) Identify aggressor=C2=A0flows per congestion if possible=
o) Forwarding planes can signal back the the sources "earli= er" to minimize queue build ups per a "control loop=C2=A0request&= quot; asking sources to pace their writes
o) transport layers use= techniques a la BBR
o) Use "home gateways" that suppor= t tech like FQ_CODEL

Latency can be mitigated the = following=C2=A0ways
o) Mitigate or eliminate congestion, particul= arly around=C2=A0queueing delays
o) End host apps can use TCP_NOT= SENT_LOWAT along with write()/select() to reduce host sends of "better= never than late" messages=C2=A0
o) Move servers closer to the clie= nts per fundamental limit of the speed of light (i.e. propagation=C2=A0dela= y of energy over the wave guides), a la CDNs
(Except if you'r= e a HFT, separate servers across geography=C2=A0and make sure to have exclu= sive user rights over the lowest latency links)

Transport control lo= op(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=C2=A0OWD used to compute the bandwidt= h delay product, imbalance and effects need to be measured
o) for= warding planes signaling congestion to sources wasn't designed in TCP o= riginally but the industry trend seems to be to moving towards this per thi= ngs like L4S

Photons, radio & antenna designo) Find experts who have experience & knowledge, e.g. many do hereo) Photons don't really have mass nor size, at least=C2=A0per my limit= ed understanding of particle physics and QED though, I must admit, came fro= m reading things on the internet=C2=A0

Bob

On Mon, Sep 20, 2021= at 7:40 PM Vint Cerf <vint@google.com> wrote:
see https://mediatrust.com/
v


On= Mon, Sep 20, 2021 at 10:28 AM Steve Crocker <steve@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
<= br>

On Mon, Sep 20, 2021 at 8:18 AM Valdis Kl=C4=93tnieks <valdis.kletnieks@vt.e= du> wrote:
htt= ps://www.cnn.com

...


...


...


145, at least half of which appeared to be analytics.=C2=A0 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.=C2=A0 As I commented = over on
NANOG, we've gotten to a point similar to that of AT&T long distanc= e, 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
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd=C2=A0
McLean, VA 22= 102
703-448-0965

until further notice




This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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. --000000000000aade5605ccad37d6--