Interview with Dr Nitinder Mohan: Edge, satellites, and the reality behind Internet performance

• El laboratorio SPEAR construye sistemas reales y realiza mediciones para abordar las brechas de rendimiento en la computación en el borde y los protocolos modernos de Internet.
• Las redes de satélites LEO sufren una mala entrega de contenido cuando carecen de infraestructura terrestre local y de una coordinación integrada de DNS/CDN.
• Las mediciones de Internet revelan que el despliegue en el mundo real de protocolos como Multipath TCP sigue siendo limitado debido a la incompatibilidad con los middleboxes.

A medida que la computación en el borde y la conectividad satelital transforman Internet, investigadores como el Dr. Nitinder Mohan están repensando cómo funcionan las redes en el mundo real. El Dr. Mohan es profesor asistente en el Departamento de Ingeniería Eléctrica, Matemáticas y Ciencias de la Computación de la Universidad Tecnológica de Delft. Dirige el laboratorio Systems and Protocols for Edge-Enabled Internet (SPEAR), donde su investigación se centra en la computación en el borde, los protocolos de red de próxima generación, las mediciones a escala de Internet y el despliegue y gestión de aplicaciones críticas. Con una formación tanto en investigación académica como en sistemas aplicados, el trabajo del Dr. Mohan tiende un puente entre la investigación académica y las realidades operativas de la Internet actual y futura.

P1. Usted dirige el laboratorio SPEAR, ¿podría presentar brevemente sus áreas de enfoque principales, particularmente en computación en el borde? ¿Cuál diría que es el mayor desafío en este momento?

Mohan: Dirijo el laboratorio de Sistemas y Protocolos para Internet Habilitada en el Borde, o laboratorio SPEAR. Aunque el laboratorio en sí es relativamente nuevo, la investigación que lo sustenta ha estado en marcha desde que terminé mi doctorado. Nuestro trabajo se sitúa en la intersección de los sistemas de computación en el borde y las mediciones a gran escala de Internet. Ver también: El registro de miembros desaparecido de AfriNIC.

La motivación principal del laboratorio es comprender y abordar cómo la computación en la nube tradicional y las tecnologías de Internet están comenzando a converger. Aunque esta convergencia está ocurriendo en concepto, todavía observamos una clara división entre las comunidades que trabajan en sistemas en la nube y aquellas centradas en la infraestructura de Internet. Esta brecha se hace más evidente a medida que vemos que los recursos informáticos se acercan a los usuarios finales. En los últimos años, los servidores de cómputo ya no se encuentran solo en centros de datos distantes. Cada vez más, se despliegan dentro de las redes de los ISP, justo en el borde. Ver también: Desaparición del registro de miembros de AfriNIC.

Al mismo tiempo, la propia Internet está evolucionando. Ya no es simplemente una herramienta para conectar a los usuarios con servidores remotos. Ahora incluye elementos intermedios, como los middleboxes, que pueden realizar cálculos mientras los datos están en tránsito. Esta evolución se vuelve especialmente importante cuando pensamos en nuevas aplicaciones como los juegos en la nube, la realidad aumentada y la realidad virtual. Estas aplicaciones requieren una latencia extremadamente baja y ya no pueden depender de modelos tradicionales en los que todo el procesamiento se realiza en una ubicación central. En cambio, exigen que el cómputo se realice mucho más cerca del usuario, posiblemente incluso a lo largo de la propia ruta de red. Ver también: Alejandro Fernandez.

Este cambio crea un desafío claro. Existe un desajuste creciente entre las demandas de las aplicaciones modernas y las capacidades de la infraestructura de red actual. En el laboratorio SPEAR, abordamos esto construyendo sistemas reales que soportan la computación en el borde, con un enfoque particular en la orquestación. Junto a esto, realizamos mediciones a escala de Internet para comprender mejor cómo se comporta la red en la práctica. Estudiamos el rendimiento de los protocolos de transporte, el rendimiento de los ISP y el rendimiento de las aplicaciones a gran escala. Ver también: Aldo Garcia.

Es esencialmente un ciclo: construimos sistemas, medimos su rendimiento y luego mejoramos esos sistemas en función de lo que aprendemos. Ver también: Alcymer Vieira.

Dr. Nitinder Mohan, profesor asistente de la Universidad Tecnológica de Delft

Utilizamos los hallazgos de estas mediciones para mejorar los sistemas que diseñamos. Es un ciclo continuo. Construimos sistemas, observamos cómo se comportan en Internet y utilizamos esos conocimientos para hacerlos más efectivos en entornos del mundo real. Ver también: Alcides Cremonezi.

Lea también: Computación en el borde vs. computación en la nube: ¿Cuál es la diferencia?

Lea también: Deutsche Telekom crea una unidad de nube soberana

P2. Mencionó que los protocolos tradicionales como TCP tienen dificultades en los entornos modernos. En el contexto de las redes de satélites LEO, ¿cuáles diría que son las brechas de rendimiento más críticas?

