Posts Tagged ‘P2P’

How not to do P2P

Tuesday, February 23rd, 2010 by Kriss Andsten

Peer-to-peer is rather interesting to work with. Disruptive technologies always fascinate me, especially when it’s closely related to work so I can spend oodles of time on it. It’s also interesting to see the developments in the area – even if I don’t always agree with the sentiments of the researchers (for instance, I quite agree with “http://www.digitalsociety.org/2009/11/analysis-of-bittorrent-utp-congestion-avoidance/” George Ou on BitTorrent – for now).

Even so, there are good apples and bad apples. BitTorrent got an undeservingly bad name from people confusing content with transport. Even if I don’t think that they got it right with their be-nice-to-the-network idea, they tried. All in all, a sane actor.

Pando, on the other hand, is an actor that seems quite sane – working in the P4P working group, seemingly trying to make a living out of a very kosher sort of P2P. The protocol isn’t too bloody bad either – the only problem is that parts of the client lodge themselveswhere it’s quite invisible on a Windows system. That, and the usual foray of “Would you want to make xyz.com your default website? Search page? Dog grooming service?”.

Some quick testing shows PMB.exe – Pando Media Booster – disregards the Pando client setting telling it not to start on Windows startup. Different binary from the Pando client, you say? Sure. Explain that to the average user. The net effect is that the software is happily chugging along at 1.5 Mbps without any sort of user notification. No tray icons, or windows – nothing.

Speaking in terms of ISP per-subscriber data usage (on average per user), Pando will skew it to the tunes of one Pando user not knowing she runs PMB to 50 – give or take – purely average users. That, in my book, is the dark side of P2P. Users running BitTorrent, Spotify, Voddler, etc. make a conscious decision to run it. Users running PMB don’t and really have no simple way of knowing why World of Warcraft lag went up or why pages are loading slowly.

Does LTE ♥ DPI?

Monday, February 8th, 2010 by Cam Cullen

There is a lot of talk in the industry about DPI and mobile operators. There was an article on Light Reading in 2008 titled “DPI (hearts) LTE” that explored this topic. The general belief is that mobile operators MUST have DPI in their network to survive and compete, due to a number of bandwidth and usage challenges. Operators are bracing for users that will treat their mobile connection in the same way that they use their fixed broadband networks today (i.e. streaming video, file downloads, peer-to-peer, etc). Since laptops are expected to be one of the earliest LTE devices supported in many of the early LTE deployments, the data requirements of LTE must be addressed from the initial deployment.

The debate has been stoked by the inclusion of a loose requirement in the SAE-GW for Deep Packet Inspection, aimed at application classification and QoS at Layer 7 (not traditional router-style Layer 4 filters). Many traditional GGSN/PDSN gateway vendors have begun to message that DPI is a part of their LTE solutions, and the expectations of mobile operators are rising daily. RFPs are coming at a rapid pace from mobile operators, and every one includes a request for information on how DPI can be deployed in an LTE network.

At Procera, our experiences working with mobile operators have convinced us that DPI will be a key technology for LTE deployments. Mobile operators need network intelligence on what is happening on their network, and the ability of DPI to reach back into the access network and correlate individual subscribers to their location in the Radio Access Network and manage congestion is a vital requirement to ensure a good Quality of Experience for operators. Tight integration with the BSS and OSS backoffice systems ensures that the DPI systems provide a single point of contact for network visualization that includes subscriber, device, location, service plan, and application knowledge. This information can also be used for billing, allowing service providers to create flexible billing packages based on location, time of day, on-net or off-net application, roaming, or usage volume.

That is all well and good, but how does it relate to LTE? These requirements are also valid for 3G deployments, and are even deployed on some 2G networks today. The challenge for LTE and DPI pushes the boundaries of the DPI that is deployed on networks today because the scalability, performance, and service expectations will exponentially increase with LTE deployments over 3G. 10G links are a minimum performance requirement, and the bandwidth and session count per user will skyrocket as mobile devices become more capable of multi-tasking and cloud-based applications take hold. It will not be acceptable to do “a little” DPI, as all traffic will be required to receive DPI treatment. LTE networks will be service and application oriented, as operators will push new applications as a way to justify the higher rates for LTE services, and DPI will be required to recognize and prioritize real-time services.

Many providers of Mobile Gateway solutions will also claim this functionality, and try to convince operators that their integrated DPI solution is “good enough” to provide equivalent functionality for a LTE deployment. But there are some issues with integrated solutions that should cause operators to pause before deploying an integrated solution. The first is that an integrated solution ties you to a single vendor for your deployment, and ties your upgrade in capabilities to what your integrated solution can be upgraded to. Standalone solutions provide more flexibility, and give you more leverage as best-in-breed solutions increase in performance and capabilities. Integrated solutions also tend to suffer from performance and scalability decreases when additional functions are activated in the systems, of which DPI has traditionally been one of the most processor intensive applications on a CPU module. The “single chassis” argument that is commonly made by integrated vendors is also often an invalid one, as the performance and scalability requirements of a full DPI deployment often exceed the capabilities of an integrated chassis. Although LTE deployments will start small, requiring additional chassis systems just to activate DPI functionality will negate any advantage of an integrated solution.

The story of LTE and DPI is just starting to be written, but we are sure that the two will be tightly intertwined together going forward.

Don’t Invest In DPI Until Net Neutrality Has Been Resolved

Monday, January 25th, 2010 by Jon Linden

Sorry, there should be a question mark at the end of that heading, and the answer is No!  The fact is you need to invest in DPI now. I know I’m biased, but that’s why I possess hands-on knowledge and facts of what our customers do and why.

DPI does not equal P2P throttling and Net Neutrality infringement. P2P control originally presented itself as an opportunity for DPI with a quick ROI on a hair-on-fire issue where P2P filesharing rampaged at an exponential growth rate, which meant exponential cost. But today we’re in the second, or I would even argue the third generation of DPI, and both products, and the use of these products, have evolved and become much more sophisticated.

Today the most common request is visibility. Visibility of what traffic is traversing the network in order to detect changes early in user behavior to avoid surprises on the core business and business models. Today’s rapid increase in streaming video is both a threat and an opportunity to cable MSOs, whose core business is TV distribution.

This is a good illustration of why network traffic intelligence is so important. Today we don’t watch TV as we did before. We don’t watch in real-time since we have TiVo and subscribe to episodes as they are “released”. It’s just a small step to Hulu and the broadcasting companies’ Play services. Early detection of these phenomena gives the operator the ability to offer relevant packages, change pricing, and develop new services without being left far behind.

In all honesty, very few of our customers and prospects even consider limitation of competing over-the-top (OTT) services. Savvy end-users catch what they do, draw attention to it, and the operator is caught with their pants down. You don’t “get away with it”.

But knowledge is power. Based on proper network intelligence you can make proper decisions. For example reach out to emerging services and join them instead of trying to beat them, look at the value add of your paid-for services compared to free OTT services, see the impact on your network of new applications, and project the investments required to accommodate these new services.

You could actually go as far as to say that DPI is required to enable Net Neutrality. Transparency is a cornerstone in Net Neutrality and DPI offers the tools that verify that you are transparent, that you’re not preventing good service levels due to obsolete policies supporting an old reality.

We, Procera, have not seen an impact on our DPI business from Net Neutrality, and I think it’s due to the above. Operators understand this, have understood why DPI is necessary, how it’s used properly, and are able to discard the background noise of an infected discussion while listening to creative and reasonable input.

Is Accuracy Really That Important?

Wednesday, December 2nd, 2009 by Jon Linden

Trust me, it is. There are a lot of good reasons why we promote “accuracy and control, redefined” in our logo. Ask any operator with DPI experience, and you’ll hear that accuracy is top of the list. And we can, in all honesty, say that DPI didn’t really deliver on this promise originally. The first generation of DPI identified port-hoping filesharing applications good enough to cap them to avoid disaster.

But times have changed. Today we have very sophisticated tools in our bag and our traffic identification engine looks at several criteria when determining what application each individual connection is. We also leverage characteristics, like interactive, streaming, download and bulky to categorize traffic in an application-agnostic fashion.

Online applications have evolved extensively over the years I’ve been working with DPI. Back in the days when IP and TCP were invented, all traffic was client-server-based. The applications were neither time nor quality sensitive, but everyone was happy with a global and resilient network.

Fast forward to today. P2P technology is used to leverage bandwidth and CPU capacity at the edge of the network for faster connectivity and to decrease the traffic being sent over the core network. P2P technology is used by the streaming music services we run all day at the office, as well as the online HD video on demand service we use at home at night. Both Salesforce.com and our office phones run over IP enabling us to work from home as if we were at the office. But we would also be totally paralized if the Internet connection (as well as the redundant link ;-) ) was down. This is how crucial and integrated the Internet is in our lives today, and this is why traffic volumes grow at a pace that outdoes Moore’s law and that saturates pipes.

Of course, these applications are totally different in nature and have different requirements for how to be treated to function properly. Of course, different users have different expectations in different situations at different times of day. Of course, it would be an issue if you treat HD video as filesharing or World of Warcraft as SIP. This will impact the performance of the network, but also your ability to manage expectations and create viable business cases for how to satisfy different user profiles. Step one in any process is analysis, and unless you trust the intelligence you use for your analysis you won’t dare to make decisions based on these facts.

So, this is one of these cases where good enough isn’t good enough. Trust me when I say that you will want to trust the information you have at hand when you make critical decisions.