Resumen

  • En la RFC 7683, OC-Reduction-Percentage = 100 exige tratar el total de las nuevas solicitudes coincidentes que el nodo reactivo habría enviado; el propio algoritmo no garantiza una reducción absoluta del tráfico.
  • Una conclusión operativa necesita enlazar la OLR exacta con el OCS aceptado, las decisiones sobre cada solicitud y las mediciones de tráfico y trabajo útil, sin mezclar nodos, alcances ni ventanas temporales.

Un mandato con apariencia de medición

“Reducción del cien por cien” parece una cifra calculada al final de un intervalo. En Diameter Overload Indication Conveyance aparece al principio. La RFC 7683 dice que OC-Reduction-Percentage expresa cuánto tráfico se pide reducir respecto del que el emisor enviaría de otro modo. El valor 100 pide que todo el tráfico comprendido reciba tratamiento de mitigación porque el nodo informante soporta una carga grave y deja de procesar mensajes nuevos.

La OLR acredita una intención precisa del plano de control. No cuenta lo que llegó al nodo protegido, no confirma que todos los clientes admitieran DOIC y tampoco revela si una solicitud fue descartada, desviada o reintentada. Convertirla en “tráfico cero” borra tanto el sujeto que ordena como el sujeto que observa.

Ben Campbell ofrece un hilo coherente para seguir esa distinción. Su perfil del IETF recoge trabajo en comunicaciones en tiempo real y responsabilidades anteriores en el IAB, la dirección del área ART y varios grupos de trabajo. Figura como coautor de la RFC 7068, que fija requisitos de control de sobrecarga; de la RFC 7683, que define DOIC; y de la RFC 8583, que separa carga y sobrecarga. El valor de esa secuencia documental reside en no prometer una observación donde sólo existe una acción solicitada.

Lo que promete el algoritmo de pérdida

DOIC distribuye el conocimiento entre dos papeles. El nodo informante decide que existe una condición de sobrecarga y calcula la reducción necesaria mediante un método propio de la implementación. Envía una OLR. El nodo reactivo la recibe, mantiene un Overload Control State —OCS— y elige qué mensajes de solicitud recibirán mitigación. Esa selección también queda en manos de la implementación.

La obligación normativa consiste en aplicar tratamiento al porcentaje solicitado de las nuevas peticiones. Sin embargo, la RFC 7683 advierte que el algoritmo sin estado no garantiza una disminución absoluta del tráfico. Garantiza la selección de una proporción de solicitudes nuevas. El denominador es lo que el nodo reactivo habría enviado y, antes de usarlo, todavía hay que saber qué solicitudes coincidían con el estado activo.

Mitigar tampoco equivale siempre a eliminar. Las reglas de la aplicación pueden desviar tráfico hacia otro destino o limitarlo. En el caso de sobrecarga de un agente, la RFC 8581 prefiere el desvío hacia otros pares y obliga a frenar cuando no hay capacidad alternativa suficiente. Puede caer el tráfico de entrada de un servidor y aumentar al mismo tiempo la presión sobre otro. El sistema conserva actividad aunque el punto protegido vea una cifra muy baja.

El alcance está dentro del OCS

La RFC 7683 distingue informes de host e informes de realm. El primero rige solicitudes encaminadas a un host; el segundo, solicitudes de un realm. El Application-ID forma parte de la correspondencia. La RFC 8581 incorpora el informe de par para la sobrecarga de agentes, identificado por la aplicación y la identidad Diameter del par.

Por eso, “todo” significa todas las solicitudes que coinciden con ese OCS, no todo el tráfico de la red. Otra aplicación, otro host o un cliente sin soporte para la extensión puede quedar fuera. En un informe de par, si el SourceID no coincide con la identidad del par del que vino la respuesta, el nodo reactivo debe ignorarlo. La autenticidad de la procedencia es parte del control, no un dato accesorio.

