Pages

Pages

Monday, January 17, 2011

Why developers need to take responsibility and create more network-aware applications

In all the brouhaha about traffic management and Net Neutrality, it is startling that one aspect is often completely overlooked - the need for mobile application developers to become much more network-aware, and write their software to take account of the realities of the user's situation.

This is not, primarily, about saving money for the network operators. It is about creating a better all-round experience for the applications' users, whether that is through improved or more consistent performance, less impact on device battery life, easier monitoring and feedback, or saving users time and money.

Ideally, applications should be aware of a broad plethora of network-related variables, and be able to act on them accordingly. An incomplete list includes:

- Real-world end-to-end speed, latency and jitter, for both uplink and down
- Bearer type - WiFi (and SSID and security method), 3G, 2G etc - or combinations of the above
- Which bearers are potentially available, but not being used
- Whether the cellular connection is routed via a macro- or femtocell
- Roaming status
- Variations in network quality, either predicted or real-time measured
- Price plan details - eg per-MB billing, time- or location-variable, proximity of thresholds & caps
- Probable future connection status - eg likelihood of going out of coverage, or switching to another network
- Awareness of current or likely future congestion on the network
- Mechanisms used for offload
- Policies applied by the network, and how these vary by time or bearer
- What types of signalling the application is likely to generate, directly or indirectly
- Handset capabilities & status (eg ability to use multiple radios, battery level, whether WiFi or 3G or roaming are switched on, potential for side-loading via Flash memory or Bluetooth and so on)
- Whether the phone is being used as a tether, or could use another device as a tether / peer

In reality, no application is going to be able to deal with all of these, or pick a comprehensive decision-tree route to decide on how to behave. Instead, there is likely to be a sub-set chosen - based on the nature of the application, the availability of the various input data, and the preferences of the user. A certain proportion of these "network-aware" elements will also be the responsibility of the OS, which might dictate either universal rules ("no updates while roaming") or might bundle some up into a general "network status API" or "bearer-awareness recommendations" accessible by all apps.

Some apps already make use of this type of data, at least in part and on some platforms. VoIP and streaming-video applications are typically the most bearer-sensitive, able to choose different codecs or frame rates based on observed network performance.

But we are still at very early days, especially with regard to the ability of apps to understand or predict mobile broadband congestion, offload dynamics, or cell-edge drop-off effects.

There are three main sources of this data:

- Direct measurement and input by the app itself. For example, Skype clients can measure latency and packet-loss directly.
- From the handset OS, which may expose some of this data centrally - eg WiFi vs. 3G connections, or perhaps in future the aggregate cellular data consumption vs. a user-defined monthly cap.
- From an operator API - perhaps roaming status, or ideally information on the user's data plan. Ultimately, operators will expose "congestion APIs" to applications and devices, although this is still a future-looking concept.

There may also be data that can be gathered from other sources, such as utility applications in the handset or in the cloud, or via direct provision from network elements in the data path.

There is likely to be a considerable amount of push-back from parts of the developer community towards this concept. This stuff is complex, perhaps boring, and will add time and risk to the development process. Some will undoubtedly say "It's not my problem" and attempt to abdicate their part of the decision-making. Nevertheless, mobile application (and mobile web) developers need to take responsibility for their creations' actions and performance.

There are far more variables - and variability - involved in wireless connectivity than is the case on fixed broadband, or a company LAN. On an ADSL line, you're not at risk of suddenly "going out of coverage". On a local gigabit ethernet connection in an office, you don't have to conisder the impact of roaming or the benefits/drawbacks of switching to an alternative connection. Using normal home WiFi you don't have to think about signalling loads.

Mobile *is* different and is much less predictable, and that should be reflected in application design where connectivity is required.

Disruptive Analysis believes that it is incumbent open both device and OS vendors to educate their developer base on the importance of "network-awareness", to a much greater degree than in the past. It may even need some sort of app certification as "network-friendly" to identify which software acts as a good mobile citizen.

Operators also have a role to play - firstly by exposing the right information via APIs or other mechanisms, and secondly by being honest and communicating the limitations of their infrastructure. Whether they are ever going to be able to charge extra for this information is unclear, but it is certainly in their own self-interest to enable network-friendly applications. That said, they also need to be wary of providing tools to those trying to "game the system".

Overall, the next few years will continue to see grudging moves to more network-aware applications, and more application-aware networks that aim to actively help applications rather than just use DPI or PCC to arbitrarily enforce blind network policies.

In fact, all of this is an absolute prerequisite for the success of future mobile cloud applications. Without this bearer/radio-aware knowledge and the development of network-based feedback loops, cloud services are doomed to niche status.

4 comments:

  1. Great post. agree. linked to my post as well

    Could the facebook app be responsible for high phone bills?
    http://www.opengardensblog.futuretext.com/archives/2011/01/could-the-facebook-app-be-responsible-for-high-phone-bills.html

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. great post, very interesting and relevant topic!

    I'm curious about your take on self-reglauting machinisms in the market itself.

    In the Netherlands it is no secret that the operators will be moving from flat-fee to pay-per-use subscriptions.
    Furthermore the operators are looking into differnetiating their data tarrifs based on types of services.

    This will link the subscribers' bill directly to the data-efficiency of the applications they use, therby introducing an 'OPEX-factor' in the app stores.
    Won't this be a mayor incentive for both mobile OS and application developers to increase the network-awereness of their products?

    ReplyDelete
  4. I think a lot of developers would comply if they could. The reality is that the devices themselves don't really allow devs to pull the information they need. Android is the big exception here, but iPhone, BlackBerry and Windows Phone 7 sandbox the apps so hard that it it virtually impossible to get meaningful data out.

    ReplyDelete