As Douglas Adams observed in The Hitchhiker’s Guide to the Galaxy:
“Space is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.”
Douglas Adams, The Hitchhiker’s Guide to the Galaxy
The Internet Engineering Task Force (IETF) does not launch rockets or design spacecraft, nor does it even work on radio systems and spectrum assignment, but it has been engaged in standardizing communication protocols used to communicate with these spacecraft. These are my observations from the space-related sessions at IETF 126 in Vienna in June 2026.
TIPTOP: IP in outer space
Space networking may seem more related to science fiction than current networking topics for today’s Internet. However, the work holds immediate relevance when considering the need to communicate with distant spacecraft, and the population of such spacecraft. The number of entities that are launching such vehicles continues to grow year-by-year, so it’s not a completely outlandish topic.
The initial effort to standardize this technology relied on store-and-forward communications via the Bundle Protocol, undertaken primarily by NASA’s Jet Propulsion Laboratory (JPL). This work was subsequently taken up within the IETF by the Delay-Tolerant Networking (DTN) Working Group. The DTN Working Group built upon the Interplanetary Internet concepts (originally developed by IPNSIG) to support communications where continuous end-to-end connectivity cannot be assumed.
Unlike traditional networks that rely on immediate, continuous paths between sender and receiver, DTN revived a store/forward practice which was common in the ad-hoc message relay networks in use in the 1980s. The Bundle Protocol (RFC 4838) included:
- An overlay network layer sitting above standard transport layers, allowing ‘bundles’ of data to be held in temporary storage until the next link in the communication chain became available.
- So-called ‘convergence layers’ that specified how DTN protocols mapped onto underlying transport systems, such as Transport Control Protocol (TCP).
However, a major drawback of DTN is its inability to directly use the rich ecosystem of existing IP applications. The Bundle Protocol differs significantly from standard end-to-end transport protocols like TCP and QUIC, and has challenges with the existing Internet infrastructure services such as the Domain Name System (DNS).
The Taking IP To Other Planets (TIPTOP) effort grew out of a different observation that deep-space networking can be viewed like many traditional network environments, just with far longer delays. If you reconfigure the transport layer with much longer timeouts, the rest of the protocol stack can remain standard IP with standard IP addressing. The main topic at the TIPTOP session at IETF 126 was not refinements associated with this effort to adapt existing Internet services into the deep space environment, but one of IP addressing.
Why not simply use existing IP address allocations, as space-based satellites have done for years? One idea was that a specific IP address prefix could act as an implicit signal to upper-layer transport protocols that they should automatically configure themselves with longer timeouts whenever sending packets to or from that address prefix. For example, if all IP networks on Jupiter used address prefix 5, and Venus used address prefix 2, then a packet with a source of 5 and a destination of 2 should expect a hefty transit time! A structured address pool for space use could serve this purpose well.
One view advocates allocating this space-use IP address space in contiguous blocks, proposing that a single Internet Registry manage these allocations. Under this model, each realm in the solar system (such as a planet) would receive a dedicated address block to be used by all local entities within that realm.
However, terrestrial geopolitics present a major hurdle. Within the current framework of Regional Internet Registries (RIRs), no single RIR is positioned to serve entities across the world, particularly given current enthusiasm from some economies to implement international sanctions that limit where specific registries can provide service. To address this, an alternative proposal suggests involving all five RIRs in the application process, allowing a terrestrial space-going entity to be served by whichever registry is legally permissible.
There are clearly intricacies of the technical requirements and their implementation, and who should be framing these requirements is itself a challenging question. Concerns were expressed about whether this IETF Working Group could effectively draft such a solution. But if not an IETF Working Group, then whom? Predictably, discussion experienced its quota of bike-shedding on minor details.
Yet the primary takeaway remains clear: In today’s geopolitical climate, no single entity in the existing framework can provide universal service across all nations. Conversely, the desire for operational simplicity keeps the single-agency option on the table.
This raises broader questions: Should the IETF engage in policy-making that accounts for geopolitical realities? Or should it declare these issues outside its scope and defer to other governance bodies like the Internet Governance Forum (IGF) or the International Telecommunications Union (ITU)? Identifying who holds the mandate for these decisions remains an open question.
Ultimately, it’s difficult to take TIPTOP entirely at face value given its small problem space and low likelihood of any volume of near-term deployment in the solar system. However, it exposes a deeper, recurring debate in Internet governance in the addressing realm: ‘Why five RIRs instead of one central registry, or even 228 national registries? Why five?’ This is a fundamental question that continues to spark debate in many terrestrial venues.
In other topics during the TIPTOP Working Group session, we heard that loss-sensitive transport protocols are prone to collapse, and only Bottleneck Bandwidth and Round-trip (BBRv1) was able to perform reasonably on a deep space simulator. Other considerations include ACK frequency and pipelining.
The original premise of TIPTOP, that bundling was an unnecessary overhead, seems to be weakening. As these studies continue, it is becoming more challenging to map existing transports into long delay and lossy network paths without extensive modification.
Slides from the TIPTOP Working Group session at IETF 126:
- draft-li-tiptop-address-space update, Tony Li,
- Addressing the Final Frontier, Warren Kumari,
- Evaluation of QUIC in Interplanetary Networks, Johannes Frisch,
LEO data comms
Low Earth Orbit (LEO) satellites pose some unique issues for data communications. The high relative speed between the satellite and the ground antenna, and the relative proximity of a few hundred kilometres, means that the signal-to-noise ratio as seen at the ground antenna will change rapidly. If the satellite system uses variable coding to maximize carriage capacity, the available capacity on the circuit will vary frame-by-frame, as will the latency over the satellite system. The high relative speeds between the sender and receiver mean that the ground antenna will need to switch satellites every few seconds. For example, Starlink uses a 15-second satellite assignment interval. These handovers would normally generate a brief period of elevated delay and a higher probability of packet loss.
High jitter, varying capacity and non-congestion packet loss are not good news when you are using an end-to-end congestion control protocol that is based on packet loss. The loss events are visible in two ways: The first is an isolated loss component that occurs every 15 seconds on satellite handover. The second is an assignment to an already heavily committed satellite beam that can produce sustained packet loss and cause sustained retransmission within the transport protocol.
A trace of a standard Starlink service for loss is shown in Figure 1. This is based on a per-second ping test over 24 hours.
The bursty nature of packet loss is shown in Figure 2. Here, the downlink is operating at speeds between 200Mbps and 400Mbps. At second 25 in this trace, the transfer encounters a nine-second period of sustained high packet loss, as shown in the packet retransmit rates in Figure 2 in the red trace.
Starlink’s carriage profile also includes high jitter. The delays experienced on a per-second ping test are shown in Figure 3. The base latency is 20ms, but the variability is up to a further 60ms of delay, with this variation occurring second-by-second (Figure 3).
How can you maximize data throughput through a LEO circuit?
Loss-based congestion control protocols, such as CUBIC or RENO, simply fail to perform. The high-frequency jitter confuses the TCP round-trip time estimate, and the continuous loss profile reduces the congestion window faster than the protocol’s ability to recover. Delay-based congestion control systems look promising, but continuous delay-based measurement will quickly get misled by the high jitter profile.
You may be tempted to conclude that we need to use congestion control protocols that are tuned to the characteristics of LEO circuits. I’m not sure that this is a good suggestion. The server in the data centre has to use a profile that can perform well across a mobile, Wi-Fi, or LEO link in the path.
Here’s where BBR gets interesting. BBR filters out high-frequency signals by running a constant sending rate for six Round Trip Time (RTT) intervals, repairing packet loss at full speed in this period. In the next RTT, it significantly increases its sending rate. Version 1 of BBR used a 25% increase in the sending rate for this RTT interval, and backed off by the same rate in the next RTT interval.
The idea is to push the network to observe whether this burst causes queues to form, as evidenced by an increase in delay. If so, then BBR can conclude that it was already working at network path capacity, and not adjust this rate. If no additional delay was observed, then BBR can conclude that the network can sustain a higher sending rate, which it then sets. It’s possible to view this behaviour as a low-frequency bandpass filter, and the combination of the two behaviours is an extremely good match to LEO carriage characteristics.
Slides: The Limitations of LEO Uplink, Manda Tran, Space Proposed Research Group
An LEO census
Dan York presented an interesting summary of the current and planned LEO and Medium Earth Orbit (MEO) satellite platforms, and the numbers are truly surprising. Here’s a summary of this report:
| Current projects | CC | Current | Planned | Role |
| Starlink | US | 12,612 | 34,864 | Broadband and (limited) D2D |
| Starshield | US | 245 | 1,600 | Military and government |
| Amazon Leo | US | 398 | 7,736 | Broadband |
| Eutelsat One Web | US | 660 | 528 | Wholesale broadband |
| AST Space Mobile | US | 9 | ~100 | D2D |
| Lynk | US | 12 | 2,000 | D2D |
| Globalstar | US | 97 | 1,946 | Voice/data (being acquired by Amazon) |
| Iridium | US | 75 | 177 | Voice/data D2D |
| Guowang | CN | 216 | 13,952 | Broadband |
| Quifan | CN | 239 | 16,000 | Broadband |
| Rassvet | RU | 21 | 924 | Broadband |
| New Projects | ||||
| Starlink Gen3 | US | 100,000 | ||
| Blue Origin TeraWave | US | 5,348 | ||
| IRIS | EU | 282 | ||
| Telesat Lightspeed | CA | 1,600 | ||
| Honghu-3 | CN | 10,000 | ||
| Meridan Space | US | 1,190 | ||
| Jio | IN | 1,600 | ||
| Logos Space | US | 4,178 | ||
| CTC-1/2 | CN | 193,248 | ||
| Orbital data centres | ||||
| AI1 / Starmind | US | 1,198,120 | ||
| Starcloud | US | 88,000 | ||
| Blue Origin | US | 51,600 | ||
| Orbital Compute | US | 100,000 | ||
| Stampede | US | 20,000 | ||
| Google Suncatcher | US | ? |
There’s no doubt that a land rush is underway, driven by reusable rockets, which have lowered LEO launch costs from around USD 10,000 per kilo in the year 2000 to USD 2,000 per kilo on a SpaceX Falcon 9. There are predictions for this cost to drop further to USD 300 or so by 2040 (Figure 4).
There are some hard questions to answer ahead, including:
- How to manage radio spectrum allocations?
- How to deal with astronomical interference?
- How to preserve access to Geostationary Earth Orbit (GEO) satellites
- How to manage risks from space debris in low orbits and the potential to trigger the Kessler syndrome?
- What to do with junk spacecraft following failed ventures?
Slides: Beyond Starlink, Understanding the Coming Waves of LEO Satellite Deployments, Dan York, Space Proposed Research Group
IETF 126
The IETF does a really good job of collecting the presentation material and the video and audio records of all the Working Group sessions throughout the week. View them online now.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.