iCloud to Test Wi-Fi Performance Mettle


Apple recently sold 4 million iPhone 4S devices during the product's first three days on the market. That's good news for Apple and its investors, but wireless LAN administrators should beware: Apple's updated ecosystem is going to put the squeeze on your Wi-Fi network's performance.

With the iPhone 4S shipment, Apple's iCloud hosting and synchronization service has become available. In addition, the over-the-air backup and syncing capability runs on other mobile Apple devices that have been upgraded to the new iOS 5 mobile operating system, as well as on Macintosh computers with Mac OS X Lion and on PCs running Windows Vista or Windows 7.

The iCloud service automatically keeps all the files on users' devices up to date with one another wirelessly. It acts as a personal master controller, orchestrating over-the-air syncs of a given user's personal music, photos, videos and data files whenever it connects to a Wi-Fi network and discovers a discrepancy among any of the associated devices.

The company describes iCloud on its Web site as "automatic and effortless." And from the end-user perspective - the standpoint that Apple unfailingly takes - the invisible capability is a welcome bit of behind-the-scenes magic. It doesn't even cost users anything for up to 5GB of storage, so users are likely to sign up for iCloud.

However, the operational costs and potential WLAN equipment investments needed to handle users' personal wireless traffic won't be an enterprise freebie. Over-the-air activity that users might not even be aware of makes it tough to plan for capacity and manage traffic loads, a threat to network performance.

Using mobile device management (MDM) solutions or WLAN vendors' group policy setting capabilities, then, is probably in order to keep Wi-Fi traffic flowing smoothly. These mobility management capabilities have some limits, but overall can ease the impact of the mounting traffic loads on users' wireless experiences.

Traffic and Cost Could Add up Fast

iPhones and iPads, along with mobile devices built on Google's Android mobile OS and others, have taken the enterprise by storm. They've shown up both as corporate-liable devices and also as part of the bring-your-own-device (BYOD) mobile enterprise revolution. Many users have collapsed their personal and work files onto a single device for the convenience of not having to tote multiple devices around. Nice for users. Nightmarish for IT.

For users who sign up for iCloud, every time their Apple iOS 5 device associates with a Wi-Fi network and finds data that the cloud doesn't have, it automatically synchronizes with the iCloud server farm by default. iCloud transmits big stuff, like music, digital photos and videos, over the WLAN. When this happens multiple times a day by multiple users, some in possession of multiple devices, the result could add up to volumes upon volumes of traffic fast.

iCloud Graphic for 102011.jpgMarcus Burton, director of product development at CWNP, Inc., a Wi-Fi training and certification company in Atlanta, says that a network with many users who back up even 200MB - which seems like very little to users with disks holding hundreds of gigabytes - "will generate a ton of traffic."

The result could be a significant network upgrade investment to accommodate traffic "that's very hard to predict," concurs Chris Hazelton, research director of mobile and wireless at 451 Research in Boston.

Already Considering a Wi-Fi Upgrade

Indeed, Chris Nowak, chief technology officer at Anthony Marano Company, a fruits and vegetables wholesaler in Chicago, is already testing an upgrade to his voice-centric 802.11g network to newer and faster 802.11n technology, primarily because of the iCloud phenomenon. Even though just 10 of Anthony Marano's 50 users currently have iPhones, "everyone wants one," Nowak explains.

Once Anthony Marano and its vendors figure out how to port the Wi-Fi-to-cellular roaming application the company uses to the Apple platform, the remaining 40 users will likely replace their various Nokia devices with iPhones, says Nowak.

For that reason, "I'm aware of iCloud, and I'm looking into additional capacity" to solve the problem, he says.

Mitigation Plan of Attack

For larger organizations, adding capacity alone might not be the answer, given the shared nature of the Wi-Fi spectrum and unpredictability of the updates. And while Apple allows individual users to specify which applications they want to back up with on/off check boxes to mitigate traffic, 451's Hazelton doesn't recommend leaving WLAN traffic management up to your end users.

