Re: Liaison statement from OMA on network efficiency

On Fri, Jan 25, 2013 at 7:58 PM, Dave Raggett <dsr@w3.org> wrote:
> Hi all,
>
> We have received a liaison statement from OMA on a new activity they're
> starting, calledWID 279 - DANE 1.0 – Device Apps Network Efficiency  — see
> attached PDF document.
>
> The System Applications Working Group is specifically called out as one of
> the targets of the document, as are the Device APIs and Web Application
> Working Groups.
>
> They are asking a review from their proposed work, as well as a summary of
> existing W3C work in this space.
>
> Anyone willing to volunteer to take a look at this and post comments to the
> sysapps list?

For breaking the ice - this is a huge topic, and for start, the key
use cases would need to be formulated.
It seems the concept is particular to mobile networks, and aims to
shoot at two targets:
- improve network usage patterns of apps
- generate more revenue to operators by offering premium QoS (when
needed, and wanted by users, and of course when it's possible: it is
not clear under what conditions the OMA proposal could guarantee a
given QoE and how charging goes when only a portion of the network
route supports QoS).
As these are rather different topics leading to different requirements
and solutions, perhaps it would be good to separate the concerns.
Also, an API proposal from OMA could help understanding where should
we focus the discussion.

For a better network usage, there are a few goals I see worth pursuing:
1) write better applications, both in "static" (written and profiled
well, see e.g. [1] and [2]) and dynamic point of view (adapting to
network conditions, like e.g. VoIP clients).
2) optimize network (and battery) usage of all applications within a
device (e.g. sleep long, with wake-up periods driven by customizable
keep-alives, relative traffic prioritization between apps, e.g. flash
player vs VoIP call vs IM etc)
3) design networks with higher capacity/bandwidth/load resilience,
rather than deploying complex mechanisms to contain congestion and
QoS.

In order that network operators start pushing apps to evolve in the
sense of better resource usage, some form of selection must be used,
e.g. penalize/choke/preempt the wrong-doers (the ones consuming too
much resources - whether with or without paying, depends on policy :).
If that is not possible, then we cannot guarantee that information
gathered from apps via an API will solve the problem any better than
usual network statistics (if at all) and the existence of an API will
not help making the network resource usage any better. Also, the
network should be able to tell whether it can honour resource
reservation requests.
Charging raises the issues of universal app identification,
authentication, security, privacy, roaming, interoperability, delivery
indicators etc.
The question is how much detail is worth exposing to apps about this.

If I understand right that what OMA would like from this work group in
terms of API's is a standard API through which apps could tell their
QoS/QoE preferences to the implementations when making new connections
(where the implementations may contain the client side of the
"Optimizer" in OMA use cases, or other solution in other case, or no
support for QoS).

There I would propose using a dictionary of connection options including
- minimum bandwidth (for working at all, and for minimum quality of
experience, respectively),
- maximum latency, and
- whether low latency is more desirable than higher bandwidth.
Each app would be responsible for mapping its QoE requirements to
these parameters. The challenge is there are different quality of
experience definitions depending on app type and protocol stack, and
there are different means to try to ensure it from the different types
of networks. So whether such proposal is good or bad is buried in the
details, and remains to be seen whether a useful and generic API could
be made.

Also, we need an API to tell if such service is available, what are
the options, costs, and also, when apps do tell such requests, the
user needs to approve the cost effect in the relevant networks.

If the parameters/enablers supporting these use cases are not present
in an app, it should still work in every network in the old
best-effort way.
If they are present, but the implementation / network does not support
them, should not cause any side effects.

Best regards,
Zoltan

[1] http://www.fiercedeveloper.com/story/pandora-zynga-build-network-efficient-apps-through-atts-aro-and-9-tips-deve/2012-08-14
[2] http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312

Received on Tuesday, 29 January 2013 15:47:09 UTC