Resumen
- El RFC 792 dio ICMP tipo 4 a gateways y destinos sin capacidad para absorber tráfico. El mensaje citaba el paquete que lo provocó y pedía reducir el envío hacia un destino.
- La orden no autenticaba a quien hablaba ni indicaba cola, tasa justa o duración. Crear control durante la sobrecarga gastaba capacidad, y una falsificación podía hundir el rendimiento de otro flujo.
- El control duradero pasó al transporte extremo a extremo; después ECN llevó la señal dentro del paquete. El RFC 6633 obligó a ignorar Source Quench y a descartarlo con registro de seguridad.
Una orden nacida en la cola llena
El RFC 792, de 1981, permitía que un gateway sin espacio en la cola de salida descartara un datagrama y enviara ICMP tipo 4, código 0. Un destino desbordado también podía hacerlo. Source Quench pedía a la fuente reducir la tasa hacia ese destino y aumentarla gradualmente cuando cesaran los avisos.
La observación era razonable: el router veía una cola invisible para la fuente, mientras la fuente controlaba los próximos paquetes. Pero ICMP ofrecía realimentación no fiable. El informe podía perderse, llegar tarde o describir una condición ya terminada; nunca reservaba capacidad.
El mensaje incluía la cabecera IP original y 64 bits de datos. Ese recibo ayudaba a identificar una conversación, pero no decía profundidad de cola, competidores, reducción adecuada ni plazo. Tampoco probaba criptográficamente que el emisor hubiera visto el paquete citado.
El RFC 1122 mantuvo el pacto en 1989. Un host podía generar Source Quench al agotar recursos y debía entregar los recibidos al transporte. TCP tenía que frenar la conexión, normalmente volviendo a slow start. Una evidencia estrecha activaba una consecuencia amplia.
Cuando la señal añadía congestión
El RFC 896 describió el colapso por congestión: crecen las colas, los hosts retransmiten paquetes sólo retrasados y la red ocupa su capacidad con duplicados mientras cae la entrega útil. Más memoria aplaza el punto sin curar el bucle.
Source Quench podía crear un mensaje por cada descarte. Incluso limitado, pedía a un camino saturado transportar noticias sobre su saturación. Varios routers podían ordenar sobre el mismo flujo sin contabilidad común, y los flujos obedientes podían ceder ante los que no reaccionaban.
Por eso el RFC 1812 cambió la norma en 1995: un router NO DEBERÍA originar Source Quench, considerado ineficaz e injusto; cualquier generación residual debía limitarse. Ver una cola llena dejó de equivaler a tener autoridad sobre un transporte remoto.
La fuente aprendió de las consecuencias
TCP situó la respuesta donde existía estado del flujo. El RFC 5681 define ventana de congestión, slow start, evitación y recuperación sin Source Quench. Los ACK muestran que datos salieron del camino; pérdida y timeout son señales imperfectas, pero pertenecen a una secuencia que los extremos conocen.
El router conservó una función propia. El RFC 2309 recomendó gestión activa de colas para indicar congestión antes del desbordamiento y separó esa tarea de scheduling y equidad. El intermediario actúa sobre la cola que observa; el transporte cambia el flujo que identifica.
Una marca dentro del paquete
El RFC 3168 mantuvo la señal explícita mediante ECN, pero la ató al tráfico. Los extremos declaran capacidad ECN; un router puede marcar Congestion Experienced en el paquete en lugar de descartarlo. El receptor devuelve la marca por el transporte y el emisor responde de modo semejante a una pérdida.
La marca viaja en el paquete que encontró la cola, no como una orden huérfana que cita otro paquete. ECN no es autenticación perfecta ni despliegue universal, pero mantiene la evidencia dentro de una conversación y de una capacidad negociada.
Retirar también la obediencia
Desalentar la emisión no bastaba si un host todavía obedecía. Equipos viejos o atacantes conservaban el mando. El RFC 6633 cerró la vía en 2012: hosts no deben enviar; TCP, UDP y demás transportes deben ignorar; routers deben ignorar; firewalls deben descartar y deberían registrar el tipo 4.
Una falsificación podía ejecutar un ataque ciego de reducción de throughput. Además, el filtrado ICMP generalizado impedía basar la congestión en la entrega del mensaje. ICMPv6 ni siquiera definió Source Quench.
Los ocho RFC prueban la secuencia normativa, no una retirada mundial instantánea. No demuestran que todo router lo enviara, que todo host obedeciera, que toda pérdida sea congestión o que ECN sea inmune a manipulación. Demuestran que un número registrado puede seguir siendo reconocible y perder toda autoridad operativa.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
