Cloudflare CTO proposes a Starlink-native transport protocol; Musk forwards it
Dane Knecht wants Cloudflare and Starlink to redesign internet transport for moving satellites, extending earlier work on edge capacity.
By Ryan Merket · Published
Why it matters
Cloudflare and Starlink control complementary parts of the connection. A joint protocol could reduce the speed penalties caused when terrestrial congestion controls misread satellite handovers and variable radio links.

Cloudflare CTO Dane Knecht (@dok2001) proposed on August 9th that Cloudflare and Starlink jointly develop a transport protocol designed for low-Earth-orbit satellite networks. Elon Musk (@elonmusk) replied that he had forwarded the idea to Starlink's engineering team.
The exchange amounts to a technical proposal and an internal referral. It does not establish a new product or commercial agreement. The premise, however, addresses a documented constraint on satellite broadband: widely deployed congestion-control systems can mistake the routine variability of a moving satellite network for conventional terrestrial congestion.
Knecht has spent 13 years building Cloudflare's network and developer products, joining when Cloudflare had fewer than 30 employees. According to Cloudflare's executive biography, he helped develop and scale its Zero Trust products, developer platform and AI inference infrastructure. Before Cloudflare, he founded an e-commerce software company that was acquired and held product roles at MessageOne and Dell.
That background makes Knecht's proposal more than a passing suggestion. Cloudflare operates infrastructure on both ends of millions of internet connections, giving its engineers a place to test transport changes at the server and edge layers. Starlink controls the radio network, satellite handovers and internal telemetry that an ordinary internet endpoint cannot see.
The protocol problem
The technical issue concerns transport and congestion control, rather than a wholesale replacement of the internet's routing system.
TCP congestion-control algorithms monitor signals such as round-trip time and packet loss, then adjust how quickly a sender transmits data. That feedback loop works best when changes in delay or loss indicate that a fixed network path is becoming congested.
A Starlink connection behaves differently. Satellites move relative to users, terminals hand traffic between satellites, available bandwidth changes and network paths can shift. Weather and radio conditions can also produce losses that have little to do with an overloaded router. A conventional algorithm may respond by reducing its sending rate even when spare capacity remains available.
Researchers have measured the resulting performance gap. A 2025 study of 14 Linux TCP congestion-control variants found that Google's BBR algorithms outperformed Cubic, a common Linux default, over Starlink connections. The researchers found that Cubic performed particularly poorly on single flows and concluded that changes within Starlink during 2023 and 2024 likely reduced its throughput further.
Other work has identified periodic handovers as another source of delay spikes and packet loss. Those events can trigger the same defensive behavior that protects terrestrial networks from genuine congestion, slowing downloads and degrading interactive applications.
Knecht's clean-sheet approach could incorporate information that current end-to-end protocols lack. Starlink could expose signals about handovers, radio-link conditions or path changes. Cloudflare could use those signals to pace traffic from its edge servers instead of waiting for packet loss to reveal that the connection changed.
An existing relationship moves deeper into the stack
Cloudflare and SpaceX have already explored ways to improve Starlink closer to the ground. The Information reported in August 2023 that the companies were working to expand Starlink's terrestrial points of presence, the facilities where satellite traffic enters the wider internet.
That work targeted physical proximity and network topology. Knecht's new proposal moves deeper into the software stack by changing how endpoints decide when and how fast to send packets.
The distinction matters. A 2026 measurement study of Starlink and content-delivery networks found that moving points of presence closer to users cut median page-fetch times by 60% in the regions studied. Better transport control could attack another source of delay after the traffic reaches the right location.
The potential deployment base is large. A SpaceX prospectus said Starlink had approximately 10.3 million customers as of March 31st, 2026. Cloudflare separately measured a 2.3-fold increase in global request traffic from Starlink during 2025, including rapid growth after service opened in new markets, according to its 2025 internet traffic review.
Deployment will determine the reach
A protocol used only between Starlink and Cloudflare infrastructure could improve traffic served through Cloudflare while leaving connections to other networks unchanged. A public specification or standards-track effort could reach the wider internet, though adoption would require support from operating systems, browsers, server vendors or application developers.
There is also a narrower path. Cloudflare could adapt QUIC or build a specialized congestion controller without replacing the applications above it. That would make experimentation faster and preserve compatibility with the existing web, while giving Starlink a way to provide explicit network feedback.
Musk's response gives the proposal an internal sponsor at Starlink. The engineering test is whether Cloudflare and Starlink can turn knowledge of satellite movement into measurable gains without creating a protocol that works only inside two companies' networks.