Résumé

  • RFC 1553 comprimait les en-têtes IPX en conservant leur forme complète dans des cases correspondantes chez l’émetteur et le récepteur. L’information omise devenait une mémoire distribuée.
  • Pour un contexte IPX général, un paquet Initial confirmé et son Confirm devaient établir le couple case-identifiant avant l’envoi comprimé. Omettre aussi le numéro de case exigeait que toute erreur de réception soit visible du décompresseur.
  • Le rapport proche de 2:1 était un calcul illustratif fondé sur des tailles supposées. Le statut Standards Track de 1993 et le statut Historic actuel ne prouvent ni déploiement, ni performance mesurée, ni résultat applicatif.

La compression commençait dans deux mémoires

Sur une liaison lente, répéter trente octets d’en-tête IPX pour un échange dont les adresses et le type varient peu paraît coûteux. L’intuition de CIPX consistait à ne plus transporter ce que les deux extrémités pouvaient déjà connaître.

Mais « déjà connaître » n’est pas une propriété du paquet. C’est une relation entre deux états.

RFC 1553, Compressing IPX Headers Over WAN Media (CIPX), a formalisé cette relation. Sa fiche IETF et sa fiche RFC Editor l’identifient comme un document Standards Track de décembre 1993, produit par le groupe Point-to-Point Protocol Extensions; il est aujourd’hui classé Historic. La version texte conserve la spécification et le registre d’errata fournit une surface de contrôle documentaire.

Ces sources établissent un contrat publié. Elles ne décrivent pas un parc installé, une version de produit, une campagne d’essais ou un gain observé chez un client.

Le point historique le plus fécond n’est donc pas seulement la réduction de taille. C’est le déplacement de l’autorité. Les octets qui quittaient le fil entraient dans une table partagée que le protocole devait maintenir, versionner et réparer.

Deux méthodes, deux propriétés de récupération

L’en-tête IPX ordinaire mesurait trente octets. RFC 1553 imposait une méthode générale capable de le ramener à un à sept octets. Elle pouvait s’appliquer à n’importe quel paquet IPX sans dépendre du protocole de transport.

Une seconde méthode comprimait ensemble les en-têtes IPX et NCP. Elle visait les requêtes et réponses NCP de types 0x2222 et 0x3333, faisant passer un en-tête combiné de trente-six octets à un à huit. Les autres types NCP restaient compressibles au niveau IPX, mais ne bénéficiaient pas de la règle propre au couple NCP/IPX.

La séparation n’était pas décorative. Les requêtes et réponses NCP possédaient un numéro de séquence et un comportement de retransmission capables de rendre certaines pertes visibles. Un datagramme IPX général n’offrait pas la même preuve.

Le document permettait aussi d’associer compression d’en-tête et compression de données. Leur ordre faisait partie du format effectif: à l’émission, l’en-tête devait être comprimé avant les données; à la réception, les données devaient être décomprimées avant la reconstruction de l’en-tête. Un inventaire disant simplement « deux compressions actives » manquerait l’ordre qui conditionnait leur décodage.

Le mécanisme reconnaissait l’influence de RFC 1144, consacré à la compression TCP/IP sur liaisons série lentes; sa fiche en fournit le contexte. Cette filiation technique ne prouve pas que CIPX ait repris chaque règle de récupération de TCP, ni qu’il ait connu la même trajectoire opérationnelle.

Une case n’était pas son contenu

Après négociation de CIPX, tous les paquets IPX de la liaison recevaient un octet de drapeaux CIPX, y compris un paquet Regular envoyé sans compression d’en-tête. L’émetteur et le récepteur tenaient des tables distinctes. Dans chaque case, ils conservaient l’en-tête complet associé à une connexion.

Le compresseur comparait le paquet courant à sa copie afin de choisir les différences à transmettre. Le décompresseur appliquait ces différences à sa propre copie pour reconstruire l’en-tête remis à IPX.

Le plus petit paquet comprimé ne portait que l’octet de drapeaux. Selon les bits présents, il pouvait ajouter le numéro de case, le checksum, la longueur ou le numéro de tâche NCP. Quand un champ était absent, le récepteur devait consulter une autre autorité: la case précédente, la convention 0xFFFF, la longueur donnée par la couche MAC ou la dernière tâche connue.

L’absence n’était donc jamais vide. Elle signifiait « reprendre cette valeur selon cette règle ». Pour vérifier un paquet comprimé, il ne suffit pas de posséder ses octets. Il faut aussi connaître la génération de la case, l’Initial qui l’a installée, les mises à jour suivantes, les pertes intermédiaires et les hypothèses utilisées pour chaque champ omis.

Un numéro de case désigne un emplacement. Il ne prouve pas que les deux extrémités y ont conservé le même contenu.

Initial et Confirm établissaient une génération

