Archive for February, 2010

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.

Tags: , , , ,
Posted in Technology | 1 Comment »

Mobile World Congress…It is all about the Apps!

Thursday, February 18th, 2010 by Cam Cullen

I have spent the week in Barcelona attending the Mobile World Congress event. Anyone that thinks that there is no vibrancy in the networking world should have been here to see the show. The halls were packed, the booths were busy, and the meeting rooms fully booked. There is a lot of excitement about where the mobile industry is going, and the opportunity that exists for mobile providers going forward.

One thing that jumped out at me during the show was the growing focus on the applications that are driving mobile usage. Yes, there was plenty of LTE hype, and lots of platform and operating system buzz (you should have seen the line for the Android developers lab as well as the push Microsoft made for Windows 7 Mobile), but focus seems to be shifting towards the applications that are driving mobile usage. The operators are keen on pushing new applications, because they will drive up data usage and increase the urge for users to upgrade their devices and service packages.

There is a clear recognition that mobile success may be won or lost on the application front. In the US, Apple has done a good job with marketing the iPhone by focusing on the everyday things that it can do to make your life easier with mobility (finding restaurants, checking on movie showtimes, etc). Google did a great ad during the SuperBowl (American Football for those outside the US) that showed Google search used to progress a storyline for a person’s life (http://www.youtube.com/watch?v=nnsSUqgkDwU) which is not specifically targeted at Android, but can be applied to Android and mobility. Microsoft was showing the same type of applications and integration at MWC as part of their booth show. Ericsson announced an applications store (eStore) with more than 30,000 applications that carriers can offer those apps to their own customers.  A new alliance was formed between 24 operators (including ATT, China Mobile, Orange, etc) called the Wholesale Applications Community (WAC) designed to simplify how application vendors get their applications to the end user.

Why is this important to a DPI vendor? Mobile operators who want to understand what applications are clicking with their users need to look no further than to a “robust” DPI system to understand what applications, clients, and software their users are running – even down to the device level. Application vendors obviously want the operators to know that their application is popular, since it will open up more opportunities to sell that application, whether it is through the operators own application store or the mobile OS store (iTunes, Android market, etc). The DPI “lite” solutions provided by some vendors will never keep pace with the ability of a dedicated DPI solution. At Procera, application recognition has always been a core element of our solution, we release updates every two weeks to keep pace with the new applications our customers encounter in the wild, and this includes mobile applications.

The applications that really jumped out at me are the “useful” applications that can simplify or make life easier for people. Simple navigation capabilities can be helpful even if you are walking through a large city – looking for a specific location for a meeting, searching for a restaurant, looking for a store. VOIP applications (which are finally being approved for mobile use by some operators) can be cheaper than international calls in some instances (or using the VOIP over wi-fi is even better). Even bar-code scanners that allow instant internet price comparisons are really useful if you are shopping and want to make sure you are getting a better deal.

As mobile operators look to understand what they need to do to generate revenue, I am certain that going forward, applications will be a big part of that plan – whether it is enabling some of the applications in real-time (even if it is not sold by the operator – like GPS), or form a retail perspective in their application stores. DPI can help them understand where their greatest opportunities are – and will allow them to service their customers better by meeting their expectations.

Tags: , , , , , , , , ,
Posted in Industry, Technology | No Comments »

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.

Tags: , , , , , , , ,
Posted in Industry, Technology | No Comments »

File Transfer – The Ugly Way

Monday, February 1st, 2010 by Kriss Andsten

Working in the field of traffic analysis, you get to see a rather modest number of good solutions to a given problem, a larger number of decent solutions and – sadly – quite a few less than stellar ideas as well.  My favorite pet peeve – and believe me, there’s a slew to choose from, is using FTP as an update mechanism for games, and doing it in a not very thought-out manner.

Say that you have 4000 asset files in a given game. Most of them are pretty small – well under 8KB. You want to support users going from version A, B or C to version D, utilizing the least amount of bandwidth in the process. Logic dictates that it would make a lot of sense to get a checksum of all your local files, send the checksums to the server and have the server return a list of files you need to update, right? A minimum amount of bandwidth is utilized and the user can update from pretty much any version.

Enter FTP. FTP uses one control connection and n data connections, where n equals the number of transferred files and directory listings done over the lifetime of the session. And by ‘connection’, that’s a full-blown TCP stream, three-way handshake and all. Let’s pretend that I have a 100ms latency to the update server and the server or clients themselves incur no extra overhead – that leaves us with:

* One PASV call in the control connection and the response to that one. 200 ms.

* One three-way handshake, add another 300 ms (SYN, SYNACK, ACK) – plus another 100 ms before I start seeing the data from the server.

So the tally: To transfer a given file (be it 0.5 KB, 200 KB or 15 MB), the transfer overhead itself will be 600 ms. ,which could be OK’ish for one large patch file. Let’s say there’s a 200 MB update covering 1500 files – that’s 15 minutes worth of waiting for the transfers to start for a set of files that should take something along the lines of two minutes to actually transfer over a pretty basic broadband connection.

I think World of Warcraft  (and others, but they’re a good example) got the right idea from a developer’s perspective – they transfer the patches in sets – going from A to D would require you to go from A to B to C to D – more to download, but people can do such over BitTorrent or any old HTTP mirror rather than the developer’s own site. Game developers, take note. Please.

Tags: , , , ,
Posted in Technology | No Comments »