Source Quench is an ICMP based mechanism used by network devices to inform data sender that the packets can not be forwarded due to buffers overload. When the message is received by a TCP sender, that sender should decrease its send window to the respective destination in order to limit outgoing traffic. The ICMP Source Quench usage is specified in RFC 896
- Congestion Control in IP/TCP Internetworks. The currently used standard specified in RFC 1812
- Requirements for IP Version 4 Routers says that routers should not originate this message, and therefore Source Quench should not be used any more.
Problems with Source Quench
There are several reasons why Source Quench has fallen out of favor as a congestion control mechanism over the years:
- Source Quench messages can be lost on their way to the sender (due to congestion on the return path, filtering/return routing issues etc.). A congestion control mechanism should be robust against these sorts of problems.
- A Source Quench message carries very little information per packet, namely only that some amount of congestion was sensed at the gateway (router) that sent it.
- Source Quench messages, like all ICMP messages, are expensive for a router to generate. This is bad because the congestion control mechanism could contribute additional congestion, if router processing resources become a bottleneck.
- Source Quench messages could be abused by a malevolent third party to slow down connections, causing denial of service.
In effect, ICMP Source Quench messages are almost never generated on the Internet today, and would be ignored almost everywhere if they still existed.
- Congestion Control in IP/TCP Internetworks, RFC 896, J. Nagle, January 1984
- Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID), RFC 1016, W. Prue and J. Postel, July 1987
- Requirements for IP Version 4 Routers, RFC 1812, F. Baker (Ed.), June 1995
- IETF-discuss message with notes on the history of Source Quench, F. Baker, Feb. 2007 - in archive
- 05 Jul 2005