Résumé

  • Un calendrier de coûts ALTO fournit une suite de valeurs associées à des intervalles futurs ; une application peut alors choisir le moment d’un transfert, et pas seulement sa destination.
  • Ces valeurs sont des indications publiées par un fournisseur. Elles ne commandent aucun routeur et ne garantissent ni prix, ni latence, ni capacité.
  • Un déploiement robuste relie le calendrier au bon type de coût et aux bonnes versions de cartes, reçoit les mises à jour et conserve une solution de repli lorsque la prévision devient fausse.

Le créneau le moins cher est une affirmation

Prenons un ordonnanceur chargé de répliquer un grand volume avant le matin. Le serveur ALTO lui indique qu’entre deux zones réseau, le coût baisse après 02 h 00. Il attend. Cette décision ne modifie pas BGP, ne réserve pas de lien et ne reprogramme aucune file. L’application a simplement accepté une affirmation : pour cette origine, cette destination, ce type de coût et cet intervalle, plus tard paraît préférable à maintenant.

RFC 7285 définit le protocole Application-Layer Traffic Optimization pour les applications capables de choisir entre plusieurs extrémités. Une carte réseau regroupe les adresses sous des identifiants définis par le fournisseur, les PID. Une carte de coûts associe ensuite des valeurs orientées aux couples de PID.

La vue publiée reste volontairement abstraite. L’opérateur peut fournir un classement ordinal ou une valeur numérique sans révéler sa topologie, ses politiques d’ingénierie de trafic ni ses coûts commerciaux. La valeur 20 ne signifie donc pas automatiquement vingt millisecondes ou vingt euros. En l’absence d’une métrique dotée d’une unité explicite, elle indique surtout qu’une option est classée différemment d’une autre.

Ajouter le temps n’ajoute pas la certitude

RFC 8896 étend ce modèle par le Cost Calendar. Au lieu d’une valeur unique, le serveur renvoie un tableau couvrant des intervalles successifs. La date de départ, la durée d’un intervalle et leur nombre donnent au client les repères nécessaires pour lire le tableau.

Le calendrier peut dériver de rythmes observés, d’une maintenance prévue ou d’un schéma périodique. C’est une connaissance utile, mais prospective. Une coupure, un événement imprévu, une panne de cache ou un changement de routage peuvent transformer l’heure creuse annoncée en période chargée. Un calendrier répété peut rester parfaitement conforme à son format tout en décrivant une journée qui n’existe plus.

Le client doit donc conserver le contexte complet : point de départ, fuseau, frontières des intervalles, type de coût et versions des cartes dont dépendent les PID. Appliquer le tableau de demain à la carte d’aujourd’hui, ou lire la troisième case avec un décalage horaire, produit une décision que le serveur n’a jamais recommandée.

La fraîcheur possède son propre protocole

Le modèle initial permet au client de télécharger de nouveau une ressource. Cette méthode devient lourde lorsqu’une grande carte ne change que sur quelques cellules. RFC 8895 ajoute un flux de mises à jour fondé sur Server-Sent Events. Le serveur peut pousser un remplacement complet ou une modification incrémentale en JSON Merge Patch ou JSON Patch.

Ce flux constitue une seconde surface de contrôle. Le client doit rattacher chaque événement à la bonne ressource et à la bonne version de départ, respecter l’ordre et réagir à une interruption sans présenter son dernier état comme actuel. Une petite correction appliquée au mauvais calendrier peut être plus trompeuse qu’une absence franche : elle fabrique un planning plausible que personne n’a publié.

RFC 8896 recommande donc d’associer le calendrier au mécanisme incrémental. Une connexion SSE ouverte ne suffit pas à prouver la fraîcheur. Il faut montrer qu’une modification chez l’éditeur devient la même modification dans l’état de décision actif de l’application, avec une version traçable et un retard borné.

La recommandation modifie sa propre prévision

Un calendrier ne se contente pas d’observer la demande : il peut la déplacer. Si de nombreux clients reçoivent le même créneau peu coûteux, ils peuvent tous reporter leur travail vers lui. L’intervalle se remplit parce qu’il avait été annoncé comme vide. RFC 8896 demande explicitement aux éditeurs et aux consommateurs de tenir compte de cette boucle de rétroaction.

Le choix de granularité devient alors stratégique. Un calendrier grossier protège mieux les informations sensibles et change moins souvent, mais concentre davantage de clients. Un calendrier fin répartit mieux les décisions, au prix de plus de détails révélés et de plus de mises à jour. Le réseau cherche peut-être à lisser ses liens coûteux ; l’application veut peut-être tenir une échéance. Le protocole transporte leur coordination sans confondre leurs intérêts.

L’information peut aussi être détournée. Un client compromis peut utiliser la prévision pour choisir le moment d’un trafic malveillant. L’authentification identifie l’éditeur ; elle ne rend pas l’intention du lecteur bienveillante.

Ce que prouvent les RFC

Le dossier normatif établit le modèle : emplacements définis par le fournisseur, coûts orientés, intervalles temporels et mises à jour complètes ou incrémentales. Il montre également que les concepteurs ont envisagé l’obsolescence, les boucles de rétroaction, les recommandations authentiques mais nuisibles, l’instabilité du client et l’abus.

Il ne prouve pas qu’un opérateur nommé déploie ALTO, qu’une valeur représente un tarif réel ou qu’un transfert particulier s’améliorera. Une RFC explique comment formuler une recommandation. Seules les observations du service et du client peuvent démontrer qu’elle était fraîche, adaptée et efficace.

Sources