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.
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 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.
David Lang
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
[email protected]
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
