Resumen

  • Si la compresión aumentaba el tamaño, RFC 1977 enviaba el paquete PPP original para no reducir la MTU efectiva, pero conservaba el cambio producido por el intento en el diccionario de ambos pares.
  • Al no haber un flujo LZW visible en ese paquete nativo, el código CLEAR no podía anunciar siempre el vaciado; emisor y receptor tenían que llegar por separado a la misma decisión adaptativa.
  • La secuencia de 16 bits descubría ciertos huecos antes de decodificar una trama comprimida y Reset-Request/Reset-Ack empezaba desde cero. Ninguno demostraba integridad, autenticidad ni reparación de lo perdido.

El cálculo que no se envió

La elección de RFC 1977 se entiende mejor siguiendo el tiempo. El emisor no sabía de antemano que un datagrama era incomprensible. Lo pasaba por BSD Compress, obtenía un resultado y comparaba tamaños. Cuando la salida crecía de manera significativa, debía conservar la encapsulación PPP ordinaria. Si el aumento era inferior a tres octetos, también debía preferir normalmente la forma nativa, salvo que el resultado cupiera en la MTU.

La ventaja evitaba reservar espacio para un sobre que podía empeorar el paquete. Sin ella, las capas superiores tendrían que tratar el enlace como si su MTU fuera menor. Sin embargo, el ensayo ya había ocurrido. LZW había recorrido el protocolo y los datos, creado combinaciones, contado octetos y quizá alcanzado una nueva anchura de código.

RFC 1977 no permitía que ese trabajo desapareciera solo porque su salida no viajaba. El siguiente paquete comprimido dependería de las entradas aprendidas. Por ello, un receptor que veía un protocolo nativo comprendido entre 0x0000 y 0x3FFF, con las excepciones de los propios tipos comprimidos, suponía que habría existido expansión y comprimía localmente los bytes para actualizar su historia.

La función de referencia pf_bsd_incomp no intenta reconstruir una carga recibida. Simula la operación que el emisor decidió no transmitir. Incrementa la secuencia, cuenta la entrada, calcula la salida hipotética y añade las mismas entradas. El paquete era nativo como representación; seguía siendo una entrada del protocolo de compresión.

El diccionario cruzó los límites del datagrama

Unix compress trabajaba con un archivo y podía olvidar su tabla al terminar. En PPP, RFC 1977 convirtió esa tabla en una conversación que continuaba entre datagramas. Dos máquinas separadas mantenían una memoria común sin enviarla explícitamente.

La opción de configuración solo fijaba el punto de partida. El tipo 21 identificaba BSD Compress. La versión era 001 y Dict indicaba la mayor anchura de código, entre 9 y 16 bits; el texto menciona 12 como valor habitual. El código incluido llegaba a 15, una limitación de esa realización, no de la opción definida.

Tener más memoria no autorizaba al receptor a escoger un diccionario mayor. La anchura cambia cuando se ocupan determinados códigos; la tabla llena activa la evaluación de rendimiento; el momento del vaciado depende de esos límites. Una diferencia local desplazaría toda la historia futura.

También importaba el tratamiento del campo Protocol original. Antes de calcular la secuencia o comprimir el conjunto, un valor inferior a 0x100 debía reducirse a un octeto, aunque PPP no hubiese negociado Protocol-Field-Compression. La regla eliminaba otra fuente de dos entradas distintas para el mismo datagrama.

PPP tenía que estar en la fase de protocolos de red y CCP en Opened antes de usar BSD Compress. Llegar a ese estado probaba que la opción había sido aceptada. No probaba que dos implementaciones, o un demonio de control y un módulo de núcleo, ejecutarían a tiempo cada actualización posterior.

Borrar a la vez sin recibir la orden

El compress clásico reservaba el código 256 para CLEAR. Dentro de una salida LZW, el emisor podía señalar que la tabla acababa de vaciarse. Un paquete PPP nativo no contenía códigos LZW. Si datos poco compresibles llenaban la tabla, el mensaje explícito podía faltar justo cuando más se necesitaba.

El RFC sustituyó el aviso por una condición reproducible. Su código de ejemplo revisa la relación de compresión cada 10.000 octetos cuando la tabla está llena. Si el nuevo rendimiento cae respecto del anterior o queda por debajo de uno a uno, pf_bsd_clear devuelve el sistema a códigos de nueve bits y reinicia entradas, relación y contadores.

