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

When a source device sends out a datagram, it will travel across the internetwork and eventually arrive at its intended destination—hopefully. At that point, it is up to the destination device to process the datagram, by examining it and determining which higher-layer software process to hand the datagram.

If a destination device is receiving datagrams at a relatively slow rate, it may be able to process each datagram “on the fly” as it is received. However, datagram receipt in a typical internetwork can tend to be uneven or “bursty”, with alternating higher and lower rates of traffic. To allow for times when datagrams are arriving faster than they can be processed, each device has a buffer where it can temporarily hold datagrams it has received until it has a chance to deal with them.

However, this buffer is itself limited in size. Assuming the device has been properly designed, the buffer may be sufficient to smooth out high-traffic and low-traffic periods most of the time. Certain situations can still arise in which traffic is received so rapidly that the buffer itself fills up entirely. Some examples of scenarios in which this might happen include:

• A single destination is overwhelmed by datagrams from many sources, such as a popular Web site being swamped by HTTP requests.
  
  
• Device A and device B are exchanging information but device A is a much faster computer than device B and can generate outgoing and process incoming datagrams much faster than B can.
  
  
• A router receives a large number of datagrams over a high-speed link that it needs to forward over a low-speed link; they start to pile up while waiting to be sent over the slow link.
  
  
• A hardware failure or other situation causes datagrams to sit at a device unprocessed.

A device that continues to receive datagrams when it has no more buffer space is forced to discard them, and is said to be congested. A source that has its datagram discarded due to congestion won't have any way of knowing this, since IP itself is unreliable and unacknowledged. Therefore, while it is possible to simply allow higher-layer protocols to detect the dropped datagrams and generate replacements, it makes a lot more sense to have the congested device provide feedback to the sources, telling them that it is overloaded.

In IPv4, a device that is forced to drop datagrams due to congestion provides feedback to the sources that overwhelmed it by sending them ICMPv4 Source Quench messages. Just as we use water to quench a fire, a Source Quench method is a signal that attempts to quench a source device that is sending too fast. In other words, it's a polite way for one IP device to tell another: “SLOW DOWN!” When a device receives one of these messages it knows it needs to cut down on how fast it is sending datagrams to the device that sent it.

ICMPv4 Destination Unreachable Messages 1 2 3 ICMPv4 Time Exceeded Messages