Resumen

  • RFC 2395 redujo la vida de la ventana LZS de 2.048 bytes a un datagrama: emisor y receptor debían reiniciar el historial para que cada paquete pudiera reconstruirse por sí solo.
  • El vaciado impedía que quedaran datos pendientes para el paquete siguiente y el marcador final separaba el código del relleno; ninguno de los dos probaba entrega, integridad ni autenticidad.
  • Los 90 bytes aproximados y los ratios del Calgary Corpus eran observaciones de una carga concreta, no umbrales universales ni promesas de rendimiento.

El diccionario no podía cruzar la frontera

LZS sustituía secuencias repetidas por referencias a una ventana deslizante. En un flujo continuo, conservar la ventana parecía obvio: más pasado significaba más coincidencias. IP no ofrecía, sin embargo, un flujo continuo. Un datagrama podía llegar antes que su predecesor o sobrevivir cuando otro se perdía.

Si el segundo paquete citaba bytes aprendidos en el primero, la pérdida del primero inutilizaba ambos. La compresión habría creado una garantía de orden que la capa IP nunca prometió. RFC 2395 respondió haciendo obligatoria la amnesia: reinicio del historial antes de comprimir y nuevo reinicio antes de descomprimir.

Así, una pérdida no desincronizaba un diccionario duradero. Cada paquete llevaba un problema completo. El coste era renunciar a repeticiones entre datagramas, sobre todo en cargas pequeñas. El perfil prefirió una falla acotada a un promedio más atractivo.

Los perfiles PPP demuestran que esta decisión no pertenecía inevitablemente al nombre LZS. RFC 1967 y RFC 1974 definían historiales y reparación dentro de una relación de enlace. El mismo algoritmo podía tener otra vida de estado. Era el perfil —no la marca del compresor— quien otorgaba autoridad a la memoria.

Vaciar era impedir una deuda futura

Incluso con el historial reiniciado, un codificador podía guardar bits esperando más entrada. Esa espera funciona en un flujo, pero rompe un datagrama: parte del contenido del paquete actual aparecería en una unidad futura que quizá tomara otra ruta o nunca llegara.

Por eso RFC 2395 exigía vaciar el compresor cada vez que se transmitía una forma comprimida. Todo byte de entrada debía quedar representado en la salida presente. Nada podía cruzar la frontera por conveniencia del codificador.

El recibo seguía siendo limitado. «Vaciado» significaba que el compresor no retuvo datos. No significaba que el receptor recibiera el datagrama, que aceptara el encabezado IPComp, que reconstruyera la carga o que una aplicación completara trabajo. Confundir cierre interno con resultado exterior era precisamente el tipo de salto que una arquitectura por capas debía evitar.

El marcador final resolvía el relleno

El código LZS no siempre terminaba en un límite de ocho bits. RFC 2395 definió un marcador final para que el decodificador supiera dónde acababa la información y dónde comenzaban bits u octetos de relleno. La carga transmitida seguía teniendo longitud entera en octetos.

Esa marca cerraba la gramática, no la confianza. No era hash, firma, checksum de aplicación ni prueba de origen. Una secuencia maliciosa también podía llevar un final bien formado. El marcador contestaba «¿dónde termina este flujo LZS?», no «¿quién lo envió?» ni «¿qué efecto produjo?».

Acordar el transformador no obligaba a usarlo

IPCOMP_LZS identificaba la transformación en ISAKMP y podía servir como CPI en una asociación configurada manualmente. El acuerdo permitía elegir el decodificador correcto. IPComp conservaba la decisión por datagrama: si carga comprimida más encabezado no era menor que el original, se enviaba la forma original sin encabezado IPComp.

RFC 3173 mantuvo esa regla al sustituir RFC 2393. Por ello, la ausencia de protocolo 108 no demuestra que la asociación fallara. Su presencia tampoco demuestra que la descompresión terminara bien. Asociación, elección del paquete, sintaxis, decodificación y resultado siguen siendo eventos distintos.

El LZS descrito no incluía una prueba adaptativa de compresibilidad. Un producto podía observar resultados anteriores y dejar de intentar ciertos flujos, pero esa política era local. No debía atribuirse al algoritmo ni convertirse en requisito común.

Un corpus no era todo Internet

Las pruebas informales con el Calgary Corpus sugirieron que por debajo de unos 90 bytes el resultado podía expandirse. La tabla del apéndice mostraba ratios crecientes con el tamaño: 1,18 para 64 bytes y 2,14 para 16.384. La propia frontera explica la tendencia: un paquete largo ofrece más repetición antes del siguiente reinicio.

La cifra tenía contexto. No describía datos cifrados, imágenes ya comprimidas, todos los protocolos de control ni tráfico contemporáneo. Era una pista para política local, no un campo del protocolo. RFC 2394 perfiló DEFLATE con otro contexto; RFC 3051 discutió después el coste de reiniciar otro diccionario. Las comparaciones enseñan a medir, no a copiar un número.

RFC 3819 añadió una advertencia operacional: una capa inferior obtiene poco de bytes ya comprimidos o cifrados. El nombre de la asociación nunca sustituye la distribución real de los datos.

La licencia también condicionaba la adopción

RFC 2395 declaró que Hi/fn poseía patentes sobre LZS en el momento de publicación y describió opciones de licencia. Esa información no alteraba el formato, pero sí el cálculo de quien debía implementarlo. La adopción era técnica, económica y jurídica a la vez.

La frase debe quedar fechada. No prueba la titularidad, vigencia, precio o disponibilidad actual de ningún derecho. Un registro histórico no se actualiza solo. Convertirlo en conclusión legal presente sería dar a una descripción antigua un poder que no tiene.

El valor estaba en la renuncia

RFC 2395 no maximizó memoria; maximizó independencia. No pidió a IP que garantizara orden para favorecer al compresor. Hizo que el compresor respetara la unidad que IP sí entregaba.

La lección permanece: cada optimización con estado debe revelar quién posee ese estado, cuánto dura y qué ocurre si falta una entrada. Un mejor ratio puede esconder una cadena de fallos más larga. Un indicador de «LZS negociado» puede ocultar paquetes correctamente enviados sin comprimir.

La observación honesta conserva recibos separados: transformador disponible, asociación aceptada, historial reiniciado, paquete comprimido o no, flujo cerrado, salida recuperada y efecto de aplicación. El código en ejecución decide los últimos pasos; el RFC sólo define su parte.

Fuentes