Résumé

  • La RFC 3321 permettait au compresseur de prendre un accusé explicite comme preuve qu’un état avait bien été établi chez le décompresseur distant.
  • Cette preuve n’était pas permanente : la pression mémoire et les règles de rétention pouvaient supprimer l’état, y compris après la transmission d’une indication qui semblait le confirmer.

Le paradoxe de la priorité la plus forte

Un « checkpoint state » semble, par son nom, offrir un sol ferme. Dans la RFC 3321, le compresseur lui attribue la plus forte priorité de rétention qu’il ait envoyée et exige un accusé explicite. Pourtant, le texte demande ensuite au compresseur d’inférer si un ancien point de contrôle a été supprimé lorsqu’un nouveau point de contrôle consomme la mémoire disponible. La priorité protège relativement ; elle n’abolit pas la finitude.

Cette nuance révèle le problème historique des opérations étendues de SigComp. La compression dynamique voulait réutiliser l’histoire d’un échange afin d’alléger les messages de signalisation suivants. Mais cette histoire résidait chez deux machines qui ne voyaient pas exactement le même présent. Le compresseur conservait un modèle de ce que le décompresseur avait en mémoire. L’accusé servait à améliorer ce modèle, sans le rendre intemporel.

La RFC 3321 est un document informatif de janvier 2003. Elle n’apporte aucune mesure d’adoption ni de gain réel. Elle décrit comment exploiter les instructions de la machine virtuelle de décompression universelle définie par la RFC 3320. Son intérêt réside ici dans la discipline de preuve : avant de référencer un état distant, le compresseur doit savoir qu’il a été établi ; après l’accusé, il doit encore suivre les événements susceptibles de le faire disparaître.

Trois raisons pour une même absence

Le mécanisme de point de contrôle énumère trois chemins vers un état introuvable. Le message qui devait le créer peut être perdu. La mémoire peut être insuffisante au moment de la création. Enfin, l’état peut être créé correctement puis supprimé plus tard faute de mémoire. Ces scénarios aboutissent au même symptôme au moment de la décompression, mais ils ne racontent pas la même histoire.

Le troisième est le plus important pour l’accusé. Si le décompresseur a enregistré l’état et a renvoyé sa confirmation, les deux journaux peuvent être vrais : « état établi » à l’instant A, « état absent » à l’instant B. Qualifier le second événement de contradiction reviendrait à ignorer la règle de suppression qui relie les deux.

La RFC 3321 demande donc au compresseur de suivre la quantité de mémoire que le pair annonce. Le paramètre state_memory_size aide à déduire qu’une création ultérieure a pu évincer un point de contrôle précédent. Ce n’est pas un inventaire nominatif de la mémoire distante. Il ne répond pas directement à la question « cet identifiant précis existe-t-il maintenant ? ». Il fournit une contrainte à partir de laquelle l’émetteur reconstruit un état probable avec l’ordre des créations, leur âge et leur priorité.

La livraison fiable ne suffit pas

Le document oppose le transport fiable, comme TCP, qui garantit la réception des messages antérieurs, au transport non fiable, pour lequel un accusé SigComp explicite devient nécessaire. La réception fiable ferme la question de la perte sur le chemin. Elle ne réserve pas de mémoire chez le pair. Elle ne prouve ni l’autorisation applicative de créer l’état, ni sa survie après de nouvelles allocations.

Cette frontière sépare aussi la présente analyse de l’article consacré à la RFC 3320. Celui-ci expliquait pourquoi une décompression réussie n’autorise pas automatiquement la création d’un état persistant : l’application doit accepter le compartiment. Ici, la création est déjà autorisée et attestée. La question est devenue temporelle : combien de temps cette attestation reste-t-elle une base sûre pour le message suivant ?

Une confirmation implicite traversée par l’éviction

La compression partagée rend le problème moins intuitif encore. Un compresseur peut conserver la version non compressée d’un message comme état partagé. Quand l’autre extrémité se sert de cet état, cette utilisation peut confirmer implicitement qu’un état compagnon a été créé chez elle. L’optimisation évite d’envoyer un acked_state_id distinct.

Mais la RFC 3321 prévient que l’information d’annonce peut être transmise avec succès alors que l’état correspondant est ensuite abandonné faute de mémoire. Le signal est arrivé ; son référent n’est plus là. Sans suivi de state_memory_size, le prochain message peut dépendre d’un passé que seul le compresseur croit encore présent.

Le format étendu renforce cette obligation d’interprétation. Un identifiant partiel peut renvoyer à un état confirmé, partagé ou global. L’implémentation doit en déduire le type, et une implémentation SigComp de base peut ignorer les indications étendues. La présence d’un identifiant sur le fil ne constitue donc pas une preuve autosuffisante. Il faut connaître le mécanisme qui l’a produit et la cartographie locale qui le relie à un état précis.

La correction de 2007

La RFC 4896 a clarifié le régime de rétention. La valeur 65535, malgré son apparence, est la priorité minimale ; viennent ensuite 0, 1 et ainsi de suite jusqu’à 65534. La priorité appartient à la référence du compartiment, pas simplement à un bloc de données global.

Ses exemples montrent surtout qu’avec plusieurs états de priorité minimale, le compresseur peut ne plus savoir lesquels subsistent. Un nouvel état peut pousser l’ancien hors de la mémoire alors même que les deux extrémités appliquent correctement les règles. La correction recommande donc de ne pas référencer un état si son existence n’est pas certaine. Une annonce promet une disponibilité conforme aux règles d’âge et de priorité ; elle ne promet pas l’immortalité.

La RFC 4077 ajoutera ensuite le NACK STATE_NOT_FOUND. Ce message signale qu’un état référencé n’a pu être trouvé et conduit normalement le compresseur à cesser de l’utiliser. Il ne révoque pas rétroactivement l’accusé antérieur. Il ajoute un fait plus récent à une chronologie où création et suppression peuvent toutes deux être légitimes.

La contribution de la RFC 3321 tient ainsi dans une phrase : un reçu est daté, même lorsque le protocole ne lui imprime pas une date visible. La compression sûre dépend non seulement de ce que le pair a confirmé, mais aussi de tout ce qui a pu se produire depuis.

Sources