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 Book is Here... and Now On Sale!

The whole site in one document for easy reference!
The TCP/IP Guide

Custom Search







Table Of Contents  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

Previous Topic/Section
ICMPv4 Destination Unreachable Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Time Exceeded Messages
Next Topic/Section

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 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.


Previous Topic/Section
ICMPv4 Destination Unreachable Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Time Exceeded Messages
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.