Résumé

  • RFC 1989 définissait entièrement le mécanisme LQR, mais laissait à chaque extrémité la politique qui transforme des pertes mesurées en jugement sur l’utilisabilité de la liaison.
  • Des compteurs cumulés de paquets, d’octets et de rapports permettaient de rapprocher ce qu’un pair disait avoir émis de ce que l’autre disait avoir reçu, séparément dans les deux sens.
  • Ce rapprochement n’était ni une authentification ni un verdict : les compteurs pouvaient boucler, le Magic-Number ne servait qu’au rebouclage, la sécurité n’était pas traitée et la reprise restait hors du contrat commun.

Mesurer n’était pas trancher

Une liaison point à point peut conserver sa porteuse, terminer correctement LCP et néanmoins perdre assez de trafic pour devenir gênante. Un routeur disposant d’un autre chemin voudra peut-être le privilégier. Un accès commuté pourra être relancé. Ailleurs, le coût de la coupure fera préférer une liaison médiocre à aucune liaison. Le même taux de perte ne commande donc pas partout la même action.

Le premier texte consacré à ce problème, RFC 1333, date de mai 1992. RFC 1989 l’a remplacé en août 1996. Sa décision de conception la plus féconde tient en une séparation : PPP spécifie le « mécanisme » de surveillance de qualité, mais non la « politique ». Le format du rapport, les points de comptage et les calculs sont interopérables. La manière de déclarer une qualité suffisante ou insuffisante appartient à l’implémentation et peut différer aux deux bouts.

Ce n’est pas un vide réglementaire. C’est une réduction volontaire du consensus nécessaire. Des équipements construits par des équipes différentes pouvaient s’accorder sur les observations sans demander à une autorité distante de connaître la valeur de la liaison pour chaque service.

La demande avait un sens

Par défaut, PPP ne surveillait pas la qualité. Une extrémité souhaitant recevoir des mesures ajoutait l’option LCP de type 4, Quality-Protocol, à son Configure-Request. La valeur hexadécimale c025 désignait Link Quality Report. En acquittant l’option, le pair acceptait d’envoyer les rapports demandés.

La formulation est orientée. Celui qui demande indique ce qu’il veut recevoir ; il ne promet pas simultanément la réciproque. Les deux sens se négociaient indépendamment, et RFC 1661 autorisait même des protocoles de qualité différents dans chaque sens. Un pair ayant accepté LQR devait toutefois traiter correctement les LQR entrants, même s’il n’en avait pas demandé et n’appliquait aucune politique locale de surveillance.

Pour LQR, l’option contenait aussi une période de quatre octets. Exprimée en centièmes de seconde, elle fixait l’intervalle maximal entre deux envois, pas une cadence minimale : le pair pouvait parler plus vite. Une valeur nulle demandait de répondre immédiatement à la réception d’un LQR sans entretenir de temporisateur. La négociation empêchait les deux côtés de choisir ce mode et d’attendre indéfiniment le premier rapport.

Le contrat demeurait révocable au niveau du protocole. Si un Protocol-Reject visait LQR, l’émetteur devait cesser ses rapports. Une capture de l’acquittement prouve donc une obligation négociée à cet instant ; elle ne prouve ni la réception ultérieure de chaque rapport ni le motif économique de la surveillance.

Le rapport faisait circuler la mémoire du pair

Les noms des champs LQR sont écrits du point de vue du destinataire, parce que c’est lui qui a demandé le rapport. Les valeurs PeerOut... décrivent les compteurs de sortie courants de l’émetteur : paquets, octets et nombre de LQR. Lors de la réception, l’autre extrémité ajoute logiquement des valeurs SaveIn... correspondant à ce qu’elle vient effectivement d’observer. Ces dernières ne sont pas transmises sur la liaison entrante ; elles appartiennent au point de mesure local.

Au rapport suivant dans l’autre sens, cette observation sauvegardée revient sous les champs PeerIn.... Les champs LastOut... reprennent, eux, la dernière vision reçue des précédents compteurs de sortie locaux. Le paquet ne contient donc pas seulement un total proclamé par l’émetteur. Il rapporte aussi la trace de ce que l’autre côté avait vu auparavant.

La comparaison porte sur des variations. La différence entre deux valeurs successives de PeerInPackets se confronte à la variation de LastOutPackets pour estimer les pertes sortantes. SaveInPackets et PeerOutPackets éclairent les pertes entrantes. Le même raisonnement s’applique aux octets. Les variations de rejets et d’erreurs chez le pair peuvent orienter l’enquête vers une saturation de réception plutôt que vers une défaillance physique.

Le mot « orienter » doit rester visible. LQR ne délivre pas d’accusé de réception individuel et ne certifie pas la sincérité d’un compteur. Il rend deux témoignages cumulatifs comparables.

