| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ICMPv4 Source Quench Messages (Page 1 of 3) When a source device sends out a datagram, it will travel across the internetwork and eventually arrive at its intended destinationhopefully. 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 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.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |