Amazon Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Friday, 13 August 2010

Work in Progress (comments welcome) - Code of Conduct for Policy Management & Net Neutrality

Posted on 02:47 by Unknown
A food analogy: I see no reason why telcos shouldn't be allowed to offer "Internet-flavoured access", or "Processed Internet Substitute" if they wish, perhaps "Now fortified with Extra YouTube!".

But they shouldn't be able to sell or market those services as 100% Certified Prime Internet Access.

Like everyone in the telecoms industry, I encounter the issue of Net Neutrality and policy management very frequently. I've been watching developments recently, with the Google/Verizon announcement, consultations occurring in the UK and Europe, Chile deciding on a "hard" neutral policy, Canada choosing a middle ground and various other endless examples of posturing and lobbying.

It's got me thinking about what might be suitable compromises - a sort of generic "code of conduct" which might be applicable as a set of initial rules and goals, and which shouldn't irritate *too* many people. (Although clearly as we've seen with the Google/Verizon announcement, there's some irreconcilable differences between extreme ends of the spectrum of opinion).

I'm particularly thinking about rules for mobile data, which does have some practical constraints that do not exist in the fixed world. But given my recent work on fixed broadband business models and fibre, I'm also interested in more generic principles across the telecom industry.

The key areas I'm considering are:

  • Deliberate prioritisation, for example by guaranteeing QoS or providing an SLA for specific services, perhaps in terms of bandwidth, latency, jitter or other variables
  • Deliberate de-prioritisation, for example by blocking, throttling or otherwise interfering with a given data stream or service
  • Internet-based and non-Internet services
  • Internet access vs. other services
  • The problems of shared network resources being used simultaneously for Internet and non-Internet services

In general, it depends if there is congestion and contention for resources – if you prioritise something on an almost-empty network it obviously doesn’t impact anything else. Conversely, whether a telco should ever be allowed to constrain an application on an empty network is much more contentious.

My opinions (at this moment, and subject to debate and change) are:


  • Operators purely offering "in-house" managed services can do what they like in terms of managing their networks for non-Internet services - for example, on the core network it is fine to prioritise corporate VPNs, and on access lines they can tune their own IPTV or broadband TV services.
  • Where resources are used for both Internet access and non Internet services (eg home broadband lines, cell-site backhaul) and in particular where they are shared between multiple users, things get more complicated. In theory, it is OK with best-efforts "full Internet access" being at the bottom of the pile after other services have been dealt with. But there needs to be clarity in marketing, management and oversight. To use an analogy - if you buy a standby ticket for a flight, you know you might not get on. But if the plane takes off with empty seats and you're still refused boarding, you've got grounds for complaint & redress. Best-effort means that the service provider *really* has to make their "best effort" to accommodate you - *and* is still subject to the original contractual terms and subsequent reporting.
  • Internet access should be sold on the basis of average real-world speeds, not theoretical peak rates. Ideally, these averages (or perhaps minimum speeds) should be estimated for specific customers or locations (eg "given your house location, you should expect to get an average 2.7Mbit/s in normal use"). Providers should collect and publish actual average achieved rates, to allow comparison with their claims and promises. The stated averages in force at the start of a user's contract should not be allowed to fall during the course of the contract - this means that any subsequent sales of "managed" services on the same shared resources should be *incremental* to existing promised and contractual Internet capacity (calculated via statistical means)
  • The term "Internet access" needs some form of "Appellation contrôlée" - it can only be sold and branded as Internet access if it is not subject to undue policy management control, specifically around blocking/prioritisation based on application, flow, or destination. Anything else needs to be marketed and sold differently, eg "Internet-like service" or "Processed & reconstituted Internet, NOW WITH EXTRA YOUTUBE!". Consumer protection agencies need to be at the top of their game to ensure that end-users understand the difference - lessons from the food & drink industries should help.
  • *However*, it is fine for the provider to sell different classes of Internet access service, for example by speed, with caps or usage limits or other similar plan characteristic. An acceptable proxy for achieving application-level policy might be to have device-specific data plans, in the knowledge that (for example) BlackBerry users will typically behave differently to those dongles or tablets.
  • If capacity is available on the "Internet access" part of the network, it should be illegal to discriminate between different applications provided within that partition.
  • Any managed services (eg prioritised YouTube) should be provided by capacity in addition to that already dedicated to contracted Internet access. (Statistical estimations are fine for network dimensioning, as average speeds will be reported subsequently).
  • Renting broadband Internet access (fixed or mobile) should be similar to renting a property. The landlord should allow you "quiet enjoyment" without undue interference or limits, but is permitted to enter in emergencies, specify upfront rules (no pets) and hold you to account for destructive behaviour (withholding a deposit)
  • Governments and regulators may decide to mandate that all broadband providers give the option of "proper" Internet access, as well as any other managed services. This applies particularly in locations where it has been determined that Internet access is beneficial for economic or social reasons. It should be permissible to price pure Internet services at a higher level to managed Internet-like services.
  • “Negative” traffic management [throttling] on a per-application/per-service, on Internet access, is acceptable if (and only if) there are genuine resource constraints or costs, not just because an operator doesn’t like a given site/service
  • “Positive” traffic management is fine for non-Internet services (eg operator-hosted IPTV) provided over the same copper or radio as Internet access, as long as this is transparently described in detail to the customer
  • "Positive” traffic management [prioritisation] on a per-app basis, on Internet access is acceptable, as long as there are not unreasonable negative impacts on other apps/traffic. There must be absolute, detailed and realtime information about policy available to the end user and all application providers”
  • Negative / positive traffic management based on user, location, tariff, device type is generally OK, as long as it is not application/site specific [although these are often good proxies for applications]
  • Traffic management to manage integrity of network (eg DDoS attacks) or for legal requirements (regulatory prohibition of VoIP or services delivered to children) is fine
  • There needs to be an open “congestion API” provided so that telcos can be audited for fairness of traffic management policies
  • It should be illegal to block, prioritise or otherwise interfere with 3rd-party tools and services for measuring network quality, unless they themselves generate unreasonable traffic levels.
  • Operators must confirm that peering / transit partners apply equivalent rules
