Résumé

  • La valeur OC-Reduction-Percentage = 100 de la RFC 7683 ordonne au nœud réactif d’appliquer un traitement de réduction à toutes les nouvelles requêtes correspondantes qu’il aurait autrement envoyées ; elle ne mesure pas le trafic obtenu.
  • Pour conclure à un résultat opérationnel, il faut relier le rapport, l’état OCS effectivement accepté, les décisions requête par requête et les mesures de trafic et de débit utile, avec les mêmes identités, périmètres et horodatages.

Le pourcentage arrive avant l’observation

La difficulté tient moins au calcul qu’au temps du verbe. Un résultat annonce ce qui s’est produit. Une Overload Report, ou OLR, formule ce qui doit se produire ensuite. La RFC 7683 définit OC-Reduction-Percentage par rapport au trafic que l’émetteur enverrait sans cette consigne. À 100, le nœud déclarant une forte surcharge demande que la totalité des nouvelles requêtes concernées reçoive un traitement de réduction.

Ce message est une preuve robuste de l’intention de contrôle, à condition d’en conserver l’auteur, le type, l’application, la séquence et la durée. Il n’est pas pour autant un compteur de paquets à l’arrivée. Il ne dit pas que tous les clients ont compris l’extension, que toutes les copies de l’état étaient à jour, que les requêtes déroutées ont disparu du réseau ni que l’application a cessé toute activité.

Le parcours de Ben Campbell éclaire cette frontière. Son profil IETF le présente comme spécialiste des communications en temps réel, ancien membre de l’IAB, ancien directeur de l’aire ART et ancien président de plusieurs groupes de travail. Il cosigne la RFC 7068 sur les exigences de contrôle de surcharge, la RFC 7683 sur DOIC et la RFC 8583 sur l’information de charge. Ces textes n’essaient pas de faire parler un chiffre au-delà du nœud qui le produit.

Deux nœuds, deux décisions locales

Dans DOIC, le nœud déclarant détermine qu’une surcharge exige une baisse de trafic et envoie l’OLR. Sa méthode de calcul n’est pas normalisée. Le nœud réactif reçoit le rapport, conserve un Overload Control State — OCS — et choisit quelles requêtes individuelles subiront le traitement. Ce choix reste lui aussi une décision d’implémentation.

L’algorithme de perte impose d’appliquer le traitement au pourcentage demandé des nouvelles requêtes. Mais la RFC 7683 précise qu’un algorithme sans état ne garantit pas une baisse absolue du trafic. Sa garantie porte sur la proportion de nouvelles requêtes sélectionnées. Cette nuance empêche de confondre une décision prise dans le plan de contrôle avec le résultat observé dans le plan de données.

Le traitement peut en outre prendre deux formes. Une requête peut être bloquée, ou être dirigée vers un autre nœud. Pour les rapports de pair ajoutés par la RFC 8581, le déroutement est même la solution privilégiée ; si les pairs de remplacement manquent de capacité, il faut alors limiter les requêtes. Le serveur protégé peut donc voir ses arrivées chuter tandis que la charge, les tentatives et parfois les erreurs se déplacent.

« Tout » dépend du périmètre

Une réduction de 100 % ne vise pas nécessairement tout le système Diameter. La RFC 7683 distingue les rapports d’hôte et de realm. Le premier concerne les requêtes routées vers un hôte ; le second celles qui relèvent d’un realm. L’Application-ID participe à l’identification de l’état. La RFC 8581 ajoute le rapport de pair, rattaché à l’identité Diameter de ce pair et à l’application.

Avant d’appliquer le pourcentage, le nœud réactif doit donc faire correspondre la requête à un OCS actif. Une autre application ou un autre destinataire peut rester hors champ. Un client sans prise en charge de DOIC peut ne jamais posséder cet état. Un rapport de pair dont le SourceID ne correspond pas au pair ayant transmis la réponse doit être ignoré, afin qu’une insertion erronée ou hostile ne gouverne pas le trafic.

