Imagine a highway on-ramp with a traffic light that controls how quickly cars can enter the highway during rush hour. When traffic becomes congested, the light turns red more frequently, forcing entering cars to wait and slow their rate of arrival. This ramp metering prevents highway gridlock by reducing inflow when capacity is strained.

In early IP networks, ICMP Source Quench (Type 4) served a similar purpose. When a router or host became overwhelmed with traffic—buffers filling, packets dropping—it could send Source Quench messages back to sources, signaling: "You're sending too fast. Slow down."

This message type represents a fascinating chapter in networking history. It was one of the first attempts at network congestion control but proved ineffective in practice. Today, Source Quench is officially deprecated (RFC 6633, 2012), and modern systems neither generate nor process it. Understanding why it failed illuminates the challenges of congestion control and why TCP's end-to-end mechanisms ultimately prevailed.

Source Quench was defined in RFC 792 (1981) as a primitive flow control mechanism. The concept was straightforward: provide explicit feedback from congested network elements to sources contributing to that congestion.

The Congestion Scenario:

                    Congestion Point
                          ↓
[Source A] ─────┐                      ┌───→ [Destination]
                 ├──→ [Router R] ──────┤
[Source B] ─────┘     (buffers full)   └───→ [Destination]
[Source C] ─────┘

1. Router R receives more traffic than it can forward
2. Buffers fill; packets start dropping
3. Router generates Source Quench to Sources A, B, C
4. (Theoretically) Sources reduce their sending rates
5. Congestion eases

The idea was logical: routers are closest to the congestion and know when they're overloaded. Why not have them directly tell sources to slow down?

Despite its intuitive appeal, Source Quench proved ineffective in practice. Multiple fundamental flaws prevented it from serving as a viable congestion control mechanism.

The Response Ambiguity Problem:

RFC 792 provided no guidance on what sources should do when receiving Source Quench:

Different operating systems implemented wildly different responses (or none at all), making Source Quench behaviorally unpredictable across the Internet.

While Source Quench attempted network-layer congestion signaling, the networking community realized that transport-layer congestion control was more effective. Van Jacobson's 1988 paper "Congestion Avoidance and Control" introduced the TCP congestion control mechanisms that became the Internet's foundation.

Why TCP Congestion Control Works:

1. Implicit signaling via packet loss: Sources detect congestion by observing dropped packets (via timeout or duplicate ACKs). No explicit ICMP required.

2. Precise rate control: The congestion window (cwnd) in bytes provides exact control over outstanding data. AIMD (Additive Increase, Multiplicative Decrease) provides mathematically proven fairness.

3. Self-clocking: ACKs arriving at the sender pace new packet transmissions. Faster ACKs allow faster sending; slower ACKs automatically slow the sender.

4. No router involvement: Routers just forward or drop. They don't generate congestion signals, preserving their CPU for forwarding.

5. Reliable feedback: TCP's acknowledgment mechanism ensures congestion signals (losses) are reliably detected.

In 2012, RFC 6633 officially deprecated ICMP Source Quench. The RFC provides formal recognition of what the networking community had known for decades: Source Quench doesn't work and shouldn't be used.

The RFC 6633 Timeline:

The 31-Year Journey:

Source Quench's official deprecation 31 years after its definition illustrates how slowly protocol standards evolve—even when practical problems are well understood. The IETF's formal process required extensive documentation of failures before standardizing the deprecation.

Beyond its ineffectiveness, Source Quench poses security risks if systems still honor it. These concerns reinforced the deprecation decision.

While Source Quench was deprecated, the need for congestion signaling remains. Modern networks use sophisticated mechanisms that avoid Source Quench's flaws.

Explicit Congestion Notification (ECN):

ECN deserves special mention as the modern, sanctioned replacement for explicit congestion signaling.

How ECN Works:

1. Source sets ECN-capable flag in IP header (ECT bits)
2. Congested router, instead of dropping, sets Congestion Experienced (CE) bit
3. Receiver sees CE bit, sets ECE flag in TCP ACK
4. Sender sees ECE, reduces cwnd as if packet was lost, sets CWR flag

ECN Advantages:

• Signaling happens before packet loss (proactive)
• Uses existing header bits (no extra packets)
• Receiver-to-sender path provides reliable feedback
• Sender reaction is well-defined (standard TCP response)
• No router CPU overhead for generating ICMP

ECN represents what Source Quench tried to achieve—explicit congestion notification—but implemented correctly.

Understanding how current systems handle Source Quench helps in troubleshooting legacy environments and security auditing.

Best Practices for Source Quench:

1. Firewall Rules: Block ICMP Type 4 at perimeter firewalls
2. Monitoring: Log Source Quench with alerts (shouldn't occur normally)
3. Security Audits: Check legacy devices for Source Quench generation capability
4. Incident Response: Treat unexpected Source Quench as potential attack indicator
5. Documentation: Note that systems ignore Source Quench for compliance auditors asking about congestion control

Source Quench's history offers valuable lessons about protocol design, congestion control, and the Internet's architectural principles.

ICMP Source Quench represents an important chapter in Internet history—a well-intentioned mechanism that proved unworkable, leading to its official deprecation and replacement by superior approaches.