La perte du premier paquet d’un contexte IPX général créait un problème particulier. Si l’Initial disparaissait, un paquet comprimé ultérieur ne contenait plus assez d’information pour être reconstitué. L’en-tête IPX ne permettait pas, à lui seul, de reconnaître sûrement une retransmission qui réparerait l’état.

RFC 1553 introduisait alors le Confirmed Initial. Ce paquet transportait le paquet IPX complet, un numéro de case et un identifiant d’un octet. Le Confirm du récepteur répétait la case et l’identifiant. Le compresseur ne pouvait commencer les trames comprimées de ce contexte qu’après cette réception.

Le couple case-identifiant nommait une génération d’en-tête. Lorsqu’une case recevait un nouvel en-tête, l’identifiant augmentait. Le texte ne promettait pas une unicité éternelle: il demandait qu’une combinaison ne se répète pas pendant une période « raisonnablement longue », dépendante de la vitesse de transmission, du délai aller-retour et de la charge.

Cette limite empêche de confondre identité de stockage et identité historique. « Case 7 confirmée » reste insuffisant si le journal ne dit pas quel identifiant a été confirmé.

L’émetteur n’était pas obligé d’attendre sans rien transmettre. Pour le même en-tête, il pouvait renvoyer un Confirmed Initial avec la même case et le même identifiant, mais de nouvelles données. Pour un autre en-tête, il pouvait réutiliser une case encore non confirmée en augmentant l’identifiant. Le protocole conservait le débit possible tout en rendant le changement de génération explicite.

Un Confirm attestait la réception de cette association. Il n’attestait ni chaque paquet futur, ni la validité de la reconstruction dans l’application.

NCP autorisait un risque mieux borné

Pour les requêtes et réponses NCP, le numéro de séquence devait normalement augmenter d’une unité. Les mécanismes de transport pouvaient retransmettre un paquet perdu. RFC 1553 utilisait cette propriété pour proposer un Unconfirmed Initial: après l’avoir envoyé, le compresseur pouvait commencer immédiatement les paquets comprimés.

Cette voie ne supprimait pas la nécessité de détecter la divergence. Elle déplaçait le signal. Si le numéro reçu n’était pas exactement supérieur d’une unité au précédent, un nouvel Initial devait être envoyé, même si la même case était conservée. Une perte pouvait aussi apparaître par un checksum significatif incorrect ou par la retransmission ultérieure.

La règle restait spécifique au type de trafic. Elle ne s’étendait pas automatiquement à tout IPX. Un compteur de séquence n’est pas une garantie abstraite de cohérence; il devient utile seulement avec la valeur attendue, l’écart observé et l’Initial qui restaure le contexte.

Le journal de preuve doit donc dire quelle stratégie a comprimé le paquet. Sans cette information, « Initial non confirmé accepté » peut être une optimisation prévue ou une violation de la condition de récupération.

Omettre la case exigeait de voir chaque perte

Le protocole pouvait encore économiser un octet en omettant le numéro de case. Le paquet signifiait alors: utilisez la même case que le paquet précédent. Cette option, appelée compression de l’identifiant de case, était désactivée par défaut.

Sa condition d’activation était remarquable. Le décompresseur devait pouvoir comptabiliser chaque paquet erroné ou rejeté. Sur PPP, la couche liaison devait signaler l’erreur de réception au module de décompression. Sinon, la disparition du paquet qui avait changé de case rendait la notion de « case précédente » indéterminée.

Après un rejet, le décompresseur devait écarter tous les paquets suivants qui omettaient le numéro de case, jusqu’à l’arrivée d’un paquet qui le transportait explicitement.

Le protocole préférait donc une perte visible à une reconstruction inventée. Un paquet ultérieur pouvait être intact sur le fil; il restait inutilisable parce que l’histoire à laquelle il faisait référence n’était plus sûre.

Cette règle relie directement optimisation et observabilité. Enlever l’identifiant n’était permis qu’en ajoutant une preuve transversale: la couche qui observait l’erreur devait informer la couche dont l’état devenait ambigu. Si une mise à jour logicielle rompait ce chemin de notification sans désactiver l’option, la négociation resterait verte tandis que sa prémisse aurait disparu.

Les voies non comprimées empêchaient le mensonge

RFC 1553 conservait un paquet Regular. Il servait lorsqu’un paquet ne pouvait ou ne devait pas être comprimé, lorsque la mémoire manquait pour une nouvelle case, lorsqu’un flux était trop sporadique pour justifier son installation, ou lorsqu’une évolution future d’IPX rendrait l’algorithme inefficace.

