[Starlink] APNIC56 last week

[Dave Taht]

On Mon, Sep 18, 2023 at 9:39 PM Ulrich Speidel via Starlink <
starlink at 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 at auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230919/94b156fc/attachment-0001.html>