OK, I think that's a decent starting point. I'll hope to refine / iterate / clarify these over time. I suspect they will annoy both operators and hardcore Internet advocates. If I annoy both groups equally, I reckon I will have succeeded....
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home
View mobile version

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Quick musing on Cloud Computing
    I just heard the phrase "Everything as a Service" during a presentation on Cloud, SaaS and other forms of managed service offering...
  • Apple, embedded SIMs, NFC and mobile payments - some speculation
    I wonder if I've just managed to join up the dots on something rather important: - Recent reports suggest that Apple is intending to use...
  • New Cisco VNI traffic report out
    One of the broadband industry's "bibles" has been published in a 2010 edition . Cisco's "Visual Networking Index...
  • Is the MID a market?
    MIDs (Mobile Internet Devices) are being pushed by some notebook OEMs and silicon suppliers as the next big convergent handheld category. I...
  • "You can't use my eyeballs for free"
    Let's look forward 10 years. We've all got augmented reality browsers on our handsets, or perhaps our 4G-connected sunglasses. They ...
  • Mobile traffic management - the Inter-technology war begins
    I've been following the proliferation of mobile broadband traffic management technologies for some considerable time now, having publish...
  • Pre-MWC notes for analyst relations staff
    OK, it's the time of the year when I get bombarded by emails and phone calls from a million people inviting me to briefings and similar ...
  • Mobile operators' future voice strategies decoded
    Apologies in advance, but this blog post is deliberately a bit of a tease. I'm not going to spell out the answer here, as it's too v...
  • Hosted mobile services in the recession - Caveat Emptor
    I used to work as an equity analyst at an investment bank back in 2000-2001. I remember an unending stream of first generation Application S...
  • Challenges in measuring offload volumes
    I suspect we're going to get bombarded with statistics in the next year, along the lines of "Operator X deployed Vendor Y's off...

Blog Archive

  • ►  2013 (31)
    • ►  October (2)
    • ►  September (3)
    • ►  August (1)
    • ►  July (2)
    • ►  June (6)
    • ►  May (5)
    • ►  April (1)
    • ►  March (3)
    • ►  February (3)
    • ►  January (5)
  • ►  2012 (46)
    • ►  December (5)
    • ►  November (4)
    • ►  October (3)
    • ►  September (2)
    • ►  August (4)
    • ►  July (3)
    • ►  June (1)
    • ►  May (6)
    • ►  April (4)
    • ►  March (1)
    • ►  February (9)
    • ►  January (4)
  • ►  2011 (73)
    • ►  December (4)
    • ►  November (10)
    • ►  October (8)
    • ►  September (6)
    • ►  August (3)
    • ►  July (5)
    • ►  June (7)
    • ►  May (9)
    • ►  April (4)
    • ►  March (7)
    • ►  February (6)
    • ►  January (4)
  • ▼  2010 (130)
    • ►  December (4)
    • ►  November (10)
    • ►  October (10)
    • ►  September (6)
    • ▼  August (9)
      • Telcos: time to stop reporting "subscribers" and s...
      • Mobile traffic management - the Inter-technology w...
      • Is mobile voice being over-valued?
      • The Top 10 Unwarranted Assumptions in Telecoms
      • The hidden secret in the Google / Verizon statemen...
      • Work in Progress (comments welcome) - Code of Cond...
      • Device rental as a mechanism for mitigating roamin...
      • BlackBerry BBM intercept - workarounds probable?
      • Device-specific data plans and policy management
    • ►  July (7)
    • ►  June (19)
    • ►  May (19)
    • ►  April (11)
    • ►  March (18)
    • ►  February (7)
    • ►  January (10)
  • ►  2009 (126)
    • ►  December (4)
    • ►  November (14)
    • ►  October (9)
    • ►  September (8)
    • ►  August (9)
    • ►  July (10)
    • ►  June (21)
    • ►  May (14)
    • ►  April (2)
    • ►  March (11)
    • ►  February (15)
    • ►  January (9)
  • ►  2008 (94)
    • ►  December (24)
    • ►  November (26)
    • ►  October (25)
    • ►  September (19)
Powered by Blogger.

About Me

Unknown
View my complete profile