El OCS también aporta orden temporal. Una secuencia superior actualiza el estado; una igual o inferior se descarta como repetición o versión vieja. Cualquier cambio de duración o del porcentaje de reducción exige incrementar OC-Sequence-Number, y la propiedad de orden debe sobrevivir a un reinicio mientras haya informes anteriores sin expirar. Para reconstruir un incidente no basta la copia de una OLR: hace falta saber qué versión había aceptado cada nodo cuando clasificó sus solicitudes.

El silencio conserva el estado

Un campo que desaparece de una respuesta puede parecer una señal de normalidad. En DOIC significa lo contrario: recibir un mensaje sin OC-OLR no elimina el OCS; la ausencia de OLR significa “sin cambios”. El final puede señalarse con una duración de validez cero o llegar por expiración.

La salida de una reducción del 100 % tampoco debe abrir de golpe el caudal. La RFC 7683 recomienda actuar con cautela, por ejemplo mediante mensajes de prueba, para no provocar una oscilación que devuelva al nodo a la sobrecarga. La RFC 8581 exige igualmente terminar de forma controlada la mitigación de un informe de par. Una línea temporal válida separa el fin del informe de la recuperación observada.

Host, realm y par no se suman

La extensión de agentes permite que un mensaje contenga a la vez informes de host, realm y par. Primero se aplica la mitigación del host o realm; después, el informe de par actúa sobre las solicitudes supervivientes y debe considerar lo ya frenado. Así se evita tratar varias veces el mismo conjunto como si cada porcentaje tuviera la población original.

Sumar porcentajes produce una precisión ficticia. La investigación necesita los recuentos de cada fase: solicitudes candidatas, coincidencias con el primer OCS, supervivientes, coincidencias con el OCS de par, desvíos y limitaciones. Sólo esos conjuntos permiten explicar a qué “cien por cien” se refería cada nodo.

Dos escalas que apuntan en sentidos opuestos

La RFC 8583 llama carga a una condición continua y sobrecarga a un estado excepcional. La información de carga funciona como indicio para repartir tráfico. La OLR, en cambio, pide explícitamente reducir la carga ofrecida y opera como un contrato entre quien informa y quien reacciona.

También cambia el sentido de los números. En Diameter Load, un valor alto significa menos carga real: 65535 representa carga cero y 0 representa carga del 100 %. En OC-Reduction-Percentage, 0 significa que no hace falta mitigar y 100 pide tratar todo el tráfico coincidente. Una base de datos que los convierta en una única métrica porcentual puede invertir el significado sin lanzar ningún error técnico.

Para juzgar el resultado, la RFC 7068 propone mirar el rendimiento útil total bajo carga. Esa variable no viene dentro de la OLR. El informe demuestra la petición; el OCS, la creencia activa del receptor; el registro de decisiones, el tratamiento; los contadores, las llegadas; y la telemetría de aplicación, las operaciones completadas. La cadena sólo es tan fuerte como sus enlaces.

Un expediente que sí permite concluir

La primera pieza registra quién declaró la sobrecarga, para qué Application-ID y tipo de informe, mediante qué versión de cálculo y durante qué intervalo. La segunda conserva los bytes y campos de la OLR: secuencia, validez, algoritmo, porcentaje y hora.

Después viene una recepción por cada nodo reactivo. Debe indicar si anunciaba la capacidad, si aceptó el origen, si la secuencia creó o actualizó el OCS y cuándo lo consideró vigente. Las decisiones sobre solicitudes deben enlazarse con ese estado e identificar encaminamiento normal, desvío o limitación.

Sólo al final se comparan los contadores del nodo protegido y de los destinos alternativos, los reintentos, los rechazos, el rendimiento útil y las consecuencias para la aplicación. Si falta una capa, la conclusión debe detenerse antes. Es legítimo escribir “el nodo A mantuvo un OCS del 100 %”; no lo es sustituir esa frase por “no hubo tráfico”.

Fuentes