From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: David Lang <david@lang.hm>, starlink@lists.bufferbloat.net
Subject: Re: [Starlink] fiber IXPs in space
Date: Sun, 16 Apr 2023 19:34:15 -0700 (PDT) [thread overview]
Message-ID: <2sp7r191-q0o6-6543-0q78-p760477317o5@ynat.uz> (raw)
In-Reply-To: <5e2937ec-9d94-29ed-eac1-18d96db3a19e@auckland.ac.nz>
On Mon, 17 Apr 2023, Ulrich Speidel wrote:
> On 17/04/2023 1:04 pm, David Lang wrote:
>> I think it is going to be fairly common, but the beauty of the idea is that
>> you don't have to risk much to try it. Long lived DNS answers (and
>> especially root servers and TLD servers) can trivially be mirrored to the
>> satellites, and you can experiment with caching to see what sort of hit
>> rate you get. Even if you don't cache a lot of the CDN type traffic, it
>> should still be a win to have the longer term stuff there.
>
> Yes - but root servers and TLD servers also get cached a long time at the
> clients. If each of your clients needs a root server and a few TLD lookups a
> day, it's not a huge gain in terms of performance.
>
> It is however a significant step up in terms of complexity. E.g., your
> satellite-based DNS would have to point you at the TLD server that is
> topologically closest to your Starlink gateway, or risk a potentially much
> longer RTT for the lookup. So you'd need to maintain a list of TLD instances
> on your satellite-based DNS and return the one that corresponds to what your
> gateway-based DNS would get. Sure possible but more complex than a bog
> standard DNS server in a fixed network.
really? I don't think the root and TLD servers do any geolocation, I think they
have fixed answers and rely on anycast addresses to find the closest one. Adding
those anycast addresses to the satellites would be transpoarent to all users
(assuming the satellites are operating at the IP layer, the old bent-pipe
approach did not, but once you have routing in space via the laser links...)
>>> Practically speaking, we know from various sources that each Starlink
>>> satellite provides - ballpark - a couple of dozen Gb/s in capacity, and
>>> that active users on a "busy" satellite see a couple of dozen Mb/s of
>>> that. "Busy" means most active users, and so we can conclude that the
>>> number of users per satellite who use any site is at most around 1000. The
>>> subset of users navigating to new sites among them is probably in the low
>>> 100's at best. If we're excluding new sites that aren't dynamic, we're
>>> probably down to a couple of dozen new static sites being queried per
>>> satellite pass. How many of these queries will be duplicates? Not a lot.
>>> If we're including sites that are dynamic, we're still not getting a huge
>>> probability of cache entry re-use.
>>
>> I think that each user is typically going to use a lot less than the
>> 'couple dozen MB' that is the limits that we see, so the number of users in
>> a cell would be much higher.
> Yes, but these users aren't "active" in the sense that they will be firing
> off DNS queries during the pass...
even users who are using the connection aren't going to be using dozens of MB of
bandwidth.
>>>> DNS data is not that large, getting enough storage into the satellites to
>>>> serve 90% of the non-dynamic data should not be a big deal. The dynamic
>>>> data expires fast enough (and can be detected as being dynamic and
>>>> expired faster in the satellite) that I'm not worried about serving data
>>>> from one side of the world to the other.
>>> Yes, but the only advantage we'd get here is faster resolution for a very
>>> small subset of DNS queries.
>>
>> and while that's not as big a win as faster resolution of a larger set,
>> it's still a win.
> Yes, but are we chasing diminishing margins here when there are much bigger
> fish to fry?
possibly. it's worth discussing and DNS is an easy thing to start with compared
to most others.
David Lang
next prev parent reply other threads:[~2023-04-17 2:34 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
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 [this message]
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=2sp7r191-q0o6-6543-0q78-p760477317o5@ynat.uz \
--to=david@lang.hm \
--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