Resumen

  • RFC 3095 exigía que ROHC empezara en modo unidireccional, donde las renovaciones periódicas y el patrón observado sustituían a un canal de retorno inexistente.
  • El descompresor podía pedir luego el modo bidireccional optimista o fiable; sus acuses protegían un contexto de compresión, no demostraban la entrega extremo a extremo.

El primer paquete no podía suponer una respuesta

En un enlace radioeléctrico, una carga de voz pequeña podía viajar detrás de cabeceras IP, UDP y RTP mucho mayores. Omitir campos constantes o previsibles ahorraba capacidad, pero obligaba al receptor a reconstruirlos desde un estado compartido. Si se perdía una actualización, paquetes posteriores podían quedar dañados aunque el enlace los entregara intactos.

RFC 3095 separó estado y modo. Los estados IR, FO y SO del compresor describían cuánto se conocía del comportamiento de la cabecera. Los estados sin contexto, contexto estático y contexto completo del descompresor indicaban qué podía reconstruirse. El modo resolvía otra cuestión: ¿qué autoridad de retorno existía de verdad?

La respuesta inicial era prudente. La compresión debía comenzar en U-mode. Allí el compresor avanzaba mediante un enfoque optimista cuando estaba razonablemente seguro de haber repetido información suficiente. Temporizadores, renovaciones y cambios irregulares lo obligaban a volver a formatos más completos.

La confianza razonable no era un acuse. Era una forma de limitar el daño del silencio sin presentarlo como prueba de recepción.

El descompresor abría los modos bidireccionales

El compresor no podía declarar por sí solo que había canal de vuelta. Tras recibir un paquete, el descompresor podía enviar feedback con el modo deseado. Así podía iniciarse la transición a O-mode o R-mode.

La dirección de esa decisión tenía sentido operativo. El compresor observaba lo enviado; el descompresor observaba si su contexto reconstruía correctamente. Quien sufría el fallo inmediato podía pedir una disciplina distinta a quien elegía el siguiente formato.

RFC 4815 aclaró después que la transición pretendía mover ambos extremos de forma coherente mediante un intercambio de tres pasos. Los paquetes alrededor del cambio debían decodificarse con la regla antigua o nueva según el punto exacto. El nombre del modo no sustituía al procedimiento.

El modo optimista gastaba poco feedback

O-mode empleaba el retorno para pedir recuperación y, opcionalmente, acusar actualizaciones importantes del contexto. Las actualizaciones puras del número de secuencia no tenían el mismo trato y desaparecían las renovaciones periódicas. El objetivo era alta eficiencia con uso escaso del canal inverso.

Esa economía no eliminaba el riesgo. Permitía reaccionar a daños detectados, pero RFC 3095 advertía que las ráfagas largas de pérdidas o errores podían invalidar el contexto con más frecuencia que en R-mode.

El objeto del feedback era local. Un NACK describía el estado de reconstrucción; no decía si una trama de voz era inteligible, si la aplicación aceptó los datos o si el usuario recibió el servicio.

El modo fiable aseguraba referencias

R-mode usaba el retorno con mayor intensidad y aplicaba lógica más estricta. Acusaba todas las actualizaciones del contexto, incluidas las del número de secuencia, aunque no todos los paquetes lo actualizaban. El principio de referencia segura permitía que solo un paquete con CRC de siete u ocho bits cambiara el contexto y sirviera de referencia futura.

Era una fiabilidad específica: reducir la propagación de pérdidas y daños cuando se perdían o corrompían cabeceras y mensajes de retorno. El RFC seguía contemplando errores residuales y CRC limitados. “Fiable” no certificaba la carga, la aplicación ni la ruta completa.

El canal de vuelta también costaba

RFC 3096 situó el trabajo en enlaces con tasas altas de error y grandes retardos, incluidos WCDMA, EDGE y CDMA-2000. Exigía transparencia semántica: la cabecera reconstruida debía ser equivalente a la original o el paquete debía descartarse. También exigía minimizar la propagación de errores.

El cálculo no podía esconder el control. Los canales auxiliares y el feedback contaban como sobrecarga. Una cabecera diminuta de ida no representaba el coste completo si necesitaba acuses y recuperación de vuelta.

RFC 3409 hizo visible la dependencia inferior. U-mode podía funcionar sin retorno. O-mode y R-mode necesitaban que la capa de enlace transportara mensajes inversos con rapidez suficiente. El protocolo aprovechaba una capacidad real; no podía asumirla.

La evolución documental no demostraba despliegue

RFC 4815 reunió correcciones. RFC 4995 separó el marco de los perfiles y señaló que partes del texto anterior habían resultado complejas u oscuras para los implementadores, a la vez que describía compatibilidad. RFC 5225 definió perfiles ROHCv2 simplificados y mecanismos para pérdidas y reordenamiento.

RFC 3241 también estandarizó negociación ROHC sobre PPP. Son pruebas de especificación, no de uso por un operador concreto, ahorro medido de espectro, traspaso exitoso ni interoperabilidad entre productos identificados.

La frontera histórica perdura. RFC 3095 trató el retorno como capacidad orientada, costosa y observada por el extremo que reconstruía. Separó la predicción del compresor, la confirmación local del descompresor y el resultado extremo a extremo que todavía requería otra evidencia.

Fuentes

  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