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

[Jared Mauch <[e-mail]>]

If your goal is to replace snmp since it doesn't do what you want, it seems like that is another I-d

Jared Mauch

On Jan 8, 2012, at 3:54 PM, Naiming Shen <[e-mail]> wrote:

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