Re: Deprecating ICMP Source Quench messages

[Fred Baker <[e-mail]>]

On Nov 26, 2010, at 5:39 PM, Fernando Gont wrote:

> At the tsvwg wg meeting @ Beijing I presented the I-D
> draft-gont-tsvwg-source-quench-00, which aims at deprecating ICMP Source
> Quench messages.

You may be interested to scan RFC 1812 for comments on Source Quench. While RFCs 1122/1123 require a host to do something intelligent with them should they arrive, routers are not supposed to send them.


   ICMP Source Quench error messages, if sent at all, MUST have their IP
   Precedence field set to the same value as the IP Precedence field in
   the packet that provoked the sending of the ICMP Source Quench
   message.  All other ICMP error messages (Destination Unreachable,
   Redirect, Time Exceeded, and Parameter Problem) SHOULD have their
   precedence value set to 6 (INTERNETWORK CONTROL) or 7 (NETWORK
   CONTROL).  The IP Precedence value for these error messages MAY be
   settable.

   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.

      (1) Count-based - for example, send an ICMP error message for
           every N dropped packets overall or per given source host.
           This mechanism might be appropriate for ICMP Source Quench,
           if used, but probably not for other types of ICMP messages.

4.3.3.3 Source Quench

   A router SHOULD NOT originate ICMP Source Quench messages.  As
   specified in Section [4.3.2], a router that does originate Source
   Quench messages MUST be able to limit the rate at which they are
   generated.

   DISCUSSION
      Research seems to suggest that Source Quench consumes network
      bandwidth but is an ineffective (and unfair) antidote to
      congestion.  See, for example, [INTERNET:9] and [INTERNET:10].
      Section [5.3.6] discusses the current thinking on how routers
      ought to deal with overload and network congestion.

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

   DISCUSSION
      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
      ([INTERNET:11], [INTERNET:12]) 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.

   As described in Section [4.3.3.3], this document recommends that a
   router SHOULD NOT send a Source Quench to the sender of the packet
   that it is discarding.  ICMP Source Quench is a very weak mechanism,
   so it is not necessary for a router to send it, and host software
   should not use it exclusively as an indicator of congestion.

   INTERNET:11.
        Prue, W., and J. Postel, "The Source Quench Introduced Delay
        (SQuID)", RFC 1016, USC/Information Sciences Institute, August
        1987.

   (15) Congestion control and resource management.  On the advice of
        the IETF's experts (Mankin and Ramakrishnan) we deprecated
        (SHOULD NOT) Source Quench and said little else concrete
        (Section 5.3.6).