Subject: Deprecating ICMP Source Quench messages

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Nov 2010 20:39:54 -0300

Folks,

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.

My understanding is that the general feeling was "Oh, yeah... we should
have deprecated ICMP Source Quench a long time ago" (which had also been
the feeling at tcpm when we had discussed this idea years ago).

However, since nobody had actually read the I-D, the decision about
adoption of this document as a wg item was deferred.

So I'm asking for feedback on the document, and on whether there's
support to pursue this document in tsvwg.

FWIW, the document is so short that, even if you have not read it
before, it shouldn't take more than a few minutes to skim through it.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Nov 2010 14:05:56 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fernando Gont
> Sent: Friday, November 26, 2010 3:40 PM
> To: tsvwg
> Subject: Deprecating ICMP Source Quench messages
> 
> Folks,
> 

I read it.  Looks good.  

Might also want to mention that ICMPv6 didn't bother defining 
Source Quench.

-d

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 29 Nov 2010 14:38:57 -0800

+1.

-- 

*Mahesh Jethanandani*
*Technical Leader*
**ERBU*
*
[email-masked] <mailto:[email-masked]>
Phone :*+1 408 527-8230*
Fax :*+1 408 853-0762*

**
170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com <http://www.cisco.com>

This e-mail may contain confidential and privileged material for the 
sole use of the intended recipient. Any review, use, distribution or 
disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact 
the sender by reply e-mail and delete all copies of this message.

---

From: "DeSimone, Antonio" <[email-masked]>
Date: Mon, 29 Nov 2010 17:49:30 -0500

Yes, looks good.  About time and seems to properly update RFC 1122's
direction on transport layers.

This is probably only of academic interest, but RFC 1122 also says, "If a
Source Quench message is received, the IP layer MUST report it to the
transport layer (or ICMP processing)."  I'd be happy to see section 3 of
draft-gont-tsvwg-source-quench also say, "If a Source Quench message is
received, an IP implementation MAY silently discard it."  Dropping the ICMP
message at the IP layer seems to have at least a minor benefit; 1122
currently precludes that option.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Nov 2010 20:53:46 -0300

Hi, Dan,

Thanks so much for your feedback! Please find my comments inline...

> Might also want to mention that ICMPv6 didn't bother defining 

Will do.

BTW, some have argued (off-list) that this document should also update
RFC 1812 such that the "SHOULD NOT generate ICMP SQ" is changed to "MUST
NOT generate ICMP SQ".

Thoughts?

Thanks!

Kind regards,

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Nov 2010 18:46:19 -0800

> Sent: Monday, November 29, 2010 3:54 PM
> To: Dan Wing
> Cc: 'tsvwg'
> Subject: Re: Deprecating ICMP Source Quench messages
> 
> Hi, Dan,
> 

My 'line' for MUST-versus-SHOULD is that interoperability is harmed
if a MUST is violated.  A stack compliant with
draft-gont-tsvwg-source-quench
isn't harmed (or helped) by receiving a source quench.  So, I don't
see much value in changing it to MUST.

-d

---

From: Fred Baker <[email-masked]>
Date: Mon, 29 Nov 2010 20:57:21 -0600

> draft-gont-tsvwg-source-quench-00, which aims at deprecating ICMP Source

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 29 Nov 2010 20:58:17 -0600

> RFC 1812 such that the "SHOULD NOT generate ICMP SQ" is changed to "MUST

If someone wants to update RFC 1812, I have some suggestions for them. It's a little long in the tooth :-)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Nov 2010 00:26:11 -0300

> If someone wants to update RFC 1812, I have some suggestions for them. It's a little long in the tooth :-)

I don't think anybody *wants* to update RFC 1812. Rather, some thought
that it would be the "correct" thing to do (not necessarily "pleasant"
or whatever :-) )

But nevertheless I'd be interested in hearing your suggestions....

Thanks!

Kind regards,