How is DPI related to needing more bandwidth needed per base station or residential area?
also if you have not already read this (http://www.wired.com/science/discoveries/news/2006/05/70908) earlier, doesn't hurt to read once again.
A) this is probably true to an extent. B) slurping everything to disk is impractical, and no one has that much storage, so you're back to parsing and deciding at the boundary. This "leisure" time doesn't ever happen when you save everything all the time. C) this point seems to contradict the various claims of reasonable network maintenance I've seen; if it's trash you want to drop, you want to drop it on the floor not on your disk. If you're keeping actual traffic rather than just summaries of traffic, you're not doing reasonable network maintenance.
DPI requires decoding application-layer protocols. This requires many layers of decoding. That's all well and good for one client (feature phones happily load web pages, after all), but to do it inline at the router means the router needs to be as powerful as the sum of all of the networking hardware of the hosts it routes to.
Source: at my last job, we were working on fixes for security holes that could cost billions of dollars of damages per incident, and the fixes were solvable in software, but we couldn't persuade customers of the value of buying beefy enough network equipment to actual block the attacks. Mind you, I didn't run any numbers myself on the cost of the hardware; that's just what my colleagues said.
If you have any trustworthy source of ballpark pricing for a 10Gb/s DPI solution, Narus or otherwise, I'm curious. I'm talking BALLPARK here.
I looked up some of Narus's whitepapers, and what I'm seeing looks like Grade A Bullshit. That doesn't mean they ARE bullshit -- their whitepapers would look like this in either case. But I would like to point out that it is absolutely possible to build a company like this without actually delivering the goods, because many of your potential customers are largely incapable of understanding whether or not the goods have really been delivered.
ALSO, I guess I should remember that DPI for stopping malware, and DPI for spying on citizens, are really different things. When you're spying on citizens, 90% effectiveness is good enough. When you're trying to block malware (versus e.g. commited cyberterrorism), 90% is a little better than 0%, but not much, because your adversary can try many times and they only have to succeed once. So in that sense, the DPI being discussed here is a much easier problem than the DPI that we were trying to tackle.
any cellular network that you send data on, already does this. standardization only levels the playing field.
It does equal bandwidth until everything is jumbo frames UDP
If you want to argue against DPI that's fine but "it'll make the Internet slower" comes off as whining plus you're fighting against the exponential effects of Moore's law. A quick Google search tells me there are several products that'll do line rate DPI at 10Gbps.
There are much better arguments to be made against DPI such as privacy, a slippery slope to a walled garden, or just plain unfairness.
All else being equal, increasing the denominator reduces the rate. It's just math.
If we assume that there are a fixed number of packets in flight at any given time, and we increase the flight time of all packets, then it will be true that the packets-processed-per-time will drop (and ceteris paribus that the bandwidth would drop). This assumption, however, is incorrect. One could (in theory, and within limits in practice) add extra pipeline steps to do extra processing, increasing the time taken to process each packet, without decreasing the rate at which packets traverse the processor (e.g. the router). This is hopefully what happens.
Of course, as I and others said elsewhere, it is OFTEN the case that as processing-per-packet increases, this becomes a bottleneck on packets-per-time, and this does eventually limit the bandwidth. (Jumbo frames sometimes help, but not if the processing is being done on the entire application payload, which of course is what DPI does, so jumbo frames ain't gonna help there.) So in practice, more DPI might well decrease bandwidth.
If you would like an analogy, imagine the hosts are cities, the packets are trucks carrying goods, and the route is a highway of fixed speed limit and width. (Yes, one weird thing about this analogy is that building new trucks is basically free and done on-demand.) Suppose we consider shipping an infinite amount of coal from city A to city B. The number of tons of coal shipped per day does not depend on the length of the highway. The amount of time it takes for each ton of coal to get there DOES depend on the length of the highway. Coal-per-day is like bandwidth, hours-per-truck-trip is latency. You can increase or decrease one without affecting the other, all else being equal.
Note: really, I shoulda done that example as a series of tubes, oh well.
My personal understanding of DPI is that they want to do it in-series so as to be able to reset TCP connections immediately upon detecting a hit, but that might not be how they do it.