Resumen

  • En el ejemplo acotado de RFC 5390, una petición SIP podía originar hasta 18 peticiones y otras tantas respuestas cuando se combinaban tres destinos sobrecargados, reintentos del proxy y retransmisiones UDP.
  • El 503 no identificaba con precisión el recurso afectado ni decía cuánto tráfico seguía siendo admisible; por eso podía empujar trabajo hacia la misma dependencia agotada, excluir capacidad sana o hacer oscilar la carga.
  • Los estándares posteriores separaron monitorización, decisión, realimentación y actuación. Una respuesta negativa, una reducción instalada y una llamada completada son comprobantes distintos.

El balanceador recorrió una lista que ya no contenía salida

La conducta inicial era fácil de defender. RFC 3261 permitía que un servidor SIP respondiera con 503 cuando estaba temporalmente indisponible y que indicara mediante Retry-After cuánto tiempo convenía evitarlo. Un proxy podía probar otro destino. Si una máquina concreta falla y otra conserva capacidad, esa política transforma redundancia en servicio útil.

RFC 5390 examinó el caso que rompe esa intuición. El proxy tenía tres servidores alternativos, pero los tres estaban sobrecargados. Enviaba la solicitud al primero, recibía 503, continuaba con el segundo y finalmente llegaba al tercero. La lista ofrecía tres nombres; el sistema ofrecía cero rutas independientes hacia capacidad disponible. Cada intento exigía recepción, análisis, planificación y generación de una respuesta en procesadores que ya no podían absorber el trabajo normal.

La métrica engañosa era el éxito sintáctico. El balanceador podía registrar que había agotado correctamente todos los destinos y que cada servidor había contestado conforme al protocolo. Ninguna de esas afirmaciones demostraba que la llamada avanzó. Tampoco demostraba que la carga ofrecida disminuyó. El mecanismo producía respuestas correctas mientras consumía más del recurso cuya escasez pretendía comunicar.

Esta es la primera separación probatoria. Un 503 acredita una decisión local sobre una petición. No acredita capacidad liberada, diversidad real entre destinos, reducción aguas arriba ni resultado para el usuario. Convertir esos hechos en una sola casilla verde vuelve invisible el propio mecanismo de amplificación.

La retransmisión añadió copias antes de que llegara la negativa

El servidor exhausto no respondía en tiempo cero. Mientras trataba de producir el 503, el cliente que usaba UDP podía retransmitir. RFC 5390 contó cuatro transacciones SIP en su topología, incluida la relación entre cliente y proxy, y hasta siete retransmisiones por transacción antes del tiempo límite. Bajo esas hipótesis, una única petición inicial podía producir hasta 18 peticiones y hasta 18 respuestas.

La cifra no es una medición de una red concreta ni una constante universal. Es el límite ilustrativo del ejemplo descrito por el RFC: tres servidores, transporte UDP, temporizadores y reintentos determinados. Su valor reside en el libro mayor que obliga a mantener. La operación no termina al emitir una negativa; hay que contar todas las copias creadas por el camino de recuperación.

Cambiar a transporte fiable reducía un multiplicador, pero no corregía la decisión. En el mismo escenario, sin retransmisiones de segmentos TCP, la petición aún generaba tres peticiones aguas abajo y cuatro respuestas. El problema fundamental seguía intacto: el proxy conocía direcciones alternativas, no sabía que todas desembocaban en la misma condición de agotamiento.

Por eso la investigación de una sobrecarga necesita conservar tiempos y causalidad. Si solo queda el total final de mensajes, una ráfaga de retransmisiones puede confundirse con demanda nueva. Si solo queda el código final, el coste previo desaparece. El comprobante útil enlaza la petición original con cada retransmisión, cada selección de destino y cada resultado.

Un segundo proxy volvió a explorar la misma dependencia

RFC 5390 amplió después la topología. Un proxy superior podía enviar primero el trabajo a P1. Tras recorrer S1, S2 y S3, P1 sabía que el conjunto estaba sobrecargado. Pero esa conclusión no viajaba aguas arriba como estado de control que delimitara la dependencia. El proxy superior probaba P2, y P2 repetía la exploración de los mismos tres servidores.

La expansión parecía tolerancia a fallos porque participaban más nodos. En realidad, ningún intento incorporaba un recurso nuevo. La información sobre la causa estaba encerrada en el nivel que acababa de fracasar. Una respuesta procedente de P1 podía interpretarse como estado de P1, no como evidencia de que los servidores compartidos detrás de P1 y P2 carecían de capacidad.

Ese detalle convierte la procedencia en parte del control. La topología lógica de proxies no basta para decidir independencia. Dos rutas que terminan en la misma base de datos, pasarela o grupo de procesadores forman un solo dominio de fallo para la petición relevante. Enumerar endpoints sin registrar dependencias hace que la diversidad nominal autorice trabajo duplicado.

