OK, Network topology 101:
- It has the added handicap of the round trip. That's not something that makes the timing less strict, it only makes it more strict.
Not following you here. Are you saying
starlink has the added handicap of the round trip and that makes things
worse for caching at the edge (anywhere in orbit for the purposes of this).
- The whole point of caching is that you take away all of the downstream latency by having a low-latency node closer to the endpoint. So you typically expect a caching server to have latency less than the upstream latency. Say a starlink satellite typically sits at 5ms, then you expect the caching server to serve you in less than 1-2ms. If it sits at 100ms, you'd expect 20-30ms to be acceptable. This has to do with the statistical nature of lookups. A median 2ms lookup is going to have extremes of e.g. 10 or even 100ms, and you want your cache hits to be economical in like 99 or 99.9% of cases.
This seems like it directly agrees with MilleniX's statement that, because the hop the cache is trying to avoid is about 70ms, the cache doesn't have to be super fast? Or are you saying the negative match lookup has to be super fast to avoid makign the already slow latency much worse?
IME pure solid state storage can have very tight latency bounds, though I was spoiled by having a bunch of Optane for it. PRAM may well be different, though but the baseline read latency is so low (nanos) that it just doesn't matter. The power/IOps of the storage sub systems above the hardware will be the dominant factor, and starlink is fine with that that being custom I should think.
- Internally, it's most efficient these days to have single-layer storage solutions. If you can get away with it, all that's in a caching server is a big bank of nonredundant SSDs connected directly to the CPU's PCIe lanes. Once you add higher-latency or more complex storage like NASes, you need to add additional layers of caching internally to deal with that, and that's just extra power and complexity
Yes, I envisaged a complete flat system. Not sure if PCIe is the way to go in space though
I would assume the starlink processing right now is Asics with a lot of content Addressable Memory to do fast constant speed routing. Whether that can do the necessary manipulations to spot locally cached data would be the bottle neck for it working without change to the Application layer. In theory you could still achieve specific targeting of things efficiently with changes to the application layer though (netflix client and server are aware of the starlink cache on a specific session and send specific requests for it that is easy for the starlink processing units to detect and respond to - including as the specific satellite servicing you changes).
Whether that's tenable though is a very different question and it seems unlikely outside of being an open standard in future if satellite networks get more popular.
- Caching these days is something you do for expensive content. Caching servers aren't serving up tiny images like the google doodle, they serve up entire movies. Dynamic content, the things people most frequently access (e.g. social media feeds), isn't easily cached but it's also not bandwidth or storage sensitive. And stuff you want to cache is security handshakes, which are the major source of slowdown in straight internet traffic these days.
The google doodle almost certainly comes from googles own edge network regardless. I agree entirely that having the latest hotness on netflix and the like is the big win and would envisage that being the core targets. Security handshakes had not occurred to me, but I suspect are not tenable in the (rough) architecture I outlined.
Edit: This got
discussed already over on nasaspaceflight
There's some additional compelling arguments for not trying to do the CDN in space there (the issue of the CDN ceding control to the ISP and the business relationships involved is a very good non technical one I hadn't considered)
The suggestion in there of caching
DNS though sounds way more plausible. Vastly less data, much more scope for improvement of initial multi hops. Might play havoc with location aware DNS as the satellite moves though
