Et si on parlait technique ?
Dans ce Welcome to the Planet nous avons souhaité parler technique pure au travers de la personnalité d’un ingénieur ARealTI, tant ces dernières peuvent être différentes. En effet, ARealTI sait trouver et embarquer sur sa planète les profils les plus variés comme ceux que vous avez pu découvrir dans les éditions précédentes.
Guillaume, 35 ans, est ingénieur télécom et réseaux ENSEEIHT de Toulouse (École nationale supérieure d’électrotechnique, d’électronique, d’informatique, d’hydraulique et des télécommunications) en 2009. Il est également titulaire d’un doctorat en réseaux télécom, systèmes et architecture obtenu à l’INSA de Toulouse en 2014.
Comment avez-vous connu ARealTI ?
« J’ai connu ARealTI en 2016, classiquement sur LinkedIn. Je n’ai pas été retenu une première fois, mais j’ai postulé à nouveau en 2020. Je viens de terminer une mission de constitution d’un dossier de certification auprès de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) pour un client de ARealTI. »
Quels sont vos hobbies, vous êtes guitariste ?
« Oui, je fais de la guitare classique depuis 3 ans, notamment sur des romantiques espagnols comme Fernando Sor. Je commence aussi le répertoire du compositeur français Roland Dyens. »
Que trouvez-vous dans cette activité ?
« Côté travail tout le côté scientifique et technique me nourrit intellectuellement et j’ai besoin d’autres activités pour me compléter comme la guitare pour l’artistique, l’escalade pour le sport, ou dans une association d’éducation populaire pour la philosophie. »
En escalade, Guillaume fait du « bloc » en salle ou à Fontainebleau, moins contraignant que l’escalade en cordée, mais plus intense et explosif.
Alors venons-en au sujet principal, donnez-nous un exemple de choix de solution originale apportée à un problème.
« Cet article résume le travail d’une thèse de doctorat entamée en 2009 et soutenue en 2014. Celle-ci est librement consultable en intégralité ici : »
Introduction
D’un point de vue usages et techniques, l’évolution des réseaux depuis l’explosion de l’utilisation d’Internet par le grand public a provoqué l’apparition de nouveaux protocoles de transport et l’évolution des protocoles existants.
Ce contexte soulève cinq points de problématique susceptibles de limiter cette évolution :
- complexité de choix ;
- configurabilité ;
- extensibilité ;
- assujetissement ;
- déploiement.
Ces problèmes reflètent une complexité croissante dans le choix et l’utilisation des solutions de transport, et les freins dans leur adoption. Le travail de ma thèse de doctorat a consisté à redéfinir le fonctionnement de la couche transport et ses interactions avec les applications.
Cette nouvelle couche transport permettrait l’intégration transparente de solutions novatrices futures pour les niveaux supérieurs et inférieurs de la pile protocolaire tout en simplifiant son utilisation par une augmentation du taux d’abstraction du réseau qu’elle propose. Afin de décharger les utilisateurs humains et applicatifs de cette nouvelle solution, celle-ci intègre des principes d’autonomie lui permettant une prise de décision sans intervention extérieure, et dynamique afin de toujours délivrer le meilleur service aux applications, quelles que soient les évolutions du contexte applicatif et réseau en cours de communication.
Cet article présente les principes fondamentaux d’une telle solution, que nous appelons Autonomic Tranport Layer (ATL), ainsi que son architecture globale.
Problématique
Le problème principal réside dans le fait que les deux principaux protocoles de transport, UDP et TCP (trois aujourd’hui si on souhaite ajouter SCTP) sont les seuls à vraiment passer à peu près partout sur les réseaux. C’est la faute à des middleboxes (NAT, PEP, IPS, etc.) qui remontent jusqu’à cette couche alors qu’ils ne le devraient théoriquement pas, accroissant exponentiellement la difficulté à déployer de nouvelles solutions.
Les usages ont également évolué, rendant les deux services précédents trop laxistes (ni ordre ni fiabilité) ou trop drastiques (ordre et fiabilité totaux). Qu’en est-il d’un besoin d’ordre partiel ou d’une fiabilité contrainte en temps comme la diffusion en streaming pourrait souhaiter, surtout avec des résolutions toujours plus hautes ? Qui a vraiment envie de retransmettre une frame P de plusieurs Mo qui ne sera jamais affichée car elle arrivera trop tard ?
Finalement, souhaite-t-on vraiment en tant que développeur connaître en détail la collection de protocoles résidant sous notre application et quand utiliser lequel et pour quelle raison ? Non. Décidément, le développeur ne devrait avoir à communiquer que la description de son besoin en QoS et laisser le système s’occuper du reste.
La solution étudiée
La solution proposée consiste à introduire une certaine dose d’autonomie à la couche Transport, la rendant ainsi capable de définir l’implémentation technique (choix du protocole et de sa configuration) en fonction du service requis. Petit bonus, celle-ci permet également de modifier aussi bien la configuration que la structure en run time pour s’adapter aux changements du réseau, et tout ça de manière transparente pour les couches supérieures.
Le point central est l’adoption du principe de l’autonomic manager, provenant des travaux d’IBM sur l’autonomic computing. Celui-ci vient se brancher sur le plan de donnée de la couche transport afin d’en prendre le contrôle, analyser les remontées, effectuer les choix techniques et en commander la mise en place. Son avantage réside également dans le fait qu’il peut lui-même être commandé, en cascade, par un autonomic manager de niveau supérieur, etc. Jusqu’à arriver à un manager central permettant l’intégration d’une business policy de l’administrateur ou utilisateur du terminal ayant des répercussions sur tous les aspects de la machine.
Cette étude a été menée de manière à permettre une intégration transparente à l’existant, s’appuyant sur des technologies déjà disponibles. Le monitoring peut parfaitement intégrer SNMP. La distribution de nouvelles solutions protocolaires à intégrer à la solution peut se reposer sur des DHT. Le path discovery peut-être étendu à la découverte de quels protocoles peuvent passer, permettant l’intégration globale progressive de nouvelles solutions, et le plus important sans doute : les applications legacy peuvent parfaitement utiliser le point d’accès à l’ATL comme une socket classique de manière transparente pour elles. C’est l’ATL qui se chargera de la traduction.
Le mot de la fin
« Il est évident que depuis que ces travaux conceptuels de recherche fondamentale ont été menés, les technologies ont évolué, l’état de l’art scientifique également. Cette thèse même a été précisée par M. Oulmahdi :
Il est a noter également que parallèlement à ces travaux, le projet RINA, soutenu par Louis Pouzin, l’inventeur du réseau Cyclades, a gagné en force et représente à mon sens le futur de la science des réseaux informatiques. Je ne peux qu’inviter le lecteur à se renseigner sur ceux-ci qui mettent déjà incroyablement l’eau à la bouche des ingénieurs que nous sommes. »
Rappel : la cooptation
Si vous connaissez des talents qui pourraient intéresser ARealTI dans des environnements variés, de la start-up au grand groupe, alors :
