Caspian Adds P2P Punch

The new-look Caspian Networks Inc. appears to be poising itself against Cisco Systems Inc. (Nasdaq: CSCO), announcing partnerships today that tackle the problems peer-to-peer traffic can place on networks.

Caspian, which formerly targeted the core router market, today announced partnerships with CacheLogic Ltd. and Shenick Software Systems Ltd., aiming to help service providers find and act upon P2P sessions. CacheLogic would provide Layer 7 inspection of each packet, and Shenick would offer the tools for quantifying P2P traffic and emulating its effect on bandwidth (see Caspian Intros New P2P Control and CacheLogic: Another P-Cube?).

The resulting triad looks a lot like the team Cisco has amassed. The company is acquiring P-Cube Inc., which has made a name for itself in corralling P2P traffic. Cisco has also acquired Parc Technologies Ltd., which develops routing optimization software, and invested in Corvil Ltd., which makes appliances for IP-network capacity planning. (See Cisco Plucks P-Cube for $200M, Cisco's Parc Purchase: An MPLS Play, and Corvil: Another Cisco Secret?.)

"It's very much like what Cisco's doing," says Jeff Ogle, an analyst at Current Analysis. And the comparisons don't stop there. "If you look at Alcatel's 7750 Service Router platform, it's about managing things by traffic flows as opposed to, say, Juniper's approach of having tons of knobs and buttons for QOS in the IP network," Ogle says.

All this activity stems from the discovery that P2P flows have the potential to paralyze networks by sucking up most of the available bandwidth. Companies such as P-Cube aim to identify P2P sessions, allowing carriers to either limit the bandwidth alotted to those sessions or terminate them entirely. Other companies in the market include Allot Communications and Ellacoya Networks Inc.. (See Cisco Reroutes Traffic Management and the Light Reading report, Flow-Based Networking.)

The idea is to let the network react in real time when P2P sessions are discovered. "You can think of this almost as a dynamic QOS applied by the network internally as opposed to an edge QOS that the service provider would pre-configure for you," Ogle says.

Caspian's routers would first identify which flows are lasting for unusually long times, one hallmark of a P2P download. CacheLogic's software would than analyze packets within the suspect flows to determine what's going on, says Dallas Kachan, Caspian director of marketing.

Some analysts expect Cisco to integrate the P-Cube functions into routers eventually. Could the same thing happen between Caspian and CacheLogic? Possibly, but Kachan says there's no immediate plan to try it. "I would say there's no technology barrier to doing it. It's just [a question of] time and customer demand," he says.

Ellacoya and P-Cube will be among the speakers discussing P2P traffic at Light Reading's Next Generation Services Roadshow, a seminar being held September 13 in New York and September 15 near San Francisco. For more information (in .pdf format), click here.

— Craig Matsumoto, Senior Editor, Light Reading

For more on this topic, check out: For further education, visit the archives of related Light Reading Webinars:

Page 1 / 5   >   >>
Frank 12/5/2012 | 1:17:35 AM
re: Caspian Adds P2P Punch The capabilities discussed in this article concerning the monitoring and controls placed on P2P traffic are reminiscent of the controls that are placed on programmed trading in order to avert avalanches and meltdowns. This consultant wonders if deploying such technologies might be the beginning of a slippery slope, where arbitrary decision-making to shut down traffic flows by network operators is concerned. What do you think?
mr zippy 12/5/2012 | 1:17:32 AM
re: Caspian Adds P2P Punch All this activity stems from the discovery that P2P flows have the potential to paralyze networks by sucking up most of the available bandwidth.

This is no discovery, any and all application protocols that use TCP will attempt to suck up all available capacity at any particular time. This is done to maximise the investment in the network infrastructure. Why not try to use "excess" capacity if it is available, and not being used by anybody else. TCP backs off on its utilisation if performance suffers, commonly caused by other TCP connections starting up, or a change in a route, resulting in a smaller "end-to-end" amount of bandwidth.

P2P apps are no more of a threat to bandwidth than HTTP, SMTP or FTP is, as they all use TCP (I'm assuming that no UDP based P2P applications exist). P2P apps aren't that special.

What problem are these products trying to fix ?
Frank 12/5/2012 | 1:17:31 AM
re: Caspian Adds P2P Punch What problem are these products trying to fix ?

I would imagine they are trying to stem the torrents of content related data that follow, irrespective of what protocol(s) is used.
lroberts 12/5/2012 | 1:17:27 AM
re: Caspian Adds P2P Punch The Caspian product, using flow routing, can watch the rate, duration, byte count, ave packet size, and other measures of each and every flow that passes, generally 100,000 flows/Gbps. This is because it keeps state memory on each flow (5-tupple) which no conventional routers do. Thus, P2P flows can easily be separated from other flows like HTTP or VoIP typically by rate and byte count. The problem with the current best efforts networks is that when we only look at packets, not flows, the big flows can be disguised as VoIP or HTTP. These smaller flows, due to TCP action, get squashed to a small fraction of the network bandwidth. The Broadband user pays a flat fee for 1-100 Mbps and can send all the P2P he wants up to his pipe size. The other normal users get much less than they paid for. We have stuck with flat rate pricing (which is good for traffic growth and budgeting) but now the P2P user is getting far more bandwidth than the normal user. thus 5% of the users get 80% of the bandwidth for a real bargain. To fix this one hates to go to complex charging systems, even if the routers supported them. The network providers need a clean solution to balance the traffic with the price paid. By adding a router like the Caspian router that can look at flows and separate different types of flows, the inequity can be rectified. The addition of level 7 sniffing then helps identify the flow further, but need not operate at 40-120 Gbps like the Caspian router. The result is that network operators can control the traffic each user gets for what the user pays without complex pricing. The inspection and control can be done at any choke point in the network, the edge or the peering points, thus reducing the cost of adding such control.

It would have been nice to consider flow routing earlier but recent analysis shows it was economically impossible before 2000 due the high cost of flow state memory. Now this memory is 1% of the cost and can improve the traffic mix (P2P) and the trunk utilization (25% up to 80%). Thus it now saves on router cost rather than increasing it.

The Light Reading article mentions that Cisco is doing similar things with P-Cube, but without a cheap way to watch the flow characteristics the problem requires deep analysis on every packet, at great cost, and still can be fooled if the P2P looks exactly like VoIP or some other low rate traffic. One really needs flow information over time to do this economicly.
Tony Li 12/5/2012 | 1:17:24 AM
re: Caspian Adds P2P Punch

Could you please compare and contrast Cisco's netflow routing with Caspian's solution?

lroberts 12/5/2012 | 1:17:22 AM
re: Caspian Adds P2P Punch Tony,
First, I hope Light Reading notes that when you and I and Drew Lanza use our real names, the discussion is far better and useful. I would not answer most readers.

As t Caspian and Netflow, Cisco samples the flows and gets ststistics, this help in future rule setting but not in real-time control. Flow routing keeps statistics on every flow throughut the session which allows real-time control of the rate or acceptance of each flow based on the flow and the network load. This can almost totally eliminate the need for queues and congestion since the router knows if this flow is within a bound like 85% utilization. It also allows monitoring rate and bytes count until it is sure this is a P2P flow and slow it rate to what the rules request after 1MB. Rules extracted from Netfolw statistics only help classify packets and do not identify the rate or duration of a current flow.

It is assumed tht PsP vendors will make the packet signiture look identicl to a rule checker and with encryption, it really is impossiable to look at higher level to sort this out. So looking for what hurts the network and is'nt being paid for (high rate long flows) is only possible with flow state collection, not statistics (Netflow) or deep packet inspection (Cisco's addition of P-Cube).
curiousgeorge 12/5/2012 | 1:17:14 AM
re: Caspian Adds P2P Punch
Given that P2P flows are generated by end points that have far more MIPS/Mbps (i.e. x86 CPUs that only have to worry about their few Mbps), isnt this an arms race that is inherently tilted against the router? E.g. P2P applications can hop from TCP port to TCP port , and/or can induce various temporal profiles wrt burstiness, and other things beyond my ken. No??

Or is the argument that all non-standard flows (ie non-HTTP, FTP etc) are upto something undesirable and so the router can have a guilty-until-proven-innocent policy? Once you start doing that, isnt the differentiation of flow based routing wrt static QoS somewhat reduced?
dljvjbsl 12/5/2012 | 1:17:13 AM
re: Caspian Adds P2P Punch
You've obviously never had to deal with Larry before.

I have not had to deal with Larry Roberts before but I have dealt with someone who has had more influence on computer science.
dljvjbsl 12/5/2012 | 1:17:13 AM
re: Caspian Adds P2P Punch In case someone wonders why anonymous interactions have been fou nd to be beneficial,some of the reasons are:

a) to eliminate the fear of contradicting high status indviduals
b) to eliminnate he fear of appearing silly for introducing a new idea
c) to cope with shyness
d) to eliminate embarassment in pointing out errors
e) ...

Note that these also seem to be the reasons that the peer reviewers of academic papers are anonymous,
dljvjbsl 12/5/2012 | 1:17:13 AM
re: Caspian Adds P2P Punch
First, I hope Light Reading notes that when you and I and Drew Lanza use our real names, the discussion is far better and useful. I would not answer most readers.

Not only is this pompous and condescending, it contradicts the results of many experiments in decision support and collaboration systems.

Anonymous comment and interaction has been found to be very beneficial to the type and quality of discussions in both of these areas.

It is so nice to be able to prick such a self-satisfied balloon so easily
Page 1 / 5   >   >>
Sign In