Resumen

  • El servicio garantizado comparaba cada elemento real con un servidor fluido ideal y acotaba su desviación máxima mediante C/R + D.
  • Los errores se acumulaban como Ctot y Dtot; junto con el TSpec y la tasa reservada R, permitían calcular una demora máxima de cola.
  • La cifra sólo valía dentro de sus condiciones de tráfico, tamaño, admisión, recursos y ruta. No era una promesa de jitter cero, autenticidad ni resultado útil.

Comprar tasa no compraba tiempo uniforme

RFC 2212 partía de un modelo deliberadamente limpio. Un flujo recibía un cable dedicado de capacidad R; con un token bucket (r,b), su demora fluida quedaba limitada por b/R si R era al menos r.

El router real no era un cable continuo. Atendía datagramas completos, compartía ciclos y podía interrumpir servicio para procesar otras tareas. La especificación convirtió esa distancia entre modelo e implementación en dos términos que el elemento debía exportar.

C era el error dependiente de la tasa. Su contribución al tiempo era C/R, por lo que una reserva mayor podía reducirla. D era la variación local independiente de la tasa: esperar una ranura o atravesar una pausa de servicio. Más R no la hacía desaparecer.

El límite local quedaba, en su forma sencilla, en:

b/R + C/R + D

No era una predicción media. C y D debían cubrir el peor apartamiento permitido. El equipo podía entregar un servicio mejor, pero no podía sobrepasar los máximos que había aportado al contrato.

El flujo tenía una forma comprobable

El TSpec distinguía cinco parámetros. r era la tasa del token bucket y b su profundidad. p fijaba la tasa de pico. m era la unidad mínima que contaba el policer. M era el mayor datagrama que podía ser conforme.

Durante un intervalo T, la fuente no debía superar:

M + min[pT, rT + b - M]

Por eso una reserva no cubría cualquier cosa que llevara la misma etiqueta. Un datagrama mayor que M quedaba fuera. Si el M pedido superaba el MTU de un enlace, la solicitud tenía que rechazarse.

El RSpec añadía R y el slack S. R >= r definía el servicio reservado. S >= 0 indicaba cuánto retraso adicional aceptaba el receptor respecto del resultado obtenido con esa reserva.

Declaración, petición y tratamiento seguían siendo registros distintos. La forma matemática no convertía una intención en tráfico observado.

Sumar C y D hizo posible hablar del camino

Cada elemento aportaba su pareja. La regla aditiva formaba Ctot y Dtot, que el mecanismo de establecimiento podía entregar a los extremos.

Para p > R >= r, la demora máxima de cola era:

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

Para r <= p <= R, era:

(M+Ctot)/R + Dtot

Si se ignoraba la tasa de pico, seguía disponible una estimación conservadora:

b/R + Ctot/R + Dtot

La ecuación revelaba una decisión operativa. Subir R reducía el coste de la ráfaga y de Ctot, pero no Dtot. Dos rutas con la misma reserva podían ofrecer límites diferentes. El nombre del servicio tampoco bastaba: había que conocer los errores de los elementos que componían esa ruta.

La latencia fija pertenecía a otra cuenta

RFC 2212 acotaba cola. Para obtener un máximo de extremo a extremo aún había que sumar propagación, transmisión y otros retardos fijos del camino.

La norma tampoco elegía el camino. Delegaba esa tarea al protocolo de establecimiento o al sistema de encaminamiento. La tasa y el límite permanecían estables mientras la ruta no cambiara. Si cambiaba, conservar la vieja cifra sin conservar la vieja ruta convertía un cálculo válido en una afirmación falsa sobre el presente.

Esta separación es más importante que una discusión terminológica. Permite identificar qué sistema tenía que producir cada prueba: servicio, ruta, latencia y observación de paquetes.

El slack no era una rebaja sin recibo

Un elemento podía gastar parte de S para reducir su reserva local. La transformación estaba condicionada por:

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

y por r <= Rout <= Rin.

La flexibilidad del receptor podía ayudar a admitir un flujo que, con una exigencia más estricta, habría sido rechazado. Pero el elemento debía trasladar la nueva tasa y el slack restante. Un refresh posterior tenía que usar el mismo consumo, no volver a apropiarse de la misma margen.

El mecanismo no anulaba el límite. Redistribuía un presupuesto de demora sin violarlo.

Csum y Dsum protegían el siguiente moldeado

Los totales de extremo a extremo no eran las únicas sumas. Csum y Dsum se reiniciaban en el último punto de reshaping y describían la distorsión acumulada desde allí.

Con ellas, un elemento podía dimensionar buffer para devolver tráfico conforme a su envolvente. Sin aprovechar p, una reserva conservadora era b + Csum + Dsum × R. Esa memoria local tenía una finalidad diferente de Ctot/Dtot.

Si el TSpec era menor que el tráfico real, el moldeado podía acumular una cola grande. Los datagramas que rompían la envolvente debían normalmente descender a best effort en el borde. Haber admitido el flujo no convertía el exceso en conforme.

El plazo máximo dejaba espacio para el jitter

RFC 2212 negó de forma explícita una lectura cómoda: el servicio no intentaba minimizar jitter. Controlaba el máximo de cola, no la distancia entre el paquete más rápido y el más lento. La mayoría podía llegar mucho antes del plazo y esperar en el receptor.

Tampoco prometía ausencia de pérdida sin condiciones. La protección frente al desbordamiento exigía tráfico conforme, reserva admitida, recursos suficientes, soporte en todos los elementos necesarios, tamaño cubierto y ausencia de fallo o cambio de ruta.

“Garantizado” designaba una obligación precisa dentro de ese conjunto. Fuera de él no era un talismán.

Cada recibo terminaba donde empezaba el siguiente

El documento permitía que RSVP, configuración manual o gestión de red establecieran el servicio. RFC 2210 organizaba los objetos RSVP; autenticación, política y contabilidad seguían aparte.

Así, un FLOWSPEC bien formado probaba una solicitud. Una admisión probaba una decisión de recursos. C/D caracterizaban el modelo de servicio. La fórmula probaba una consecuencia de esas entradas. Una captura probaba el paquete observado. La aplicación aún debía demostrar que lo decodificó y cumplió su propósito.

Ningún paso autenticaba por sí solo al emisor ni autorizaba el uso de recursos. Ninguno podía emitir el recibo final de la capa superior.

El avance de RFC 2212 fue poner un borde duro alrededor de una promesa de red. Su lectura responsable consiste en no borrar ese borde cuando la cifra sale del router.

Fuentes y límites

Estas fuentes fijan el contrato técnico y el marco analítico. No prueban adopción histórica o actual, prestaciones de un producto, una medición de ruta real ni descendencia causal hacia otro sistema QoS.