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

[Fred Baker <[e-mail]>]

I think my view is clear. There is no operational problem. The working group can decide what it wants to do.

On Jan 5, 2011, at 10:15 AM, Fred Baker wrote:

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