L’état est également versionné. Le OC-Sequence-Number distingue une mise à jour d’une répétition ancienne. Une séquence supérieure remplace l’état correspondant ; une valeur égale ou inférieure est ignorée. Toute modification de durée ou de pourcentage impose une nouvelle séquence, et l’ordre doit survivre au redémarrage du nœud déclarant tant que des rapports antérieurs demeurent valides. Une enquête sérieuse ne demande donc pas seulement « quelle valeur a été envoyée ? », mais « quelle version chaque nœud croyait-il active au moment de décider ? »

L’absence d’un rapport n’est pas un retour au vert

Autre piège : une réponse sans OC-OLR ne supprime pas l’OCS. Dans les RFC 7683 et 8581, l’absence d’OLR signifie « aucun changement ». Le nœud déclarant peut envoyer une durée de validité nulle pour signaler la fin, ou laisser l’état expirer selon sa durée.

Même cette fin ne rétablit pas instantanément le régime normal. Après une réduction de 100 %, la RFC 7683 recommande une reprise prudente, par exemple au moyen de messages de sonde, afin d’éviter qu’un retour massif ne replonge le nœud dans la surcharge. La bonne chronologie comporte donc au moins quatre instants : émission, acceptation, expiration ou fin explicite, puis remontée contrôlée. Un graphique qui place la récupération au premier message silencieux invente une transition qui n’existe pas.

Des rapports superposés, pas des pertes additionnables

Un même message peut transporter des rapports d’hôte, de realm et de pair. La RFC 8581 demande de traiter d’abord l’hôte ou le realm, puis d’appliquer la réduction du pair aux messages restants, en tenant compte de ce qui a déjà été éliminé. Le but est notamment de limiter les oscillations.

Additionner les pourcentages donnerait un chiffre sans dénominateur commun. Il faut suivre les populations successives : requêtes candidates, requêtes correspondant à l’état d’hôte ou de realm, survivantes, requêtes correspondant à l’état de pair, puis décisions de déroutement ou de limitation. Sans ces comptes, un « 100 % » reste une politique appliquée à un ensemble inconnu.

Charge et surcharge parlent deux langues numériques

La RFC 8583 distingue la charge, permanente, de la surcharge, exceptionnelle. Une information de charge est un indice utilisable pour répartir les requêtes. Une OLR réclame explicitement une baisse de la charge offerte ; le texte la décrit comme une forme de contrat entre le nœud déclarant et le nœud réactif.

Les échelles ne se lisent pas dans le même sens. Pour Diameter Load, une valeur élevée représente une charge plus faible : 65535 correspond à une charge nulle et 0 à une charge de 100 %. Pour OC-Reduction-Percentage, 0 signifie qu’aucune réduction n’est nécessaire et 100 que toutes les requêtes correspondantes doivent être traitées. Les ranger dans une colonne générique « pourcentage de charge » suffit à retourner le sens de la donnée.

La RFC 7068 propose un arbitre extérieur à ces messages : le débit utile global sous charge constitue la mesure ultime de la valeur d’une solution. Ce débit doit être observé. Le rapport prouve une demande ; l’OCS prouve l’état détenu par un nœud ; les journaux de décision prouvent une sélection ; les compteurs prouvent des arrivées ; la télémétrie applicative prouve des transactions utiles. Chacune de ces pièces a sa juridiction.

Construire une preuve de bout en bout

Le dossier minimal commence par la décision de déclaration : identité du nœud, Application-ID, type de rapport, version du calcul et motif de surcharge. Il conserve ensuite l’OLR exact, avec sa séquence, sa validité, son algorithme, son pourcentage et son heure d’envoi.

Pour chaque nœud réactif, il faut savoir si la capacité DOIC a été annoncée, si la source a été acceptée, si la séquence a créé ou modifié l’OCS et pendant quel intervalle cet état était actif. Viennent ensuite les décisions sur les requêtes correspondantes : acheminement normal, déroutement ou limitation.

Les mesures de trafic ne deviennent interprétables qu’après cette reconstruction. Elles doivent couvrir le nœud protégé et les destinations alternatives, les rejets et les nouvelles tentatives, puis le débit utile et les effets applicatifs sur la même fenêtre. Si la chaîne s’interrompt, la formulation doit s’arrêter au dernier reçu disponible. « L’OCS à 100 % était actif sur le nœud A » demeure exact sans prétendre que « le trafic était nul ».

Sources