"IT needs MDM [software or services] to deal with iCloud," he asserts.

MDM is a budding category of software and cloud services that allow enterprises to gain control over the many aspects of their mobile devices, users, applications and security using a special mobile policy-setting and enforcement engine. With an MDM solution, available from more than 60 providers at the time of this writing, "IT would be able to turn iCloud off or block iOS devices from connecting," Hazelton notes.

"For seriously bandwidth-constrained enterprises, disabling iCloud via MDM is an option," agrees Burton. "However, with more users expecting a seamless home-to-work iOS user experience, I expect more enterprises to embrace iCloud with restrictions," Burton says.

He observes that most enterprise-class WLAN infrastructure vendors have added OS identification features to their Wi-Fi management software. The capabilities allow network administrators to tie a specific device type such as an iOS 5 device to a policy that controls access parameters, including rate limits, without administrative intervention.

His advice is to investigate these features. "Rate limiting iOS devices is probably the most graceful way to keep users happy and productive while preventing serious network strain caused by iCloud syncs and backups," he says.


Email and Social Media Links: Share securely via email |  |


Great note, Joanie. I think fully automated, transparent media syncing services like iCloud and Google Music are going to gobble bandwidth at an unprecedented rate, without users being fully aware of what their phones and tablets are doing, much less the impact.

From a network performance management perspective, I agree with Marcus - application-specific rate-limiting is the way to go. This can easily be applied to devices that you manage AND to those you don't, letting IT strike an adjustable balance between embracing iCloud and ensuring WLAN availability and QoS for business apps.