La consecuencia de liderazgo es incómoda: «se intentaron todos los servidores» puede describir diligencia del algoritmo y, al mismo tiempo, despilfarro del sistema. Para distinguirlos se necesita una prueba de qué recurso nuevo aportaba cada alternativa. Sin ella, el reintento no es recuperación acreditada, sino una apuesta repetida.

La misma ambigüedad también podía apagar capacidad sana

El defecto no siempre enviaba demasiado tráfico. RFC 5390 observó que el alcance de 503 en RFC 3261 no era suficientemente inequívoco. ¿La indicación correspondía a una dirección IP, a un nombre de host o a una URI? Algunas implementaciones aplicaban la respuesta al nombre de host. Si DNS SRV distribuía ese nombre entre varios miembros, el 503 de uno podía retirar de servicio a todo el grupo.

Entonces el sistema cometía el error inverso. Había capacidad sana, pero la política dejaba de utilizarla porque una observación estrecha se había convertido en una prohibición amplia. La misma falta de alcance causaba tanto amplificación como infrautilización: en un caso el proxy creía distintas rutas que compartían agotamiento; en el otro creía agotado un conjunto que aún contenía rutas útiles.

El requisito 18 de RFC 5390 pidió que la indicación dejara claro si se aplicaba a una dirección IP, un host o una URI. No es un detalle de presentación. El alcance define el objeto sobre el que el receptor está autorizado a actuar. Un servidor puede describir su estado local; su código no establece automáticamente el estado de sus hermanos, su dependencia común o toda la identidad publicada por DNS.

Una consola que muestra solamente «503 recibido» pierde ese límite. Para reconstruir una decisión hacen falta el objeto observado, el instante, la duración, el vecino que recibió la señal y la regla que convirtió la señal en exclusión o reducción. De otro modo no puede saberse si la defensa protegió un recurso o retiró capacidad disponible.

Retry-After convirtió dos decisiones razonables en un péndulo

El temporizador proponía una pausa para que el servidor vaciara su cola. En el comportamiento base, sin embargo, la actuación era binaria. RFC 5390 dibujó dos servidores que trabajaban al límite. Cuando S1 rechazaba una petición y pedía una espera, el proxy trasladaba todo el tráfico a S2. S2 recibía entonces el doble de su capacidad, respondía a su vez, y el tráfico regresaba a S1 cuando expiraba el primer temporizador.

Ninguno de los servidores mentía. Cada observación local era válida. La inestabilidad aparecía en la traducción de esa observación a una acción de cero o todo. Faltaba una cantidad gradual: cuánto tráfico podía procesar todavía el receptor, durante qué intervalo y con respecto a qué emisor.

El propio RFC acotó el ejemplo. Cuando existen muchos clientes independientes y cada uno aporta una porción pequeña, rechazar selectivamente a algunos puede aproximar una reducción gradual. No se sigue que Retry-After produzca oscilación en toda arquitectura. Sí se sigue que el mecanismo base no garantizaba estabilidad en las topologías que la especificación quería proteger.

Los requisitos 7 y 21 capturaron ese cambio. El primero exigió reconocer grados de sobrecarga; el segundo, que el rendimiento se estabilizara cuando la carga ofrecida cayera por debajo de la capacidad. El objetivo dejó de ser emitir una negativa comprensible y pasó a ser gobernar un lazo dinámico.

El mismo 503 ocultaba causas que exigían decisiones opuestas

La práctica había usado 503 para más cosas que el agotamiento del procesador SIP. Una pasarela podía conservar capacidad de señalización pero no disponer de un circuito PSTN para cierta llamada. Otro grupo frontal podía estar sano mientras compartía una base de datos caída. En el primer caso una ruta alternativa tal vez resolvía el problema; en el segundo, otra máquina frontal podía conducir a la misma dependencia inútil.

El proxy no podía deducir cuál de esos mundos tenía delante. Reintentar podía salvar una llamada o multiplicar trabajo. No reintentar podía proteger un sistema o abandonar capacidad legítima. El requisito 6 pidió una indicación explícita de sobrecarga, separada de otros fallos. Los requisitos 8 y 9 protegieron ambos lados: evitar destinos sobrecargados o de estado desconocido sin impedir el uso de destinos realmente sanos.

También había una frontera temporal. El requisito 14 reclamó instrucciones claras sobre el momento del reintento, en especial durante el establecimiento de conexiones y el registro posterior a un reinicio. Causa, alcance, cantidad y vigencia eran dimensiones distintas. Comprimirlas en un código común obligaba al receptor a inventar la política que faltaba.

La lección no es que toda señal deba transportar un modelo completo del sistema. Es que una sintaxis compartida debe ser lo bastante estrecha para no fingir autoridad que no posee. El receptor puede aceptar una observación local y rechazar una inferencia global. La coordinación mejora cuando cada dato declara su límite.

Los estándares posteriores repartieron cuatro responsabilidades

RFC 6357 describió un circuito con componentes explícitos. Un monitor observa el procesador SIP protegido. Una función de control convierte las muestras en realimentación. El elemento aguas abajo publica esa realimentación. Un actuador situado en el emisor reduce, retrasa, rechaza o redirige antes de que el exceso llegue al recurso escaso.

