Not

Hacker News!

Beta
Home
Jobs
Q&A
Startups
Trends
Users
Live
AI companion for Hacker News

Not

Hacker News!

Beta
Home
Jobs
Q&A
Startups
Trends
Users
Live
AI companion for Hacker News
  1. Home
  2. /Story
  3. /Towards Interplanetary QUIC Traffic
  1. Home
  2. /Story
  3. /Towards Interplanetary QUIC Traffic
Nov 17, 2025 at 1:32 PM EST

Towards Interplanetary QUIC Traffic

wofo
103 points
26 comments

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 discussion

First comment

3h

Peak period

16

Day 3

Avg / period

7.3

Comment distribution22 data points
Loading chart...

Based on 22 loaded comments

Key moments

  1. 01Story posted

    Nov 17, 2025 at 1:32 PM EST

    6d ago

    Step 01
  2. 02First comment

    Nov 17, 2025 at 4:39 PM EST

    3h after posting

    Step 02
  3. 03Peak activity

    16 comments in Day 3

    Hottest window of the conversation

    Step 03
  4. 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

Discussion (26 comments)
Showing 22 comments of 26
jauntywundrkind
6d ago
1 reply
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
6d ago
OP here. I'm also looking forward to an ending! I'll definitely write more once our research has made more progress :)
Veserv
6d ago
1 reply
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
3d ago
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
6d ago
2 replies
> 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.

voidUpdate
3d ago
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
wofo
5d ago
> 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.

juancn
3d ago
3 replies
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
3d ago
1 reply
That is the underlying consensus currently.

https://en.wikipedia.org/wiki/Delay-tolerant_networking

throw0101c
3d ago
Also:

* https://datatracker.ietf.org/group/dtn/about/

justin66
3d ago
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
3d ago
I think the idea is to store-and-forward IP packets, then use QUIC on top of that
incognito124
3d ago
1 reply
Is this meant to replace the Bundle Protocol
justin66
3d ago
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
3d ago
1 reply
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
3d ago
1 reply
Using fec codes would get better throughput than sending exact copies
elcritch
3d ago
1 reply
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
3d ago
1 reply
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
3d ago
Agreed it seems like a link layer issue to resolve. Definitely better than just sending out duplicates.
xvilka
3d ago
1 reply
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
3d ago
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.

throw0101c
3d ago
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...

4 more comments available on Hacker News

View full discussion on Hacker News
ID: 45956438Type: storyLast synced: 11/21/2025, 6:02:03 PM

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.

Read ArticleView on HN

Not

Hacker News!

AI-observed conversations & context

Daily AI-observed summaries, trends, and audience signals pulled from Hacker News so you can see the conversation before it hits your feed.

LiveBeta

Explore

  • Home
  • Jobs radar
  • Tech pulse
  • Startups
  • Trends

Resources

  • Visit Hacker News
  • HN API
  • Modal cronjobs
  • Meta Llama

Briefings

Inbox recaps on the loudest debates & under-the-radar launches.

Connect

© 2025 Not Hacker News! — independent Hacker News companion.

Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.