From an enterprise security perspective, IT should seriously consider using iOS5 Restriction profiles to stop sensitive data from flowing into iCloud. iCloud Restrictions that can now be controlled by IT-provisioned profiles (deployed either using an MDM or Apple's Config utility) are backup, document sync, key-value sync and photostream. IMO, these on/off Restrictions are nowhere near as granular as they need to be, but they do give IT a shot at enforcing coarse controls to deter unintended corp data leakage.

Lisa - as per rate limiting: are you aware of whether most or all WLAN vendors offer app-level rate limiting? I know that Meraki offers it, but at the time they announced it (a year or so ago), it was unique in the Wi-Fi community.

Per your rate limiting recommendation, are you aware of whether most or all WLAN vendors offer app-level rate limiting? Meraki offers a traffic shaping service, but at the time they announced it (a year or so ago), it was unique in the Wi-Fi community.

I usually see WLAN rate limiting applied either to devices or to classes of traffic generated by devices. App awareness does seem to be growing but I'm not convinced it would be required to throttle iCloud. Even APs with on-board L4 firewalling could apply bandwidth rules to specific destinations (e.g., limit all traffic headed to/from apple.com).

Another consideration for other members of the IT team is the impact the iCloud traffic loads might have on Internet backhaul capacity. All the OTA Wi-Fi traffic, of course, gets aggregated and routed over the last-mile link, as the diagram shows, which might cause IT departments to rethink the size of that connection.


We use Open-Mesh units in most of the locations we manage. All non-trusted devices already get rate limited in our CloudTrax setup so this will be mostly a non-issue for us. With the exception of 1 or 2 devices belonging to admins, all the smartphones that come into our network are being treated as non-trusted (and thus rate limited).

It does present future planning issues for backhaul/gateway internet connections but doesn't change the order of magnitude for which we were already planning based on current traffic growth.


Hi Joanie,

This article couldn't possibly be more relevant, timely, and important. I had thought about writing a blog on this myself, but you beat me to the punch. Excellent. All this syncing and upgrades over the Wi-Fi is going to be hideous unless properly dealt with.

When iPods/iPads do backups to iCloud, they give you the option of what content on the device to backup - app-by-app. Most people of course just select everything unless it exceeds their free 5GB, at which point they start thinking about where they could cut back.

More-or-less, most people will eventually max out their 5GB (and soon), and then many more people (like me) will eventually start paying for one (OR MORE) iCloud (or similar, like SugarSync, DropBox, etc) accounts. I already use a 50GB DropBox account, but I'm already growing fond of iCloud.

Think about the fact that users may be syncing an average of 5GB each pretty soon, and then think about the number of devices we'll soon be dealing with. It's an ungodly amount of uplink data at best. WAN pipes - dead. Wi-Fi - strained. Most of today's enterprise Wi-Fi is built for DOWNLINK, but rarely built for good uplink. This is where I would normally get my vendor jab in, but instead, I'll let Matthew do it:

Then there's the need for rate limiting based on the device type itself. Many vendors claim to RECOGNIZE the device type these days, but ask them if they can apply security and QoS policies to those devices once they recognize them. :) Aerohive can do just that, applying SLAs (such as rate limiting) and security profiles to iPads/iPhones/iPods that can be used to prevent this nightmare of iTraffic from killing your WLAN and your WAN.

Again, great article. LOVED it. Keep'em coming.

Devin Akin
Chief Wi-Fi Architect
Aerohive Networks

Devin, methinks thou doth suck up too much! Can I verify: do you rate limit "by device" or "by application" (or both)?

Rate limiting by device type is available from multiple WLAN vendors and is certainly a big help. Wi-Fi rate limiting based on application type/protocol is less common.

Still, it seems the WLAN is poised to find itself in the same choked situation that skinny WAN links found themselves in years ago, giving rise to the whole traffic shaping/WAN optimization market that rate limits (and otherwise treats/controls) traffic based on app, comms protocol, source or destination IP address, and a number of other parameters. Going forward, I'd think that similarly, the more granular you can set Wi-Fi rate-limiting policies, the better.

QoS and rate-limiting iCloud Internet traffic would be easier if Apple did not run it all over HTTP / port 80 to a changing cast of server addresses... And if Apple shared any useful info about the ports and protocols used by iOS devices.

Oh if only Apple did iCloud iOS backups using a predictable URL (like apple/com/icloud/backup). Or a specific port or server address (like backup.icloud.apple.com).

We have a Packetshaper and have to kludge things (using user agent strings and other sledgehammers) and it is not entirely effective.

To sum up: Apple's obsessive lack of information sharing is not helpful to network engineers trying to maintain network throughput in the presence of large iPad / iOS deployments...

Hi Jim,

I'm still waiting for a more detailed post to be OK'd, but wanted to mention that you can set up the PacketShaper to track the iCloud traffic by using the SSL certificate common name of *.icloud.com as the matching rule. That way it doesn't matter if Apple keep changing the destination address. You can see more info about PacketShaper's application specific criteria at https://bto.bluecoat.com/packetguide/8.6/info/application-criteria.htm#ssl

Cheers, Cliff


Hi, I enjoyed reading the article, and quite soon after I got my iCloud account. I was interested to see how hard it hit my Internet link so I measured my first backup. The results are posted at http://post.ly/3ieLQ

The traffic is SSL with a certificate common name of *.icloud.com so if you have a PacketShaper or something similar it should be straightforward to throttle the backup traffic, end-to-end, which will relieve the pressure on the Wireless links.

Thanks again for the article

Cliff Chapman
Application Delivery Architect

Join the Webtorials Community
Subscription Maintenance

Featured Sponsors

Recent Comments

Webtorials TechNotes

Featured Analysts

Gary Audin, Delphi, Inc.

Michael Finneran, dBrn Associates

William A. Flanagan, Flanagan Consulting

Douglas Jarrett, Keller and Heckman LLP

Jim Metzler, Ashton, Metzler & Associates

Lisa Phifer, Core Competence

Dave Powell, Independent Technical Writer

David Rohde, TechCaliber Consulting LLC

Steven Taylor, Distributed Networking Associates, Inc.

Joanie Wexler, Technology Analyst/Editor


Steven Taylor

TechNotes is a special program of Webtorials and Distributed Networking Associates, Inc.


Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Please encourage colleagues to download their own copy after registering at http://www.webtorials.com/reg/.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2013, Distributed Networking Associates, Inc.