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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 03 Jan 2011 16:02:04 +0000

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)

---

From: <[email-masked]>
Date: Mon, 3 Jan 2011 14:01:54 -0500

> or have comments on the suitability of this draft as a TSVWG work item.

The problem is that everyone here "knows" that Source Quench is deprecated in "running code", but that knowledge is not documented.  We really should document it just in case someone who isn't in the "know" tries to use Source Quench.  This draft does a reasonable job of that by specifying that Source Quench SHOULD NOT be sent and SHOULD be ignored on receipt.

Proceeding to answer the questions:

1) There is an existing problem, although not a major one.
2) This draft effectively addresses that problem.
3) I support this draft as a tsvwg work item.

A longer list of surveyed implementations in Appendix A would be a good idea (e.g., Windows and MacOS for starters).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Monday, January 03, 2011 11:02 AM
> To: tsvwg list; [email-masked]
> Subject: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench)
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jan 2011 17:18:41 -0300

Hi, David,

Thanks so much for your comments and support! Please find my response
inline...

On 03/01/2011 04:01 p.m., [email-masked] wrote:

> A longer list of surveyed implementations in Appendix A would be a
> good idea (e.g., Windows and MacOS for starters).

I will be including Solaris in the list in the next revision of the
document (thanks to feedback by James Carlson). And will ping the
Windows folks about the status of Windows -- however, I bet they ignore
ICMP SQs. -- will also try to investigate the status of MacOS.

Thanks!

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Jan 2011 10:15:14 -0800

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Jan 2011 03:55:07 -0300

Hi, Fred,

Please take a look at the document. Among other things, it deprecates
the *reaction* to ICMP SQ. -- Specs-wise, TCP is still required to
slow down upon receipt of an ICMP SQ.

Thanks!

Best regards,
Fernando

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Jan 2011 23:11:16 -0800

> slow down upon receipt of an ICMP SQ.

Are there any Source Quenches out there? Do you know of any equipment anywhere that is generating them?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Jan 2011 04:31:38 -0300

> Are there any Source Quenches out there? Do you know of any equipment anywhere that is generating them?

Isn't one of the IETF's responsibilities to maintain its
specifications? Or has it become intentional for the specs to be
disconnected with the "running code"?

Thanks,
Fernando

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Jan 2011 23:35:09 -0800

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Jan 2011 02:20:48 -0700

Fred,

Fred Baker wrote:                      (Wed, 05 Jan 2011 23:35:09)
>
> I think my view is clear. There is no operational problem. The
> working group can decide what it wants to do.
> 

Well, I agree with you, Fred.  It is even more wasteful of the WG's
time arguing whether it is wasteful of the WG's time.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "DeSimone, Antonio" <[email-masked]>
Date: Thu, 6 Jan 2011 09:40:28 -0500

>> working group can decide what it wants to do.

I agree with Fred on this.  There is no operational problem, but there is
are minor spec problems.  At best that is bad form, but there are some
people who care about the specs.

The doc closes the identified spec problems, in particular by updating 792
and 1122, which contain statements inconsistent with running code and
now-accepted good practices.  I support this draft as a tsvwg work item.

> time arguing whether it is wasteful of the WG's time

agree

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 09:58:45 -0800

+1 on both counts (agree with Fred, agree the WG should consume 
resources carefully)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jan 2011 15:09:25 -0300

Joe,

It is "surprising" that you don't support this document (if I read your
view correctly), as you were one of the motivators of this I-D. During
the last few years, and in many opportunities, you have insisted that
"we should formally deprecate ICMP SQ", etc.

Given that the I-D is already good enough, the height of irony is that
more resources are being wasted discussing whether we're wasting energy,
rather than adopting the doc, possibly rev'ing it once more, WGLC and
publish.

Sigh..

P.S.: It makes me wonder that we, at the IETF, do not care about our
specs being outdated and irrelevant.

Fernando

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 10:17:00 -0800

