Re: Liaison statement from OMA on network efficiency

Thanks for the thoughtful comments. The next step will be to see if 
anyone else has has something to say, and whether the group is agreeable 
to passing the comments back to the OMA as is. We can then see if that 
leads to any pending actions on our behalf.

Best regards,

   Dave

On 29/01/13 15:46, Kis, Zoltan wrote:
> 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.RE: Re: Re: Re: Re: webinos Payment API revisited
>>
>> 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
>
>


-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Tuesday, 29 January 2013 17:55:38 UTC