Le format protégeait aussi le redémarrage d’un pair. L’octet de drapeaux CIPX ne pouvait jamais valoir 0xFF, car un en-tête IPX ordinaire commençait souvent par le checksum 0xFFFF. Sur une liaison persistante, un équipement pouvait redémarrer et reprendre l’envoi d’IPX normal sans l’enveloppe CIPX, tandis que son voisin conservait l’ancien état de compression. Celui-ci devait reconnaître l’en-tête normal et renégocier, pas forcer les octets dans une table périmée.

Un paquet Reject formait une troisième voie. Il permettait au décompresseur de signaler un type ou un drapeau dépendant qu’il ne comprenait pas. Les bits reconnus étaient effacés dans le retour, laissant apparaître les fonctions refusées. Prévoir des extensions ne signifiait pas accepter silencieusement leur sémantique.

Regular, redémarrage et Reject ne racontaient pas le même événement. Le premier était un choix valide à l’intérieur du mode négocié. Le deuxième révélait que la réalité du pair ne correspondait plus à l’état supposé. Le troisième établissait une incompatibilité visible de fonction. Les agréger sous « paquet non comprimé » ferait perdre la décision de réparation.

PPP et IPX-WAN ne négociaient pas de la même manière

Sur PPP, la compression était désactivée par défaut. Une option IPXCP annonçait la capacité de recevoir des paquets comprimés. Chaque extrémité devait la demander séparément pour obtenir une compression bidirectionnelle.

RFC 1552 et sa fiche bornent ce voisinage IPXCP. L’Article précédent conserve son propre sujet: la signification conditionnelle d’Opened, les Desired Parameters et le second négociateur. Ici, la question commence après la permission de comprimer: quelles preuves maintiennent la table de reconstruction?

IPX-WAN pouvait aussi négocier CIPX. Dans cette voie, les paramètres étaient symétriques: même nombre de cases et mêmes options dans les deux directions. La réponse acceptée ne pouvait retenir qu’un sous-ensemble de la demande.

Le mot CIPX ne suffit donc pas pour inférer la forme du contrat. Il faut conserver le mécanisme de négociation, la direction, les valeurs proposées et celles effectivement retenues.

Les contemporains RFC 1548 et RFC 1661, ainsi que leurs fiches 1548 et 1661, donnent le cadre PPP. Le registre IANA des numéros PPP atteste l’attribution d’identifiants. Aucun de ces documents ne prouve que deux tables réelles aient convergé.

Le rapport de compression était un calcul, pas une mesure

RFC 1553 avançait un rapport proche de 2:1 pour un trafic IPX ordinaire, en comptant en-tête et données. La section de performance montrait les hypothèses: vingt-six octets de données en moyenne, trente octets d’en-tête non comprimé et deux octets d’en-tête comprimé.

Ce calcul éclaire le bénéfice attendu. Il ne constitue pas une observation de terrain.

Le résultat réel dépendrait de la taille des données, du nombre de connexions actives, des cases disponibles, de leur réutilisation, des paquets Initial et Confirm, des bascules vers Regular, des pertes, des retransmissions, du support physique et d’une éventuelle compression de données. Réduire les octets transmis ne prouve ni l’exactitude de l’en-tête reconstruit, ni la latence de l’application.

La section Security Considerations affirmait que CIPX ne modifiait pas significativement la sécurité de base d’IPX. C’est la limite d’analyse écrite dans le mémo. Elle ne devient pas une assurance contemporaine et n’autorise pas à imaginer un incident absent des sources.

La primauté du code exécuté de Heng Lu aide à distinguer calcul, décodeur réellement parcouru et résultat observé. Son principe de spécification initiale minimale et décision future localisée éclaire la séparation entre format commun et choix locaux de cases ou de repli. La discipline des couches de réalité empêche enfin identifiant enregistré, option négociée, état conservé, paquet reconstruit et effet utilisateur de se remplacer mutuellement. Ces essais ultérieurs sont un cadre déclaré, non une preuve des intentions privées des auteurs de 1993.

Les octets absents avaient toujours un dépositaire

Une trame CIPX compacte n’était complète qu’avec ce qui l’entourait: négociation, case, génération, Initial, Confirm éventuel, chemin de notification d’erreur et historique des paquets acceptés ou rejetés.

Un dossier opérationnel responsable conserverait le propriétaire et la direction de la négociation; les options et le nombre de cases; l’allocation et le couple case-identifiant; l’en-tête Initial complet; le Confirm requis; les erreurs remontées par la liaison; la suite des rejets; le choix explicite ou implicite de case; l’origine du checksum et de la longueur; l’empreinte de l’en-tête reconstruit; la décision du décompresseur; la récupération du transport; et le résultat de l’application.

La compression n’avait pas supprimé vingt-neuf octets. Elle avait confié leur garde à une histoire commune. Dès que cette histoire divergeait, le bon comportement n’était pas de deviner plus vite, mais de rendre le désaccord visible et de reconstruire l’autorité.

Sources