Résumé

  • RFC 1977 conservait l’encapsulation PPP native lorsqu’un essai de compression agrandissait le paquet, tout en exigeant que cet essai fasse évoluer le dictionnaire partagé de l’émetteur et du récepteur.
  • Un paquet natif ne pouvait transporter le code LZW CLEAR ; les deux côtés devaient donc reproduire les mêmes compteurs, changements de largeur et décisions d’effacement adaptatif.
  • Le numéro de séquence sur 16 bits signalait une rupture avant le décodage d’un paquet compressé, puis Reset-Request/Reset-Ack ouvrait une nouvelle histoire. Il ne prouvait ni l’authenticité ni l’exhaustivité de l’ancienne.

Une décision prise après le calcul

L’économie de RFC 1977 commence par une opération apparemment gaspillée. L’émetteur compresse d’abord le datagramme pour savoir si la compression mérite d’être envoyée. Lorsque le résultat s’allonge de façon notable, il jette cette représentation et remet sur le fil le paquet PPP natif. Même un gain négatif inférieur à trois octets conduit normalement au même choix, sauf si le résultat reste compatible avec la MTU.

Ce détour évite d’abaisser artificiellement la MTU annoncée aux couches supérieures. Un paquet incompressible n’a pas à payer un supplément de format. Mais l’essai n’a pas été neutre : l’algorithme LZW a parcouru les octets, reconnu ou créé des chaînes, déplacé le seuil de largeur des codes et actualisé les mesures de rendement.

Annuler ces effets chez l’émetteur produirait une incohérence au datagramme compressé suivant. Le récepteur, lui, ne reçoit aucun marqueur disant « cet essai vient d’avoir lieu ». RFC 1977 lui demande donc de le refaire localement pour tout paquet natif dont le numéro de protocole appartient à la plage compressible. La routine d’exemple pf_bsd_incomp simule la compression, incrémente la séquence et construit les mêmes entrées sans mettre le flux codé sur le réseau.

Le paquet visible et l’événement d’état sont ainsi deux choses distinctes. L’encapsulation répond à une question de taille ; le dictionnaire répond à une question de continuité.

D’un fichier fini à un flux sans fin

Le programme Unix compress avait une limite naturelle : la fin du fichier. RFC 1977 transpose son vocabulaire LZW à une suite de datagrammes dont l’horizon n’est pas connu. Le dictionnaire devient alors un bien commun entre deux exécutions indépendantes.

L’accord CCP est bref. Le type d’option 21 désigne BSD Compress. La version doit être 001, et Dict annonce la largeur maximale des codes, de 9 à 16 bits ; le texte cite 12 comme choix courant. Le code fourni en annexe va seulement de 9 à 15 bits. Cette limite de l’exemple ne rétrécit pas la plage du protocole, mais elle rappelle qu’un acquiescement de configuration ne garantit pas l’identité des réalisations.

La mémoire disponible n’autorise pas non plus le récepteur à choisir une table plus grande. Quand la table est pleine, quand la largeur change et quand l’effacement devient nécessaire dépendent de cette borne. Une différence apparemment généreuse déplacerait précisément les frontières qui doivent rester communes.

L’histoire comprend aussi le protocole interne, comprimé sur un octet lorsqu’il est inférieur à 0x100 avant tout calcul, que la compression du champ Protocol ait été négociée ou non. Elle comprend chaque paquet admissible, qu’il sorte finalement en 0x00FD, en 0x00FB ou sous son protocole ordinaire. Observer seulement les paquets marqués comme compressés revient donc à lire les pages imprimées en oubliant les pages qui ont modifié le lexique.

L’effacement que personne ne voit

Dans le LZW classique, la valeur réservée 256 porte l’ordre CLEAR. Elle peut figurer à la fin d’un flux codé. Rien de tel n’existe dans un paquet PPP natif. Or une séquence de données difficiles à compresser peut remplir puis empoisonner le dictionnaire au moment même où aucune trame ne transporte de codes LZW.

La solution de RFC 1977 est de rendre l’effacement calculable de part et d’autre. Le code de référence mesure le rapport entre octets d’entrée et octets de sortie théoriques, examine ce rapport par intervalles de 10 000 octets une fois le dictionnaire plein, puis efface si le nouveau rapport se dégrade ou devient inférieur à un. L’émetteur compte le résultat de son essai ; le récepteur compte le résultat de sa simulation. Les mêmes octets doivent mener au même instant.