L’unité de compte était elle-même normalisée

Sans règle précise, deux implémentations pouvaient appeler « octet » des réalités différentes. Un convertisseur pouvait masquer l’échappement asynchrone ; un contrôleur matériel pouvait prendre en charge le tramage ; un processus logiciel pouvait voir davantage de détails. La différence entre deux compteurs aurait alors ressemblé à une perte de données.

RFC 1989 a fixé une représentation abstraite. Les octets couverts par le FCS comptent, ainsi que le FCS et un octet de drapeau par trame. Les drapeaux supplémentaires et les bits ou octets d’échappement ne comptent pas. La mesure vise une quantité d’information reproductible, non la totalité des symboles physiques consommés. InGoodOctets exclut les octets des trames classées comme rejetées ou erronées.

Le rapport doit déjà inclure la contribution attendue du LQR en cours de fabrication. Les compteurs croissent, mais leurs champs de 32 bits finissent par revenir à zéro. Un calcul de différence doit reconnaître ce bouclage. Plusieurs compteurs d’interface ne partent d’ailleurs pas d’une valeur commune lorsque LCP entre en établissement : c’est la variation qui synchronise l’analyse, pas l’illusion d’une origine absolue.

Ce niveau de minutie est le prix de l’interopérabilité. Échanger des nombres ne suffit pas ; les pairs doivent conserver le même sens derrière ces nombres.

Le silence d’un rapport n’était pas une panne instantanée

LQR recevait la priorité maximale dans le multiplexage, afin que l’information de qualité ne reste pas derrière le trafic ordinaire. Pourtant, augmenter la fréquence n’apportait pas toujours davantage de connaissance. Sur une bonne liaison, les rapports sont superflus et doivent gêner le trafic le moins possible. Sur une liaison variable, une fenêtre longue lisse les pointes mais retarde la détection d’une rupture complète.

L’asymétrie complique encore la lecture. Si les rapports entrants arrivent et révèlent que le sens sortant est très mauvais, envoyer davantage de rapports vers le pair ne sert guère : ils risquent précisément de se perdre. Si le sens sortant est bon mais le sens entrant mauvais, multiplier les tentatives peut permettre à quelques rapports de passer et aider le pair à former sa propre décision.

RFC 1989 ne permettait pas de transformer un seul silence en verdict. Après un rapport absent ou un résultat réellement mauvais, au moins un rapport supplémentaire devait être tenté. Une décision algorithmique exigeait au moins deux temps aller-retour : une charge transitoire ou la perte du rapport lui-même pouvait expliquer le premier signal.

Le texte recommandait une hystérésis et proposait K succès parmi N périodes comme exemple. Il ne les imposait pas. La récupération restait également non spécifiée. Fermer les protocoles réseau tout en continuant les LQR constituait une possibilité ; basculer une route, raccrocher ou attendre en étaient d’autres. Le protocole commun s’arrêtait avant le pouvoir d’agir.

c025 ne portait aucune signature

Lorsqu’un Magic-Number avait été négocié, le LQR pouvait aider à détecter une liaison rebouclée : recevoir son propre nombre constituait un indice. Sans négociation, le champ valait zéro et devait être ignoré. Ce mécanisme ne prouvait pas l’identité du pair.

RFC 1989 indique que les questions de sécurité ne sont pas discutées. Il ne définit ni intégrité cryptographique du rapport ni justificatif indépendant pour ses compteurs. L’authentification PPP se traitait dans sa propre phase et avec ses propres protocoles. Observer c025 à un point de capture prouve la présence d’une représentation LQR à ce point, pas la vérité universelle de son contenu.

Un dossier d’exploitation doit donc conserver séparément la demande LCP, son acquittement, la période négociée, les heures réelles d’arrivée, les compteurs bruts, le traitement du bouclage, les différences calculées, la règle locale et l’action qui a suivi. Une seule date intitulée « liaison mauvaise » efface précisément la frontière que le protocole avait préservée.

Un consensus plus petit que la décision

L’histoire de LQR n’est pas celle d’un algorithme ayant découvert le seuil parfait. C’est celle d’un mécanisme suffisamment étroit pour être partagé. Les pairs s’accordaient sur la demande, la cadence maximale, les points de mesure et le retour des observations. Ils pouvaient ensuite expérimenter des politiques différentes sans perdre la capacité de se comprendre.

L’affectation IANA c025 identifie un type de paquet. Un Configure-Ack atteste un engagement négocié. Les différences de compteurs étayent une estimation de perte. Les erreurs et rejets resserrent les hypothèses. Seule la politique locale produit un jugement d’utilisabilité, et seules les traces de routage, de NCP, de liaison et d’application montrent les conséquences réelles.

Le rapport rendait le désaccord observable. Il n’avait pas reçu le pouvoir de le supprimer.

Sources