Technical analysis
Why Not Internet, Satellite or 5G
The requirement under analysis: sustained bulk delivery of machine data from each site to two fixed destinations at average payload rates of roughly 44 to 131 Gbps per dense site depending on the delivery window, within a bounded data-age SLA, with protected telemetry and engineered backlog recovery. What follows is the transport-layer mechanics of internet access, then the same test applied to satellite and private 5G. None of it is a judgment about carrier quality.
1. What an internet path is actually made of
Only the first hop is dedicated. The rest is shared with everyone.
A dedicated internet circuit is dedicated for exactly one segment: the access loop from the site to the carrier's first aggregation point. Everything after that is statistically shared. A typical path from a rural site to a cloud or GPU ingress crosses ten to twenty routed hops across three to five separately owned administrative domains. Every domain boundary is a queue, a policy point, and a potential congestion point, and every element past the first is outside the site contract.
| Path segment | Who controls it | Capacity committed to this flow | Observable to you |
|---|---|---|---|
| Access loop, site to carrier | Site carrier | Yes, the port rate | Yes |
| Carrier metro aggregation and core | Site carrier | No, statistically multiplexed | No |
| Carrier peering or transit handoff | Two parties, bilateral | No, sized to average demand | No |
| Transit backbones | Transit providers | No | No |
| Transit to destination peering port | Two parties, bilateral | No, historically the hottest point | No |
| Destination ingress edge and fabric | Cloud or GPU provider | No, policed and rate-managed | No |
On the private path, every segment from site demarcation to destination cross-connect is a contracted product with committed capacity, held by one operator, instrumented end to end.
Why internet transport does not hold
Only the first hop is yours. At every shared handoff the flow queues behind everyone else, and the packets that fall out are re-sent into the same congestion. The lower lane is one operator, one committed circuit, end to end.
2. Internet routing picks the cheapest path, not the fastest
Internet paths are selected by a policy protocol. Selection is driven by each network's commercial preference, typically its cheapest egress, and by path length. No step in that selection consults latency, loss, jitter, or link utilization, so traffic keeps being sent into a saturated interconnection port indefinitely, because saturation is invisible to the protocol. Each network also hands traffic off at its nearest exit to minimize its own carriage cost, which routinely produces asymmetric paths: the forward and return directions of one flow cross different infrastructure, with different behavior, defeating both performance reasoning and fault isolation.
The path is also not stable. Routes change without notice through maintenance, failures, and commercial renegotiations, so the path measured during a pilot is not guaranteed to be the path in production. Every network in the middle is optimizing its own cost of carriage. None is optimizing, or even aware of, your delivery objective. On the private path there is no path selection between site and destination at all: traffic follows engineered circuits whose route, capacity, latency, and failover behavior are fixed by design and stated in each Site Deployment Plan.
3. Delivery times have to be predictable
End-to-end latency has two components: propagation, fixed by distance, and queueing, variable and accruing at every congested hop. On a multi-domain path, queueing delay varies with everyone else's traffic: diurnal peaks, buffer bloat at access and interconnection points, and congestion events produce round-trip variance the site's dedicated loop does nothing to prevent. For interactive traffic jitter is an annoyance. Here it is contractual, because the SLA is expressed as maximum data age at the destination, and delivery-time predictability is exactly what queueing variance destroys. A path whose round-trip time breathes between 35 ms and 120 ms with the internet's load cannot support a bounded delivery commitment.
- 35 to 120 ms
- typical internet round-trip variance under load
- 18 to 47 ms
- engineered per-site route baselines, stated per site
- Sub-millisecond
- jitter on the private path, held at peak
4. A little packet loss wrecks transfer speed
Lose a fraction of a percent, and speed falls off a cliff.
Sustained bulk transfer is governed by the loss-throughput relationship: per-flow throughput is proportional to segment size divided by round-trip time times the square root of loss. Two structural consequences follow. Fractions of a percent of loss on a long path cut per-flow rates by an order of magnitude. And the internet path caps segment size at the standard 1500-byte frame, because jumbo frames do not survive multi-domain transit, while the private path runs jumbo frames end to end, raising the per-flow ceiling roughly sixfold at identical round-trip time and loss.
| Path loss rate | Per-flow ceiling, 40 ms round trip, 1500-byte frames | Parallel flows needed for 44 Gbps |
|---|---|---|
| 0.001%, well-run path, off-peak | ~113 Mbps | ~390 |
| 0.01%, ordinary internet weather | ~36 Mbps | ~1,200 |
| 0.1%, congested peering at peak | ~11 Mbps | ~3,900 |
| 1%, congestion event | ~3.6 Mbps | ~12,300 |
Parallel flows mitigate the per-flow ceiling but do not repair the underlying capacity: thousands of competing flows converging on the same congested port amplify queueing, raise the loss rate they are trying to outrun, and inflate transfer time through retransmission, which also duplicates carried volume. Loss at peak is precisely when the fleet is offloading. The private path is engineered to loss at or below 0.001% with fixed round-trip time and jumbo framing, so the same 44 Gbps objective is met with a handful of flows, and the loss and latency budget for each route is a stated, tested acceptance criterion.
5. Every site ends up squeezing through the same few points
Every shared segment above is oversubscribed by design: it is sized to average demand across all customers, not to any customer's committed rate, because that is what makes internet service economical. The binding constraints in practice are the bilateral interconnection ports, carrier to transit and transit to cloud, which are sized commercially, run hot at peak, and are augmented on negotiation timescales measured in quarters, by parties with no contract to your program.
The fleet then makes this worse with its own success: every added site sends bulk flows to the same two destinations, so the program's traffic fans in on identical choke points and congests itself, with degradation correlated across all sites, at peak, simultaneously. Every architecture has bottlenecks. The distinction is whether they are owned, measured, provisioned, observable, and expandable, or merely encountered downstream. The private design does not eliminate convergence, it relocates it to the A/B Aggregation Core, where aggregate demand is the arithmetic sum of contracted tiers, capacity is contracted non-blocking, utilization is reviewed quarterly, and upgrades follow a published tier ladder ahead of saturation.
6. You cannot see, or fix, most of the path
Operationally, the internet path ends at the carrier edge. There is no telemetry into a transit provider's queue depths, no ticket to file on someone else's peering port, no restoration target that attaches to the segment actually failing, and, given asymmetric routing, often no certainty about which segment that is. Fault isolation across three to five administrative domains is a negotiation, not a procedure. The private path is instrumented per segment, and delivery telemetry, bytes generated, queued, transmitted, received at aggregation, and accepted at destination, localizes any shortfall to source, storage, transport, core, or destination ingest, under one operator's SLA with stated restoration targets, credits, and chronic-outage rights.
7. What you need, and what each option actually does
| What the program needs | What internet access actually does | What the private path does |
|---|---|---|
| Sustained 44 to 131 Gbps payload per dense site | Per-flow ceilings set by loss and round-trip time; shared segments sized to average demand | Non-oversubscribed committed capacity, jumbo framing, engineered loss budget |
| Bounded data age at destination | Queueing variance and route instability make delivery time unpredictable | Fixed engineered round-trip time per route, sub-millisecond jitter, stated in the deployment plan |
| Protected telemetry class | No end-to-end quality of service: class markings are not honored across domains | Three service classes enforced end to end: protected, shaped, recovery |
| Backlog recovery after impairment | Recovery flows compete at the same congested choke points at peak | Deliberate spare capacity engineered per site for drain rate |
| Fault isolation and remedy | Three to five domains, asymmetric paths, no cross-domain SLA | One operator, per-segment telemetry, single SLA with restoration targets |
| Path and cost governance | Routing selects for each intermediary's cost; paths change without notice | Engineered circuits; route, capacity, and failover fixed by design |
8. The same test, applied to satellite and private 5G
Starlink, the broader LEO constellations, and private 5G are genuinely good technologies. This is not an argument against them. It is the arithmetic of what they are engineered to do, against what this workload requires: 25 to 100 gigabits per second of sustained upload per site, a bounded data age at the destination, and a private path to cloud and GPU infrastructure. Three tests. Here is how each technology meets them.
Why Starlink cannot carry it
- 01
The per-terminal arithmetic fails by orders of magnitude. A Starlink-class terminal delivers uplink measured in tens of megabits. This workload uploads tens of thousands of megabits, sustained. No practical number of terminals bridges a thousand-fold gap, and the beam serving them is shared anyway.
- 02
The asymmetry runs the wrong way. Satellite service is engineered download-heavy for consumption. Machine-data offload is upload-heavy by definition: the workload lives in exactly the direction the service is thinnest.
- 03
It lands on the public internet. Behind carrier-grade NAT, on shared transit, with no private path to cloud on-ramps or GPU providers. Every delivery, security, and cloud-economics property of internet transport applies in full.
- 04
Variance versus a data-age budget. Beam handoffs, weather, and load shape throughput hour to hour. A bounded delivery commitment cannot be written on top of it.
Why satellite cannot carry the offload
What one terminal returns on the uplink
tens of Mbps
What one site has to upload, sustained
25 to 100 Gbps
The two bars are roughly a thousand times apart. Adding terminals does not close that, because they share the same beam overhead.
The satellite moves, the beam is shared with everyone under it, and the uplink is the thin direction by design. The workload needs upload measured in tens of gigabits per second; a terminal returns tens of megabits per second, and it lands on the public internet at the far end.
Where Starlink is right: crew connectivity, bootstrap communications, and out-of-band management. We recommend it for exactly those, and use it ourselves.
Why LEO in general cannot
The limitation is not one company; it is the design axis of the category. A constellation spreads finite spectrum and finite beam capacity across continental coverage: it is engineered for breadth of reach, not depth of capacity at a point. The capacity density available to any single square kilometer is a small fraction of one fiber pair, and inter-satellite links do not change the uplink physics of the cell above your site. And every constellation ultimately lands its traffic at gateway earth stations that hand off to the same terrestrial fiber networks, minus your control of the path. For a point that must move fiber-scale volumes, the answer is fiber-scale infrastructure: a tower that already has it, and optics that carry it the last ten kilometers.
Why private 5G cannot, and why you might still want it
- 01
It is an access network, not backhaul. Private 5G answers how machines and people connect on the site. It is often the right answer to that question. It does not answer how the data leaves.
- 02
The cell arithmetic is an order short. A mid-band sector delivers shared capacity in the low single-digit gigabits; shared spectrum frameworks cap the aggregate; millimeter-wave adds capacity at the cost of range and line-of-sight fragility measured in meters. The workload needs 25 to 100 gigabits, sustained, per site.
- 03
Every byte it carries still has to leave. A site with private 5G has solved its radio access and not its offload. The two are complements, not alternatives.
Why private 5G does not solve the offload
Private 5G is the on-site access answer, and it works. The machines connect, the data arrives at the edge, and then it still has to leave. A mid-band sector shares low single-digit gigabits across the site; the exit is the part that has to carry 25 to 100 gigabits per second.
If your site runs private 5G, we are not the alternative. We are where its data goes.
9. What the same movement would cost elsewhere
Priced anyway, the alternatives are an order of magnitude more expensive for a service that cannot keep pace.
A standard site generates about 20 TB per day, roughly 600 TB per month. Keeping pace requires about 1.85 Gbps of sustained uplink around the clock, or about 5.6 Gbps to deliver inside an eight-hour window. An eleven-site program moves roughly 6.6 PB per month. Those are the numbers every alternative has to meet.
| Test | Starlink / LEO | Cellular / private 5G | The private path |
|---|---|---|---|
| Meeting 1.85 Gbps sustained | About 93 terminals on paper, but the beam overhead is shared, so the ceiling does not move with terminal count | About 500 Mbps of shared uplink per mid-band sector, so four dedicated sectors at a standard site and a stadium-grade build at a dense one | 10G or 100G dedicated, engineered to the requirement |
| Recurring data fees, standard site | 10 to 20 times the entire program fee every month, before terminal hardware | Bought as carrier data, several times the whole program fee for a single site | Flat site fee, no per-gigabyte metering |
| Capital before first byte | Terminal count in the dozens per site | Several hundred thousand in private 5G capital, and the core still needs the backhaul this study started with | No site capital, delivered as a managed service |
| Data age | Unbounded, backlog grows continuously | Unbounded at these volumes | Bounded, per-site delivery commitment |
Terminal throughput does not sum. Every terminal at a site shares the capacity of the same beam overhead, so the requirement cannot be met at any terminal count, and backlog grows without bound. Data age, the governing constraint of the program, becomes unbounded with it. On the cellular side the order is the same: 5G answers how machines connect on a site, not how 600 TB per month leaves one.
Comparisons are directional, drawn from published pricing classes and rounded. The finding is the order of magnitude, not the third digit.
10. Side by side
| Starlink / LEO | Private 5G | The private path | |
|---|---|---|---|
| Sustained uplink per site | Tens of megabits per terminal, shared beam | Low single-digit gigabits per sector, shared | 25 to 100 gigabits, dedicated |
| Capacity model | Shared constellation beams | Shared spectrum, local cell | Dedicated tower optics plus dedicated wave |
| Delivery determinism | Varies with load, weather, handoffs | Varies with load and interference | Engineered path, bounded data age |
| Path to cloud and GPU | Public internet, carrier NAT | Whatever backhaul the site has | Private cross-connects at the core |
| Best role | Crew, bootstrap, out-of-band | On-site machine and people access | The offload path itself |
Three good technologies. Three different jobs. For moving fiber-scale data off a remote site, the job belongs to the tower and the wave.
Conclusion
None of these mechanisms reflects poor carrier engineering. Each is the internet working as designed. Routing economics, statistical multiplexing, nearest-exit handoff, and best-effort interconnection are what make universal reachability affordable, and they are exactly the properties that make bounded, sustained, high-volume delivery between fixed endpoints unachievable as a contractual commitment.
Internet access optimizes reachability at lowest cost. This program requires assured delivery within a data-age budget. Those are different engineering problems, and the private managed fabric exists because the second cannot be solved with the tools of the first. The mismatch is not paid for in network terms: it is paid in idle GPU capacity waiting on delayed data, and in training and program milestones that slip behind it.
Figures shown are illustrative planning and engineering values. Per-site values are set in each Site Deployment Plan.