Re: network neutrality and speech codecs

On 10/10/2011 8:23 PM, James Salsman wrote:
> On Mon, Oct 10, 2011 at 5:33 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> ...
>> James Salsman brought up 8 bullet point items, it seems that many were
>> discussed; together they bring up a complex issue about how the User Agent
>> may provide hints to an application as to Quality of Service.
> Hints such as a microphone would provide about sound pressure waves.
> The proposed network device API additions in
> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0088.html
> include quantities that can easily be measured by tools available
> today on nearly all desktop computers, and proven reliable ways to
> report qualities and quantities which can not be automatically
> measured.
>
> There have recently been some new violations of network neutrality and
> standards compliance described in
> http://corp.sonic.net/ceo/2011/08/11/the-five-levels-of-isp-evil/ some
> of which could also be measured automatically.


Here are some scenarios I've been through, in relation to the 8-point 
list you've posted:

Many iOS and Chrome OS devices have access to both cellular data and 
wifi networks.
In early iOS it was a frustrating experience to keep the phone from 
wandering onto various available WiFi networks.I often turned WiFi off.
Many Chrome OS devices come with a [free for a year or two] limited 
monthly plan for cellular data bandwidth.

The Windows OS has for some time asked users when they create new 
networking connections as to whether
the connection is at "home", "work" or "public". This is intended for 
users roaming with their laptops.

Many airports are WiFi enabled, some providing free WiFi. Most of them 
require an initial acceptance of the terms of service via web browser.
It seems in the interim step, DNS net neutrality  would not apply, but 
it could apply subsequently.

Seems like these small bits of information reside in the OS and could be 
shared by the UA.
Checking for dns-capture is very simple for the UA. Many UAs check for 
connectivity to the UA vendor.


As a web app developer + team:

We've considered "high bandwidth" and "low bandwidth" modes in our 
application.

In some cases we deal out a lot of image data. We can tone down our 
bandwidth use, and allow a user to manually set what kind of mode 
they're working with,
but it'd be nice to have some hints in advance, for new users.

The same applies to end-to-end encryption; it may help users roaming 
about unsecured wifi connections, connecting via http.

We might for instance, show a one-time warning about connecting to 
non-https sites, if the user is on an insecure wireless connection.
Firesheep certainly brought this issue to the mainstream: 
http://codebutler.com/firesheep

We run round trip time statistics in our app, both as part of websockets 
and as part of image loading.


-Charles

Received on Tuesday, 11 October 2011 08:03:54 UTC