Resumen

  • El estado por flujo permitía una respuesta precisa, pero imponía clasificación y memoria donde el núcleo necesitaba escala.
  • Los agregados DiffServ reducían ese coste, aunque RFC 2990 observó que no estaba definida la señal de capacidad del núcleo al borde ni la decisión del borde a la aplicación.
  • Descubrir, admitir, medir la entrega y atribuir el uso eran actos diferentes; una marca no podía servir como recibo de todos ellos.

El «no» que no cruzaba la red

En una reserva por flujo, la negativa tenía un lugar. La aplicación describía una carga, la señalización recorría el trayecto y cada elemento podía aceptar o rechazar la petición. La red recordaba lo acordado. Esa memoria hacía posible relacionar la solicitud con recursos concretos.

También hacía crecer el coste. Cada reserva añadía estado, clasificación, medición y trabajo de planificación. La precisión que funcionaba cerca de una aplicación podía resultar inviable en el centro de una red de gran capacidad.

DiffServ invirtió la relación. El borde clasificaba y acondicionaba; el núcleo atendía unos pocos agregados reconocidos por el código del paquete. Ya no era necesario instalar una conversación completa por cada flujo. La arquitectura escalaba porque resumía muchas demandas.

Pero el resumen descartaba información que la aplicación necesitaba. Si el dominio no podía sostener la respuesta solicitada, podía limitarse a no prestarla. RFC 2990 señaló que no existía obligación de notificar ese fracaso. La aplicación debía deducirlo mirando el rendimiento.

No recibir el servicio y recibir un rechazo no eran el mismo hecho. El primero era una experiencia ambigua. El segundo podía activar una decisión.

Comportamiento más regla de carga

La RFC evitó reducir la calidad de servicio a una cola rápida. Una respuesta diferenciada dependía del mecanismo que trataba el tráfico y de la regla que limitaba cuánta carga entraba. Si todos podían reclamar prioridad sin control de admisión, la prioridad reorganizaba la congestión pero no creaba capacidad.

IntServ ligaba el control de carga a peticiones explícitas. DiffServ permitía que el operador lo aplicara en el borde de una categoría agregada. Ambas opciones preservaban una autoridad local sobre recursos finitos, pero exponían interfaces distintas.

El problema aparecía cuando el borde prometía con información incompleta. RFC 2990 llamó a DiffServ un modelo centrado en la frontera. El interior no tenía definido cómo comunicar su disponibilidad actual a los acondicionadores. Tampoco estaba definido cómo esos acondicionadores comunicaban a la aplicación el resultado.

La cadena necesitaba dos señales: núcleo a borde para decidir con datos vivos, y borde a aplicación para que la petición tuviera desenlace.

Descubrir no era encaminar

Ambas arquitecturas solían apoyarse en la ruta de mejor esfuerzo ya elegida. En una Internet de despliegue desigual, esa ruta podía no ser la única ni la capaz de sostener la calidad deseada.

RFC 2990 no encontró un mecanismo robusto para consultar varias rutas y descubrir cuál ofrecía un perfil específico. El marcado de paquetes expresaba preferencia dentro de un tratamiento conocido; no exploraba caminos. RSVP podía reservar en el camino que encontraba; no demostraba que otro camino no fuese más apto.

La métrica necesaria tampoco equivalía a «capacidad ociosa». El texto propuso pensar en el potencial de una ruta para transportar tráfico adicional con cierta calidad, incluso desplazando tráfico de menor prioridad. Esa posibilidad incorporaba una decisión distributiva. Medirla exigía conocer tanto la topología como las reglas de sustitución.

Descubrimiento, selección de ruta y admisión debían conservar recibos separados.

La mitad de TCP viajaba de vuelta

La discusión de TCP impidió imaginar el servicio como una flecha unilateral. El flujo de datos dependía de los acuses que regresaban. Tratar bien los datos y mal los acuses podía reducir el rendimiento total.

Una variación alta en el retorno podía comprimir varios acuses y hacer que el emisor lanzara una ráfaga. Esa ráfaga tensionaba de nuevo la capacidad. Una política simétrica parecía atractiva, pero introducía otra decisión: quién solicitaba la calidad de vuelta y cómo se contabilizaban ambos sentidos sin duplicar el cargo.

El rendimiento de la aplicación pertenecía al ciclo completo. El contador de una cola en el sentido de ida sólo observaba una parte.

Medir antes de cobrar

RFC 2990 pidió mediciones para dos propósitos distintos. El control de admisión necesitaba una vista de los recursos disponibles a lo largo de una ruta. Después, operador y cliente necesitaban medir los parámetros del servicio entregado.

El operador debía sustentar objetivamente que la prestación se ajustaba a la especificación. El cliente debía poder justificar el gasto adicional mediante una mejora real de la aplicación. La configuración interna no resolvía ninguna de esas preguntas por sí sola.

El documento anticipó que un servicio premium traería una tarifa incremental. El precio podía asignar el coste a quien consumía más recursos y moderar la demanda. Sin embargo, constató que aún no había un modelo de contabilidad QoS ni una definición de los datos necesarios para vincular uso y cliente.

La petición, la admisión, el consumo de recursos, la entrega observada, la identidad facturable y la factura formaban una secuencia. Saltarse un eslabón convertía una métrica técnica en una afirmación económica que no podía sostener.

Un borde bilingüe

La combinación de IntServ y DiffServ trató de repartir responsabilidades. RSVP podía conservar la conversación por flujo con la aplicación. El dominio DiffServ podía aparecer como un elemento agregado dentro de un trayecto mayor. El borde traducía el perfil individual a una clase compatible.

Ese borde debía hablar dos lenguajes: la intención individual y la capacidad colectiva. Si la asignación del agregado era estática, podía cargar límites conocidos. Si cambiaba, necesitaba una señal dinámica desde el interior. Y si la región DiffServ rechazaba la admisión, el fracaso debía volver por RSVP para que la aplicación redujera su petición o terminara.

La traducción positiva era sólo la mitad del contrato. La traducción del fracaso protegía la precisión del extremo.

Diversidad sin ficción de universalidad

RFC 2990 juzgó improbable una única tecnología de diferenciación para toda Internet. Esperaba islas, combinaciones y grados de interoperabilidad. Por eso situó descubrimiento, invocación y medición al mismo nivel.

Su conclusión no eligió un vencedor. Propuso mecanismos agregados en el núcleo, donde dominaba la escala, y elementos por flujo en el borde, donde la precisión era sostenible. La arquitectura común debía definir cómo cooperaban, no borrar sus diferencias.

La idea de especificación inicial mínima de Lu Heng ayuda a leer esa elección. Coordinar exige un núcleo compartido pequeño y verificable; no exige que una institución decida cada asignación futura. Sin embargo, la autonomía local pierde legitimidad operativa si es opaca para quienes dependen de ella.

Las capas de realidad ofrecen la disciplina final: código de clase, decisión de admisión, recursos, tratamiento, rendimiento, medición, atribución y cobro no son sinónimos. Sólo el sistema en ejecución puede producir la cadena de evidencias.

El silencio podía ocultar un rechazo. La tarea de la arquitectura era devolverlo como información.

Fuentes