Towards Interplanetary QUIC Traffic
Mood
calm
Sentiment
neutral
Category
tech
Key topics
QUIC Protocol
Space Communication
Networking
The article discusses the potential use of the QUIC protocol for interplanetary communication, but there is no discussion or reaction from the HN community.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
3h
Peak period
16
Day 3
Avg / period
7.3
Based on 22 loaded comments
Key moments
- 01Story posted
Nov 17, 2025 at 1:32 PM EST
6d ago
Step 01 - 02First comment
Nov 17, 2025 at 4:39 PM EST
3h after posting
Step 02 - 03Peak activity
16 comments in Day 3
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 20, 2025 at 2:57 PM EST
3d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
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!
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.
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.
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.
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.
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.
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.
[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...
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.
* 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...
4 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.