La separación permite auditar fallos que un contador de 503 mezcla. El monitor puede medir bien y la realimentación llegar tarde. La señal puede llegar y el actuador ignorarla. El actuador puede cumplir una reducción total mientras descarta las clases equivocadas de mensajes. Incluso una tasa ofrecida menor puede no restaurar trabajo útil si la dependencia real sigue caída.

RFC 6357 explicó también por qué el rechazo local no bastaba: rechazar consume recursos del servidor. Puede ser la última barrera defensiva, pero no evita por sí solo el colapso por congestión. La actuación debe ocurrir aguas arriba, antes de pagar repetidamente el coste que se intenta limitar.

RFC 7339 llevó después información de sobrecarga salto a salto en la entrada Via superior. Como ese Via se consume en la relación con el vecino adyacente, la señal queda vinculada a ese enlace operativo. oc expresaba una reducción en el esquema base, oc-validity limitaba su vigencia, oc-seq ordenaba actualizaciones y oc-algo indicaba la familia de algoritmo. Esos campos definían un intercambio; no demostraban que toda la ruta los aplicara ni que una llamada terminara.

Un porcentaje de pérdida y un límite de tasa no prometían lo mismo

RFC 7339 exigió soporte para un algoritmo basado en pérdida. El servidor podía pedir al cliente aguas arriba que redujera la proporción de peticiones reenviadas. Era una forma relativamente ligera de realimentación, pero el porcentaje se movía con la demanda: si crecía la carga ofrecida, también podía crecer la fracción admitida.

RFC 7415 añadió de forma opcional un control basado en tasa. El servidor indicaba a un cliente una tasa máxima de peticiones, constante hasta una actualización posterior. Ese valor establecía un techo entre mensajes de control, a cambio de mantener más estado y decisiones por cliente.

Ninguna cifra era una promesa de servicio. Un máximo de 150 peticiones por segundo no garantizaba 150 transacciones completas, y mucho menos 150 llamadas satisfactorias. Las clases de mensajes podían tener costes distintos. La política local seguía eligiendo qué peticiones ocuparían la cuota; los estándares no impusieron una prioridad universal.

Por eso el registro debe conservar eslabones separados: valor recibido, versión y vigencia; límite instalado; tráfico ofrecido; mensajes seleccionados; transacciones completadas; diálogos preservados y resultado para el usuario. Cumplir el porcentaje o la tasa puede proteger un procesador y aun así sacrificar mensajes de cierre, registros o tráfico prioritario que liberaban más recursos.

El rendimiento útil era el criterio que impedía celebrar el error

El primer requisito de RFC 5390 apuntó al rendimiento útil cuando la oferta superaba ampliamente la capacidad. Esa palabra evita que el sistema declare victoria porque ahora rechaza todo con rapidez. Emitir respuestas es actividad; no necesariamente es progreso.

El rendimiento útil exige unir admisión con finalización y liberación de estado. Un BYE que cierra un diálogo puede recuperar recursos; un INVITE nuevo puede consumirlos. Una actualización de registro no tiene el mismo coste ni el mismo efecto que otra clase de petición. El número bruto de mensajes no describe el valor preservado.

La especificación dejó la priorización en manos de la política local. Esa reserva de autoridad era deliberada. El protocolo podía transportar evidencia común sobre sobrecarga sin convertirse en el planificador global de un operador. Emergencias, diálogos existentes y obligaciones comerciales podían justificar elecciones distintas, pero cada elección seguía necesitando comprobantes propios.

La disciplina de capas de realidad de Lu Heng ayuda a mantener el límite. El estándar define símbolos interoperables y un acuerdo mínimo. La red en ejecución conserva la verdad sobre su cuello de botella, su acción instalada y su resultado. Publicar un parámetro Via no crea procesadores, no independiza bases de datos y no transfiere la responsabilidad por una prioridad mal elegida.

Límite de la evidencia

El expediente congelado establece el texto de RFC 5390, su condición informativa, los problemas de despliegue que enumera y la arquitectura descrita en RFC 6357, RFC 7339 y RFC 7415. No establece que un operador, producto o red actual implemente esos mecanismos. Tampoco atribuye una interrupción real al ejemplo de 18 peticiones.

Ese máximo permanece unido a sus supuestos: tres servidores en la topología descrita, transacciones UDP, retransmisiones y vencimiento. El ejemplo de oscilación pertenece a una relación con pocos emisores grandes; el RFC reconoce que muchos emisores pequeños pueden comportarse de otra manera. Un 503 observado en producción tampoco demuestra por sí solo sobrecarga, pues puede representar otra causa.

La conclusión transferible es más estricta y más modesta. Negarse no equivale a reducir. Para afirmar control hay que mostrar el recurso medido, el alcance causal, la realimentación vigente, la actuación aguas arriba, la selección local y el trabajo útil resultante. Si falta un eslabón, una secuencia de errores perfectamente válida puede seguir alejando el sistema de la recuperación.