L’effacement remet la largeur à neuf bits, ramène la dernière entrée à sa position initiale et réinitialise rapport et compteurs. Il ne s’agit pas encore d’une réparation CCP. C’est une décision interne prévue par l’algorithme, silencieuse lorsque le paquet qui la déclenche reste natif.

Cette symétrie économise un en-tête mais élargit la définition de l’interopérabilité. Deux programmes doivent s’accorder non seulement sur les valeurs négociées, mais sur l’ordre des entrées, le vieillissement des compteurs, l’arrondi du rapport et la frontière exacte du paquet. Au début d’un dictionnaire, les premiers paquets sont souvent peu compressibles et restent natifs ; leur apparence ne dit pas s’ils précèdent l’activation ou s’ils nourrissent déjà la nouvelle histoire.

Un compteur qui révèle tardivement l’absence

Chaque paquet réellement BSD-compressé porte un numéro de séquence sur 16 bits, transmis octet fort d’abord. Il part de zéro après l’effacement, avance après chaque paquet admissible—y compris les paquets natifs—et reboucle après 65535. Le récepteur devrait le vérifier avant de décoder.

La précaution empêche un code valide dans l’ancien dictionnaire d’être interprété avec une histoire déjà fausse. Pourtant, le paquet natif ne porte pas ce numéro. S’il se perd, le récepteur n’observe pas nécessairement le trou sur le moment. Il avancera moins vite que l’émetteur, et la rupture apparaîtra au prochain paquet compressé portant le compteur attendu par l’autre côté.

Le signal dit qu’une continuité manque. Il ne dit pas quel datagramme, ne sépare pas la perte du désordre, ne fournit pas les octets absents et n’authentifie pas l’émetteur. RFC 1977 s’appuie sur le FCS HDLC et les rejets ordinaires pour les corruptions ; sa section de sécurité ne traite d’aucun mécanisme. Ni le FCS ni un compteur cyclique ne deviennent ainsi une preuve d’intégrité de bout en bout.

Recommencer n’est pas réparer le passé

À la première séquence inattendue, le récepteur devrait envoyer un Reset-Request CCP et écarter les paquets compressés jusqu’au Reset-Ack. L’émetteur vide alors son dictionnaire, remet la séquence à zéro et répond. Le récepteur fait de même à la réception de chaque acquittement correspondant. Le texte compare explicitement l’opération à l’abandon d’un fichier et au commencement d’un autre.

Sur une liaison occupée, plusieurs paquets peuvent devenir inutilisables pendant l’aller-retour du contrôle. Il faut réémettre assez pour qu’une demande atteigne l’autre côté, mais pas plus souvent que le RTT : chaque doublon reçu provoque un nouvel effacement. La seconde proposée dans le texte n’est qu’un exemple. Une renégociation par Configure-Request fournit une autre issue, plus coûteuse.

Le découpage logiciel peut encore déplacer la frontière. Si un démon traite CCP et si le noyau traite les données, l’émetteur doit lier son effacement à l’envoi du Configure-Ack ou du Reset-Ack ; le récepteur doit avoir fini le sien avant le paquet suivant. Le reçu de contrôle ne suffit pas si l’exécution des deux chemins s’est croisée.

Une petite spécification, une longue chaîne de preuves

RFC 1977 définit des règles communes précises : quels paquets participent, quelle version est comprise, où la largeur s’arrête, comment les compteurs avancent, quand un écart arrête le décodeur et comment une nouvelle histoire commence. Le registre IANA conserve l’option CCP 21 et les protocoles de datagrammes compressés. Ces inscriptions rendent le langage commun vérifiable ; elles ne racontent pas l’exécution d’une liaison particulière.

La distinction rejoint l’exigence de Lu Heng de donner la primauté aux faits produits par les systèmes en fonctionnement. L’acquittement d’une option est un fait. L’ordre complet des paquets, la reproduction des compteurs et la simultanéité d’un effacement en sont d’autres. Les confondre transforme une déclaration de compatibilité en certificat de résultat.

Cette analyse ne reprend ni l’histoire générale de CCP dans RFC 1962, ni le format série de RFC 1963, ni le réordonnancement multilink de RFC 1990. Elle ne mesure aucun déploiement actuel. Son objet est plus net : dans BSD Compress, « non compressé » qualifiait ce qui traversait le fil, pas ce qui arrivait au dictionnaire.

Sources