Résumé

  • Le profil LZS de la RFC 2395 enfermait une fenêtre glissante de 2 048 octets dans un seul datagramme : remise à zéro avant chaque entrée, vidage complet avant émission, nouvelle remise à zéro à la réception.
  • Le marqueur de fin séparait le flux comprimé du bourrage, sans fournir intégrité, identité, chiffrement ni preuve de livraison.
  • Les quelque 90 octets et les ratios du Calgary Corpus décrivaient une expérience bornée ; négociation, usage effectif, gain de taille, décompression et résultat applicatif restaient des faits distincts.

La panne qui ne devait pas se propager

Imaginons trois datagrammes. Le premier apprend au compresseur une longue séquence. Le deuxième la réutilise par une référence courte. Le troisième fait de même. Si le premier disparaît, les deux suivants deviennent illisibles bien qu'ils aient atteint leur destination. Une optimisation locale a transformé une perte unique en panne en chaîne.

La RFC 2395 interdit cette dépendance. LZS dispose bien d'une fenêtre glissante de 2 048 octets, mais l'émetteur doit la réinitialiser avant chaque charge utile. Le récepteur doit faire de même avant toute décompression. Les répétitions utiles sont donc celles du datagramme courant, jamais celles d'un paquet antérieur.

Cette règle correspond à la réalité du réseau IP. L'ordre d'arrivée n'est pas une garantie. La route peut changer, une file peut retarder un paquet et un routeur peut en supprimer un autre. Le profil n'a pas demandé au réseau de se comporter comme un flux fiable ; il a adapté la durée de vie de l'état au service réellement fourni.

Le prix est visible. Une chaîne répétée au début du paquet suivant ne bénéficie d'aucun souvenir. Une petite charge utile donne peu de matière à la fenêtre. Mais le domaine de panne reste un paquet. L'efficacité moyenne cède devant une propriété de récupération explicable.

Vider le compresseur fermait le présent

Réinitialiser l'historique ne suffisait pas. Un compresseur de flux peut recevoir des données sans produire immédiatement tous les bits correspondants. Il attend la suite pour choisir un codage plus compact. Dans un datagramme, cette attente créerait une dette envers un paquet futur.

La RFC exige donc un vidage à chaque émission comprimée. Tous les octets fournis doivent se retrouver dans la sortie du même datagramme. Rien ne peut rester dans le compresseur dans l'espoir d'être mieux codé plus tard. La frontière de livraison et la frontière de compression redeviennent la même frontière.

Il faut toutefois résister au mot « complet ». Le vidage atteste seulement que l'encodeur n'a pas gardé d'entrée. Il ne dit pas que le réseau a livré le paquet, que le décodeur l'a accepté, que les contrôles de transport ont réussi ou que l'application a accompli son travail. La preuve de fermeture d'un encodeur ne vaut pas preuve d'effet.

Cette adaptation distingue le profil IP des profils PPP. Les RFC 1967 et 1974 utilisent également LZS, mais dans un environnement de liaison doté de choix d'historique, de numéros de séquence ou de mécanismes de réinitialisation. Le nom de l'algorithme n'impose donc pas une durée de mémoire. C'est le profil qui décide où l'état commence, où il finit et comment une divergence est réparée.

Neuf bits pour dire « arrêtez ici »

Le codage LZS alterne des octets bruts et des références longueur-déplacement. Son flux se termine par un marqueur défini. Comme le dernier code ne tombe pas nécessairement sur une limite d'octet, des bits ou des octets de bourrage peuvent suivre. Le marqueur permet au décodeur de distinguer la fin réelle de l'alignement.

Cette précision ferme la grammaire du flux. Sans elle, le bourrage pourrait être lu comme une instruction supplémentaire. Avec elle, la charge utile transmise reste composée d'octets entiers tandis que le sens s'arrête au bon bit.

Le marqueur n'est pourtant ni une empreinte ni une signature. Un attaquant peut fabriquer une séquence bien fermée. Un paquet corrompu peut contenir accidentellement un motif valide. La présence du marqueur ne prouve ni l'auteur, ni l'intégrité, ni l'autorisation, ni l'utilité de la sortie. Elle permet seulement au décodeur de reconnaître la limite annoncée du langage LZS.

Un accord sur LZS n'était pas un ordre de comprimer

