Résumé

  • En mode fiable, RFC 3408 ne permettait de remplacer par un paquet sans en-tête que le type R-0, lorsque la couche d’assistance pouvait restituer sans ambiguïté le type et la séquence.
  • Dès que cette restitution devenait incertaine, l’économie d’octet devait s’arrêter jusqu’à ce qu’une mise à jour acquittée ait franchi le point de rupture enregistré.

L’histoire ne commence pas par une nouvelle méthode de compression, mais par la forme rigide de certains canaux radio. Un en-tête ROHC d’un seul octet pouvait faire passer une petite trame vocale dans la classe de taille suivante. Le prix physique dépassait donc largement l’octet logique. RFC 3243 limitait bien l’ambition : la compression sans en-tête servait les applications dont la forme correspondait à ces liaisons, et non l’efficacité en général.

RFC 3242 avait déjà décrit cette opération pour les modes unidirectionnel et optimiste. Son exigence essentielle était facile à manquer : l’absence d’en-tête n’était possible que si une couche d’assistance fournissait autrement les fonctions retirées. Elle devait distinguer un paquet sans en-tête d’un paquet ROHC normal, conserver l’ordre attendu et signaler chaque perte pertinente. Le silence sur le fil devenait un contrat entre couches.

RFC 3408 étendit ce contrat au mode fiable. Il n’autorisa pas n’importe quel paquet compressé à disparaître. Seul R-0 pouvait être converti en NHP, le paquet sans en-tête. Le décompresseur reconstruisait le numéro de séquence RTP à partir de sa dernière référence sûre et d’un décalage. La norme ne prétendait pas qu’une formule universelle suffisait : le document propre à la technologie de liaison devait expliquer le calcul.

Deux chemins étaient proposés. Une réalisation pouvait compter les paquets qui ne modifiaient pas le contexte, ainsi que les indications de perte reçues depuis la dernière mise à jour réussie. Une autre pouvait s’appuyer sur une relation maintenue entre le temps de la liaison et la séquence RTP. Dans les deux cas, la couche inférieure devait produire une preuve, pas une intuition.

Le moment décisif survenait lorsque la couche d’assistance ne pouvait plus garantir le résultat. Elle enregistrait alors le numéro concerné comme SN_break et cessait d’envoyer des NHP. Pour reprendre, deux conditions étaient nécessaires : l’usage sans en-tête devait redevenir sûr et SN_ACKed, la dernière séquence acquittée, devait dépasser la rupture. Un acquittement ancien ne réparait rien.

L’attente passive pouvait durer jusqu’à une future mise à jour du contexte. RFC 3408 recommandait donc une interface optionnelle permettant à la couche d’assistance de demander au compresseur un paquet de mise à jour. Si cette requête se perdait entre des composants séparés, la conséquence définie était un retard dans le retour à l’efficacité. La règle de sécurité ne devenait pas plus souple pour autant.

Le contexte restait lui aussi bien délimité. En mode R, les NHP et les indications de perte ne mettaient à jour ni le contexte du compresseur ni celui du décompresseur. R-0 n’avait pas de CRC à remplacer. Le paquet R-0-CRC envoyé autour du bouclage des six bits assurait déjà une vérification périodique. Cette architecture explique aussi pourquoi les retours ACK intercalés étaient déconseillés : ils interrompaient la continuité de séquence et désactivaient temporairement les NHP.

La section de sécurité montrait l’autre prix de l’optimisation. De faux paquets de contrôle de contexte pouvaient provoquer des échecs CRC artificiels, invalider le contexte et déclencher davantage de retours et de rafraîchissements. L’attaquant ne gagnait pas nécessairement la parole ; il supprimait le bénéfice économique du profil.

Les cadres ROHC ultérieurs ont réorganisé l’architecture et ROHCv2 a défini d’autres profils. Ils ne transforment pas RFC 3408 en mesure de déploiement. Sa leçon historique est plus durable : une information retirée d’un paquet doit réapparaître sous forme d’obligations observables, sinon l’économie visible masque une dette de synchronisation.

Sources