80 Gbps Deep Packet Inspection Hardware Announced

An anonymous reader writes to tell us that Procera Networks is launching a new weapon on the deep packet inspection (DPI) front. At $800,000 these 80 Gbps tanks aren't going to be sitting in everyone's closet, but it could mean that more traffic shaping is on the way. "The PL10000 can handle up to 5 million subscribers and can track 48 million real-time data flows. That's certainly a potent piece of hardware, but larger ISPs will need more. That's why Procera designed the new machines with full support for synchronizing traffic flows where return traffic might be routed to a different PacketLogic machine. The machine receiving the return traffic can make the machine monitoring the outbound traffic aware that it sees the other half of a TCP/IP conversation, for example, giving the devices more accuracy than those which might only have access to one side."

Just in time!

Just in time for the olympic games!

$800,000?

At almost a million dollars a pop, is it really saving money for ISPs to use these? How many would a major ISP need to shape all of their traffic?

Math is fun.

$800,000/5 million subscribers = $0.16 per subscriber.

Expect to see the surcharge in your next bill!!!

Re:Math is fun.

$800,000/5 million subscribers = $0.16 per subscriber.

Yeah, but 80Gbps/5 million subscribers = 2kBps. How long can you keep 5 million subscribers with speeds like that?

Re:Math is fun.

assuming every single subscriber is using his connection continuously 24 hours per day, not even stopping to so much as read a webpage or an email ...

Re:Math is fun.

Yes, 2kBps would be the available average bandwidth. So, assuming that nobody is running p2p software, downloading pornos, or retrieving linux isos, the available peak bandwidth would be much higher. But that would mean that you'd have to advertise speeds that you can't provide during high-demand times and hide a "we'll provide whatever we feel like providing and you'll have to keep paying for it whether you're satisfied or not" clause in the contract. Would any ISP ever stoop so low as to try something like that?

Re:Math is fun.

This is also assuming every single packet that an ISP manages goes through a single physical location. So unless Comcast routes every packet to their headquarters at the top of Mt. Doom for inspection before delivery, they're going to need a lot more of these.

Re:$800,000?

Seriously.
Spend the money on a couple more 40Gb fiber lines instead.

Re:$800,000?

Better yet, force the telco's to put up the fiber networks they were awarded huge tax cuts to put up! They don't have bandwidth problems they have accountability problems created by the RIAA et el backed by people desperately trying to find a way to sensor the net.

Re:$800,000?

force the telco's to put up the fiber networks they were awarded huge tax cuts to put up!

Just bill them for the back taxes for the networks they failed to install as promised.

Re:$800,000?

At almost a million dollars a pop, is it really saving money for ISPs to use these? How many would a major ISP need to shape all of their traffic?

Not only that but it seems like a dumb technical solution for P2P traffic shaping.

Most ISPs would be geographically distributed. I can't think of to many places where you would actually see this much traffic. You'd need, what, 10 OC-192's to see 80Gb/s? Maybe they add all the GigE ports together and cheat to advertise a big number, but still.

Second, this is the kind of device you want closest to your customers, not down the line where your traffic aggregates. If you want to stave upstream traffic, do it as soon as possible in the network.

Third, it's better in almost every aspect of IT to scale out, not up. Every node would be different. You could have business customers in one CDIR or another and different configurations for each. I'm sure this thing is configurable per port, but I'd think it would be easier and more cost effective to have smaller distributed individually configurable devices only where you need them.

No, I don't think this thing is best suited to do traffic shaping for the typical ISP. If you can do DPI on that much traffic, there's bigger, less benign applications I can think of.

Re:$800,000?

Yep, and how much were computers, originally? The price on these will drop when enough of them are bought.

No it won't. There is realistically only a market for a handful of these worldwide. Not several million of them like PCs. Its exactly like cisco hardware, it has remained astronomically expensive simply because only a very small select group of people (network admins) actually buy them.

tank

80 Gbps tanks aren't going to be sitting in everyone's closet

Not until Wrath of the Lich King comes out ... wait, what were we talking about?

DPI - Encrypt

DPI has only one option when presented with encrypted information however (at least afaik). Give the packet a low priority or pass it through normally (of course, it could also drop it entirely but doing that as a rule would be problematic to say the least). So it would be possible to force a bet. Can the ISPs afford to give encrypted traffic a very low priority?

Re:DPI - Encrypt

Can the ISPs afford to give encrypted traffic a very low priority?

No, but if they wanted to be pricks they could identify p2p users and give THEIR encrypted traffic a very low priority.

Even if you ran with full encryption and encrypted the communication with the tracker it's still trivial to identify you as a p2p user -- not many VPNs make connections with dozens (or hundreds) of remote hosts.

The only way around that would be to VPN somewhere and use that VPN link to pass all your p2p traffic -- but if you have the means at your disposal to set that up then you likely have the means to find an ISP that doesn't throttle your p2p traffic.

Re:DPI - Encrypt

https://www.relakks.com/?lang=en [relakks.com] does exactly what you've described. I believe the cost is $10/month US.

Re:DPI - Encrypt