El emisor toma esa decisión después de la compresión de prueba. El receptor llega a ella al simular el mismo datagrama nativo. Ambos deben contar los mismos octetos de entrada y el mismo tamaño codificado teórico. La ausencia de un CLEAR visible no elimina la frontera; traslada su prueba a la igualdad de los dos cálculos.

Ese diseño ahorra bytes y protege la MTU, pero hace que detalles de ejecución sean parte del contrato. El orden de los datagramas, la asignación de códigos, el cambio de anchura, el envejecimiento de contadores y la comprobación de la relación tienen que coincidir. Además, los primeros paquetes después del vaciado suelen ofrecer poca ganancia y viajan en forma nativa, idénticos a simple vista a los que circulaban antes de activar la compresión.

La secuencia solo habla cuando vuelve la compresión

El encabezado BSD Compress sí incluía una secuencia de 16 bits. Empezaba en cero tras limpiar la tabla, se incrementaba por cada paquete admisible—también por los nativos—y volvía a cero después de 65535. El receptor debía comprobarla antes de decodificar.

Un paquete nativo, no obstante, no llevaba ese encabezado. Si se perdía, el receptor podía seguir sin advertirlo. Su diccionario y su contador quedarían una entrada por detrás. La discrepancia aparecería cuando llegara una trama comprimida y su secuencia no coincidiera con la esperada.

El mecanismo evitaba aplicar códigos nuevos a una tabla que ya se sabía incorrecta. No explicaba cuál fue la pérdida, no diferenciaba pérdida de desorden, no recuperaba los bytes y no autenticaba a nadie. El FCS HDLC detectaba ciertas corrupciones en el enlace y los mecanismos normales las descartaban. La sección de seguridad de RFC 1977 no analiza seguridad. Un contador de 16 bits y un checksum de enlace no forman una prueba criptográfica.

El reinicio renuncia a la historia

Ante la primera secuencia inesperada, el receptor debía pedir un Reset-Request CCP y descartar paquetes comprimidos hasta obtener Reset-Ack. El transmisor limpiaba el diccionario y contestaba cada petición, porque no podía saber si un acuse anterior había llegado. El receptor limpiaba con cada acuse correspondiente, pues el otro lado ya lo habría hecho.

La metáfora del RFC es precisa: se abandona un “archivo” y se empieza otro. El reinicio no completa el pasado ni verifica sus paquetes; crea una base nueva. Una nueva Configure-Request podía forzar otra negociación, aunque con mayor coste.

El RTT limitaba la insistencia. En un enlace ocupado, varios paquetes comprimidos posteriores al error llegarían antes del acuse y serían descartados. Hacían falta suficientes retransmisiones para atravesar la pérdida, pero una cadencia superior al tiempo de ida y vuelta provocaba vaciados redundantes. El segundo citado por el documento era un ejemplo, no una constante universal.

Hay una última frontera fuera del formato. Si CCP vivía en un proceso de control y los datos en el núcleo, limpiar y enviar Reset-Ack tenían que quedar ordenados respecto del siguiente paquete. Un mensaje correcto en la captura no demostraba que la memoria compartida se hubiera reiniciado antes de que el otro camino continuara.

Lo que puede afirmar la historia

RFC 1977 definió un conjunto pequeño de invariantes: qué datagramas alimentan la tabla, qué versión comparten los pares, dónde termina la anchura, cómo avanza la secuencia, cuándo se evalúa el rendimiento y cómo se descarta una historia rota. IANA registra todavía el tipo de opción CCP 21 y los campos PPP para datagramas comprimidos.

La lectura de Lu Heng ayuda a mantener separado el documento de la realidad operativa. Las reglas deterministas hacen posible la verificación local; no sustituyen la evidencia de que un sistema concreto las aplicó. Para esa conclusión se necesitan los paquetes nativos, el orden, los contadores, los vaciados y el cruce entre control y datos.

Este texto no desarrolla la negociación general de RFC 1962, el formato serial de RFC 1963 ni la reordenación multilink de RFC 1990. Tampoco afirma uso actual o rendimiento de un producto. Conserva una frontera histórica más útil: «sin comprimir» describía la forma elegida para el enlace, mientras el diccionario seguía moviéndose.

Fuentes