From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 7F73B3B29D for ; Tue, 19 Sep 2023 21:14:12 -0400 (EDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-59bbdb435bfso62573027b3.3 for ; Tue, 19 Sep 2023 18:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695172451; x=1695777251; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ex3EGFYfnIaEJEBmedEN77QVw0dJO5gsi2aMv7QOWtI=; b=ls7FJ3c0nIvTZrdREUbYzlWHAFUVvsZO21CmG+rqSZxAD4hYcUSlBx6caAJOgpRRTp AFIyIWtf1to9Dzg2QwT1cyP5c54djyaWKxid1F8wvTRfnR3L7uZKlaDr5Nmg3C24Qdfc BJVUE01nt8vSgv6pXV/UvgOLJMsr8NwO13eKJaldd8+fBh5SF0PBlhgG3UoKTyCdZWeB CWNVgIBbWDH41Rhr4HR2P0NtPcnop/jkwrC2Q/SAG3yFG85hfdTq73MuAgkjoaueQTzk IaBbbWGMy8Nqbhv6FAgcUnX4ULw3CQ/B7K4VKViqwMooSzHJkv2RokP6ZSRR189paVoH GhTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695172451; x=1695777251; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ex3EGFYfnIaEJEBmedEN77QVw0dJO5gsi2aMv7QOWtI=; b=Osn0eiafzFBA8IuUf3uF63LKWZnWUFoEyFrfnotbSqTOuIIbkFcMNcoxQtn5UiJOEp TYVe8WfWEdkYiovyqgTe5dLI5n3Zv2fJANtcbf1DpEqiaJMdDatr1tVlGk2SA/8YAJYO hzZJHgtqi0e005SQIyo8nNd0KTXE3esVIxd0ZDX4RCJqGuCJh1FzUGUkMJXnAlj0EqT4 OHxm1i43a8gc+2qe0NvWA2RTscJHLYIqeMajnaok3Pp6i/HWZg/v/iSG95YWmIibtbh3 QT/8CukiZl5O7diyQ9Kijt3hv89Ta3emYalwzZe9K5Svjg7obxx1b5z3u9nOQuoMjegz Fhog== X-Gm-Message-State: AOJu0Yw7L2Zh3Qa+KgdkoNMNNEXZdZrCIXWqqolW6IloYsjrjik5uRnM yHGzZ5YSqI8aedxXxHLCwY94eJH+/Kadq1ODshk= X-Google-Smtp-Source: AGHT+IHWTNa1F+wDeAieyc18Z7+1jU462FuN14Kf05sSFLh/DxOb+TWxV7sJFR3dbWbGiXR8a+A7/2WMqMzwHikUwxk= X-Received: by 2002:a81:5386:0:b0:59b:bacb:a84f with SMTP id h128-20020a815386000000b0059bbacba84fmr1228675ywb.47.1695172450276; Tue, 19 Sep 2023 18:14:10 -0700 (PDT) MIME-Version: 1.0 References: <9d96e8d6-8a40-4353-b7a3-49881742f1a7@auckland.ac.nz> In-Reply-To: <9d96e8d6-8a40-4353-b7a3-49881742f1a7@auckland.ac.nz> From: Dave Taht Date: Tue, 19 Sep 2023 18:13:57 -0700 Message-ID: To: Ulrich Speidel Cc: "starlink@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000bb5b8e0605c0177b" Subject: Re: [Starlink] APNIC56 last week X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2023 01:14:12 -0000 --000000000000bb5b8e0605c0177b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 18, 2023 at 9:39=E2=80=AFPM 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 > --=20 Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.htm= l Dave T=C3=A4ht CSO, LibreQos --000000000000bb5b8e0605c0177b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 18, 2023 at 9:39=E2=80=AF= 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.

<= div>I worked through both presentations just now, thank you.

=
As vs=C2=A0Geoffs presentation on QUIC=C2=A0eating the universe = in terms of traffic volume, and the world becoming a giant content distribu= tion network, I still hold, that the internet is a communications network, = and that despite content moving ever closer to the edges, more private cont= ent, and connecting people to people, and vpns to corporations, will remain= an important use case. Ssh as one example, still holds the underpinnings o= f the network together, and is very low traffic volume, and there is no suc= h thing as a "voip caching server". Also, big providers of replic= ated content, such as steam, are experimenting with bittorrent-like techniq= ues again. QUIC makes torrent extremely feasible once again.=C2=A0

I liked that geoff left traffic shaping as a question at t= he end. I have long opposed DPI based methods! However, inserting well defi= ned drop and marking and fq-ing behaviors into the network has long seemed = to be a major step forward.

In the case of quic, d= espite its ability to multiplex flows on one connection to the google mainf= rame, I still usually see many connections opened to collect various assets= .

It was also interesting to see higher adoption o= f Quic in south america, rather than America. why is that? Whatsapp dominat= es 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 "lo= cal"
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 con= tent also. More IXPs are needed worldwide. Despite the siloing of content i= nto apple, google, facebook burbclaves, and wars between the telcos, they n= eed 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 bu= fferbloat 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>
I hope in qualifying the wifi gear for a plane, they man= age the bloat better, and actually test what happens when 300 passengers ar= e attempting to stream both local videocontent and use the web.
<= br>


=C2=A0
--
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auc= kland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
--000000000000bb5b8e0605c0177b--