The Laser Network That Must Tie It Together

Part 9 of 30 · Series date: September 8, 2026

Fast processors need useful connections—not just an impressive peak speed on a laser demonstration.

Imagine building a town of brilliant specialists and connecting their offices with narrow footpaths. Each person works quickly alone. When a project requires constant collaboration, everyone waits for messages.

Computers can have the same problem. Processing speed matters only if information reaches the processors quickly enough. For orbital computing, communications may determine the scale of the business.

Light carrying information

Laser communications encode information in light. A receiver detects that signal and reconstructs the data. Compared with many radio arrangements, optical systems can offer high data rates and narrow beams, but they require careful pointing and suitable receiving equipment.

NASA's TBIRD demonstration achieved space-to-ground laser communications at 200 gigabits per second. That was a communications demonstration under mission conditions, not a promise that every orbital customer can obtain that rate continuously. NASA: TBIRD mission results.

The distinction between a peak rate and a dependable service is essential.

A link is not a network

One fast connection joins two endpoints. A network must decide where traffic goes, handle congestion, recover from failures, and share capacity among users.

It must also contend with changing geometry. Can two spacecraft see one another? Are their terminals available? Does a maneuver interrupt pointing? Is another route possible when a link fails?

Adding more nodes increases opportunities for routing, but also increases management complexity. A diagram containing many glowing lines does not establish that every line can operate simultaneously.

The last link to Earth

Space-to-space optical links avoid most atmospheric interference. A path to a ground receiver does not. Clouds can block an optical downlink, while turbulence and other conditions affect performance.

MIT Lincoln Laboratory's TBIRD program describes the practical work behind moving large datasets through brief satellite passes. The demonstration is useful evidence for high-rate delivery, not evidence that weather and access windows have vanished. MIT Lincoln Laboratory: TBIRD.

A possible commercial architecture would use several geographically separated ground sites, with storage and alternate routing when one site is unavailable. That is a design option with costs, not free redundancy.

Bandwidth and delay are different

Bandwidth describes how much information a link can carry per unit of time. Latency describes how long a message takes to arrive. A connection can have high bandwidth and still impose substantial delay.

Imagine mailing a truckload of books. The shipment carries a large amount of information, but the recipient cannot read it until the truck arrives. A short telephone call has a different balance.

Some AI workloads need frequent exchanges among processors. Others need a large input once and can work independently afterward. These workloads will respond differently to the same orbital network.

Distance also imposes a physical floor. For an illustrative 1,000-kilometer path, light requires roughly 3.3 milliseconds in vacuum before switching, queuing, and processing are counted. A multi-hop route can be much longer than the altitude printed in a satellite brochure.

Protecting the conversation

A narrow beam makes casual interception harder, but it does not replace encryption, authentication, or secure endpoints. A compromised computer can expose information before it enters a perfectly aimed beam.

Operational resilience matters too. A platform needs a safe way to receive essential commands if its high-capacity terminal fails. The appropriate backup depends on the mission, but separating survival communications from customer traffic is a useful design principle.

Why Starlink is relevant—and why it does not settle the problem

Starlink's technology description includes optical intersatellite links. That makes it relevant to the broader idea of moving data through a space network. It does not establish that an arbitrary orbital computer can connect, obtain a particular service level, or use the network like the internal fabric of a ground AI cluster. Those questions require compatible equipment and explicit service arrangements. Starlink: technology.

The distinction resembles the difference between a highway and the wiring inside a factory. Both move something important, but they serve different patterns of traffic. A broadband network can be valuable for delivering inputs and results while still being unsuitable for constant fine-grained coordination among thousands of accelerators.

Google's Suncatcher research illustrates a different approach: closely grouped computing spacecraft with demanding optical links. Its system study and laboratory work should be read as evidence about that proposed architecture, not as a performance guarantee for an existing global network. Google: Suncatcher system design.

Put a stopwatch on the whole transfer

Consider a hypothetical ten-gigabit-per-second connection. At that ideal rate, a decimal terabyte—eight trillion bits—takes 800 seconds, or about 13 minutes and 20 seconds, to transfer. This ignores headers, retransmissions, competing traffic, and time spent acquiring the link.

If the receiver is available for only five minutes, the job cannot finish in that contact at the stated rate. Storage and another contact may solve the problem, but the delivery promise changes.

Now suppose a task needs that input only once and then computes for several days. The initial transfer might be acceptable. If it needs another terabyte every ten minutes, the same connection is inadequate.

These invented examples show why application demand must be compared with usable network capacity over time. A large peak-rate number does not answer whether the next file will arrive before its deadline.

Units deserve attention too. Eight bits make a byte. Confusing gigabits with gigabytes produces an eightfold error before any spacecraft limitation enters the calculation.

The slowest ordinary day can matter more than the fastest test

A cloud buyer may care less about the best observed delay than about how often a result is late. Two routes with the same average delay can produce very different customer experiences if one suffers occasional long interruptions.

A useful service report would show the spread of delivery times and the conditions behind missed deadlines. It would also identify whether a backup route has enough capacity when several primary routes fail together.

Imagine several optical ground sites beneath the same broad weather system. They are different buildings, but their failures may be related. Placing receivers farther apart could help, while increasing terrestrial connection costs and operational complexity.

Network resilience is therefore a geographical and commercial design problem as well as an optical one. The laser is a remarkable instrument. The dependable service requires someone to plan for the afternoon when it cannot reach its usual destination.

What would prove this?

Ask for sustained useful throughput, availability, delay distributions, error rates, and recovery behavior across realistic routes. Include cloudy ground stations, competing traffic, and interrupted links.

For distributed AI, test the application itself rather than inferring success from a fast file transfer. A network that excels at moving independent files may still be unsuitable for tightly synchronized training.

The orbital cloud will not be held together by processors alone. Its highways must carry the right information, at the right time, often enough for customers to rely on the destination.

Previous article · Next article