Subject: RE: Content for deprecating source-quench

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 1 Apr 2011 01:07:17 -0700

Fernando,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Thursday, March 31, 2011 10:43 AM
> To: Bob Briscoe
> Cc: Anantha Ramaiah (ananth); tsvwg IETF list;
draft-ietf-tsvwg-source-
> [email-masked]; [email-masked]
> Subject: Re: Content for deprecating source-quench
> 
> On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe <[email-masked]>
> wrote:
> >
> > Personally I think, if an RFC is going to deprecate something, it
> needs to
> > say why.
> 
> I fully agree. The current doc is what it is because at the time the
> idea of formally deprecating ICMP SQ originated, folks argued that a
> kinda a single page document would do. That's it. But I do agree with
> your view.
> 
> 
> > Referencing an email archive is a bad idea.
> 
> Yes. I just asked which option would make you happier. :-) Unless
> somebody yells, I'll incorporate this in the current Section 2 of the
> I-D.

Well, I would do both. i.e, add some text which enumerates the reasons
of deprecating SQ. Also add the reference.

That said, I did briefly go through the email archive pointed by Bob,
but I am afraid I don't necessarily agree with some of the assertions
that email has made :-

a) "IPsec and tunneling" :- how different is it for any other for any
other ICMP message. For example ICMP PTB messages?

Also, it needs to be noted that most stacks do check the sanity of
incoming ICMP messages (as described by RFC 5927). So the robustness
worries can be alleviated with such checks.

b) "ICMP packet creation is normally (always) implemented on the ingress
interface of a router. Congestion is detected on the egress, where it is
too late, and too expensive wrt. critical processing time, to trigger
the creation of an ICMP packet, without hugely re-working the
implementation architecture of most routers."

This is again not true, even when you are forwarding to the outgoing
link, you need to check with the MTU and if it needs fragmentation and
DF bit is on, an ICMP PTB message would get sent. So the SQ case is no
different where you  can consult the outgoing link properties (queues,
QOS etc.,) and generate the ICMP back. (it can be ingress or egress
feature or both)

There are other reasons which seem to point to some other RFC etc., but
I haven't had a chance to read them, so, at a first glance the reasons
of deprecating seem dubious or atleast this falls into the category of
"what might have been valid 15 years back, is no longer true, things
have changed"

I am not saying that SQ should not be be deprecated, but this it time to
probably dig up history, validate it and share the results in the
document.

-Anantha
> Thanks!
> Fernando

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Apr 2011 10:25:12 +0100

Anantha,

> > On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe <[email-masked]>

snip

>worries can be alleviated with such checks.

The difference is that for some ICMP messages it's not a show-stopper 
if they can't get back. But for congestion control "most stacks" 
isn't good enough.

>probably dig up history, validate it and share the results in the

I agree - I posted that list in 2006, as a copy and paste from a tech 
note I had written in 2000, which in turn was based (in some cases) 
on info Jon gave me which could have been based on reasons valid even 
earlier. They certainly should not just be forwarded from 
/dev/history to /dev/standards-track without going through /dev/brain.

Bob

> > Fernando

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design