Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench)

[Fred Baker <[e-mail]>]

As we have discussed privately, I'm not sure I agree that the deprecation of source quench is "undocumented", given RFC 1812's comments on it, but the statements are at the MAY/SHOULD level, not MUST. Given that we don't see source quench in use in the network and source quench was not carried forward into IPv6 (which is where current attention SHOULD be, IMHO), I don't think that a document changing "SHOULD" to "MUST" accomplishes much. The document is probably a very fine document, but I don't think the issue is a good use of the working group's time.

From RFC 1812:

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.

5.3.6 Congestion Control
   ...
   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.

On Jan 3, 2011, at 8:02 AM, Gorry Fairhurst wrote:

> There was discussion of the draft below on the TSVWG list and at the last IETF meeting.
> 
> Deprecation of ICMP Source Quench messages
> (draft-gont-tsvwg-source-quench)
> http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01
> 
> We'd welcome feedback to the list on the question below:
> 
>   "Does the WG believe this document effectively addresses
>   an existing problem, and should this draft form the basis for
>   a solution?"
> 
> Please email the chairs and/or list if you support this as a work item, or have comments on the suitability of this draft as a TSVWG work item.
> 
> Best wishes,
> 
> Gorry & James
> (TSVWG Co-Chairs)