[Starlink] fiber IXPs in space

[David Lang]

On Mon, 17 Apr 2023, Ulrich Speidel wrote:

>> 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.
>
> Yes, full understood. That's how it works on terrestrial DNS (and even on GEO 
> this would be a really good argument). But on LEO, that benefit only 
> materialises if the second client and any others in the same area get to 
> query the same satellite that handled the first client's query, because 
> that's where the information would be cached if we had a DNS server of sorts 
> on each bird. For this to happen, the second client and any subsequent ones 
> have to query within minutes if not seconds of the first one. What is the 
> probability for this to happen? This depends on the total number of active 
> users hanging off that satellite and the popularity of the target host/site 
> among them. The larger the number of users and the higher the site 
> popularity, the more likely that cached entries will see a second or 
> subsequent query. "Active" in this context means users navigating to new 
> sites during the visibility window of that satellite.

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.

> 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.

>> 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.

There are various things that could be done if there is enough interest in 
starlink users to improve the CDN traffic, and it's not clear that misdirecting 
starlink users in some (or even many) cases would be that horrible. Geolocation 
is very imprecise at best and routinely misidentifies locations.

David Lang