Résumé

  • RFC 3095 exigeait que chaque contexte ROHC débute en mode unidirectionnel, où les rafraîchissements périodiques remplaçaient une voie de retour absente.
  • Le décompresseur pouvait ensuite demander un fonctionnement bidirectionnel optimiste ou fiable ; ces modes dépensaient différemment le retour d'information sans jamais prouver le résultat de bout en bout.

Le premier paquet ne pouvait présumer une réponse

Sur une liaison radio coûteuse, les en-têtes IP, UDP et RTP peuvent peser lourd face à une petite charge vocale. Beaucoup de champs restent fixes ou évoluent de façon prévisible. Les omettre économise des bits, mais oblige le récepteur à les reconstruire à partir d'un état partagé. Une mise à jour perdue peut alors rendre inutilisables des paquets que la liaison a pourtant livrés.

RFC 3095 sépare deux dimensions. Les états du compresseur — initialisation et rafraîchissement, premier ordre, second ordre — décrivent la maturité du modèle. Les états du décompresseur — aucun contexte, contexte statique, contexte complet — décrivent ce qui peut être reconstruit. Le mode répond à une autre question : quelle autorité de retour existe réellement entre les deux extrémités ?

La règle initiale est nette : la compression doit commencer en mode unidirectionnel. U-mode fonctionne si le retour du décompresseur est impossible ou indésirable. Le compresseur progresse selon une approche optimiste lorsqu'il estime avoir répété assez d'information. Des temporisations, des rafraîchissements et des irrégularités de champs le ramènent vers des formats plus riches.

Cette confiance n'est pas un accusé de réception. Elle borne le prix du silence ; elle ne transforme pas le silence en preuve.

Le décompresseur ouvrait les modes bidirectionnels

Le compresseur ne pouvait pas proclamer qu'une voie de retour existait. Après réception d'un paquet, le décompresseur pouvait envoyer un message indiquant le mode souhaité. Ce geste pouvait engager le passage de U-mode vers un mode bidirectionnel.

La répartition est logique. Le compresseur sait ce qu'il a émis. Le décompresseur sait si son contexte permet de reconstruire l'en-tête. L'acteur qui observe l'échec immédiat peut donc demander une autre discipline à l'acteur qui choisit le prochain format.

RFC 4815 a ensuite précisé que la transition utilisait une négociation en trois temps afin que les deux côtés changent de règle de façon cohérente. Les paquets situés autour de la frontière devaient encore être interprétés sous l'ancien ou le nouveau mode au bon moment. Le mot « fiable » ne remplaçait pas ce protocole de transition.

Le mode optimiste économisait volontairement le retour

O-mode ajoutait une voie de retour pour les demandes de récupération et, facultativement, pour l'accusé de réception des mises à jour importantes du contexte. Les simples mises à jour de numéro de séquence n'étaient pas traitées de la même manière. Les rafraîchissements périodiques disparaissaient.

Le but était une compression efficace avec un usage parcimonieux du canal inverse. Cette économie déplaçait le risque. O-mode pouvait réagir à une invalidation détectée, mais RFC 3095 avertissait que les longues rafales de pertes ou d'erreurs pouvaient invalider le contexte plus souvent qu'en R-mode.

Le retour portait sur le contexte de compression. Un NACK n'indiquait pas si une parole avait été comprise, si l'application avait consommé la charge ou si un utilisateur avait reçu le service attendu.

Le mode fiable sécurisait les références

R-mode utilisait plus intensément le retour et une logique plus stricte. Toutes les mises à jour de contexte, y compris celles du champ de numéro de séquence, devaient être acquittées, même si chaque paquet ne modifiait pas le contexte. Le principe de référence sûre réservait la mise à jour du contexte et le rôle de référence aux paquets munis d'un CRC de sept ou huit bits.

La fiabilité visée était précise : réduire la propagation des pertes et des dommages lorsque des en-têtes ou des retours disparaissent. Elle ne rendait pas l'échec impossible. RFC 3095 examine encore les erreurs résiduelles et la couverture imparfaite. R-mode certifie une discipline de synchronisation relative aux deux autres modes, pas l'issue du flux applicatif.

Le canal inverse faisait partie du coût

RFC 3096 explique le contexte : liens à taux d'erreur élevé et longs délais aller-retour, notamment WCDMA, EDGE et CDMA-2000. Le document exigeait une transparence sémantique : l'en-tête reconstruit devait équivaloir à l'original, sinon le paquet devait être rejeté. Il définissait aussi la propagation d'erreur, lorsqu'une perte antérieure condamne des en-têtes ultérieurs pourtant reçus.

Surtout, le calcul d'efficacité devait compter les canaux auxiliaires de contrôle et de retour. Un minuscule en-tête aller n'était pas gratuit s'il exigeait des accusés, des demandes de récupération ou un trafic inverse.

RFC 3409 a traduit cette dépendance pour les couches inférieures. U-mode ne nécessitait aucun retour. O-mode et R-mode exigeaient le transport des messages inverses, idéalement sans retard. Le protocole utilisait une capacité fournie par la liaison ; il ne pouvait l'inventer.

Les textes ultérieurs ne prouvaient pas l'exploitation

RFC 4815 a rassemblé corrections et clarifications. RFC 4995 a séparé le cadre des profils et signalé que les implémenteurs avaient trouvé RFC 3095 complexe ou parfois obscur, tout en décrivant les deux définitions comme compatibles. RFC 5225 a défini des profils ROHCv2 simplifiés, mieux armés pour les pertes et le réordonnancement.

Cette continuité prouve un travail de spécification. RFC 3241 prouve aussi qu'un mécanisme de négociation ROHC sur PPP a été normalisé. Aucun de ces faits ne démontre l'usage par un opérateur nommé, une économie de spectre mesurée, un handover réussi ou l'interopérabilité de deux produits précis.

La leçon historique tient dans la limite. RFC 3095 a traité le retour comme une capacité orientée, coûteuse et détenue par l'extrémité qui observe la reconstruction. Elle a distingué ce que le compresseur prévoit, ce que le décompresseur confirme sur leur contexte commun et ce qu'une observation de bout en bout doit encore établir.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3095.html
  2. https://www.rfc-editor.org/info/rfc3095
  3. https://datatracker.ietf.org/doc/rfc3095/
  4. https://www.rfc-editor.org/rfc/rfc3096.html
  5. https://www.rfc-editor.org/info/rfc3096
  6. https://datatracker.ietf.org/doc/rfc3096/
  7. https://www.rfc-editor.org/rfc/rfc1144.html
  8. https://www.rfc-editor.org/rfc/rfc2508.html
  9. https://www.rfc-editor.org/rfc/rfc3241.html
  10. https://www.rfc-editor.org/rfc/rfc3409.html
  11. https://www.rfc-editor.org/rfc/rfc4815.html
  12. https://www.rfc-editor.org/info/rfc4815
  13. https://www.rfc-editor.org/rfc/rfc4995.html
  14. https://www.rfc-editor.org/rfc/rfc5225.html