Re: API for network optimization

Hi all, apologies about the delayed reply!

On Wed, Nov 26, 2014 at 6:52 AM, Dominique Hazael-Massieux <dom@w3.org>
 wrote:

> I wonder if there is also any interest in working
> on an operator-neutral API that would let developers get some visibility
> as to how they should behave on the network to obtain optimal
> performances while reducing network load.
>
> I'm interested in feedback on the value of pushing such work, as well as
> on whether there is any realistic hope such information can be provided
> by (at least some) network operators.
>

Before I attempt to answer above questions, let me try to explain the
problem we're running up against (apologies about the length):

Mobile radio(s) consume a lot of energy and all existing standards design
the underlying protocols with an explicit goal of trying to power down the
radio as quickly as possible, and to keep it in that state for as long as
possible. Further, some standards define multiple radio states where small
amounts of data may be trickled out over a shared channel without causing a
full high power cycle on the radio. Also, each radio cycle incurs a lot of
coordination overhead in the carrier network ("signaling storms"), hence
it's also in carriers interest to try and keep the device in a shared
channel / radio-off state for as long as possible. So far so good...

The problem today is that all of that underlying logic is hidden from the
application layer, which leads to really painful edge-cases. A real-world
example to illustrate the point... We ran into an issue where the Google
Search was responding *really* slowly to user input (the autocomplete
results would take forever), but it only happened on a particular carrier.
After lots of trial and error (and poking in the dark), we realized that
the issue was that the amount of data we were sending (very small) was
causing that particular carrier to keep us in the "shared channel" and
hence the slow request-reply. Once we sent enough data everything was fast
again... After contacting the carrier, they confirmed that they recently
raised their limit for the shared channel, which triggered this condition
on our end. This took a long time to diagnose, and it affected a lot of
users. That said, nobody in particular is at fault: carrier wanted to
minimize signaling storms and reduce energy usage on device, our app wanted
to minimize data overhead, both of which are the right goals.

The above example generalizes into a recurring problem: interactive traffic
is being misclassified and is kept in the slow lane, causing unexpected
delays and high variability in response times. And at the same time we also
have the opposite problem: there are many cases where we're transferring
small-but-sufficiently large payloads which are *not* interactive, and
we're perfectly fine if they take longer to transmit but consume less
energy.

In effect, what's missing is a channel to communicate between the browser
(or any app working with sockets, this is not a "web only" thing) and the
underlying radio drivers + carrier logic that can indicate the type of
transmission (background vs. interactive). If such thing existed, the
browser could classify packets as interactive or background and defer to
the radio to make the right decisions.

Instead the "workaround solution" today is to pad transmissions from
app-space and force the radio into high-power state -- needless to say,
this is a terrible approach. In fact, we're stuck in an unfortunate loop:
developers pad more bytes, carriers raise limits, developers pad... At the
same time, we don't have a good solution for efficient background
transfers: different standards have different logic, different carriers
have different thresholds, and so on.

Solving this problem is a non-trivial exercise as we're talking about "app
> network driver > carrier" coordination, and I'm not sure that this is the
right forum for it? That said, perhaps someone else has some clever ideas
or insights on how this could be tackled, or knows the right people at
right places that can make it a reality? :-)

----

Independent of the above, what we have found very useful is data on how the
various networks are configured under the hood -- e.g. how long until radio
transitions from high state to low power, and so on. ATT's ARO project is a
rare (and very valuable) example of providing this data:
https://github.com/attdevsupport/ARO/blob/master/ARODataAnalyzer/src/lte.conf

As one idea and suggestion: I'd love to see similar configuration data for
other carriers. If available, it could be incorporated into developer
tools, simulators / emulators for energy use and latency, and so on.

---

All that said.. I'm also curious to hear any other ideas from both sides of
the table for what we could/should do better to deliver a better experience
to the user. Our goals are aligned, even if our APIs are not... (currently,
at least :)).

ig

On Thu, Nov 27, 2014 at 3:28 AM, Natasha Rooney <nrooney@gsma.com> wrote:

> Thanks for this Dom!
>
> Guys - please take a look at Dom¹s suggestion below and let the list know
> your thoughts (thanks to Kawada san for already doing this!). We will be
> having some discussions about this on the list and on the calls.
>
> >From a GSMA perspective I love the idea! It is a great initiative to ease
> network traffic, as well as provide more insight into how to react to
> certain network situations for developers.
>
> Thanks all!
>
>
> Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730
> 219 765 | @thisNatasha | Skype: nrooney@gsm.org
>
> Tokyo, Japan
>
>
>
>
>
>
>
> On 11/26/14, 23:52, "Dominique Hazael-Massieux" <dom@w3.org> wrote:
>
> >Hi all,
> >
> >Back at the Telcos@w3c breakout in TPAC, we ended the session discussing
> >how browser vendors and/or Web application developers could adapt their
> >network usage to the underlying network:
> >http://www.w3.org/2014/10/29-telcos-minutes.html#item04b
> >
> >Ilya (copied) explained how the specific network configuration (e.g. its
> >response to particular pattern of network traffic) can affect
> >dramatically the final performance of the Web app.
> >
> >While there are already ongoing discussions on an API to adapt to the
> >user's data plan [1], I wonder if there is also any interest in working
> >on an operator-neutral API that would let developers get some visibility
> >as to how they should behave on the network to obtain optimal
> >performances while reducing network load.
> >
> >I'm interested in feedback on the value of pushing such work, as well as
> >on whether there is any realistic hope such information can be provided
> >by (at least some) network operators.
> >
> >Thanks,
> >
> >Dom
> >
> >1.
> >http://lists.w3.org/Archives/Public/public-web-mobile/2014Oct/0004.html
> >
> >
> >
>
> This email and its attachments are intended for the above named only and
> may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
>
>