Resumen

  • RFC 3387 mostró que clasificar, marcar o priorizar tráfico resolvía una parte ejecutable de QoS, pero no definía por sí sola un servicio comprensible y verificable.
  • Su mapa separó funciones de acceso, núcleo y frontera administrativa, y dejó visible el coste que las reservas premium podían imponer al mejor esfuerzo.

El experimento parece concluyente: dos paquetes esperan, uno lleva una marca, el programador lo transmite primero. Hay una captura, una configuración y un resultado local. Sin embargo, ninguna de esas pruebas dice quién compró qué ni si la promesa sobrevivió al siguiente dominio.

Esa fue la incomodidad central de RFC 3387. Publicado en septiembre de 2002 como Informational por integrantes del Service Management Research Group de la IRTF, no presentó un protocolo nuevo ni una red ya terminada. Preguntó qué faltaba cuando los mecanismos de diferenciación progresaban más rápido que la gestión del servicio.

El Internet de mejor esfuerzo había crecido con una preferencia por la sencillez y el control distribuido. QoS añadía decisiones sobre escasez. Si un flujo recibía un trato distinto, alguien debía especificar el trato, comprobar que la red podía realizarlo, decidir quién estaba autorizado y preservar evidencia suficiente para un desacuerdo posterior.

El RFC dividió el servicio en definición y materialización. La definición tenía que ser inequívoca. La materialización debía traducirla a recursos y controles concretos. Un objeto de política podía describir el deseo del operador, pero no era un recibo del programador. Una fila configurada podía existir sin que se hubiese admitido capacidad a lo largo del camino.

En el acceso aparecían autenticación, autorización, admisión, control de parámetros y facturación. Allí se encontraba al solicitante y se limitaba el tráfico antes de que un exceso afectara a terceros. También hacían falta notificación de fallos, verificación del servicio, reactivación y terminación.

El núcleo tenía otra tarea. Debía informar recursos, recibir configuración, realizar ingeniería de tráfico, detectar fallos y recuperarse. RFC 3387 examinó cálculos con una visión más amplia de la red porque cada salto aislado desconocía datos necesarios para optimizar un trayecto. Pero preguntar por una función central no equivalía a concederle autoridad ilimitada: el documento también recordó el coste de complejidad y desestabilización.

La frontera administrativa multiplicaba la dificultad. Un flujo podía cruzar proveedores competidores, con modelos comerciales y métricas diferentes. Los SLA bilaterales eran posibles, pero una cadena de pactos locales no producía automáticamente una garantía cuantitativa extremo a extremo. Tampoco era razonable exigir que cada operador revelara su capacidad interna a un rival.

De ahí surgían propuestas como el bandwidth broker o un tercero confiable. Podían coordinar autorización, precio, pago o verificación. Eran opciones funcionales, no un mandato de RFC 3387. El problema político consistía en impedir que el mensajero de evidencias se convirtiera en dueño de la validez del servicio.

La facturación debía entrar desde el diseño inicial, igual que la seguridad. RFC 2975 ayuda a evitar una cadena falsa: la contabilidad registra consumo bajo un alcance; la tarificación aplica reglas económicas; la facturación formula el cobro; el pago lo liquida. Un registro contable no prueba por sí solo un precio correcto, una deuda pagada ni la entrega técnica.

El mismo límite se aplicaba a DiffServ. Un comportamiento por salto describe el trato en un nodo o dominio bajo condiciones definidas. RFC 3387 negó que esa garantía local fuese una garantía extremo a extremo. El cliente no compra el movimiento de una sola cola; compra una expectativa sobre ancho de banda, retardo o error a través de un camino.

La arquitectura tenía además un tercero silencioso: el tráfico de mejor esfuerzo. Reservar capacidad para un servicio premium podía dejarla ociosa e inaccesible. Dar prioridad a una clase podía empeorar a las demás. El documento no afirmó haber medido ese resultado, pero sí identificó el incentivo del proveedor para favorecer el producto con mayores ingresos.

La primacía del código en ejecución de Lu Heng sugiere el límite correcto. Los dominios necesitan reglas comunes mínimas para identidad, autorización, parámetros, medición y traspaso. No necesitan entregar su gobierno interno a una institución central sólo porque cooperan. La adopción operativa y las pruebas deterministas deben sostener el acuerdo.

La lección histórica no es que QoS fracasara ni que toda centralización fuera imposible. Es más precisa: el paquete podía recibir un trato especial mucho antes de que la red hubiese reunido todos los recibos que convierten ese trato en servicio. RFC 3387 puso nombre a la distancia entre ejecutar una preferencia y responder por su resultado.

Fuentes