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

[Naiming Shen <[e-mail]>]

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