<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 18, 2023 at 9:39 PM Ulrich Speidel via Starlink <<a href="mailto:starlink@lists.bufferbloat.net">starlink@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">FWIW, I gave a talk about Starlink - insights from a year in - at last <br>
week's APNIC56 conference in Kyoto:<br>
<br>
<a href="https://conference.apnic.net/56/program/program/#/day/6/technical-2/" rel="noreferrer" target="_blank">https://conference.apnic.net/56/program/program/#/day/6/technical-2/</a><br>
<br>
Also well worth looking at is Geoff Huston's excellent piece on the <br>
foreseeable demise of TCP in favour of QUIC in the same session. One of <br>
Geoff's main arguments is that the Internet is becoming local, i.e., <br>
most traffic goes between a CDN server and you, and most data is <br>
becoming proprietary to the application owner, meaning it suits the <br>
Googles and Facebooks of this world very well not to be using TCP for <br>
its transport, but rather pull the transport specifics into the <br>
application layer where the have full control.</blockquote><div><br></div><div>I worked through both presentations just now, thank you.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It was also interesting to see higher adoption of Quic in south america, rather than America. why is that? Whatsapp dominates down there...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Food for thought, especially since LEO networks are a particularly bad <br>
place to put local content caches, since the concept of what's "local" <br>
in a LEO network changes constantly, at around 20,000 miles an hour or <br>
so. Spoke to a Rwandan colleague who installs Starlink there and sees <br>
all traffic to anywhere go via the US with RTTs of nearly 2 seconds, <br>
even if the Rwandan user is trying to access a Rwandan service.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
About to hop onto a plane (ZK-NZJ) tonight with free WiFi (Ka band GEO) <br>
enroute to Auckland in the hope of getting a better experience than last <br>
time when the system seemed to run out of IP addresses on its DHCP.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div><a href="https://paxex.aero/jsx-starlink-spacex-review/">https://paxex.aero/jsx-starlink-spacex-review/</a> did pretty well.<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
****************************************************************<br>
Dr. Ulrich Speidel<br>
<br>
School of Computer Science<br>
<br>
Room 303S.594 (City Campus)<br>
<br>
The University of Auckland<br>
<a href="mailto:u.speidel@auckland.ac.nz" target="_blank">u.speidel@auckland.ac.nz</a><br>
<a href="http://www.cs.auckland.ac.nz/~ulrich/" rel="noreferrer" target="_blank">http://www.cs.auckland.ac.nz/~ulrich/</a><br>
****************************************************************<br>
<br>
<br>
<br>
_______________________________________________<br>
Starlink mailing list<br>
<a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/starlink" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Oct 30: <a href="https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html" target="_blank">https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html</a></div><div>Dave Täht CSO, LibreQos<br></div></div></div></div>