Resumen

  • La propuesta de RFC 1046 protegía el tiempo de espera de los datagramas admitidos mediante una cola pequeña de baja demora. Cuando se llenaba, el exceso se descartaba, y la clase no podía apropiarse de toda la capacidad del enlace.
  • Pedir varias clases no sumaba garantías. Con recursos disputados, las peticiones funcionaban como alternativas OR; el nodo escogía una cola, y un repliegue podía admitir más tráfico a cambio de desorden y tiempos menos previsibles.

RFC 1046 empieza donde termina una etiqueta. Un emisor marca el datagrama, pero el siguiente nodo debe decidir si le reserva un hueco, cuándo lo transmite y qué ocurre cuando llegan demasiados. En febrero de 1988, W. Prue y J. Postel describieron una posible respuesta y la presentaron como documento de ideas, no como prueba de que Internet ya la hubiera adoptado.

Su diseño es valioso porque no permite llamar «mejor» a todas las propiedades a la vez. La baja demora se construía limitando la espera; la alta fiabilidad, tolerándola; el alto rendimiento, dedicando más oportunidades de salida. Cada opción trasladaba el coste a otro lugar.

El TOS describía deseos, no recursos existentes

RFC 791 había definido precedencia y preferencias de demora, rendimiento y fiabilidad en el octeto Type of Service. También advertía que formaban un intercambio de tres vías. En muchas redes, mejorar un parámetro empeoraría otro.

RFC 1046 observó que todavía faltaba explicar el comportamiento de las colas. Su algoritmo sólo entraba en escena cuando la demanda superaba la capacidad. Si el tráfico no hacía crecer una fila significativa, la disciplina especial no tenía utilidad frente a FIFO.

La congestión era así el momento de verdad. Antes de ella, varias marcas podían parecer compatibles. Al competir por el mismo búfer y el mismo transmisor, el nodo tenía que materializar una preferencia y negar otra.

MGD limitaba la espera del admitido

El documento aspiraba a un Maximum Guaranteed Delay por nodo para la clase de baja demora, si el datagrama conseguía atravesar Internet. La frase no prometía entrega. Tampoco describía el tiempo de ida y vuelta: el servicio era unidireccional, y una respuesta podía llevar otra clase.

El límite se derivaba de:

Demora máxima = N / (P × R)

N era la longitud de la cola, P la fracción de recursos asignada y R la tasa del enlace en datagramas por segundo. Mantener fija la demora obligaba a reducir la cola cuando bajaba la velocidad o la asignación. Una conexión con demora física elevada consumía parte del mismo presupuesto.

El número no viajaba dentro del datagrama. Vivía en la combinación de capacidad, configuración y condiciones del enlace. La marca permitía clasificar; no reservaba ninguna de esas tres cosas.

La cola rápida expulsaba antes

La solución era mantener pequeña la cola de baja demora y limitar su frecuencia de servicio para que no excluyera a las demás. Un datagrama admitido podía esperar poco porque había pocos por delante. Cuando ya no quedaban huecos, el recién llegado se descartaba.

Para esa cola diminuta, RFC 1046 consideraba que Source Quench reaccionaría demasiado tarde y proponía no usarlo en el esquema básico. No era una declaración de que la pérdida careciera de importancia. Era el reconocimiento de que la retroalimentación no podía crear espacio antes del siguiente desbordamiento.

La cola de alta fiabilidad era más larga. Avisaba antes mediante Source Quench y conservaba datagramas hasta llenarse, aceptando más espera. La protección se limitaba a pérdidas por congestión: no corregía una línea con muchos errores.

La clase de alto rendimiento recibía la mayor tasa de servicio del ejemplo y un búfer mayor. El coste era una demora media superior. Agrupar ráfagas podía ayudar a un protocolo superior, aunque el texto advertía que esa suposición podía ser incorrecta.

Las casillas múltiples eran rutas de escape

RFC 1046 formuló la regla sin ambigüedad: bajo contención, pedir varias clases era una solicitud OR, no AND. La suma aparente del encabezado no generaba una suma de derechos.

Un datagrama sólo podía entrar en una cola por nodo. El orden sugerido era baja demora, alto rendimiento y alta fiabilidad. Si un paquete marcado para baja demora y fiabilidad encontraba llena la primera cola, podía pasar a la segunda. Obtenía otra oportunidad de ser aceptado, pero ya no el mismo trato.

En una ráfaga, unos datagramas podían entrar por una cola y otros por otra. Las diferentes velocidades podían cambiar el orden y ensanchar la distribución de demoras. La marca original no registraba esa bifurcación. Para conocer el resultado hacían falta los eventos internos del nodo y la observación posterior.

La precedencia no debía congelar al último de la fila

Además de las clases, había ocho niveles de prioridad. La propuesta permitía adelantar dentro de cada cola, pero acumulaba puntos locales de frustración en el datagrama desplazado. Después de suficientes adelantamientos, su prioridad efectiva local alcanzaba a la del recién llegado y dejaba de ceder.

Ese ascenso desaparecía en el siguiente salto; no reescribía la cabecera. Tampoco autorizaba a sacar un paquete ya admitido. Si la cola estaba llena, se descartaba el nuevo, tuviera o no prioridad alta.

El remedio contra la inanición alteraba la demora. En el ejemplo, un datagrama de baja demora sin prioridad alta podía esperar hasta 28 veces el valor sin adelantamientos. Por eso, el bit de demora, el orden local y el tiempo observado no deben condensarse en un único estado «QoS aplicado».

La gobernanza quedó en la lista de preguntas

La división 17/50/33 por ciento y el sistema proporcional de fichas eran ilustrativos. El propio RFC preguntaba qué porcentaje asignar, qué MGD escoger, cómo contener el abuso de clases atractivas, si la complejidad añadida era aceptable y qué simulaciones faltaban.

También proponía instrumentar la clase realmente utilizada, en especial cuando el paquete llevaba varias solicitudes. Contar tres preferencias como tres servicios prestados habría falseado tanto la demanda como el resultado.

Esas preguntas son parte del hallazgo histórico. La política no se agotaba en leer la cabecera. Alguien debía fijar el sacrificio, vigilar la distribución y corregir una elección que perjudicara a los demás.

Los documentos posteriores acotan, no completan, el experimento

RFC 1349 declaró después que TOS era estrictamente orientativo e inadecuado para solicitar garantías. Minimizar demora no significaba conseguir una cifra determinada.

RFC 2474 y RFC 2475 sustituyeron la interpretación antigua por el campo DS y separaron codepoint, comportamiento por salto, servicio, acondicionamiento e implementación. No prueban que RFC 1046 se desplegara ni que DiffServ copiara su algoritmo; sí preservan la diferencia entre la señal portátil y el mecanismo local.

RFC 1016 explica el contexto contemporáneo de Source Quench. RFC 6633 fijó después el límite actual: no enviarlo, ignorarlo y no implementar el enfoque de RFC 1016.

Fuentes y límites

Las fuentes sostienen el diseño publicado, sus ecuaciones, cautelas y evolución normativa. No demuestran implementación, parámetros de una red concreta ni cumplimiento para un paquete observado. Solicitud, clasificación, admisión, orden, descarte, entrega y resultado de aplicación son registros distintos.