RE: Network Information Use Cases

Daniel wrote:
> To me, most popular use cases of *network information* are
> 
> - smooth handover among various network interfaces on the mobile
> devices: for instance, in case any of network interface is being
> disconnected, app should be preparing the handover (depends user
> setting for handover time such as jitter > 1sec, packet loss > 10%,
> etc...) to another available interface where API should get these
> available network information (enabled network interfaces and their
> available bandwidth and features)...In this use case, *network
> information API* is very useful...

This isn't how most tablet devices work today. On WiFi, when your WiFi network falls off, you don't instantly transition to a new network, you transition to *no* network. Your device then spends 15 seconds acquiring a replacement network. A "network information" API isn't going to help you there.

Now, you could have tethering (or BB Bridge if you're on a PlayBook) in the background in addition to your WiFi link, however most services I've used can't possibly be prepared for such conditions and it will take a few seconds for them to realize there's a problem.

If you're talking about general management for a device to decide that it needs to shift all routing, that's probably in scope for Sys Apps.

Certainly RIM has a product called MVS for our BlackBerry phones which lets us make VOIP calls where we smoothly transition between WiFi and cellular, but I don't really see that as something normal web applications could possibly rationally manage. It might make sense for very system specific applications (hence Sys Apps).


> - adaptive streaming according to network conditions: given the
> *network information* API, app can obtain the network characteristics
> especially available bandwidth, and piggyback to the contents servers
> to adjust its ongoing traffics volumes.

The Network Information API will not give you this. You want an API from a Performance WG which tells you about current speed for current connections to the current server. Theoretical total bandwidth on the device doesn't help you any. The browser shouldn't tell your application about bandwidth being used by other applications on the device, and you shouldn't expect to have access to 100% of the bandwidth. Nor can you rely on all bandwidth being available between you and the destination.

I'm on a desktop computer on a corporate network with a generally reasonable uplink to the internet. There's a server which is supposedly Akamai hosted. In theory both of these computers have decent bandwidth. I certainly have reasonable transfer speeds from other sites. But for this one site, the download speed is terrible. The Network Information API will not tell me that my speed for downloading from that site is bad. And if I'm using an app which is talking to that site, then asking about total bandwidth will give me absolutely the wrong answer.

The only correct answer to this problem is "try it and see". If you try to download a 5mbps stream and you don't get 5mbps, then you need to switch to a different path or a different rate. Your application can trivially try both. If it finds that it can't get 5mbps, it can try 2mbps, if it gets that, it can periodically try to get 5mbps on a background transfer, if it gets that successfully, it can switch.

Theoretical bandwidth will *never* let you answer the question you need answered.

> It is also very useful feature
> for WebRTC where RTCWeb protocol (RTP or RTCP) is able to be used for
> the signalling to piggyback the network information to the server
> side.

Sorry. I don't see how. Again, this information is *junk*. It's meaningless.

If I connect to a WiFi network, and it turns out that it's actually an Android phone in hotspot mode, and that phone is on a cheap low speed cellular subscription, then just because I have a 10mb or 54mb network link to the WiFi network doesn't mean I have a 10 or 54 link to the internet. Heck. I could have a 100mb link to a WiFi point which is serviced by a 14mb or 20mb Cable/DSL link.

The Network Information API will *never* give you the information you need. It can't. Every use case that isn't "sit in the system notification area and explain the local link to the user" requires actual bandwidth to an actual destination, and that number is *barely* related to the first link. There can be congestion or a narrower link anywhere between the source and the destination.

> - multihoming use case: in case the mobile node can use multiple
> network interfaces (most case is both cellular and WiFi), app is able
> to handle its communication style, for instance; watching the movie
> through WiFi interface and paying something through cellular according
> to network security level information via API.

This isn't a valid use case. I've addressed it elsewhere. And it definitely isn't a Web API. It's a Crypto or Sys Apps API.

> In addition, load
> balancing between WiFi and cellular interfaces according to network
> price information (cellular is 5G/Month and WiFi is free, etc) via API
> is feasible, so that app can switch its ongoing services to WiFi from
> cellular in order to prevent user's cellular overloading (over 5G
> could be very expensive to user regardless of user intention).

This isn't the job of an web application, it's the job of the platform.

If one web application checks this, and twenty don't, then you've just broken three expensive downloads, and not actually saved the user any money.

Again, that's a reasonable request to make to Sys Apps, but it isn't reasonable for building web applications.

> These are very straightforward, but my point is to emphasize the value
> of network information API...

They're not valid within scope of DAP, nor are they particularly valid for Core Mob. They also don't really help the user. Most of these use cases make sense for platforms to use internally to provide the right general behavior. They do not make sense to expose to user applications.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Friday, 6 July 2012 12:51:12 UTC