Caspian Adds P2P Punch

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 4 / 5 > >>

andi_parker 12/5/2012 | 1:16:44 AM

re: Caspian Adds P2P Punch Hi Packetboy, following on from your comments I agree that P2P is certainly not all illegal content. There are numerous examples of legitimate uses such as the BBC with their IMP project or people like RedHat offering ISO images via BitTorrent. This makes traditional "traffic shaping" solutions largely ineffective.

The solution being discussed is a joint solution between CacheLogic and Caspian. Caspian send suspected P2P flows to CacheLogic's DPI unit where it is analysed to see if it is P2P or not. This is then tagged as P2P and routed back via the Caspian device where appropriate control measures can be applied if necessary. Alternatively an on-net cache can be queried to see if the request can be fulfilled there. The premise of the solution is that DPI does not need to be performed for every packet crossing the wire as many applications are well behaved so the DPI overhead is unnecessary.

This solution can be applied on an "as necessary basis" - i.e. is the pipe getting full, if it is then start DPI and control, if not then just allow traffic through as all users are getting what they need.

With regards to the pipe size, I believe the argument being made here is that for certain providers (specifically cableco's) the upstream is very precious and the whole network was designed on the basis of most services being asymetric. For example a light weight web request up the pipe results in a lot of data coming down the pipe. The problem with P2P is that it is inherently symetric. For every download there has to be an upload. Therefore lots of users using P2P will result in congested upstream.

The point about the pricing models is that the use of a solution such as the joint one proposed allows providers to implement a tactical solution to P2P without needing to resort to a usage based billing model.

Reply | Post Message | MESSAGES LIST | START A BOARD

Frank 12/5/2012 | 1:16:43 AM

re: Caspian Adds P2P Punch Tony,

Just as a point of clarification, which forms of entities are you including under the term 'carrier,' when you state:

"The hard part is that most carriers can test about two software updates a year. At best. More likely it's one. Again, this speaks to their organization, not to the technology."

Frank

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 1:16:34 AM

re: Caspian Adds P2P Punch Can P-Cube replicate the functionality of Caspian as well as CacheFlow? It looks like CacheFlow detects application level signatures while Caspian cannot.

Is this assumption correct?

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 1:16:13 AM

re: Caspian Adds P2P Punch Hi Tony,

I agree with you that the firmware update is the hardest.

However I guess you might underestimate how hard it is to identify those P2P applications, especially at the core speed. Please refer to this paper.

I doubt in the near future it is possible to do such type of P2P protocol identification at the 10G/s speed.

http://citebase.eprints.org/cg...

Reply | Post Message | MESSAGES LIST | START A BOARD

lroberts 12/5/2012 | 1:16:10 AM

re: Caspian Adds P2P Punch indianajones asked,
"Can P-Cube replicate the functionality of Caspian as well as CacheFlow? It looks like CacheFlow detects application level signatures while Caspian cannot. Is this assumption correct?"

P-Cube and CacheFlow both must look at every packet and thus are limited to 1 Gbps type speeds. It then takes lots of boxes to handle a peering point. Combining a flow router like Caspian vastly increases the capacity by about 300:1 but also adds the invaluable information about the duration, byte count, and rate of the flow. In many cases this information is enough to determine that the flow is an offending flow (legal or ilegal). Then the L7 sniffer can make the final discrimination as to the flow signature. The combined information of signature and flow size gives a far better result, at far greater rates.
Larry

Reply | Post Message | MESSAGES LIST | START A BOARD

lroberts 12/5/2012 | 1:16:10 AM

re: Caspian Adds P2P Punch Tony Li asked:
"How many L7 protocols can you reckognize at the core speed?"

Tha advantage of the combined flow router (Caspian) and a L7 sniffer is that there are about 14 packets per flow on the average so at worst only 1 packet in 14 need be sent to the L7 sniffer. However, since most offending P2P flows are much longer, the flow router neeed only check out the L7 content of those flows that exceed a rate and byte count limit, typically reducing the count to 1 packet in 280 (5% flows are P2P). Thus a typical L7 sniffer that supports 1 Gbps can now help identify all the long or fast flows in 280 Gbps. Given the 300:1 speed boost and the extra information as to the flow size and rate, almost any number of protocols can be distingushed.

Tony's next question:
"How fast can you add new protocols to the set of the reckognized ones (new major P2P application can become popular in about one-two months) ? How many firmware upgrades can a carrier perform in a year in order to keep up-to-date with new P2P applications? "

Given that the flow router has already identified the large fast flows that are clogging the network based on watching the flow over time, the L7 problem is reduced significantly. No longer is it possiable for Kaza to pretend to be Skype voice, because it is sending many more bytes at higher speed and typically longer packets. The L7 sniffer then can say the packets look like Skype and thus if it is a high rate flow it should be slowed down when bandwidth is scatce. Thus, to answer the question, the number of changes per year required is greatly reduced. At the bottom end, no updates may be required since large long flows are identified up front by the flow routing. In the worst case, a few updates per year may be required since one still needs to sniff legetimate file transfers from P2P traffic.

Larry

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:15:55 AM

re: Caspian Adds P2P Punch Just as a point of clarification, which forms of entities are you including under the term 'carrier,' when you state:

"The hard part is that most carriers can test about two software updates a year. At best. More likely it's one. Again, this speaks to their organization, not to the technology."

Frank,

I would include any of the large ISPs that are now embedded in an RBOC, IXC, or other large corporation.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:15:55 AM

re: Caspian Adds P2P Punch However I guess you might underestimate how hard it is to identify those P2P applications, especially at the core speed. Please refer to this paper.

I doubt in the near future it is possible to do such type of P2P protocol identification at the 10G/s speed.

Thank you for your reference. It's quite clear to me that we're talking about two different problems. Your need for a very high degree of accuracy is very much harder than the pragmatic analysis that I was thinking of performing.

Still, I suspect that you underestimate the amount of compute power that can be brought to bear on the problem. In your paper, you describe your results on a two processor result. I was contemplating the results from a 278 processor systolic pipeline, albeit at a lower clock rate.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 1:15:54 AM

re: Caspian Adds P2P Punch Hi Tony,

First the paper is not mine and I am trying to do the similar deepe-content analysis in ASIC.

The technique I refer to is to accurately identify P2P applications by analyzing as less packets as possible by spending some 'significant' time on the first few of packets. In this sense it is similar to the Caspian's flow based approach.

The systolic pipeline based architeture is not very effective in this type of computation. For example the lines of C code might be over 20K (roughly 10K for the TCP stack and 10K for L7 analysis). It is not easy to divide the code into the pipeline stages and let each pipleine stage focus on a samller task anymore :-(

I understood the Procket's 200+ pipleine architecture. I think it is fine (or preferred) to attack l2-L3 (switching + routing) applications using this type of the systolic architecture. However L4-L7 applications might need a different architecture since the application complexity is much higher.

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:15:53 AM

re: Caspian Adds P2P Punch
Hi MT,

I think we had best agree to disagree, all the way down to the fundamental techniques and problem statement.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 4 / 5 > >>