Posts Tagged ‘congestion control’

Mobile Data Plans that Work

Monday, June 7th, 2010 by Cam Cullen

Mobile data plans have been in the news quite a bit lately, with Verizon (LTE plans) and AT&T (iPad and iPhone plans) updating the market on their mobile data positions. Verizon has all but announced that there will be no unlimited data plans on their LTE network, which is now scheduled to go live in 30-40 cities in Q4 2010, and people will pay based on their usage. AT&T announced that they are doing away with the unlimited iPad plan (already) and will now support tethering for the iPhone (but only for a 2GB/month plan). Other mobile operators also would rather have data plans based on usage rather than unlimited plans, but it remains to be seen how long or if operators with rich data devices can hold out, or if the pain of congestion will hit their network as it has for AT&T.

But is the ideal answer for mobile data to always bill based on usage? Although I understand the issues that are driving the operators to implement usage based plans (cost control, congestion management, etc.), I think that there are hybrid plans that could significantly accelerate the adoption of mobile data usage (and fixed mobile substitution for some users). Mobile operators could serve their customers better by offering flexible plans that were targeted towards different “consumer” types on their mobile network that were sensitive to application usage and time of day. These plans would be ideal for the new generation of rich media devices (Android phones/tablets, iPhone, iPad, and laptops) and accelerate their adoption by the consumer groups that covet the devices but are still afraid of bill shock (which will be even higher now that overage charges are going to be pervasive). It has been proven that devices can sell data plans, but the plans can also stunt the usage of the devices if using them becomes too complicated and expensive.

What would these plans look like? Most plans would be similar to the existing plans, with usage meters for the majority of data and separate usage meters for the applications that are attractive to specific consumers, with streaming video, audio, and file sharing leading the pack. Although web pages can be a lot of data (I once read an analysis that said the BBC front page was 1MB of data, which could cost you a pretty penny when you are roaming!), the real problem for mobile operators are long-lived streaming or downloading applications that can cause persistent congestion in a cell or on the network. Some examples of targeted plans:

  • Streaming Video: Monday through Friday 8 a.m. to 6 p.m., 25GB of data, unlimited nights and weekends
  • Streaming Audio: Monday through Friday 8 a.m. to 6 p.m., 10GB of data, unlimited nights and weekends
  • Unlimited Web: Unlimited web browsing and email, 2GB streaming media and other applications
  • Social Media: Unlimited Facebook/MySpace/IM/email, 2GB other applications

These plans could either be an add-on to an existing data plan, or part of different bundles for users. A very attractive iPad plan would offer unlimited web browsing, but a usage meter on other applications. I don’t see these plans as being negative towards Network Neutrality, since they will be selected by the users – as an alternative to the pure usage-based plan that the mobile operator would also offer. Time-based plans are already popular among mobile operators for voice, and could easily be popular among students and business travelers (i.e. Nights and Weekends plans).

My concern is that placing restrictive limits on bandwidth usage will stifle or limit the potential of the nascent market for rich data devices, or limit their use to Wi-Fi networks, which completely misses the goal of upgrades to LTE and other high speed mobile data networks – which is to make access ubiquitous for users (and not ubiquitous just for email). The challenge of implementing these plans is on the systems that would be used to meter the different applications (i.e. DPI systems) to ensure that the application classification is accurate.

An innovative mobile operator that offered these plans as an alternative to a more restrictive plan could tip the scales in their favor when competing for the “high value” users for mobile data. In the highly competitive mobile market, operators that think outside the box and find ways to best leverage the technology that they are already deploying in their networks will emerge victorious and profitable. Flexibility will be a key success factor.

As a user – would you be more likely to purchase a plan that gave you flexibility in how you used your mobile broadband?  I know that I would.

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.

Do’s and Don’ts in Bandwidth Control

Wednesday, December 2nd, 2009 by Jon Linden

Suddenly it all happens at once. We went from zero to two events focused on DPI in one week – Light Reading’s virtual tradeshow Policy Control & Deep Packet Inspection, and Informa’s Broadband Traffic Management event IRL in London early last week. These events are good validation that DPI has grown up to get proper attention.

I was on-site at the event in London – and I apologies for the hotel lobby background noise on my line in the LR panel discussion. But I also had the pleasure to be on a panel in London together with Benny Lim from SingTel and David Hodgers from O2 Ireland, moderated by Mark Newman from Informa. The topic was “Lessons Learnt: The Do’s and Don’ts of Bandwidth Control”.

So what are the lessons learnt on bandwidth control? Let me quickly go through my conclusions and what I told the audience. When looking at do’s and don’ts I see two categories: what works and what ‘s ethical. The latter is more challenging with today’s fast moving social media where bad news travels fast and subscribers vote with their feet.

How do you manage this? Well, don’t expect to “get away with it”. Internet users are savvy and operators in London confirmed that non-transparency came back to bite them. You must be able to defend what you’re doing, and a good test is if you’d accept it yourself. Greed is not an acceptable reason, though a viable business case normally is.

Do’s and don’ts also depend on what you’re trying to achieve. DPI and bandwidth control spans over a broad range of applications, from network protection and congestion control to quality assurance and service differentiation. We tend to be very introvert and technology-driven in this industry, but you must start from business benefits and objectives in order to define intentions and make it understandable to your end-users.

The key to what works is knowing what’s going on. It’s not an option to guess what your customers do and how your network is doing. And conditions change – all the time. What used to be 80% filesharing a year and a half ago is today replaced with 40% streaming video as the largest bandwidth consumer. A policy rule-set that is not up-to-date will cause some strange consequences.

I wish I could provide a blueprint for what works, but every situation is unique. Your product mix, fixed and/or mobile, target groups, price positioning, and on top of this there are geographical differences like what applications are used and what bandwidth control practices are accepted.

This means that the number one thing to do is try. You will have to try it out and assess the outcome in your specific situation and your environment. I know this sound scary, but be adaptive, be quick, and make sure you make qualified decisions based on facts rather than guesstimates and assumptions.

Let me also summarize my don’ts: Don’t lie – be transparent. Don’t insert packets – honor integrity. Don’t get introverted and super techie – understand your business and your customers. And don’t do nothing – this is the most expensive decision of them all…

Let me wrap up with one more suggestion for what you should do: Keep it simple! Complexity kills this cat. If it’s too complicated you won’t be able to communicate to your subscribers, it’ll be impossible to update and change, and you won’t be able to measure if you successfully achieved what you intended to. This is hard to make simple – which is why we, Procera, are here to help ;-)