Resumen
- RFC 3006 añadió al TSpec original una pista de compresibilidad: el emisor describía la posibilidad, pero cada router decidía si su enlace podía convertirla en una reserva menor.
- Si un salto utilizaba la pista para admitir el flujo, debía vigilarlo con el TSpec comprimido y tratar como exceso la capacidad que la compresión real no consiguiera ahorrar.
Una reserva de 48 kbit/s podía ser demasiado grande en el mensaje y perfectamente viable en el cable. Ese era el problema que abrió la RFC 3006. El router del enlace lento sabía comprimir cuarenta bytes de IP/UDP/RTP hasta cuatro; el emisor, sin embargo, no sabía qué otros routers del trayecto tenían la misma capacidad. Rebajar la cifra en origen habría mentido a los saltos sin compresión. Mantenerla intacta podía provocar un rechazo innecesario.
La solución no fue elegir una autoridad única. El Sender TSpec siguió viajando sin modificaciones, como establecía RFC 2210. El emisor añadió una pista sobre el tipo de compresión y, si quería, un factor cuantitativo. El control de tráfico de cada router podía producir para su interfaz un TSpec comprimido. La palabra pista impedía interpretar el campo como una orden o una prueba del ahorro.
La ubicación del campo seguía la arquitectura de RFC 2205. El emisor conocía la forma probable de sus datos. El router conocía el código y la capacidad del enlace. RSVP transportaba información; admisión y asignación tomaban la decisión. Así, mecanismos de reserva distintos de RSVP también podían entregar el mismo parámetro al componente lógico correcto.
El ejemplo hizo auditable la rebaja. Con tasa r de 48 kbit/s, profundidad b de 120 bytes, máximo M de 120 y unidad mínima m de 64, comprimir la cabecera de cuarenta a cuatro bytes producía un factor del 70 %. r bajaba a 33,6; b y M, a 84. Para m había que restar 36, no multiplicar sin más: el resultado era 28 bytes.
En el caso general de una cabecera que elimina N bytes, tasa y ráfaga se escalaban por f/100, la tasa de pico permanecía, y los tamaños máximo y mínimo perdían N. No toda compresión obedece a esa forma. La suma de comprobación UDP, la evolución de la marca temporal RTP y la distribución de tamaños podían alterar el ahorro. Un router podía calcular el peor caso. El factor cero delegaba la estimación; 100 indicaba que no se esperaba reducción.
Con varios emisores, la RFC no permitía esconder la diversidad detrás de una media simple. Cada TSpec se reducía por separado antes de agregarse. En el servicio garantizado de RFC 2212, R se escalaba mediante un promedio ponderado por el tamaño de las ráfagas. El salto también debía aumentar su término C de forma inversa para que C/R no ampliara el retraso que el receptor había intentado limitar.
La promesa adquiría significado cuando podía fallar. Si se reservaron 33,6 kbit/s y la salida comprimida consumió 35, los 1,4 restantes no aparecían mágicamente dentro de la reserva. Eran exceso, sujeto a las reglas del servicio. RFC 3006 no garantizaba compresión determinista ni permitía que una expectativa favorable requisara capacidad ya comprometida.
También contemplaba la exageración deliberada. Un emisor podía declarar compresibles datos que no lo eran, obtener una admisión incorrecta y dejar recursos insuficientes para otros. El remedio ubicó el deber donde nació la rebaja: cualquier router que usara la pista debía comportarse, a efectos de vigilancia, como un borde de red. La policía del borde real sólo había comprobado el contrato original; no podía certificar el coste transformado de una interfaz posterior.
El máximo de datagrama conservaba el valor sin comprimir para los servicios que lo usaban en el control. Algunos paquetes podían no reducirse. Era una precaución esencial: la eficiencia repetida no borraba el tamaño individual que el sistema aún podía recibir.
La extensión debía atravesar equipos antiguos sin convertir su ignorancia en una rebaja. El comportamiento preferido era ignorar el parámetro localmente, conservarlo al reenviar y reservar con el TSpec completo. Si una implementación rechazaba el PATH como malformado, el emisor podía recibir PathErr y repetir sin la pista. La degradación segura era más cara, pero comprensible.
Ese límite separa el artículo de sus vecinos. RFC 2688 cuenta bytes añadidos o eliminados por PPP; RFC 2689 coordina el conjunto de mecanismos de enlaces lentos; RFC 2508 define la compresión IP/UDP/RTP. RFC 3006 se ocupa del tránsito institucional entre una afirmación, una rebaja de recursos y la consecuencia si la afirmación falla.
RFC 3241 reutilizó después la numeración de pistas para ROHC sobre PPP. Eso demuestra capacidad de extensión, no adopción universal. La enseñanza documentada es que una optimización sólo debía alterar la admisión en el lugar donde el sistema podía ejecutarla y observarla.
La lente de Lu Heng permite formularlo como diseño de autoridad. El campo común expresa una posibilidad mínima. La decisión futura queda localizada en el router y su adopción no obliga a todo el trayecto. La estabilidad exige evidencia continua: si el ahorro deja de existir, debe cambiar el tratamiento del tráfico, no la realidad contable de los demás flujos.
Fuentes
- RFC 3006, Integrated Services in the Presence of Compressible Flows
- Página informativa de RFC 3006
- RFC 2205, Resource ReSerVation Protocol — Version 1 Functional Specification
- RFC 2210, The Use of RSVP with IETF Integrated Services
- RFC 2212, Specification of Guaranteed Quality of Service
- RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
- RFC 2688, Integrated Services Mappings for Low Speed Networks
- RFC 2689, Providing Integrated Services over Low-bitrate Links
- RFC 3241, Robust Header Compression over PPP
- Lu Heng, «Running-Code Primacy»
- Lu Heng, «Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption»
- Lu Heng, «The Stability Fallacy in the RIR Argument»
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
