1969 ms vers Rarotonga : une semaine de congestion sur le câble Manatua

Tôt dans la matinée du 11 avril 2026, une seule réponse ICMP de Rarotonga a mis 1968 millisecondes pour atteindre notre serveur à Minsk. À quatre heures du matin le même jour, la même réponse est arrivée en 443. À quatorze heures, le réseau était revenu à sa ligne de base ennuyeuse de 440 ms et faisait semblant que rien ne s'était passé.

Ce n'était pas un incident isolé. Pendant huit jours, cinq de nos sondes de mesure — à Minsk, Tbilissi, Jérusalem, Sébastopol et Almaty — ont regardé la liaison vers les îles Cook se dégrader par vagues. Notre moniteur de câble, pendant ce temps, a signalé le câble Manatua — l'unique liaison sous-marine qui dessert les quinze îles — en bonne santé tout le long. Ces deux choses sont vraies en même temps, et cet article explique ce que cela signifie.

Ce que nous avons mesuré

Toutes les quatre-vingt-dix minutes, chacune de nos sondes effectue un traceroute complet vers une seule adresse IP : 202.90.64.1, un routeur périphérique à l'intérieur du réseau de Telecom Cook Islands, à la frontière du réseau national. Au cours des vingt jours précédant le 3 avril, le temps d'aller-retour de base depuis l'Europe ou le Caucase vers cette adresse était de 430 à 490 millisecondes, stable à quelques millisecondes de gigue près. C'est la réalité physique du routage d'un paquet IP de Minsk vers une petite île du Pacifique : Europe → transit GTT à travers l'Atlantique → Los Angeles → Papeete sur la chaîne des câbles Honotua et Manatua → dernière étape à l'intérieur du réseau abonné des îles Cook. Environ 450 ms, aller-retour, à chaque fois.

Puis la queue de distribution s'est épaissie.

Le premier pic que nous avons enregistré était le 3 avril, lorsqu'une mesure depuis Tbilissi est revenue à 973 ms au lieu des 440 habituels. Une curiosité. Quatre jours plus tard, le 7 avril, trois pics sont apparus dans la même fenêtre du soir, l'un d'eux atteignant 1928 ms depuis Jérusalem. Le 8 avril, un quatrième pic avec quatre timeouts groupés en fin d'après-midi. Puis trois jours calmes — les 9 et 10 avril ressemblaient exactement à la ligne de base. Et puis est arrivé le 11 avril.

11 avril, heure par heure

Huit jours de dégradation progressive de la latence de queue compressés dans une seule journée. Le pire est venu dans deux fenêtres de tempête — une au milieu de la nuit, une autre vers sept heures du matin UTC — et entre les deux, le réseau semblait parfaitement normal.

Toutes les valeurs sont des millisecondes d'aller-retour vers 202.90.64.1. Les valeurs supérieures à 800 ms sont en gras. Cinq sondes dans cinq pays différents, et pendant les fenêtres de pic quatre d'entre elles se sont simultanément accordées à dire que quelque chose n'allait pas. Cela exclut un problème local à une sonde — ce n'est pas notre serveur de Minsk qui a une mauvaise matinée, ce n'est pas un flap d'un FAI tbilissien. La seule façon pour que quatre sondes eurasiennes s'accordent en même temps, c'est que le problème se trouve quelque part après leur premier saut commun — et ce saut commun est à quinze mille kilomètres et un câble sous-marin d'ici.

Almaty présente un schéma différent — huit timeouts sur quatorze mesures au cours de la journée, mais pas de pics. Elle a un problème léger de joignabilité ICMP vers cette cible particulière depuis environ une semaine, que nous traitons comme un problème séparé et excluons mentalement de l'analyse des pics.

Même route, latence différente

Le traceroute le plus utile que nous ayons capturé est celui derrière ce chiffre de 1969 ms. Voici à quoi il ressemble — et voici à quoi ressemblait la même sonde vingt heures plus tôt, un jour tranquille.

10 avril, Minsk → îles Cook — 466 ms (ligne de base)

11 avril, 02h59 UTC, Minsk → îles Cook — 1969 ms (pic)

Jusqu'au saut 11, les deux traceroutes sont presque indiscernables. Le chemin est légèrement différent — RETN a choisi une entrée tallinnoise pour l'un et une entrée moscovite pour l'autre — mais le profil de latence est identique : Minsk → Vienne → Los Angeles → Papeete, arrivant à 302 millisecondes un bon jour et 304 millisecondes un mauvais jour. Si le transit Manatua lui-même s'était dégradé, ou si la dorsale Pacifique de GTT avait ralenti, on le verrait ici. On ne le voit pas. Le transit du câble était normal les deux jours.

La divergence se produit après Papeete. Le jour normal, trois sauts intermédiaires ne répondent pas et la cible répond à 454 ms — un propre +150 ms pour le dernier segment, ce qui correspond à peu près à ce qu'on attend pour la liaison fibre Papeete → Rarotonga plus quelques équipements de réseau abonné. Le mauvais jour, sept sauts intermédiaires gardent le silence et la cible répond à 1969 ms — une queue de +1665 ms sans aucune distance physique à blâmer. Même IP, même câble, même transit, même dernier saut. Jour différent.

