El CTO de Cloudflare propone un protocolo de transporte nativo para Starlink; Musk lo reenvía
Dane Knecht quiere que Cloudflare y Starlink rediseñen el transporte de Internet para satélites en movimiento, ampliando el trabajo previo sobre la capacidad de borde.
By Ryan Merket · Published
Primary source: X
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) propuso el 9 de agosto que Cloudflare y Starlink desarrollen conjuntamente un protocolo de transporte diseñado para redes de satélites en órbita baja. Elon Musk (@elonmusk) respondió que había reenviado la idea al equipo de ingeniería de Starlink.
El intercambio equivale a una propuesta técnica y a una referencia interna. No establece un nuevo producto ni un acuerdo comercial. La premisa, sin embargo, aborda una limitación documentada del acceso por satélite: los sistemas de control de congestión ampliamente desplegados pueden confundir la variabilidad rutinaria de una red de satélites en movimiento con la congestión terrestre convencional.
Knecht ha pasado 13 años construyendo la red y los productos para desarrolladores de Cloudflare, uniéndose cuando Cloudflare tenía menos de 30 empleados. Según la biografía ejecutiva de Cloudflare, ayudó a desarrollar y escalar sus productos Zero Trust, la plataforma para desarrolladores y la infraestructura de inferencia de IA. Antes de Cloudflare, fundó una empresa de software de comercio electrónico que fue adquirida y ocupó roles de producto en MessageOne y Dell.
Ese historial hace que la propuesta de Knecht sea más que una sugerencia pasajera. Cloudflare opera infraestructura en ambos extremos de millones de conexiones a Internet, lo que brinda a sus ingenieros un lugar para probar cambios de transporte tanto en el servidor como en las capas de borde. Starlink controla la red de radio, las transferencias entre satélites y la telemetría interna que un extremo ordinario de Internet no puede ver.
El problema del protocolo
La cuestión técnica se refiere al transporte y al control de congestión, más que a un reemplazo total del sistema de enrutamiento de Internet.
Los algoritmos de control de congestión de TCP monitorean señales como el tiempo de ida y vuelta (round-trip time) y la pérdida de paquetes, y luego ajustan la velocidad a la que un emisor transmite datos. Ese bucle de retroalimentación funciona mejor cuando los cambios en la latencia o en la pérdida indican que una ruta de red fija se está congestionando.
Una conexión Starlink se comporta de manera diferente. Los satélites se mueven en relación con los usuarios, los terminales transfieren el tráfico entre satélites, el ancho de banda disponible cambia y las rutas de red pueden variar. Las condiciones meteorológicas y de radio también pueden provocar pérdidas que tienen poco que ver con un enrutador sobrecargado. Un algoritmo convencional puede responder reduciendo su tasa de envío incluso cuando todavía hay capacidad disponible.
Los investigadores han medido la brecha de rendimiento resultante. Un estudio de 2025 sobre 14 variantes de control de congestión de TCP en Linux encontró que los algoritmos BBR de Google superaron a Cubic, un valor predeterminado común en Linux, en conexiones Starlink. Los investigadores observaron que Cubic tuvo un desempeño particularmente pobre en flujos individuales y concluyeron que los cambios dentro de Starlink durante 2023 y 2024 probablemente redujeron aún más su rendimiento.
Otros trabajos han identificado las transferencias periódicas entre satélites como otra fuente de picos de latencia y pérdida de paquetes. Esos eventos pueden desencadenar el mismo comportamiento defensivo que protege a las redes terrestres de la congestión genuina, ralentizando las descargas y degradando las aplicaciones interactivas.
El enfoque desde cero de Knecht podría incorporar información que los protocolos actuales de extremo a extremo no poseen. Starlink podría exponer señales sobre las transferencias, las condiciones de los enlaces de radio o los cambios de ruta. Cloudflare podría usar esas señales para regular el tráfico desde sus servidores de borde en lugar de esperar a que la pérdida de paquetes revele que la conexión cambió.
Una relación existente se adentra más en la pila
Cloudflare y SpaceX ya han explorado formas de mejorar Starlink más cerca del suelo. The Information informó en agosto de 2023 que las empresas estaban trabajando para ampliar los puntos de presencia terrestres de Starlink, las instalaciones donde el tráfico satelital entra a la Internet más amplia.
Ese trabajo se enfocó en la proximidad física y la topología de la red. La nueva propuesta de Knecht se adentra más en la pila de software al cambiar cómo los extremos deciden cuándo y qué tan rápido enviar paquetes.
La distinción importa. Un estudio de medición de 2026 sobre Starlink y redes de entrega de contenido encontró que mover los puntos de presencia más cerca de los usuarios redujo los tiempos medianos de obtención de páginas en un 60% en las regiones estudiadas. Un mejor control del transporte podría atacar otra fuente de demora después de que el tráfico llegue a la ubicación correcta.
La base potencial de despliegue es grande. un prospecto de SpaceX dijo que Starlink tenía aproximadamente 10.3 millones de clientes al 31 de marzo de 2026. Cloudflare midió por separado un incremento de 2.3 veces en el tráfico de solicitudes globales desde Starlink durante 2025, incluido un crecimiento rápido después de que el servicio se abriera en nuevos mercados, según su revisión del tráfico de Internet 2025.
El despliegue determinará el alcance
Un protocolo usado solo entre la infraestructura de Starlink y Cloudflare podría mejorar el tráfico servido a través de Cloudflare mientras deja sin cambios las conexiones con otras redes. Una especificación pública o un esfuerzo en la vía de estándares podría alcanzar a Internet en general, aunque su adopción requeriría soporte de sistemas operativos, navegadores, proveedores de servidores o desarrolladores de aplicaciones.
También existe un camino más estrecho. Cloudflare podría adaptar QUIC o construir un controlador de congestión especializado sin reemplazar las aplicaciones que están por encima. Eso haría que la experimentación fuera más rápida y preservaría la compatibilidad con la web existente, a la vez que daría a Starlink una forma de proporcionar retroalimentación explícita de la red.
La respuesta de Musk le da a la propuesta un patrocinador interno en Starlink. La prueba de ingeniería es si Cloudflare y Starlink pueden convertir el conocimiento del movimiento satelital en ganancias medibles sin crear un protocolo que funcione solo dentro de las redes de dos empresas.