Résumé

  • Pour une mise à jour de session en PendingU, RETRY_AND_TERMINATE autorise le service lorsque Tx expire, sans clore l’attente ; un échec d’envoi ou une erreur temporaire reçu ensuite impose l’arrêt.
  • La règle effective peut provenir d’un serveur plutôt que du réglage local. Une reprise sur un autre serveur exige en outre une autorisation de transfert de session et une gestion de son état.

Le service continue ; pourtant, le système de contrôle du crédit n’a pas encore répondu. Faut-il y voir une anomalie ? Pas nécessairement. Dans un cas précisément défini par Diameter, c’est le comportement prévu, y compris sous une politique dont le nom se termine par TERMINATE. L’apparente contradiction disparaît lorsque l’on distingue l’échéance d’un temporisateur de l’issue d’une requête.

Cette distinction ne relève pas du vocabulaire. Des unités de service peuvent être consommées pendant l’intervalle. Le responsable qui ne regarde que la réponse finale risque donc de manquer une partie de la décision opérationnelle : pendant combien de temps a-t-on accepté de continuer, sous quelle règle, et avec quelle possibilité de rapprochement ultérieur ?

L’attente a plusieurs issues

Le contrôle du crédit par session organise une réservation d’unités, des échanges intermédiaires et un compte rendu final. Ces unités peuvent mesurer une durée, un volume ou une quantité de service. La section 5.3 du RFC8506 prévoit notamment des mises à jour lorsque les unités sont consommées ou que leur validité expire ; une demande anticipée peut contribuer à éviter une interruption. Il ne s’agit donc pas seulement de consulter une somme d’argent avant chaque opération.

Prenons uniquement une session déjà établie dont le client attend la réponse à une mise à jour : l’état PendingU. La section 7, tableau 4, précise ce qui arrive sous RETRY_AND_TERMINATE. Si Tx expire, le client accorde le service et reste en PendingU. Si une réponse favorable arrive, il arrête Tx et revient à Open. Si survient ensuite un échec d’envoi ou une notification d’erreur temporaire, il termine le service et passe à Idle. La première échéance n’a donc pas tranché définitivement l’issue de la demande.

L’erreur temporaire a ici un sens protocolaire précis. Ce n’est pas une façon vague de dire que le serveur prend du retard. L’échec d’envoi couvre notamment l’impossibilité de joindre la destination et, lorsqu’elle s’applique, une destination de secours, ainsi que l’expiration finale d’une requête. Assimiler ces événements à un unique « dépassement de délai » ferait perdre la logique de la machine à états.

La valeur recommandée pour Tx est de dix secondes, selon la section 13. Ce chiffre ne révèle ni le paramétrage réel d’un réseau ni une limite garantie de consommation provisoire. Validity-Time concerne la validité des unités et le besoin de mise à jour ; le temporisateur de supervision du serveur concerne encore autre chose. Leur existence ne transforme pas Tx en budget universel de risque.

Continuer n’a rien d’inconditionnel

La section 8.14 définit trois politiques. TERMINATE, qui s’applique par défaut lorsque l’attribut manque, arrête le service à l’expiration de Tx dans PendingU. CONTINUE et RETRY_AND_TERMINATE autorisent alors toutes deux le service. Leur différence apparaît au stade suivant : CONTINUE l’autorise encore après l’échec d’envoi ou l’erreur temporaire, tandis que RETRY_AND_TERMINATE le termine. La tentative vers une autre destination dépend aussi de la prise en charge de la reprise et de la disponibilité d’une solution de remplacement.

Il serait pourtant faux d’en déduire que toute réponse défavorable devient négociable. Le tableau 4 impose l’arrêt après END_USER_SERVICE_DENIED, quelle que soit la politique CCFH. De même, le premier échange associé à une AA-Request possède sa propre machine à états et déconnecte à l’expiration de Tx. Le cas étudié est celui d’une mise à jour de session, pas une autorisation générale d’admettre un utilisateur sans authentification. Le RFC porte sur l’autorisation de crédit ; l’authentification et l’autorisation propres au service sont hors de son périmètre.

Le paramétrage local ne suffit pas non plus à identifier la politique effective. La section 5.7 accorde la priorité à la valeur reçue du serveur AAA du domaine d’origine sur la valeur locale ; celle contenue dans la réponse du serveur de contrôle du crédit remplace ensuite la valeur existante. Pour comprendre une transition, il faut donc connaître la règle appliquée à cet instant et son origine. Un inventaire des valeurs par défaut ne constitue pas cette preuve.

Le secours doit retrouver davantage qu’une adresse

Le maintien provisoire du service et le déplacement du flux de contrôle d’une session en cours sont deux sujets différents. Les sections 5.7 et 8.4 encadrent le second par CC-Session-Failover. En l’absence de cet attribut, FAILOVER_NOT_SUPPORTED s’applique : le flux de messages de contrôle du crédit de la session ne doit pas être transféré à un autre serveur. Choisir un serveur de secours pour une nouvelle session est distinct. Un basculement de pair sur le chemin de transport peut également se produire sans constituer ce transfert d’une session avec état.

Lorsqu’une reprise de session est prise en charge, le RFC recommande le transfert des états de session et de compte entre serveurs et exige la détection des doublons et des messages hors séquence. Il ne définit pas le mécanisme de communication interserveurs qui assure ce transfert. Session-Id et CC-Request-Number servent à identifier une requête ; leur présence ne prouve pas que les réservations ont été correctement répliquées. Une adresse de secours joignable ne répond donc qu’à une partie du problème.

La comptabilisation conserve elle aussi son rôle. La section 5.7 recommande un flux de secours pour les données d’usage. Son exemple associant CONTINUE à DELIVER_AND_GRANT suppose explicitement que ces données soient recueillies et échangées avec le serveur de contrôle du crédit. Un service maintenu n’est pas, par définition, gratuit, non mesuré ou définitivement perdu pour la facturation. L’échange final de la section 5.4 rend compte de l’usage et permet de solder les réservations. À l’inverse, la libération d’une réservation côté serveur ne prouve pas à elle seule l’arrêt du service côté client.

Une lecture du mécanisme, pas un constat d’incident

La notice officielle du RFC8506 présente un Proposed Standard de mars 2019 remplaçant RFC4006. La recherche d’errata, vérifiée le 8 septembre 2026, n’a retourné aucune entrée correspondante. Ces éléments ne démontrent ni la conformité d’un produit ni la fréquence d’un incident. Aucun taux de perte ou volume d’abonnés affectés n’est établi ici.

Dans son texte sur la réalité plutôt que le plaidoyer, Lu Heng propose une discipline éditoriale utile : rendre le fonctionnement intelligible avant de prendre parti. Son analyse du problème d’agence dans la gouvernance d’internet invite à examiner la répartition des décisions et de leurs conséquences. Elle ne prouve rien sur les motivations d’une équipe Diameter particulière. Ici, le fait essentiel suffit : une demande peut rester en suspens alors que le service, lui, se réalise déjà.