[HN Gopher] Towards Interplanetary QUIC Traffic
___________________________________________________________________
Towards Interplanetary QUIC Traffic
Author : wofo
Score : 93 points
Date : 2025-11-17 18:32 UTC (3 days ago)
(HTM) web link (ochagavia.nl)
(TXT) w3m dump (ochagavia.nl)
| jauntywundrkind wrote:
| 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!
| wofo wrote:
| OP here. I'm also looking forward to an ending! I'll definitely
| write more once our research has made more progress :)
| Veserv wrote:
| 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.
| aallaall wrote:
| A congestion algorithm using a machine learning model would of
| course be better than a generic approach, and the browser could
| then also be promoted with "AI". Come on google!
| creatonez wrote:
| > 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.
| wofo wrote:
| > 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.
| voidUpdate wrote:
| You would still need relays between earth and mars (Maybe at L4
| or L5) since when they are on opposite sides of the sun, that
| will likely block radio transmissions
| juancn wrote:
| Why not a store-and-forward architecture?
|
| You still need a protocol for point to point and maybe that's
| where QUIC plays a role, but wouldn't make more sense to use
| something like email?
|
| The distances and latencies are so large, that you want to send a
| file to the next hop in the network, and from there to the next
| one, and so on.
| monocasa wrote:
| That is the underlying consensus currently.
|
| https://en.wikipedia.org/wiki/Delay-tolerant_networking
| throw0101c wrote:
| Also:
|
| * https://datatracker.ietf.org/group/dtn/about/
| justin66 wrote:
| I found it baffling the extent to which the article and the
| stuff it linked to did not discuss the current state of the
| art.
| wofo wrote:
| I think the idea is to store-and-forward IP packets, then use
| QUIC on top of that
| incognito124 wrote:
| Is this meant to replace the Bundle Protocol
| justin66 wrote:
| It reads like it was written by someone who doesn't know about
| the bundle protocol. (I assume that's not actually true, but
| nevertheless.)
| nopurpose wrote:
| Having worked with QUIC extensively lately I must say that having
| protocol entirely in userspace is truly liberating. It also helps
| that almost everything, including headers is encrypted, as a
| result middle boxes can't interfere and "optimise" your flow.
|
| For high latency and high packet loss links, like one described
| in the article, you'll probably need pre-emptive retransmits and
| I am not sure that simply tuning parameters will get there.
| Retransmitting before loss is detected cuts bandwidth, but I
| suspect will improve end to end latency.
| convolvatron wrote:
| Using fec codes would get better throughput than sending exact
| copies
| elcritch wrote:
| Aren't fec codes already used in satellite transmissions? I
| recall reading the patents around fec codes had something to
| do with the satellite industry.
| convolvatron wrote:
| definitely. that's the only reason I know about them.
| usually you have to do a little more, because the errors
| are very bursty, so you have to use very wide windows or
| interleave in order to spread the errors out so that the
| redundancy can cover them.
|
| if you're saying 'thats a link layer problem' then I agree,
| but it would be better to change your link level encoding
| strategy than to just start sending multiple copies at the
| transport layer.
| elcritch wrote:
| Agreed it seems like a link layer issue to resolve.
| Definitely better than just sending out duplicates.
| throw0101c wrote:
| See perhaps recent session at IETF 124 (Montreal; Nov 2025) of
| the Delay/Disruption Tolerant Networking Working Group (DTN WG):
|
| * https://www.youtube.com/watch?v=7hbZSwvXpZ4
|
| * https://datatracker.ietf.org/group/dtn/about/
|
| Various other sessions / meetings:
|
| * https://www.ietf.org/meeting/124/
|
| * https://www.youtube.com/playlist?list=PLC86T-6ZTP5hpTncHTKkY...
| xvilka wrote:
| We don't have proper interplanetary time standard yet[1][2][3].
| That should be a first big milestone to achieve standardized
| networking with all space objects at least in the Sol system.
|
| [1] https://science.nasa.gov/learn/basics-of-space-
| flight/chapte...
|
| [2] https://bidenwhitehouse.archives.gov/ostp/news-
| updates/2024/...
|
| [3] https://space.stackexchange.com/questions/5540/has-an-
| interp...
| drtgh wrote:
| I would use the larger star as root variable for the systems,
| using the system name as reference to such larger star
| (therefore, Sol = the sun), then each planet would adapt their
| time dilatation from this reference, something like Sol:Earth
| and Sol:Jupiter, but now I realize even like this the speed of
| the satellite in origin and destination should also be
| included, something like Sol:Earth[satellite_speed] and
| Sol:Jupiter[satellite_speed], but the transit of a satellite
| between planets would need some kind of progressive sampling
| witch don't sound specially precise. To me sounds like people
| specialised tried to design something and got trapped in a loop
| about witch ideas would be less problematic (what would be
| interesting to read if my guessing is right).
|
| PS: I mean, with something like what I described, we would read
| the packets at Sun:Earth sent from Sun:Jupiter and from
| Sun:Mars as time in the header (with the intention of being
| able also to exclude if they were sent with Radio_wave or
| Light/laser_wave speeds), the only alternative I can think of
| is a satellite orbiting the larger star, sending some kind of
| subspace instantaneous signal from an atomic clock, and read it
| at each planet instantaneously.
___________________________________________________________________
(page generated 2025-11-20 23:01 UTC)