Mohan: Antes de abordar los desafíos con el Protocolo de Control de Transmisión (TCP), es útil explicar primero cómo funciona realmente Internet por satélite LEO. Existe la percepción común de que estas redes operan completamente en el espacio, ofreciendo una mejor conectividad simplemente al evitar la infraestructura terrestre tradicional. La idea es que una vez que los satélites están desplegados y orbitando la Tierra, los usuarios ya no dependen de estaciones base locales ni de infraestructura financiada por el gobierno. Si la cobertura de satélites es lo suficientemente densa, la gente asume que debería poder acceder a Internet desde cualquier lugar. Ver también: Alberto Anaya.

Sin embargo, nuestras mediciones y un análisis más profundo muestran que esta suposición no es precisa. En realidad, las redes de satélites LEO todavía dependen en gran medida de la tierra. Los satélites funcionan esencialmente como estaciones base móviles. En lugar de conectarse a una torre tradicional, su dispositivo se conecta a un satélite, que luego transmite los datos de vuelta a la Tierra a través de estaciones terrestres. Desde allí, el tráfico viaja a un Punto de Presencia antes de llegar a la Internet más amplia.

Esta arquitectura significa que si un operador de satélites no tiene suficientes estaciones terrestres o Puntos de Presencia bien distribuidos, el rendimiento general de la red será deficiente. Observamos esto en las primeras etapas de la expansión de Starlink. Aunque habían lanzado una gran cantidad de satélites, los usuarios en regiones como África y Asia todavía experimentaban una conectividad deficiente. La razón principal fue la falta de infraestructura terrestre local. Para mejorar esto, Starlink tuvo que invertir significativamente en la obtención de licencias, el despliegue de nuevas estaciones terrestres y la construcción de acuerdos de peering en esas regiones para reducir la latencia y mejorar el rendimiento general.

Lea también: Starlink recibe advertencia del organismo de control australiano

Ahora estamos viendo a más operadores LEO entrar en el espacio. Empresas como OneWeb y Kuiper también se están preparando para lanzar muchos satélites. A medida que crecen, esperamos ver una amplia gama de enfoques y resultados de rendimiento diferentes. Si bien las redes terrestres continúan soportando la conectividad móvil y por fibra, las redes de satélites se están posicionado como una opción más accesible o resistente en áreas remotas o desatendidas. Sin embargo, entre bastidores, ambos sistemas dependen de una infraestructura de backhaul similar.

Sin embargo, la forma en que operan es bastante diferente. Los enlaces satelitales tienen sus propias características. Implican traspasos más frecuentes, latencia variable y patrones de rendimiento diferentes en comparación con las redes tradicionales. Esta variabilidad dificulta que protocolos como TCP funcionen bien, porque TCP se diseñó originalmente para conexiones estables y predecibles.

Por ejemplo, si observamos el rendimiento de Starlink en regiones como Estados Unidos o Europa, podríamos ver una latencia en el rango de 30 a 40 milisegundos. Pero en regiones donde la infraestructura terrestre aún se está desarrollando, como partes de África, la latencia puede ser mucho más inconsistente. Esto se debe en gran medida a la capacidad limitada de las estaciones terrestres y a la necesidad de cambiar frecuentemente entre satélites durante la transmisión.

Los protocolos de transporte y enrutamiento existentes simplemente no funcionan bien en las redes de satélites LEO.

Dr. Nitinder Mohan, profesor asistente de la Universidad Tecnológica de Delft

Los protocolos tradicionales de transporte y enrutamiento no se adaptan bien a estas condiciones. Como resultado, el rendimiento se resiente. Para superar esto, necesitamos mejores métodos para integrar las redes terrestres y satelitales. Solo permitiendo que estos sistemas cooperen de manera más efectiva podremos construir una red que ofrezca un rendimiento consistente en diferentes regiones y casos de uso.

Lea también: Skynopy recauda 16 millones de dólares para su red de estaciones terrestres satelitales

P3. ¿Cuáles son algunos hallazgos iniciales o direcciones prometedoras de su investigación sobre la integración de redes de satélites LEO con las operaciones existentes de Internet?

Mohan: Una cosa que hemos observado es que existe una desconexión entre cómo los operadores de satélites LEO presentan el rendimiento de su red y cómo afecta realmente a la experiencia del usuario de extremo a extremo. La mayoría de los operadores tienden a mostrar cifras de latencia solo hasta el Punto de Presencia más cercano. Por ejemplo, en el sitio web de Starlink, se ven mapas bien ilustrados que muestran latencias de alrededor de 30 milisegundos en varios países. A primera vista, parece que la red está funcionando bien.

Sin embargo, esas cifras solo reflejan el tiempo que se tarda en llegar al Punto de Presencia, no al destino real del tráfico del usuario. En la práctica, la ruta completa hasta el servidor de aplicaciones puede ser mucho más larga y compleja. Esto es algo que estudiamos de cerca en el laboratorio SPEAR, donde nos interesa comprender cómo optimizar el rendimiento de las aplicaciones de extremo a extremo, no solo el primer salto.

Tomemos como ejemplo la entrega de contenido. Imaginemos a un usuario en Nigeria que utiliza una conexión de satélite LEO. Si el operador no ha invertido en infraestructura terrestre en esa región, el tráfico del usuario puede enrutarse a través de enlaces entre satélites hasta la estación terrestre disponible más cercana, que podría estar en Europa. Desde allí, sale de la red de satélites en una ciudad como Frankfurt. Pero si el contenido solicitado está alojado localmente en Nigeria, el tráfico viaja de vuelta a través de las redes terrestres para llegar al servidor local.

Una vez que se obtiene el contenido, recorre la misma ruta ineficiente en sentido inverso: de vuelta a Frankfurt y luego a través del enlace satelital hasta el usuario.

Este proceso añade retrasos innecesarios y crea una mala experiencia de usuario. También pone de relieve un problema más profundo. Nuestra infraestructura de Internet actual se basa en suposiciones sobre la proximidad geográfica y el enrutamiento que ya no se aplican en contextos basados en satélites. Sistemas como la resolución de DNS y las redes de entrega de contenido están diseñados para entornos terrestres, donde es relativamente sencillo determinar dónde se encuentra un usuario y servir el contenido en consecuencia.

Las redes LEO alteran este modelo. El tráfico de un usuario puede parecer que se origina en una región completamente diferente, dependiendo de dónde se conecte el satélite a tierra. Esto dificulta la entrega eficiente de contenido o la colocación adecuada de los servicios de cómputo.

A medida que la ubicación del usuario se vuelve menos predecible, ofrecer un rendimiento consistente requiere una integración más estrecha entre la infraestructura espacial y terrestre.

Dr. Nitinder Mohan, profesor asistente de la Universidad Tecnológica de Delft

Para abordar esto, necesitamos una mejor integración entre los sistemas satelitales y terrestres. Eso incluye exponer más de la infraestructura terrestre (como los nodos CDN y los recursos de computación en el borde) a los operadores de satélites LEO. Con una mejor coordinación, podemos crear mapeos más precisos entre usuarios, contenido y servicios de cómputo, lo que ayudará a ofrecer experiencias más rápidas y consistentes en diferentes geografías.

Lea también: Intelsat ve futuro en la integración satelital-terrestre

P4. Usted también trabaja en mediciones a gran escala de Internet. ¿Han contradicho sus resultados alguna vez las suposiciones comunes sobre cómo se comportan en la práctica Internet o sus protocolos?

Mohan: Sí, y esa es una de las principales motivaciones detrás de nuestro trabajo de medición. Existen muchas suposiciones sobre cómo deberían comportarse los protocolos o tecnologías de Internet, pero cuando probamos estas suposiciones a escala, la realidad a menudo resulta ser bastante diferente.

Un ejemplo claro provino de nuestro trabajo inicial sobre la computación en el borde, que finalmente se publicó en HotNets 2020. En ese momento, se hablaba mucho de cómo la computación en el borde reduciría la latencia. Muchos creían que colocar el cómputo más cerca del usuario conduciría automáticamente a tiempos de respuesta mucho más rápidos. Para probarlo, realizamos mediciones a gran escala en siete de los principales proveedores de nube. Mapeamos las conexiones de usuarios de todo el mundo, a través de redes celulares, Wi-Fi y fibra, hasta sus centros de datos más cercanos. La idea era ver qué tipo de latencia experimentaban los usuarios y si colocar el cómputo más cerca supondría una diferencia significativa.

Lo que descubrimos fue que la mayor parte de la latencia provenía de la red de acceso, como la conexión celular o Wi-Fi del usuario. Una vez que el tráfico llegaba al backhaul, la latencia hacia los centros de datos en la nube ya era bastante baja. En lugares como Europa y Estados Unidos, los proveedores de nube se interconectan directamente con los grandes ISP, por lo que no hay mucho margen de mejora. Si su objetivo con la computación en el borde es solo reducir la latencia, probablemente no sea la razón correcta.

En cambio, la computación en el borde es más adecuada para mejorar el rendimiento de las aplicaciones o construir sistemas distribuidos. Esa comprensión ahora es más ampliamente aceptada.

Otro ejemplo es nuestro trabajo sobre Multipath TCP, un protocolo que permite a los dispositivos usar Wi-Fi y datos móviles al mismo tiempo. Se estandarizó en 2020, pero descubrimos que su adopción era muy limitada. Muchos middleboxes en Internet no reconocen las cabeceras del protocolo y bloquean las conexiones o responden incorrectamente. Algunos incluso envían acuses de recibo falsos, lo que puede crear riesgos de seguridad. En la práctica, solo un pequeño número de proveedores lo utilizaban, y la mayor parte del despliegue provino de Apple. Desde que Apple se alejó de él, su uso ha disminuido. Publicamos todos nuestros datos de medición en código abierto en mptcp.io para que la gente pueda ver cómo ha cambiado la adopción. Esto demuestra que la estandarización no es suficiente. Un protocolo también necesita compatibilidad en toda Internet para ser utilizable en la práctica.