Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Naiming,

Very good clarification.

Additionally, an implementation could simply require this functionality
to be not enabled via default (or disabled via CLI), erasing any concern
one may have in the existing deployments. In other words, if I want this
functionality in my network, then I will go enable it (at whatever cost
I need to bear).

Cheers,
Rajiv 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of Naiming Shen (naiming)
> Sent: Sunday, January 08, 2012 3:54 PM
> To: SM
> Cc: [e-mail]
> Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt
> 
> 
> I have seen several comments regarding this extension having scaling
issue on
> the Internet
> and this probably is due to confusion on how this extension will be
used or how
> the
> traceroute/ping application is processed today. Let's do some analysis
here.
> 
> Traceroute packets if they are not TTL expired you don't process them
on the
> router;
> or Ping packets not destination to your address, you don't process
them on your
> router.
> This extension does not change those behavior. You only check those
extension
> while
> you are normally processing those packets anyway. So if you don't
normally
> filter those
> packets (which is a good thing you are doing), you will have no need
to filter
> them just
> because the router support this extension later. I hope this point is
clear.
> 
> Now let's see what will be the percentage of processing which is
actually
> related to this
> Traceroute/ping extension. For normal Traceroute for example, you need
to
> check UDP
> header information, you need to verify things such as checksum, you
need to
> fetch information
> to format packet to send back through your ICMP socket, information
can be
> many, such as
> interface IP address, Nexthop information, interface names (all
defined in RFCs
> now), copy the
> original payload (even you don't understand the format) and finally
format the
> ICMP packet
> to send it back. Now with this extension, you just check (in a well
known
> location of the packet)
> if it exists this extension by the magic#, if not there is nothing
more to do. Or
> you can
> have a policy to check only if the probe source address is from
network
> x.x.x.x/y,
> otherwise don't even bother with the extension. For those checks, I
would say
> may be 2-5%
> of the original processing you have already needed to do. So, does
this actually
> cause a
> concern of scaling on the Internet?
> 
> For every Traceroute/ping router implementation, they do
rate-limiting. Some
> do flow
> based, some just do a flat time based rate-limiting, e.g. they only
allow 100
> such packets
> per minute. Let's forget about the Moor's Law, forget about the
hardware/cpu
> capability
> these days, let's forget about multi-core cpu development anymore;
let's only
> concentrate
> on the legacy stuff of the past. Say take a 15 years old router, let's
upgrade the
> software
> to this extension for the Traceroute/ping. Let's assume also this
extension
> actually consume
> 10% more cpu. So instead of default punting 100 such a packet per
minute, now
> this
> router is programmed only punting 90 such packets to process. Nothing
wrong
> with that.
> This 100 per minute was some vendor's arbitrary decision 15 years
back, who
> can say
> 50 is not perfect or 200 is not the right thing for now. There is no
place you
> actually need to do
> special filtering just due to this extension. The point here is that,
if the
> implementation does
> want to take this overhead into account, they can adjust that easily
with also in
> consideration
> of today's hardware/cpu capabilities.
> 
> Then if you think about this extension can actually ask for a subset
of
> information, instead
> of just dumping everything the ICMP RFCs have defined, one may save
some
> cpu and bandwidth
> in that sense.
> 
> On the other hand if one has an implementation using this extension,
for
> example an
> OpenFlow ID trace which actually trace through the real path on the
> programed OpenFlow
> based switches. this operation let's say cost 100% of the normal
Traceroute
> processing,
> but here we hope it does not do this for every Traceroute packet, and
it actually
> checks to see
> if this is from an authorized network or station for using this
feature. And this is
> a new feature
> you want so you are willing to spend more cpu on that.
> 
> thanks.
> - Naiming
> 
> 
> On Jan 8, 2012, at 2:49 AM, SM wrote:
> 
> > At 12:44 07-01-2012, Warren Kumari wrote:
> >> If ping processing goes from being a negligible use of resources to
> something noticeable, the only reasonable solution I have is "deny
icmp any any
> echo" on edge.
> >> This is not good for me, this is not good for my customers, this is
not good
> for the Internet at large.
> >
> > Agreed.
> >
> > If the authors really want to see draft-shen-traceroute-ping-ext-03
published,
> they could add an Applicability Statement saying that the domain of
use is not
> the Internet.  Not giving due consideration to input from operators
can only
> discourage them from providing input in future.
> >
> > Regards,
> > -sm
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area