It should be trivial to limit any end nodes to a maximum of, say, 8 encrypted connections with unique netblocks on the destination. Any new sessions negotiated after that will automatically be given very low priority.

Also, a TCP packet contains a lot more than just an encrypted payload: you can tell a lot about a packet from the other parts: source and destination ports, sequence and acknowledgement numbers, header length, reserved ID bits, urgent flag, ACK flag, push flag, RST flag, SYN flag, FIN flag, Window size, checksum, urgent pointer and even the options field. I'm sure that it wouldn't be very difficult to set up a bayesian detection ruleset using this data to identify what protocol is being used. The checksum and flags wouldn't be all that useful, but the port numbers, header length, window size, urgent pointer and seq/ack number progressions can be quite telling.

Re:DPI - Encrypt

Freenet runs over UDP with fully randomized ports. It acknowledges messages, but even the ACKs are encrypted. Window sizes are hidden behind the crypto as well. Except for the initial connection, handshaking is done by routing through previously established connections.

I'd like to see them DPI that. The best they can do is traffic analysis and decide it looks like P2P and throttle on that.

Re:DPI - Encrypt

The problem with this whole "it's encrypted so they'd have to throttle SSL too" idea is that bittorrent doesn't use SSL, and lacks a Diffie Hellman exchange. Encrypted BT traffic looks nothing like any other traffic, so it can still be picked out of the traffic flows and thrown into another QoS bracket. Using SSL for BT would also be stupid, because SSL(the key exchange in partciular) is computationally expensive. You'd peg your CPU at 100% the whole time you were grabbing your porn.

Ok... I have a question...

How much of this advertised speed is more or less advertising hype more than anything else??? We all know what it takes to do packet inspection and rules table lookups, so to me, this number seems a bit on the hyped up side...

Anyone else getting this same riff??

I've decided: this is evil.

think about the original definition of ethernet and of IP, in general.

in general, it was setup to pass packets and ideally to keep them in the same order and not drop them. beyond that, the upper layers (tcp and udp) did any higher level functions.

this worked! for the longest (damned) time, it worked.

and now, ISPs (and large networks) are starting to try to break out the 'cable is a bunch of bits' into discrete 'services' and then try to re-order things, drop things, queue them differently or somehow treat things non-uniformly.

I think this is Evil(tm).

I've been in the networking field for a few decades (really) and I've seen traffic shaping (what a euphemism, btw!) try to argue its case over and over again. but I keep getting back to the basic design principles of ethernet (csma-c/d) and tcp/udp-ip and when you have large enough pipes, you don't NEED a 'fast lane' or diamond lane, so to speak. it just mucks up the works, makes things harder to design and manage and really isn't helpful since you still need large pipes and all the shaping in the world won't CURE that, it only DEFERs things. that's not a cure.

data should be 'opaque' and first-come first-served. equal access. standard layer (phys, dl, network) rules should still apply.

ISPs who employ shaping are simply RIPPING OFF customers from their rightful bandwidth and also passing along the COST of the packet snooping hardware to us, the users. (don't think they'll just spring for the hardware on their own; they'll pass the costs of this stuff to us, to be sure).

I think its evil. once you look at it from enough angles, you see that its not at all a good thing.

I've said it before, I'll say it again

If my ISP is going to inspect my packets to the point of identifying their content as p2p, then they should be 100% responsible for any and all illegal activities I may or may not conduct on their connections.

The entire concept of the DMCA safe harbor clause was founded on the understanding that it would be virtually impossible for providers to monitor and filter illegal or unlawful activities and data. However, now it has become perfectly reasonable that they can identify and reroute or slow this traffic. This clearly nullify's the safeharbor provisions.

The ISP's need to realize they cant have it both ways.

Somethng Wicked This Way Comes

This is quite the impressive machine they're talking about. But what they don't seem to cover very well are the legitimate uses for such a device. Just because they call "monitoring your communications" deep packet inspection doesn't make it right.

It looks like a disaster in a box to me: not only does it allow anyone with the price of the machine to monitor and inspect each and every packet you exchange, it also is capable of destroying the legal protections that ISPs currently enjoy.

The ISPs are treated like common carriers and are exempt from many liabilities because they carry all traffic equally and don't know or control the content of that traffic. Now that they're insisting that they need to "prioritize" some traffic at the expense of others, monitor and drop traffic because of its content, and are installing machines like these that further refine their ability to monitor and control what traffic you'll be allowed to transmit - well, their "safe harbor" exemptions are based on them not doing any of this.

Just the existence of this machine will be the undoing of many...

Re:A waste?

Investing in more capacity means a linear increase in customers and profits. Investing in network anti-neutrality, OTOH, means new and lucrative pricing structures for various services. They're just putting money where it stands to return the greater profit.

Re:Will be obsolete...

Heck, to defeat this you could just use AES with a default key. Everyone can use the same key, and have it be publicly known. It's fine because this thing doesn't have the compute power to decrypt in real time, even if it knows what it needs to be decrypting and what the key is. Screw handshaking, key management, etc -- just make the CPU cost nonzero and you're done.