On Mon, 17 Apr 2023, Ulrich Speidel wrote:
On 17/04/2023 10:03 am, David Lang wrote:
On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote:
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.
DNS time is more significant than you think, due to the fact that so many
websites pull data from many different locations, you end up with a lot of
DNS queries when hitting a new site for the first time (and many of these
queries are serial not parallel) so it adds quite a bit to the first
rendering time of a page.
But most people don't hit new sites most of the time, and a lot of cascading
loads hit the same CDNs you've seen previously.
the timeouts on DNS are short enough that they hit them every day when they wake
up
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.
This is true when the DNS answer is dynamic, but such cases also have short
cache timeouts. Even with a 90 min orbit, a 15 min timeout would
significantly lessen the impact (and I would expect that an orbital DNS
would detect short timeouts and treat them as a signal to shorten the
timeout even more)
Timeout where? At the end user client or at the satellite?
at the DNS cache and at the client. If you are using DNS to redirect people to
the closest/least loaded site, you need to have your DNS timeouts set short so
that you can change where they go with minimal downtime. Many clients refuse to
honor extremely short timeouts (IIRC about 15 min is the low end)
At the end user client, a short timeout makes no sense at all because their
host-to-CDN-IP server mapping shouldn't really change in bent pipe - only the
sat hop changes.
If the timeout is meant to be on the satellite, it means that the satellite
knows nothing about anything when it arrives to assist you, and needs to
query some sort of (probably ground-based) DNS server anyway.
Also, the assumption that a satellite will return to the same spot after a
full orbital period (of say 90 minutes) only applies to satellites in
equatorial orbits (or polar orbits, and then only to the poles). In all other
cases, the Earth's rotation will assure that the satellite's return to the
same location takes many orbital periods.
when the satellite first comes into an area, it won't know what's appropriate to
cach for the area, but it will start caching when people start using it, the
first person suffers the full hit, but everyone after that benefits.
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.
David Lang
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
