ICMP type 4, Source quench message

ICMP type 4, Source quench

Protocol suite:	TCP/IP.
Protocol type:	Transport layer control protocol.
Base protocol:	ICMP, Internet Control Message Protocol.
Host implementation:	Optional.
Router implementation:	Optional.
Links:	IANA: ICMP parameters.

The ICMP Source quench message is a request to decrease the traffic rate of data messages sent to an internet destination.

The IP header plus the first 8 bytes of the original datagram's data is returned to the sender. This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first 64 data bits of the original datagram's data.

This message is not generated in response to a datagram destined for a multicast address.

RFC 792, pages 10 and 11:

A gateway MAY discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. If a gateway discards a datagram, it may send a source quench message to the internet source host of the datagram. A destination host may also send a source quench message if datagrams arrive too fast to be processed. The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. The gateway may send a source quench message for every message that it discards. On receipt of a source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives source quench messages from the gateway. The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages.

The gateway or host MAY send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. This means that the data datagram which triggered the source quench message may be delivered.

Code 0 may be received from a gateway or a host.

Host Implementation:

RFC 1122, page 41:

A host MAY send a Source Quench message if it is approaching, or has reached, the point at which it is forced to discard incoming datagrams due to a shortage of reassembly buffers or other resources. See Section 2.2.3 of [RFC 1009] for suggestions on when to send Source Quench.

If a Source Quench message is received, the IP layer MUST report it to the transport layer (or ICMP processing). In general, the transport or application layer SHOULD implement a mechanism to respond to Source Quench for any protocol that can send a sequence of datagrams to the same destination and which can reasonably be expected to maintain enough state information to make this feasible. See Section 4 for the handling of Source Quench by TCP and UDP.

Router Implementation:

RFC 1812, pages 56 - 58:

A router which sends ICMP Source Quench messages MUST be able to limit the rate at which the messages can be generated.

A router SHOULD also be able to limit the rate at which it sends other sorts of ICMP error messages (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem). The rate limit parameters SHOULD be settable as part of the configuration of the router. How the limits are applied (e.g., per router or per interface) is left to the implementor's discretion.

A router SHOULD NOT originate ICMP Source Quench messages. A router that does originate Source Quench messages MUST be able to limit the rate at which they are generated.

A router MAY ignore any ICMP Source Quench messages it receives.

A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([RFC 1016], [RFC 1018]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended.

RFC 2003, pages 6 and 8:

After an encapsulated datagram has been sent, the encapsulator may receive an ICMP [RFC 792] message from any intermediate router within the tunnel other than the tunnel exit point. The action taken by the encapsulator depends on the type of ICMP message received. When the received message contains enough information, the encapsulator MAY use the incoming message to create a similar ICMP message, to be sent to the originator of the original unencapsulated IP datagram (the original sender). This process will be referred to as "relaying" the ICMP message from the tunnel.

The encapsulator SHOULD NOT relay ICMP Source Quench messages to the sender of the original unencapsulated datagram, but instead SHOULD activate whatever congestion control mechanisms it implements to help alleviate the congestion detected within the tunnel.

ICMP type 4, Source quench message:

00	08	16
Type	Code	ICMP header checksum
unused
IP header + the first 64 bits of the original datagram's data.

Type. 8 bits. Set to 4.

Code. 8 bits. Always cleared to 0.

ICMP Header Checksum. 16 bits.
The 16-bit one's complement of the one's complement sum of the ICMP message starting with the ICMP Type field. The Checksum field should be cleared to 0 when the checksum is computed.

unused. 32 bits. Cleared to 0.

Internet Header + 64 bits of Original Data Datagram.
The internet header plus the first 64 bits of the original datagram's data. This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first 64 data bits of the original datagram's data.

Glossary:

RFCs:

[RFC 792] INTERNET CONTROL MESSAGE PROTOCOL.