Top heavy write-up, with lots of intro & set up. Good stuff, and was happy to see it covered.
And talks to really good really neat wins! Simulated in-process network, tapping Quinn's AsyncUdpSocket and UdpPoller. Cool, nice. Better debugging with pcap, nice. Determinism, nice.
I do want a bit more of an ending though! Glad to see the work open sourced. +1 the thanks to Marc Blanchet for all his help & pushing that push. Also very fun reading their draft (linked in post), An Architecture for IP in Deep Space,
https://datatracker.ietf.org/doc/draft-many-tiptop-ip-archit...
> How can QUIC be viable, then? The attentive reader might already have spotted the answer: the problem isn’t QUIC, but its default configuration, which was designed with terrestrial internet in mind. What we need is a custom configuration, this time targeting deep space, with guidelines to tweak things further if a space mission deems it necessaryy.
I'd expect that there's a ton of work for "bandwidth shaping" interplanetary QUIC that's probably missing, even if it just needs to be basically nulled out on the way across the x-mitters. Guess it's open source & I can dive in & see what was done here!
The problem with QUIC for these kinds of problems is that it is really multiple protocols stacked in a trenchcoat with no way to get at the individual layers.
QUIC has a connection setup protocol, a stream reconstruction protocol, a stream management protocol, a adaptive channel parameter discovery protocol, a resend protocol, a channel bandwidth distribution protocol, and probably a few more that I can not think of off the top of my head just for normal stream oriented transport.
What you really want in this sort of use case is most things except adaptive channel parameter discovery (i.e. half of congestion control). You should already know the expected channel bandwidth and latency and can instead adapt in-context rather than using totally generic mechanisms designed under the assumption of a “uniform/static” network.
> Intermittence is mostly a consequence of using orbiters as communication relays to reach a planet’s surface. Orbiters go around the planet and are only able to communicate with peers they can “see”.
As I understand, this type of intermittence will mostly be a solved problem by the time there are only a few relay satellites around a planet. I think the moon may already have enough for full coverage. (It does not have to be a full-on starlink-like network, Musk is a bit delusional about this)
Still interesting and potentially useful to design around it regardless.
> by the time there are only a few relay satellites around a planet.
Based on the limited information I have, I think it will take decades (at least) to get there for most planets. Hopefully the results of this research will be useful for a long time.
Top heavy write-up, with lots of intro & set up. Good stuff, and was happy to see it covered.
And talks to really good really neat wins! Simulated in-process network, tapping Quinn's AsyncUdpSocket and UdpPoller. Cool, nice. Better debugging with pcap, nice. Determinism, nice.
I do want a bit more of an ending though! Glad to see the work open sourced. +1 the thanks to Marc Blanchet for all his help & pushing that push. Also very fun reading their draft (linked in post), An Architecture for IP in Deep Space, https://datatracker.ietf.org/doc/draft-many-tiptop-ip-archit...
> How can QUIC be viable, then? The attentive reader might already have spotted the answer: the problem isn’t QUIC, but its default configuration, which was designed with terrestrial internet in mind. What we need is a custom configuration, this time targeting deep space, with guidelines to tweak things further if a space mission deems it necessaryy.
I'd expect that there's a ton of work for "bandwidth shaping" interplanetary QUIC that's probably missing, even if it just needs to be basically nulled out on the way across the x-mitters. Guess it's open source & I can dive in & see what was done here!
OP here. I'm also looking forward to an ending! I'll definitely write more once our research has made more progress :)
The problem with QUIC for these kinds of problems is that it is really multiple protocols stacked in a trenchcoat with no way to get at the individual layers.
QUIC has a connection setup protocol, a stream reconstruction protocol, a stream management protocol, a adaptive channel parameter discovery protocol, a resend protocol, a channel bandwidth distribution protocol, and probably a few more that I can not think of off the top of my head just for normal stream oriented transport.
What you really want in this sort of use case is most things except adaptive channel parameter discovery (i.e. half of congestion control). You should already know the expected channel bandwidth and latency and can instead adapt in-context rather than using totally generic mechanisms designed under the assumption of a “uniform/static” network.
> Intermittence is mostly a consequence of using orbiters as communication relays to reach a planet’s surface. Orbiters go around the planet and are only able to communicate with peers they can “see”.
As I understand, this type of intermittence will mostly be a solved problem by the time there are only a few relay satellites around a planet. I think the moon may already have enough for full coverage. (It does not have to be a full-on starlink-like network, Musk is a bit delusional about this)
Still interesting and potentially useful to design around it regardless.
> by the time there are only a few relay satellites around a planet.
Based on the limited information I have, I think it will take decades (at least) to get there for most planets. Hopefully the results of this research will be useful for a long time.