Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Internet Layer (OSI Network Layer) Protocols            9  Internet Control Message Protocol (ICMP/ICMPv4 and ICMPv6)                 9  ICMP Message Types and Formats                      9  ICMP Version 4 (ICMPv4) Error Message Types and Formats

ICMPv4 Destination Unreachable Messages 1 2 3 ICMPv4 Time Exceeded Messages

Problems With Source Quench Messages

What's interesting about the Source Quench format is that it is basically a “null message”. It tells the source that the destination is congested but provides no specific information about that situation, nor does it specify what exactly the destination wants the source to do, other than to cut back on its transmission rate in some way. There is also no method for the destination to signal a source it has “quenched” that it is no longer congested and to resume its prior sending rate. This means the response to a Source Quench is left up to the device that receives it. Usually, a device will cut back its transmission rate until it no longer receives the messages any more, and then may try to slowly increase the rate again.

In a similar manner, there are no rules about when and how a device generates Source Quench messages in the first place. A common convention is that one message is generated for each dropped datagram. However, more intelligent algorithms may be employed, specially on higher-end routers, to predict when the device's buffer will be filled and preemptively quench certain sources that are sending too quickly. Devices may also decide whether to quench all sources when they become busy, or only certain ones. As with other ICMP error messages, a device cannot count on a Source Quench being sent when one of its datagrams is discarded by a busy device.

The lack of information communicated in Source Quench messages makes them a rather crude tool for managing congestion. In general terms, the process of regulating the sending of messages between two devices is called flow control, and is usually a function of the transport layer. The Transmission Control Protocol (TCP) actually has a flow control mechanism that is far superior to the use of ICMP Source Quench messages.

Another issue with Source Quench messages is that they can be abused. Transmission of these messages by a malicious user can cause a host to be slowed down when there is no valid reason. This security issue, combined with the superiority of the TCP method for flow control, has caused Source Quench messages to largely fall out of favor.

ICMPv4 Destination Unreachable Messages 1 2 3 ICMPv4 Time Exceeded Messages