Pour confirmer que ce n'est pas une histoire propre à Minsk, voici le pic de Jérusalem du 7 avril à 21h00 UTC, 1928 ms :

Pays d'origine différent, FAI eurasien différent, dorsale de transit différente (Arelion au lieu de RETN vers LA). Même signature. La queue vit quelque part entre Papeete et la cible finale, et elle n'est pas faite de fibre.

Où vivent 1650 ms de latence quand elles ne sont pas faites de distance ?

La distance physique de Papeete à Rarotonga par le câble Manatua est d'environ 1 150 kilomètres. La lumière voyage dans la fibre optique à environ 200 000 kilomètres par seconde — deux tiers de la vitesse de la lumière dans le vide, à cause de l'indice de réfraction de la fibre. Un trajet aller du photon sur 1 150 km prend 5,75 ms, aller-retour 11,5 ms. Ajoutez le traitement des routeurs à chaque extrémité, un peu de mise en file d'attente un jour calme, et on obtient les 150 ms que nous avons effectivement vus le 10 avril entre Papeete et la cible — bien dans la surcharge normale pour un réseau de petite île, où la dorsale locale est construite avec des commutateurs commodity et où la liaison agrégée vers le monde extérieur n'est pas à 400 Gbit/s.

Ce que la physique ne peut pas expliquer, c'est 1665 ms. C'est presque cent fois le budget de vitesse de la lumière pour le même chemin. Aucune fibre sur Terre n'est assez lente pour produire ça. Ce n'est pas de la distance. Ce n'est pas une coupure de câble. C'est de la mise en file d'attente.

Le terme de manuel est bufferbloat. Quand une liaison réseau sature — parce que trop de trafic, pas assez de capacité, ou les deux — les paquets ne sont pas perdus. Ils attendent dans la file de sortie du routeur leur tour sur le fil. Si la file est grande (un ou deux mégaoctets, ce qui est parfaitement ordinaire sur du matériel commodity) et si la liaison est lente (quelques centaines de mégabits, disons), un paquet arrivant au fond d'une file pleine peut y rester une seconde et demie avant d'être transmis. Il finit par arriver, indemne. Ça a juste pris une éternité. Le contrôle de congestion de TCP n'a pas été conçu pour ça : il réagit aux pertes, pas aux délais, alors il ne ralentit jamais efficacement — et la file reste pleine. La latence s'effondre dans un brouillard qui se renforce lui-même.

Le 11 avril, la file s'est remplie deux fois. Une fois vers 01h00 UTC et une autre vers 07h00 UTC. Entre les deux tempêtes, le trafic s'est écoulé et nos mesures sont revenues à la ligne de base. À 10h00, la queue avait disparu. Si la tendance sur une semaine continue — et un pic isolé, suivi d'un groupe de trois pics, suivi d'un mur de dix pics est une tendance — on devrait s'attendre à une autre fenêtre le 12 avril, et une autre le 13.

Et pendant ce temps, le câble est en bonne santé

Notre système de surveillance des câbles vérifie la santé de Manatua indépendamment. Toutes les quelques heures, il ping un endpoint au point d'atterrissage directement à travers le câble et enregistre l'aller-retour et un ratio par rapport à la ligne de base. Voici la même fenêtre temporelle, de son point de vue :

SELECT * FROM cable_alerts WHERE cable_id='manatua' a retourné zéro lignes sur toute la fenêtre. Nous n'avons pas émis un seul avertissement concernant le câble Manatua pendant aucune des périodes de pic. Et nous avions raison de ne pas le faire, au sens littéral : le câble transmettait les paquets très bien, à presque exactement la même vitesse qu'hier. Le problème était ailleurs.

C'est l'écart qui mérite d'être nommé. Quand la surveillance au niveau du câble ping un endpoint au point d'atterrissage, elle teste la fibre et le routeur périphérique de l'autre côté. Elle ne teste pas la dorsale de l'opérateur, ni l'arrangement de peering amont, ni l'équipement d'accès abonné, ni la politique QoS, ni le buffer d'interface qui peut être quatre fois plus grand qu'il ne devrait l'être. Dans de nombreux réseaux en bonne santé, bien conçus, rien de tout cela n'a d'importance — le câble sous-marin est la partie la plus étroite et la plus souvent défaillante du chemin, donc le tester est un proxy équitable pour l'ensemble. Sur une île à câble unique, ce n'est pas le cas. Tout ce qui se trouve entre Papeete et un utilisateur à Rarotonga est le backhaul d'un petit opérateur, et ce backhaul est invisible pour un test de ping qui s'arrête au bord du câble.

Les îles Cook, en chiffres