> "we should formally deprecate ICMP SQ", etc.

Yes. Does that mean we need to create a separate doc to do it? No.

We can put it on queue for 1122-bis or 1812-bis, and *whenever* that 
happens should be sufficient for this particular issue.

I'm getting a bit tired of separate docs for each individual issue.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jan 2011 15:34:34 -0300

> Yes. Does that mean we need to create a separate doc to do it? No.

You proposed exactly this a number of times, on the tcpm list. -- Should
I dig the archive?

> happens should be sufficient for this particular issue.

Please be realistic.

I'm not going to continue wasting energy discussing about wasting
energy. Nor am I going to get into yet another endless discussion on why
you oppose to virtually every document you have not authored.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 10:37:45 -0800

As a followup to the note below, I'd like to raise a separate point of 
discussion.

On 1/6/2011 10:17 AM, Joe Touch wrote:
...
> I'm getting a bit tired of separate docs for each individual issue.

I'd really like to see some time spent at each WG meeting, and 
periodically on the list (TSVWG and TCPM at least, but all WGs would 
benefit from this, IMO), addressing:

- what CAN be done (vs what can't)
- what SHOULD be done
- HOW to do it, once decided
- prioritization of WHEN to do it, given the above

Right now, we tend to ask the first question only.

What does that mean to this most recent discussion?

- issues that are not related should be separated out
	an RFC is not an opportunity for a shopping list

- separate issues should be considered independently

- just because we agree on an issue does NOT mean an RFC is warranted

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 10:42:39 -0800

> You proposed exactly this a number of times, on the tcpm list. -- Should

Yes, I wanted the issue separate so we could decide on it *independently*.

Once we decide what do do, we can then make a decision on how best to do 
it. In this case, there's no disagreement that SQ should be deprecated, 
or that (IMO) that issue should be decided independent of other ICMP or 
TCP issues.

The question is whether *issuing* a separate doc is the best way to 
achieve that recommendation. IMO, this is one of the ones that can wait. 
that's what I'm hearing from others too.

>> happens should be sufficient for this particular issue.

We all are. Realistically, an RFC officially deprecating a feature that 
is already recommended against, and is already not being used (far as 
any of us can tell) serves no *urgent* purpose.

Yes, that means this issue might wait on the shelf for a long time. So what?

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 06 Jan 2011 21:51:04 -0500

> Yes, that means this issue might wait on the shelf for a long time. So

Realistically, if there isn't an RFC, 2 years from now someone will come 
and re-write Fernando's document and ask to have an RFC published and 
we'll waste more time on the same discussion, so I'm in favor of 
blasting this through the process and getting it published as long as 
there's rough consensus on it.  We publish plenty of similarly useless 
book-keeping RFCs without controversy.

--
Wes Eddy
MTI Systems

---

From: Mark Allman <[email-masked]>
Date: Fri, 14 Jan 2011 09:59:58 -0500

> Realistically, if there isn't an RFC, 2 years from now someone will
> come and re-write Fernando's document and ask to have an RFC
> published and we'll waste more time on the same discussion, so I'm
> in favor of blasting this through the process and getting it
> published as long as there's rough consensus on it.  We publish
> plenty of similarly useless book-keeping RFCs without controversy.

I agree with this and with Fred's notion.  It isn't a problem, but this
document is completely benign and shouldn't "waste time".  Nobody has
brought up anything but process issues (i.e., nobody is arguing for
reacting to SQ) so lets just call rough consensus and move on.

allman

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 14 Jan 2011 20:48:19 -0000

+1

> From: Mark Allman [mailto:[email-masked]]
> Sent: Freitag, 14. Jänner 2011 16:00
> To: Wesley Eddy
> Cc: [email-masked]; Joe Touch
> Subject: Re: Deprecation of ICMP Source Quench messages(draft-gont-
> tsvwg-source-quench)
> 
> 
> published
> > and we'll waste more time on the same discussion, so I'm in favor of