Connected: An Internet Encyclopedia
RFC 1122 - 3.2.2.3 Source Quench: RFC-792

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 3. INTERNET LAYER PROTOCOLS
Up: 3.2 PROTOCOL WALK-THROUGH
Up: 3.2.2 Internet Control Message Protocol -- ICMP
Prev: 3.2.2.2 Redirect: RFC-792
Next: 3.2.2.4 Time Exceeded: RFC-792

### 3.2.2.3 Source Quench: RFC-792

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 [INTRO:2] 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.

DISCUSSION:

  A Source Quench may be generated by the target host or by some gateway in the path of a datagram. The host receiving a Source Quench should throttle itself back for a period of time, then gradually increase the transmission rate again. The mechanism to respond to Source Quench may be in the transport layer (for connection-oriented protocols like TCP) or in the application layer (for protocols that are built on top of UDP).

  A mechanism has been proposed [IP:14] to make the IP layer respond directly to Source Quench by controlling the rate at which datagrams are sent, however, this proposal is currently experimental and not currently recommended.

Next: 3.2.2.4 Time Exceeded: RFC-792

Connected: An Internet Encyclopedia
RFC 1122 - 3.2.2.3 Source Quench: RFC-792