Quinze îles, environ 17 500 habitants, la plupart sur Rarotonga. Un câble sous-marin — Manatua, 3 634 kilomètres, en service depuis 2020, avec des atterrissages à Rarotonga et Aitutaki, puis continuant vers Niue, Samoa, Bora Bora et Papeete. Avant Manatua, la connectivité internationale du pays était assurée par le satellite O3b, qui dans un bon jour signifiait environ 700 ms de latence et dans un mauvais jour plusieurs multiples de cela. Un opérateur national, Telecom Cook Islands, qui en pratique signifie le seul /24 vers lequel nous pointons nos traceroutes. Une relation de transit amont, visible dans chacun de nos traceroutes : AS9471 Onati, basé à Papeete.

Il n'y a pas de chemin alternatif. Si Manatua tombe, les îles Cook retournent au satellite. Si Telecom Cook Islands mal configure une file d'attente sur son uplink, quelques mégaoctets de paquets s'accumulent en une heure et y restent jusqu'au matin. Il n'y a pas de deuxième fournisseur pour contourner, pas de dorsale concurrente vers laquelle basculer. Voilà à quoi ressemblent les points de défaillance unique en pratique en 2026.

Rien de tout cela n'est une critique de l'opérateur. Faire fonctionner un FAI national pour 17 000 abonnés répartis sur quinze îles est un véritable exploit d'ingénierie, et Manatua a été l'événement infrastructurel le plus important de l'histoire moderne des îles Cook. C'est la réalité du réseautage sur les petites îles. Quand les choses tournent mal, elles tournent mal au point où il n'y a pas de redondance — parce que c'est là qu'il n'y a pas de redondance.

Ce que cela dit sur la façon dont nous surveillons les câbles

Nous n'avons pas attrapé cette semaine. Notre propre système, la surveillance de la santé des câbles, avait Manatua sur une carte de score propre tout le temps. Il nous disait que le câble était en bonne santé et il nous disait la vérité. Ce n'était simplement pas la bonne question.

La bonne question, pour un pays insulaire à câble unique, n'est pas « le câble transmet-il des paquets » mais « un paquet peut-il atteindre un endpoint côté abonné depuis le monde extérieur et revenir dans un délai raisonnable ». Ce sont des mesures différentes avec des modes de défaillance différents, et l'écart entre elles est précisément là où vit un incident comme celui de cette semaine. Une stratégie de surveillance appropriée pour le Pacifique a besoin des deux : santé au niveau du câble, que nous avons, et santé d'endpoint au niveau du pays, que nous n'avons pas encore à la résolution qu'un tel schéma exige.

Nous allons corriger cela. Les petits pays insulaires avec un seul opérateur commercial — îles Cook, Niue, Tokelau, Tuvalu, Nauru, Kiribati et une poignée d'autres — méritent leur propre voie de surveillance au niveau d'endpoint, parce qu'ils ont des modes de défaillance que leurs câbles ne peuvent pas exprimer. Si nous l'avions eue il y a deux semaines, nous aurions signalé l'écart du 3 avril, le groupe du 7 avril et la fenêtre du 8 avril comme une tendance en construction, et nous serions entrés dans le 11 avril en l'attendant au lieu de le découvrir dans le rapport du matin.

Qu'est-ce qui cause cela, en fait ?

Honnêtement — nous ne savons pas.

Ce que nous pouvons voir de l'extérieur : le câble Manatua est en bonne santé, le transit GTT de l'Europe vers Papeete est en bonne santé, le problème est quelque part après le saut 11 à l'intérieur du réseau Onati et Telecom Cook Islands, et il se manifeste comme un schéma de délai de file d'attente cohérent avec du bufferbloat sur une liaison saturée. Ce que nous ne pouvons pas voir : si cette saturation est un problème de planification de capacité (les abonnés ont finalement dépassé l'uplink), une dégradation partielle de la fibre sur le segment Pacifique qui a divisé la bande passante effective par deux, un changement de routage qui a envoyé plus de trafic dans un tuyau, un buffer d'interface mal configuré, un différend de peering, ou tout autre chose. Ce sont des questions auxquelles on ne peut répondre que de l'intérieur du réseau de l'opérateur, et nous ne sommes pas à l'intérieur.

Ce que nous pouvons dire avec certitude, c'est que ça empire. Un pic le 3 avril. Trois le 7. Dix le 11. Chaque vague plus grande que la précédente ; chaque grand pic plus proche du plafond des 2 000 ms où TCP lui-même commence à s'effondrer. Si la tendance se maintient — et huit jours de données, quatre fenêtres de pic, et une séquence ordonnée, c'est une tendance — notre prochaine publication sera sur le 13 ou le 14 avril, pas seulement sur le 11.

Essayez vous-même

Nous publions des mesures en direct vers cette cible sur la page du moniteur de route — elle se met à jour à mesure que de nouveaux traceroutes arrivent, et si le schéma que nous avons décrit ici se poursuit, le graphique le montrera. Vous pouvez aussi lire l'histoire de base qui a préparé ces mesures : comment un aller-retour propre vers les îles Cook arrive à 462 ms en premier lieu. Et le câble lui-même a sa propre page : Manatua, les 3 634 km de dorsale Pacifique qui, depuis 2020, sont la seule liaison fibre entre les îles Cook et le reste du monde.

Nous ferons un suivi avec ce que les 12 et 13 avril apporteront.