Vent de panique : le HLN a la fièvre !

Nous sommes en 1982 (si ma mémoire est bonne !). Le DTN est en gestation mais son développement prend du temps, mais chance et problème à la fois, le trafic augmente d’une manière vertigineuse. Le HLN assume conjointement la transmission du Type A et la commutation de messages du Type B. Nous avons alors deux types de machines HLS différentes: Univac (ensuite Unisys) Mark III (par exemple à Hong Kong) et Philips (par exemple à Londres). Les machines Philips sont plus puissantes, mais pour ces deux systèmes différents le challenge est que la commutation des messages Type B consomme beaucoup de ressources de ces machines et diminue d’autant la capacité de commutation du Type A, capacité dont nous avons alors grand besoin.
Différentes solutions sont mises en œuvre pour faire face à cet accroissement du trafic : augmentation de la vitesse et du nombre de circuits entre HLS : en augmentant le nombre de liaisons directes entre HLS nous diminuons le trafic de transit, mais cela ne suffit pas !
Une autre solution est trouvée : le dédoublement des centres HLS en système front-end et système back-end : Configuration HLS Front-end Back-end

 
Le HLS back-end effectue exclusivement la commutation des messages Type B tandis que le HLS font-end traite exclusivement le trafic Type A et le trafic de transit. Chaque système est spécialisé dans un seul type de trafic et de ce fait possède une capacité de commutation beaucoup plus grande. Cette solution fut donc mise en œuvre aussi bien dans les centres Univac que dans les centres Philips car le besoin en capacité supérieure du HLN était vraiment généralisé. Des codes différents furent bien sûr attribués au Front-end et au Back-end, par exemple LHR et LON dans le cas de Londres.
A cette époque je travaillais au Département des Etudes(EZ) dirigé par Georges Giraudbit, au sein du service de la planification technique sous la houlette d’Alfred Wyers, et avait déjà travaillé à des solutions d’augmentation de capacité du HLN, dont le « split-routing » qui permettait de scinder en deux le trafic entre HLS, lorsque la valeur de ce trafic dépassait la capacité des circuits (qui ne dépassaient que très rarement 9.6 kbps, rien à voir avec les liaisons ADSL ou WiFi, dont les capacités atteignent et dépassent allégrement les 100 Mbps et dont nous disposons maintenant à domicile ! Un autre temps !). Je travaillais au développement d’outils de calcul du réseau (outils qui porteront des noms de couturier, un clin d’œil humoristique : Dior, Cardin,Patou) et je suivais donc avec attention ce problème d’augmentation de capacité du HLN.
La solution dédoublement des HLS fut donc mise en place rapidement et donnait satisfaction. Cependant un jour survint u premier incident : au centre de Londres, au milieu de l’après-midi, la liaison Front-end / Back-end se saturait brusquement au point d’empêcher l’écoulement du trafic Type B vers le système Back-end. Curieusement cette saturation se répétait tous les jours à Londres à partir du milieu de l’après-midi. Bien sûr la première suspicion fut celle d’une erreur dans le logiciel et les équipes Philips (je me souviens en particulier de Pierre Tavard et de Gilles Dronne qui dirigeaient avec compétence ces équipes) étaient sur le pont. Mais aucune erreur n’était trouvée dans les deux systèmes de Londres et donc l’inquiétude grandissait. Témoignage de cette inquiétude un incident supplémentaire était survenu : suspectant un éventuel problème hardware dans l’interface de communication du HLS front-end, un opérateur à Londres avait envoyé depuis le Back-end un message pour désactiver cette interface du Front-end, mais cette tentative fut pire que le mal ! En effet tout message a besoin d’être acquitté (l’émetteur veut savoir que le message a été bien reçu sinon après un laps de temps il le ré-envoie, car les erreurs de transmission pouvaient survenir), or lorsque LHR avait reçu de LON la commande de désactiver son interface de communication vers LON, le système avait désactivé cette interface avant même d’acquitter la bonne réception de ce message. Et donc dès que cette interface était réactivée coté LHR, le système LON renvoyait immédiatement le message de désactivation de cette interface, car LON n’avait toujours pas reçu l’acquittement concernant ce message. Ce problème fut assez rapidement compris et je me souviens de Gilles Dronne effectuant une mission d’urgence à Londres pour « tuer » dans le système LON le message de commande de désactivation de l’interface de communication de LHR vers LON.
Ce problème réglé, la saturation de la liaison locale LON-LHR reprit de plus belle, toujours dans l’après-midi. La nervosité augmentait dans les équipes, et y compris au niveau de la Direction Technique (A Puerto était alors le Directeur Technique). Les réunions se succédaient, y compris aux Opérations, et je participais à celles organisées par Pierre Flahaut, alors en charge du service OL (On-Line) car ces saturations étaient une grave perturbation du réseau et faisaient planer le doute sur la viabilité da la solution du dédoublement des HLS en Front-end et Back-end. Ces réunions permirent de collecter un certain nombre d’informations, comme par exemple le fait que cette saturation survenait lorsque le trafic Type B de New York vers Londres amorçait son pic quotidien, à l’heure d’ouverture des bureaux à New York. Heureusement cette saturation ne se produisait pas dans les autres configurations de dédoublement, comme à Hong Kong. Des centaines de milliers de paquets Type B étaient « droppés » chaque jour sur le circuit LHR-LON. Mais la cause de cette saturation totale du circuit LHR-LON restait incomprise et ce problème prenait des proportions inquiétantes compte-tenu de l’augmentation constante du trafic sur le réseau.
Ce problème m’intriguait et me tracassait aussi car nous n’avions pas de solution de rechange avant l’arrivée du DTN. Par ailleurs Antoine Puerto m’avait également demandé de me pencher sur ce phénomène, car les équipes de programmation du HLN n’avaient trouvé aucun bug pouvant l’expliquer et permettre de le corriger. La manière dont ce manifestait ce problème me faisait vaguement penser à l’équivalent d’un problème de « pompage « que l’on rencontre parfois dans les automatismes (spécialité que j’avais étudié aux Etats-Unis avant de revenir aux télécommunications). Un exemple de ce phénomène de pompage vous est sans doute connu avec l’effet « Larsen », sifflement qui se déclenche lorsqu’on approche un micro d’un haut-parleur branché sur le même amplificateur que le micro : le son circule en boucle du haut-parleur vers le micro qui l’envoie vers l’amplificateur qui lui-même le transmet au haut-parleur. Mais j’étais perplexe car je ne voyais pas de boucle de rétroaction dans la configuration LHR-LON, et puis pourquoi ce problème à Londres et pas ailleurs (heureusement !) dans le HLN. Mystère…
Le réseau SITA avait été pionnier dans la technique de la commutation de paquets, en même qu’ARPANET aux Etats-Unis, mais le premier à le faire en international (voir le passionnant article de Ruedi Bébié à ce sujet :
http://wikisita.com/wp-content/uploads/2016/06/Switching-centers.pdf).
Certes nous avions connus quelques soucis dans le passé, mais cela faisait maintenant pas mal d’années que le HLN fonctionnait sans problèmes avec le même protocole de communication P1000 (à la fois pour la commutation de paquets et la transmission des messages Type B). Mes discussions avec les équipes de programmation, dont en particulier Jean-Pierre Ladam, ne m’avaient pas donnés d’indice sur un possible problème technique à ce niveau. N’étant pas un spécialiste de la P1000 je me procurais un exemplaire de la spécification de ce protocole et je me revois encore emportant précieusement ce document chez moi un vendredi soir pour l’étudier pendant le week-end. Dans le métro j’essayais de mettre de l’ordre dans mes pensées concernant ce mystère et comment le résoudre. La lecture de ce document (assez rébarbatif avec tous ses éléments techniques de spécification) ne m’apporta rien dans un premier temps et correspondait à mes connaissances générales de commutation par paquets. Rien de particulier ne m’interpellait. Mais deux pensées me revenaient sans cesse :
• Pourquoi ce problème avec les HLS Philips et pas Univac (qui traitaient également des flux Type B importants) ?
• Qu’est-ce qui pouvait provoquer ce phénomène de pompage ?
Et petit à petit germa en moi, d’abord confusément, puis de plus en plus nettement l’idée du mécanisme qui provoquait ce problème.
Mais ici quelques précisions techniques sur la commutation par paquets sont nécessaires (je m’en excuse auprès des lecteurs non-techniciens qui ont eu le courage de me lire jusqu’ici !). Afin d’assurer la fiabilité de la transmission des paquets et des messages Type B, un mécanisme « d’acquittement » des paquets correctement reçus est utilisé, à la fois pour la transmission au niveau de chaque circuit, et pour le contrôle de bout-en-bout du trafic Type B dont la transmission exigeait un très haut niveau de fiabilité (cette caractéristique était la grande fierté et spécificité de SITA) . L’existence de mécanisme au niveau des circuits expliquait le problème mentionné plus haut suite à une fausse manœuvre à Londres et corrigé par Gilles Dronne.
Pour le mécanisme d’acquittement de bout-en-bout (par exemple entre NYC et LON) le principe était le même, et afin de pouvoir optimiser la transmission du Type B en fonction de la qualité des circuits, un paramètre permettait de ne pas stopper immédiatement le flux si un paquet composant un message manquait à l’arrivée mais d’attendre la réception de N paquets, N étant un paramètre ajustable au niveau de chaque système HLS, avant de bloquer la transmission avec une demande répétition de paquets manquant. Ainsi pour un paquet perdu, N paquets étaient retransmis (ce paramètre jouait le rôle de l’amplificateur dans mon analogie avec l’effet Larsen). Un paquet pouvait être perdu soit à cause d’une mauvaise qualité sur la ligne de transmission, soit parce que cette ligne de transmission était temporairement surchargée et que la file d’attente des paquets en attente de transmission sur cette ligne était saturée et les paquets en excédent était purement et simplement éliminés (« droppés » disions-nous dans notre jargon technique).
Je tenais mon mécanisme explicatif : le trafic Type B entre LHR et LON était particulièrement important et donc il était tout à fait normal que de temps en temps un paquet soit perdu sur le circuit de LHR vers LON du fait d’une saturation transitoire. Si le paquet qui était perdu faisait partie d’un message envoyé de NYC à LON, alors le mécanisme de fenêtre de contrôle (via le paramètre N) faisait lui-même répéter la retransmission de N paquets Type B de NYC à LON et cette retransmission suffisait à entretenir la saturation du circuit LHR-LON, ce qui générait d’autres pertes de paquets Type B et ainsi de suite (j’espère que vous m’avez suivi jusqu’ici bien que ne partageant pas mon intérêt pour les choses techniques). La spécification P1000 décrivait parfaitement l’utilisation de ce paramètre N, mais n’en spécifiait pas la valeur, et donc je ne savais pas encore si mon intuition était correcte. Par ailleurs il me restait à expliquer pourquoi ce phénomène se produisait dans les systèmes Philips et pas les systèmes Univac. SE pouvait-il que la valeur de ce paramètre ait été fixée à des valeurs différentes dans ces systèmes ? Je n’en savais rien ! J’étais très excité mais il me fallait attendre lundi matin pour avoir la réponse auprès de mes collègues programmeurs de ces systèmes.
Lundi matin, je me souviens dans le métro, très impatient d’arriver au travail et d’avoir la réponse à ma question (car si N avait la même valeur dans les systèmes Philips et Univac, la plus grande puissance des systèmes Philips ne suffisait pas à expliquer que le phénomène de pompage ne se produise que dans ces systèmes). Arrivé à mon bureau je fonce au « 5ième » (étage où se trouvaient les équipes techniques) et je pose la question à mes collègues.
Bingo ! Dans les systèmes Univac la valeur de N était fixée à 0 (donc pas d’effet Larsen, pas de pompage) mais dans les systèmes Philips la valeur de ce paramètre était fixée à 8 (si ma mémoire est bonne) et donc cela expliquait le pompage. J’étais très excité. Je contactais sans tarder A Puerto et lui expliquais que je pensais avoir la solution du problème. Pour le vérifier et appliquer la correction, il fallait fixer ce paramètre à la valeur 0 dans le système Philips de LON. Je demandais l’autorisation de le faire, ce qu’A Puerto m’accorda sans difficulté.
Jean-Michel Roullier était alors à Londres, pour justement essayer de résoudre ce problème de pompage du trafic Type B. Je lui communiquais l’instruction de mettre à 0 la valeur de ce paramètre, ce qui fut immédiatement exécuté. Nous étions lundi matin, et il fallait attendre lundi après-midi vers 15h00 pour voir si tout cela était correct et vérifier que le pompage Type B ne se produisait plus. Angoisse et excitation, j’attendais ! 15h00 arrive, je suis en contact avec les équipes des opérations et de programmation. Pas de phénomène de pompage signalé. Tout se passe normalement. L’après-midi se passe ; la journée se termine : aucun problème se trafic signalé à Londres. Je suis soulagé et excité à la fois : l’explication semble la bonne et la correction paraît avoir réussi. Un léger doute persiste en moi : et si ce lundi le trafic avait été beaucoup moins important que les autres jours ? Nous attendons le mardi, mais de nouveau tout fonctionne normalement à Londres. lA modification du paramètre est généralisée aux autres centres Philips. Cette fois je jubile ! Le problème des configurations duales Philips, qui avait failli tourner au cauchemar été réglé ! L’opération du réseau HLN reprenait son cours normal en attendant le DTN!
En même temps tout cela me laissait très songeur à l’idée qu’un modeste paramètre, N : la taille de la fenêtre de contrôle de bout-en-bout du Type B, et dont la valeur n’avait posé aucun problème pendant de nombreuses années, ait pu soudain provoquer un problème qui aurait pu être dramatique pour le fonctionnement du HLN qui était le fondement du développement de SITA à cette époque.

Je venais de vivre une aventure passionnante et unique et le HLN et la SITA m’en avaient donné l’occasion unique. Le souvenir de cette aventure est resté gravé très fort dans mes souvenirs et j’en ressens encore les émotions. J’espère avoir réussi à vous faire partager ces émotions, malgré le côté très technique et très personnel du récit de cette aventure. Je me sens privilégié aujourd’hui de pouvoir la raconter et partager avec vous sur wikisita. L’époque permettait alors de vivre de telles expériences. Aujourd’hui l’aventure est certainement ailleurs !