Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] fiber IXPs in space
Date: Mon, 17 Apr 2023 09:22:51 +1200	[thread overview]
Message-ID: <a4f30cc4-e940-ca7b-fee3-6abb07fe5c7d@auckland.ac.nz> (raw)
In-Reply-To: <CAC=tZ0qrB4Eqj-7nwXirB-2x0oya0Kmgfi1_8QptmOP904D=nQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]

On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
> In case you put a DNS server in the satellite, so that it replies
> instead of a DNS server on ground, the RTT is reduced by half.
>
> The idea would be that the satellite inspects IP packets and when it
> detects a DNS query, instead of forwarding the packet to ground
> station, it just answers back to the sender of the query.
Understood - it's just that the gain you have from this is quite small. 
DNS queries only happen the first time a host needs to resolve a name, 
and then again after cache expiry much later, so they account for only a 
tiny fraction of the traffic, and also for only a small amount of the 
total delay in page loads. RTT isn't really the big issue in Starlink - 
yes it's larger than it perhaps needs to be, and bufferbloat seems to be 
present, but compared to GEO, it's now in the range seen for terrestrial 
Internet.
>
> Nowadays, satellites (starlink included) are still transparent and are
> signal repeaters, not routers processing IP packets, so doing this is
> not immediate at all, but it could bring some benefits.

Yes, but the benefits are quite small.

>
> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.

Indeed. In so many ways.

Mind though that CDNs are generally tied in with DNS nowadays, and 
there's another snag: Take two users, Alice in the UK and Bob in New 
Zealand - pretty much antipodean, using Starlink in bent-pipe 
configuration, i.e., their traffic goes through, say, the London gateway 
in the UK and the Clevedon gateway in NZ. Now imagine both trying to 
resolve the same CDN hostname some time apart, but via the same 
satellite DNS as the satellite has moved from the UK to NZ in the 
interim. Say Alice resolves first and gets the IP address of a CDN 
server in the UK. If the satellite DNS now caches this, and Bob queries 
the same hostname, he gets directed to a server in the UK literally a 
world away instead of the Auckland one closest to him. So unless each 
satellite carries a geolocated copy of the world's DNS entries with it 
and makes a decision based on user location, you have a problem.

>
> Regards,
>
> David
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
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/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 4080 bytes --]

  reply	other threads:[~2023-04-16 21:23 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-16 17:54 David Fernández
2023-04-16 21:22 ` Ulrich Speidel [this message]
2023-04-16 22:03   ` David Lang
2023-04-16 22:42     ` Ulrich Speidel
2023-04-16 23:22       ` David Lang
2023-04-17  0:51         ` Ulrich Speidel
2023-04-17  1:04           ` David Lang
2023-04-17  2:08             ` Ulrich Speidel
2023-04-17  2:34               ` David Lang
2023-04-17  3:21                 ` Ulrich Speidel
2023-04-17  5:01                   ` David Lang
2023-04-17  5:50                     ` Sebastian Moeller
2023-04-16 21:58 ` David Lang
2023-04-17 14:38   ` Rodney W. Grimes
2023-04-17 14:47     ` David Fernández
2023-04-17 19:09       ` David Lang
2023-04-17 20:09         ` Ulrich Speidel
2023-04-17 20:37           ` David Lang
2023-04-17 19:00     ` David Lang
2023-04-18  7:46       ` David Fernández
2023-04-18  8:34         ` Sebastian Moeller
2023-04-18 13:30           ` David Fernández
2023-04-18 17:55             ` David Lang
2023-04-18  5:59 ` Chris J. Ruschmann
2023-04-18 13:01   ` David Fernández
  -- strict thread matches above, loose matches on Subject: below --
2023-04-13 16:34 David Fernández
2023-04-13 17:22 ` Michael Richardson
2023-04-13 18:54   ` David Fernández
2023-04-13 20:01     ` Michael Richardson
2023-04-13 20:06       ` Tom Evslin
2023-04-13 15:57 Dave Taht
2023-04-14 14:47 ` Rodney W. Grimes
2023-04-14 19:36   ` David Lang
2023-04-14 19:50     ` Dave Taht
2023-04-15 23:56       ` Rodney W. Grimes
2023-04-16  7:03         ` Ulrich Speidel
2023-04-16 13:01           ` tom
2023-04-16 13:48             ` Ulrich Speidel

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=a4f30cc4-e940-ca7b-fee3-6abb07fe5c7d@auckland.ac.nz \
    --to=u.speidel@auckland.ac.nz \
    --cc=starlink@lists.bufferbloat.net \
    /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