From: Dave Taht <dave.taht@gmail.com>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] APNIC56 last week
Date: Tue, 19 Sep 2023 18:13:57 -0700 [thread overview]
Message-ID: <CAA93jw5cAHrEz2yB29WpPu5HwBpoMGUA25x+_omeBS5f7nurYA@mail.gmail.com> (raw)
In-Reply-To: <9d96e8d6-8a40-4353-b7a3-49881742f1a7@auckland.ac.nz>
[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]
On Mon, Sep 18, 2023 at 9:39 PM Ulrich Speidel via Starlink <
starlink@lists.bufferbloat.net> wrote:
> FWIW, I gave a talk about Starlink - insights from a year in - at last
> week's APNIC56 conference in Kyoto:
>
> https://conference.apnic.net/56/program/program/#/day/6/technical-2/
>
> Also well worth looking at is Geoff Huston's excellent piece on the
> foreseeable demise of TCP in favour of QUIC in the same session. One of
> Geoff's main arguments is that the Internet is becoming local, i.e.,
> most traffic goes between a CDN server and you, and most data is
> becoming proprietary to the application owner, meaning it suits the
> Googles and Facebooks of this world very well not to be using TCP for
> its transport, but rather pull the transport specifics into the
> application layer where the have full control.
I worked through both presentations just now, thank you.
As vs Geoffs presentation on QUIC eating the universe in terms of traffic
volume, and the world becoming a giant content distribution network, I
still hold, that the internet is a communications network, and that despite
content moving ever closer to the edges, more private content, and
connecting people to people, and vpns to corporations, will remain an
important use case. Ssh as one example, still holds the underpinnings of
the network together, and is very low traffic volume, and there is no such
thing as a "voip caching server". Also, big providers of replicated
content, such as steam, are experimenting with bittorrent-like techniques
again. QUIC makes torrent extremely feasible once again.
I liked that geoff left traffic shaping as a question at the end. I have
long opposed DPI based methods! However, inserting well defined drop and
marking and fq-ing behaviors into the network has long seemed to be a major
step forward.
In the case of quic, despite its ability to multiplex flows on one
connection to the google mainframe, I still usually see many connections
opened to collect various assets.
It was also interesting to see higher adoption of Quic in south america,
rather than America. why is that? Whatsapp dominates down there...
> Food for thought, especially since LEO networks are a particularly bad
> place to put local content caches, since the concept of what's "local"
> in a LEO network changes constantly, at around 20,000 miles an hour or
> so. Spoke to a Rwandan colleague who installs Starlink there and sees
> all traffic to anywhere go via the US with RTTs of nearly 2 seconds,
> even if the Rwandan user is trying to access a Rwandan service.
>
Africa I hope is moving towards localizing its content also. More IXPs are
needed worldwide. Despite the siloing of content into apple, google,
facebook burbclaves, and wars between the telcos, they need to interconnect
somewhere.
> About to hop onto a plane (ZK-NZJ) tonight with free WiFi (Ka band GEO)
> enroute to Auckland in the hope of getting a better experience than last
> time when the system seemed to run out of IP addresses on its DHCP.
>
>
How did it go? The world record for bufferbloat related delay on a plane is
held by dave reed, at 860 seconds. I would love to see a plane flent trace
that held it below 30ms.
https://paxex.aero/jsx-starlink-spacex-review/ did pretty well.
I hope in qualifying the wifi gear for a plane, they manage the bloat
better, and actually test what happens when 300 passengers are attempting
to stream both local videocontent and use the web.
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
[-- Attachment #2: Type: text/html, Size: 6034 bytes --]
next prev parent reply other threads:[~2023-09-20 1:14 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 4:39 Ulrich Speidel
2023-09-20 1:13 ` Dave Taht [this message]
2023-09-23 1:33 ` Noel Butler
2023-09-23 1:47 ` Vint Cerf
2023-09-23 4:22 ` Noel Butler
2023-09-23 6:41 ` Gert Doering
2023-09-23 10:53 ` Ulrich Speidel
2023-09-23 11:28 ` Sebastian Moeller
2023-09-23 12:56 ` Ulrich Speidel
2023-09-25 4:40 ` Noel Butler
2023-09-25 5:00 ` Ulrich Speidel
2023-09-25 5:10 ` Hayden Simon
2023-09-25 5:51 ` Noel Butler
2023-09-23 12:08 ` Hesham ElBakoury
2023-09-24 18:30 ` Michael Richardson
2023-09-25 4:04 ` Noel Butler
2023-09-21 13:20 ` Alexandre Petrescu
2023-09-21 19:05 ` Inemesit Affia
2023-09-21 19:08 ` Dave Taht
2023-09-22 8:26 ` Alexandre Petrescu
2023-09-22 8:41 ` David Lang
2023-09-22 17:12 ` Michael Richardson
2023-09-22 17:26 ` David Lang
2023-09-22 18:52 ` Michael Richardson
2023-09-23 21:55 ` Larry Press
2023-09-24 2:46 ` Dave Taht
2023-09-24 12:00 ` Hesham ElBakoury
2023-09-25 7:46 ` Alexandre Petrescu
2023-09-25 8:59 ` David Lang
2023-09-25 12:30 ` Frantisek Borsik
2023-09-22 17:00 David Fernández
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw5cAHrEz2yB29WpPu5HwBpoMGUA25x+_omeBS5f7nurYA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=starlink@lists.bufferbloat.net \
--cc=u.speidel@auckland.ac.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox