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

• Le laboratoire SPEAR construit des systèmes réels et effectue des mesures pour combler les lacunes de performance dans l'informatique en périphérie et les protocoles Internet modernes.
• Les réseaux satellitaires LEO souffrent d'une mauvaise distribution de contenu lorsqu'ils manquent d'infrastructure terrestre locale et de coordination intégrée DNS/CDN.
• Les mesures Internet révèlent que le déploiement réel de protocoles comme Multipath TCP reste limité en raison de l'incompatibilité des middleboxes.

Alors que l'informatique en périphérie et la connectivité par satellite redéfinissent l'Internet, des chercheurs comme Dr Nitinder Mohan repensent les performances des réseaux dans le monde réel. Dr Mohan est professeur adjoint au Département de génie électrique, de mathématiques et d'informatique de la Université de technologie de Delft. Il dirige le laboratoire Systems and Protocols for Edge-Enabled Internet (SPEAR), où ses recherches portent sur l'informatique en périphérie, les protocoles réseau de nouvelle génération, les mesures à l'échelle d'Internet, et le déploiement et la gestion d'applications critiques. Fort d'une expérience en recherche académique et appliquée sur les systèmes, les travaux du Dr Mohan comblent le fossé entre la recherche universitaire et les réalités opérationnelles de l'Internet d'aujourd'hui et de demain.

Q1. En tant que responsable du laboratoire SPEAR, pourriez-vous présenter brièvement ses principaux domaines d'intérêt, notamment en informatique en périphérie ? Selon vous, quel est le plus grand défi actuel ?

Mohan: Je dirige le laboratoire Systems and Protocols for Edge-Enabled Internet, ou laboratoire SPEAR. Bien que le laboratoire lui-même soit relativement nouveau, la recherche qui le sous-tend est en cours depuis que j'ai terminé mon doctorat. Nos travaux se situent à l'intersection des systèmes d'informatique en périphérie et des mesures à grande échelle d'Internet. Voir aussi: Registre des membres disparaissant de l'AfriNIC.

La motivation principale du laboratoire est de comprendre et de traiter la convergence naissante entre l'informatique en nuage traditionnelle et les technologies Internet. Bien que cette convergence soit en cours sur le plan conceptuel, nous observons encore une nette séparation entre les communautés travaillant sur les systèmes en nuage et celles axées sur l'infrastructure Internet. Cet écart devient plus évident à mesure que les ressources informatiques se rapprochent des utilisateurs finaux. Ces dernières années, les serveurs de calcul ne se trouvent plus seulement dans des centres de données éloignés. Ils sont de plus en plus déployés au sein des réseaux des FAI, directement à la périphérie. Voir aussi: AfriNIC: disparition du registre des membres.

Parallèlement, l'Internet lui-même évolue. Il n'est plus simplement un outil pour connecter les utilisateurs à des serveurs distants. Il inclut désormais des éléments intermédiaires, comme les middleboxes, qui peuvent effectuer des calculs pendant que les données sont encore en transit. Cette évolution devient particulièrement importante lorsque l'on pense à de nouvelles applications comme le cloud gaming, la réalité augmentée et la réalité virtuelle. Ces applications exigent une latence extrêmement faible et ne peuvent plus s'appuyer sur les modèles traditionnels où tout le traitement a lieu à un emplacement central. Au contraire, elles nécessitent que le calcul se fasse beaucoup plus près de l'utilisateur, voire le long du chemin réseau lui-même. Voir aussi: Alejandro Fernandez.

Ce changement crée un défi évident. Il existe un décalage croissant entre les exigences des applications modernes et les capacités de l'infrastructure réseau actuelle. Au laboratoire SPEAR, nous abordons ce problème en construisant des systèmes réels qui prennent en charge l'informatique en périphérie, avec un accent particulier sur l'orchestration. Parallèlement, nous effectuons des mesures à l'échelle d'Internet pour mieux comprendre le comportement du réseau en pratique. Nous étudions les performances des protocoles de transport, des FAI et des applications à grande échelle. Voir aussi: Aldo Garcia.

C'est essentiellement un cycle: nous construisons des systèmes, mesurons leurs performances, puis améliorons ces systèmes en fonction de ce que nous apprenons. Voir aussi: Alcymer Vieira.

Dr Nitinder Mohan, professeur adjoint à l'Université de technologie de Delft

Nous utilisons les résultats de ces mesures pour améliorer les systèmes que nous concevons. C'est un cycle continu. Nous construisons des systèmes, observons leurs performances sur Internet et utilisons ces informations pour les rendre plus efficaces dans des environnements réels. Voir aussi: Alcides Cremonezi.

À lire également: Informatique en périphérie vs cloud computing: quelle différence ?

À lire également: Deutsche Telekom crée une unité de cloud souverain

Q2. Vous avez mentionné que les protocoles traditionnels comme TCP rencontrent des difficultés dans les environnements modernes. Dans le contexte des réseaux satellitaires LEO, quels sont selon vous les écarts de performance les plus critiques ?

Mohan: Avant d'aborder les défis liés au protocole de contrôle de transmission (TCP), il est utile d'expliquer d'abord comment fonctionne réellement l'Internet par satellite LEO. Il existe une perception courante selon laquelle ces réseaux fonctionnent entièrement dans l'espace, offrant une meilleure connectivité simplement en contournant l'infrastructure terrestre traditionnelle. L'idée est qu'une fois les satellites déployés et en orbite autour de la Terre, les utilisateurs ne dépendent plus des stations de base locales ou de l'infrastructure financée par les gouvernements. Si la couverture satellitaire est suffisamment dense, les gens supposent qu'ils devraient pouvoir accéder à Internet partout. Voir aussi: Alberto Anaya.

Cependant, nos mesures et une analyse plus approfondie montrent que cette hypothèse n'est pas exacte. En réalité, les réseaux satellitaires LEO restent très dépendants du sol. Les satellites fonctionnent essentiellement comme des stations de base mobiles. Au lieu de se connecter à une tour traditionnelle, votre appareil se connecte à un satellite, qui retransmet ensuite les données vers la Terre via des stations terrestres. De là, le trafic se dirige vers un point de présence avant d'atteindre l'Internet plus large.

Cette architecture signifie que si un opérateur de satellites ne dispose pas de suffisamment de stations terrestres ou de points de présence bien répartis, les performances globales du réseau seront médiocres. Nous l'avons observé au début de l'expansion de Starlink. Même s'ils avaient lancé un grand nombre de satellites, les utilisateurs dans des régions comme l'Afrique et l'Asie ont continué à connaître une connectivité médiocre. La raison principale était le manque d'infrastructure terrestre locale. Pour améliorer cela, Starlink a dû investir considérablement dans l'obtention de licences, le déploiement de nouvelles stations terrestres et la mise en place d'accords de peering dans ces régions pour réduire la latence et améliorer les performances globales.

À lire également: Starlink reçoit un avertissement du régulateur australien

Nous voyons maintenant plus d'opérateurs LEO entrer dans le secteur. Des entreprises comme OneWeb et Kuiper se préparent également à lancer de nombreux satellites. À mesure qu'elles se développeront, nous nous attendons à voir une large gamme d'approches et de résultats de performance différents. Alors que les réseaux terrestres continuent de prendre en charge la connectivité mobile et par fibre, les réseaux satellitaires se positionnent comme une option plus accessible ou résiliente dans les zones reculées ou mal desservies. Dans les coulisses, cependant, les deux systèmes reposent sur une infrastructure de backhaul similaire.

Leur mode de fonctionnement est cependant assez différent. Les liaisons satellitaires ont leurs propres caractéristiques. Elles impliquent des transferts plus fréquents, une latence variable et des schémas de débit différents par rapport aux réseaux traditionnels. Cette variabilité rend difficile le bon fonctionnement de protocoles comme TCP, car TCP a été conçu à l'origine pour des connexions stables et prévisibles.

Par exemple, si vous regardez les performances de Starlink dans des régions comme les États-Unis ou l'Europe, vous pourriez voir une latence de l'ordre de 30 à 40 millisecondes. Mais dans les régions où l'infrastructure terrestre est encore en développement, comme certaines parties de l'Afrique, la latence peut être beaucoup plus irrégulière. Cela est dû en grande partie à la capacité limitée des stations terrestres et à la nécessité de basculer fréquemment entre les satellites pendant la transmission.

Les protocoles de transport et de routage existants ne fonctionnent tout simplement pas bien dans les réseaux satellitaires LEO.

Dr Nitinder Mohan, professeur adjoint à l'Université de technologie de Delft

Les protocoles de transport et de routage traditionnels ne s'adaptent pas bien à ces conditions. Par conséquent, les performances en pâtissent. Pour surmonter cela, nous avons besoin de meilleures méthodes d'intégration des réseaux terrestres et satellitaires. Ce n'est qu'en permettant à ces systèmes de coopérer plus efficacement que nous pourrons construire un réseau offrant des performances cohérentes dans différentes régions et cas d'utilisation.

À lire également: Skynopy lève 16 millions de dollars pour son réseau de stations terrestres satellitaires

Q3. Quelles sont les premières conclusions ou directions prometteuses de vos recherches sur l'intégration des réseaux satellitaires LEO aux opérations Internet existantes ?

Mohan: Une chose que nous avons observée est qu'il existe un décalage entre la manière dont les opérateurs de satellites LEO présentent les performances de leur réseau et la façon dont cela affecte réellement l'expérience utilisateur de bout en bout. La plupart des opérateurs ont tendance à ne présenter les chiffres de latence que jusqu'au point de présence le plus proche. Par exemple, sur le site Web de Starlink, vous verrez des cartes joliment illustrées montrant des latences d'environ 30 millisecondes dans divers pays. En apparence, on dirait que le réseau fonctionne bien.

Cependant, ces chiffres ne reflètent que le temps nécessaire pour atteindre le point de présence, et non la destination réelle du trafic de l'utilisateur. En pratique, le chemin complet jusqu'au serveur d'application peut être beaucoup plus long et complexe. C'est un point que nous étudions de près au laboratoire SPEAR, où nous cherchons à comprendre comment optimiser les performances applicatives de bout en bout, et pas seulement le premier saut.

Prenez la diffusion de contenu comme exemple. Imaginez un utilisateur au Nigeria utilisant une connexion satellite LEO. Si l'opérateur n'a pas investi dans l'infrastructure terrestre dans cette région, le trafic de l'utilisateur peut être acheminé via des liaisons inter-satellites vers la station terrestre disponible la plus proche, qui peut se trouver en Europe. De là, il sort du réseau satellitaire dans une ville comme Francfort. Mais si le contenu demandé est hébergé localement au Nigeria, le trafic revient ensuite par les réseaux terrestres pour atteindre le serveur local.

Une fois le contenu récupéré, il emprunte le même itinéraire inefficace en sens inverse — retour à Francfort, puis via la liaison satellite jusqu'à l'utilisateur.

Ce processus ajoute des délais inutiles et crée une mauvaise expérience utilisateur. Il met également en évidence un problème plus profond. Notre infrastructure Internet actuelle repose sur des hypothèses de proximité géographique et de routage qui ne s'appliquent plus dans les contextes satellitaires. Des systèmes comme la résolution DNS et les réseaux de diffusion de contenu sont conçus pour des environnements terrestres, où il est relativement simple de déterminer où se trouve un utilisateur et de servir le contenu en conséquence.

Les réseaux LEO perturbent ce modèle. Le trafic d'un utilisateur peut sembler provenir d'une région complètement différente, selon l'endroit où le satellite se connecte au sol. Cela rend difficile la diffusion efficace du contenu ou le placement approprié des services de calcul.

À mesure que la localisation des utilisateurs devient moins prévisible, fournir des performances cohérentes nécessite une intégration plus étroite entre l'infrastructure spatiale et terrestre.

Dr Nitinder Mohan, professeur adjoint à l'Université de technologie de Delft

Pour résoudre ce problème, nous avons besoin d'une meilleure intégration entre les systèmes satellitaires et terrestres. Cela implique d'exposer davantage l'infrastructure terrestre — comme les nœuds CDN et les ressources d'informatique en périphérie — aux opérateurs de satellites LEO. Avec une meilleure coordination, nous pouvons créer des mappages plus précis entre les utilisateurs, le contenu et les services de calcul, ce qui contribuera à offrir des expériences plus rapides et plus cohérentes dans différentes zones géographiques.

À lire également: Intelsat voit l'avenir dans l'intégration satellite-terrestre

Q4. Vous travaillez également sur des mesures Internet à grande échelle. Vos résultats ont-ils déjà contredit les hypothèses courantes sur le comportement de l'Internet ou de ses protocoles en pratique ?

Mohan: Oui, et c'est l'une des principales motivations de nos travaux de mesure. Il existe de nombreuses hypothèses sur la façon dont les protocoles ou les technologies Internet devraient se comporter, mais lorsque nous testons ces hypothèses à grande échelle, la réalité s'avère souvent très différente.

Un exemple clair est venu de nos premiers travaux sur l'informatique en périphérie, qui ont finalement été publiés à HotNets 2020. À l'époque, on parlait beaucoup de la façon dont l'informatique en périphérie réduirait la latence. Beaucoup pensaient que placer le calcul plus près de l'utilisateur conduirait automatiquement à des temps de réponse beaucoup plus rapides. Pour tester cela, nous avons effectué des mesures à grande échelle auprès de sept grands fournisseurs de cloud. Nous avons cartographié les connexions des utilisateurs du monde entier, sur les réseaux cellulaires, Wi-Fi et fibre, jusqu'à leurs centres de données les plus proches. L'idée était de voir quel type de latence les utilisateurs subissaient et si le fait de rapprocher le calcul ferait une différence significative.

Ce que nous avons constaté, c'est que la majeure partie de la latence provenait du réseau d'accès, comme la connexion cellulaire ou Wi-Fi de l'utilisateur. Une fois que le trafic atteignait le backhaul, la latence vers les centres de données cloud était déjà assez faible. Dans des régions comme l'Europe et les États-Unis, les fournisseurs de cloud s'interconnectent directement avec les grands FAI, il n'y a donc pas beaucoup de marge d'amélioration. Si votre objectif avec l'informatique en périphérie est uniquement de réduire la latence, ce n'est probablement pas la bonne raison.

Au lieu de cela, l'informatique en périphérie est mieux adaptée pour améliorer les performances des applications ou construire des systèmes distribués. Cette compréhension est maintenant plus largement acceptée.

Un autre exemple est notre travail sur Multipath TCP, un protocole qui permet aux appareils d'utiliser le Wi-Fi et les données mobiles en même temps. Il a été normalisé en 2020, mais nous avons constaté que son adoption était très limitée. De nombreux middleboxes sur Internet ne reconnaissent pas les en-têtes du protocole et bloquent les connexions ou répondent de manière incorrecte. Certains envoient même de faux accusés de réception, ce qui peut créer des risques de sécurité. En pratique, seul un petit nombre de fournisseurs l'utilisaient, et la majeure partie du déploiement provenait d'Apple. Depuis qu'Apple s'en est éloigné, l'utilisation a diminué. Nous avons ouvert toutes nos données de mesure sur mptcp.io afin que les gens puissent voir comment l'adoption a évolué. Cela montre que la normalisation ne suffit pas. Un protocole a également besoin de compatibilité sur l'ensemble d'Internet pour être utilisable en pratique.