La RFC 2395 associait IPCOMP_LZS à la négociation ISAKMP et à la configuration manuelle d'une association IPComp. Aucun autre paramètre LZS n'était requis. Cet accord rendait le décodeur identifiable ; il ne transformait pas chaque datagramme.

La règle générale d'IPComp restait souveraine au niveau du paquet. Si la charge comprimée, ajoutée à l'en-tête IPComp, n'était pas plus petite que l'original, l'émetteur devait envoyer la forme originale sans en-tête IPComp. La RFC 3173 a ensuite conservé ce principe en remplaçant la RFC 2393.

Deux erreurs d'observation deviennent alors possibles. La première consiste à voir un paquet non comprimé et à conclure que l'association a échoué. Il peut s'agir du résultat conforme d'une comparaison de taille. La seconde consiste à voir le protocole 108 et à annoncer un succès : l'en-tête indique un traitement déclaré, pas l'acceptation du décodeur ni le travail accompli au-dessus.

LZS n'intégrait pas de test adaptatif de compressibilité. Une implémentation pouvait mémoriser localement qu'un type de trafic se comprimait mal et éviter des essais coûteux, mais cette politique ne faisait pas partie de l'algorithme. La capacité partagée et la décision locale demeuraient séparées.

Le seuil de 90 octets avait un nom de corpus

La RFC rapporte des essais informels sur le Calgary Corpus. Autour de 90 octets, une charge pouvait en moyenne s'agrandir ; les implémentations pouvaient donc préférer ne pas tenter la compression sous ce niveau. L'annexe montre aussi un ratio passant d'environ 1,18 pour 64 octets à 2,14 pour 16 384 octets.

La tendance s'explique : plus le datagramme est long, plus la fenêtre remise à zéro a le temps de trouver des répétitions, et plus le coût fixe de la fermeture et de l'en-tête devient faible en proportion. Mais la mesure porte le nom de ses données. Le Calgary Corpus n'est ni du trafic chiffré, ni une collection d'images déjà comprimées, ni tous les messages de contrôle, ni un échantillon de l'Internet contemporain.

Le nombre 90 n'est donc pas une constante du fil. Il ne permet pas de rejeter un paquet, de certifier un gain ou de comparer deux produits sans reproduire les conditions. La RFC 2394 proposait un autre profil, DEFLATE, avec son propre contexte. La RFC 3051 a plus tard discuté le coût de remise à zéro d'un autre dictionnaire. Ces rapprochements montrent que la frontière du paquet compte ; ils ne rendent pas les résultats interchangeables.

La RFC 3819 a ensuite rappelé un principe opérationnel : des données déjà comprimées ou chiffrées offrent peu de redondance à exploiter. Là encore, la nature réelle du flux prime sur l'étiquette « compression activée ».

Une ligne de licence appartenait aussi à l'histoire

Le document indiquait qu'Hi/fn détenait alors des brevets sur LZS et décrivait plusieurs formes de licence. Cette information influençait l'adoption sans modifier un seul bit du format. Une technique peut être interopérable et rester soumise à un calcul économique ou juridique local.

Il faut conserver la date de cette affirmation. La RFC prouve ce qu'elle déclarait en 1998, pas le propriétaire, la validité, le prix ou la disponibilité d'une licence aujourd'hui. Transformer un paragraphe historique en conseil juridique contemporain serait une autre confusion de couches.

La force de la RFC 2395 réside ainsi dans une spécification minimale. Les pairs partagent la remise à zéro, le vidage, le codage et la fermeture. L'opérateur garde le seuil, le choix d'adoption et l'évaluation du trafic. Le paquet exécuté et le résultat applicatif peuvent ensuite contredire les attentes du tableau.

Oublier était une forme de résilience

Dans beaucoup de systèmes, davantage de mémoire paraît toujours préférable. Ici, le refus d'hériter était la protection. Un datagramme survivant portait tout ce qui était nécessaire à sa reconstruction. La perte restait locale. Le réordonnancement cessait d'être une divergence de dictionnaire.

Cette leçon dépasse LZS. Toute optimisation avec état doit annoncer la durée et le propriétaire de cet état. Si le service inférieur ne garantit pas l'ordre ou la livraison, une mémoire cachée peut inventer une dépendance que le réseau n'a jamais promise.

Il faut donc garder six reçus : algorithme disponible, association convenue, historique effectivement remis à zéro, paquet réellement comprimé, sortie correctement reconstruite et effet observé par l'application. La RFC 2395 les reliait sans les confondre.

Sources