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

["George, Wes" <[e-mail]>]

> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Naiming Shen
> Sent: Sunday, January 08, 2012 3:54 PM
>
> 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.
[WEG] Yes, that's clear. The concern is that the presence of this extension means that there will be an increase in "to us" traffic for each router in the network. If there is indeed a need for this extension to pass information back, there is an additional incentive for malicious use as well as simple non-malicious overuse, both of which result in an increase in the flow of trace/ping packets that your average box has to deal with somehow. Whether it drops them due to a filter, a rate-limit, a failed authentication, or responds to good packets, it still is going to see more of them than it does today. *That* is the scaling problem. This might not be a completely unacceptable tradeoff in all cases, but you've failed to make your case that the benefit outweighs this risk, nor to my knowledge have there been other operators who have stood up and said "we need this feature for X reason" such that we can validate your assertion that this would be something that is helpful for operations.
>
> 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
[snip - do a bunch of stuff]
>  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?
[WEG] Yes, because you're leaving out several VERY important details -
1) the information this extension is proposing to supply back in a response requires additional IPC to collect information that is not available on the local linecard. That IPC isn't free, so it'll definitely increase overhead far more than just processing additional data in the packet, especially if your IPC isn't particularly efficient and scalable. This also eliminates any possibility that response to pings and traces can be offloaded exclusively to the linecard hardware instead of punting it to the RP.
2) as noted above, if this extension gets implemented, it'll generate more traffic from people trying to use it, either to gain access to information they're not authorized to, as another DoS attack vector, or assumedly, for its intended purpose. This is not exclusively about the minor overhead generated from processing this extension. It is also about the combined overhead of enforcing your proposed policy filtering, plus whatever else is already going on in the box, etc.

> 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.
[WEG] Actually yes, yes there is. *Especially* on boxes that have very limited resources to start with, the last thing you need to be doing is being cavalier with the available resources. There are already plenty of boxes out there that are running at or above their designed scale limits because there aren't funds to replace/upgrade them, and they basically do what they need to do. Those same vendor assumptions about what is "good enough", whether arbitrary or based on what state of the art was capable of at the time are likely part of the problem in today's world where things have changed and they're no longer "good enough. "
Further, your assumption is totally wrong if the box is already processing enough traffic that it's routinely bumping up against that rate-limit with routine and legitimate traffic, because now it's being potentially crowded out by new traffic that may not even be legitimate. It's even worse if the box gets hit with enough traffic that its built-in filtering mechanisms can't cope and therefore can't differentiate between good and bad traffic enough to keep the box functional.

For boxes that are more modern, your assumption that this is essentially a non-impact is still wrong. Throwing more hardware at the problem is rarely the right solution when compared with being more efficient and judicious with your use of the existing hardware. Just because the latest and greatest CPU hardware is currently running at 25% utilization doesn't mean that it always will be. The combination of code bloat, new features, and increases in all of the scaling vectors that contribute to steady-state and peak CPU (route churn, multicast joins/prunes, protocol keepalives, etc) gradually eat up that spare capacity. We buy hardware so that we can use it for a period of years to recover our investment - the average Telco equipment depreciation cycle is 7 years, and we're lucky to get anywhere near that as it is! Anything that you do to tilt the growth curve in the wrong direction represents an opportunity cost against when we have to replace/upgrade the hardware. Sure, there are bigger impactors out there than your proposed extension, but they all add up, and it's our job as operators to make sure we don't end up dying the death of a thousand cuts anymore than we turn on one big thing that blows up the router or busts all of our scaling and growth assumptions.
>
> 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.
[WEG] Unlikely, because for the most part, if that information is available via another, more widely implemented means (eg SNMP), chances are quite good that a) I already am polling the box for it and b) that I won't stop polling it and replace that with this extension. It is simply not a valid assumption that this will do anything other than duplicate existing methods unless it's pulling some unique information that isn't available via other methods. And so far, you have not presented a unique use case for this application.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.