My comments on BEREC's Net Neutrality guidelines consultation

I've been meaning to submit a response to the BEREC consultation on its draft implementation guidelines for the new EU Net Neutrality guidelines for some time. However, a combination of project-work and vacation has meant I've had to do just a fairly rapid set of comments at the last moment. 

I'm posting them here as a reference and further discussion-point. 

As a background, I think the guidelines are quite comprehensive - but have shifted the needle somewhat from the final EU regulation back towards the Internet-centric view of the world. However, the permissiveness around both zero-rating and (in certain circumstances) so-called "specialised services" seems a pragmatic compromise position. I tend to think that zero-rating is fine "in moderation" - it's basically the Internet equivalent of promotions and coupons. "Sponsored data" is an almost-unworkable concept anyway, so the regulatory aspect is largely irrelevant.

Specialised services are OK as long as they are genuinely "special" - something I've been saying for a long time (see post here). It should also be possible to watch for genuine innovation being catalysed / inhibited by the new rules - and then regulators and policymakers can take a more-educated view to revising them in a few years, based on hard evidence.

Anyway - the contents of my submission (reformatted slightly) are below:

Preamble

I am an independent telecom industry analyst and futurist, representing my own advisory company Disruptive Analysis. I advise a broad variety of telecom operators, network and software vendors, investors, NRAs, IT/Internet firms and others on technology evolution paths, business models and applications, and regulatory issues. I look at the issue of Net Neutrality particularly through the lens of what is, or what is not, possible – and also how the Internet value-chain, applications and user-behaviour are likely to evolve in future.

In the past, I have published research studies examining the possible roles and scale of “non-neutral” broadband & IAS business models. My primary conclusions have been that, irrespective of regulation, most proposed commercial models such as “paid prioritisation”, application-based charging or “sponsored data” are broadly unworkable, for many different technical and business reasons – such as growing use of encryption, plus the risks of false positives/negatives.

Overall, I see the guidelines as broadly positive, as they help clarify some of the many grey areas around implementing NN, and clearly try to close off future potential loopholes. Some aspects will likely be difficult to implement technically – notably the precise definitions and measurements of QoS / and “quality” – but the guidelines are good in setting the “spirit” of the law, even though in some cases the “letter” may be harder to achieve.

Listed below are comments that I feel could help to:

• Clarify the guidelines further 
•  Help future-proof them against changes in technology 
•  Raise questions about possible evolution of the guidelines in response to those changes 
•  Lock down a few additional possible loopholes

                                                                                                                       

Specific points on individual paragraphs: (reference to the guidelines doc here)

#10 – in locations where “WiFi guest access” is made available (eg visitors to a company’s offices), there is sometimes a sign-up or registration required, either via a splash-page, or simply via obtaining a password. Does this count as “publicly available”?

#11 – it should be clarified that there is a difference between corporate VPNs for connecting to a central site, and personal VPNs that are designed to secure/encrypt normal users’ access to the Internet. There is also a growing trend for corporate VPNs to be replaced by a new technology, software-defined WAN, which may itself use Internet access or even multiple accesses as transport.

#12 – Consideration of WiFi hotspots needs to distinguish between voluntary access (eg if a user obtains the café password & registers independently) vs. automated “WiFi offload” by ISPs as an integral part of their IAS offering. The latter is a form of “public access”. Also, there are growing examples of ISPs using WiFi in public places, including outdoors, sometimes as part of “WiFi-Primary” public IAS.

#14 - It is worth distinguishing between capital-I “The Internet” (ie public Internet, addressable via the DNS system & IAS) and lower-case-I “internets” (internetworks) that are private domains.

#23-25 – This needs to reference what happens when “terminal equipment” becomes virtualised, through the imminent release of NFV (network function virtualisation) architectures. This could mean that either the “terminal” become a software-function in the ISPs’ data-centre, or could be (in part) pushed down as a “virtual network function” (VNF) to a general-purpose box at the customer site. Some providers are already discussing the concept of a “VNF AppStore” where the user can choose between different software “terminal” functions. It is unclear if this is permissible – or even mandatory.

#39 & #45 – the nature of software and Internet applications makes its increasingly hard to define categories. There are many blurred boundaries, overlapping categories, “mashups” and differentiated offers. How is the categorisation achieved, for example where a social network includes a large amount of video-streaming in its timelines? Is that equivalent to a “pure” video application? What about streaming of games? Is there a distinction between video-on-demand and live-streaming? This is particularly difficult where some functions such as voice communication are being included as “secondary features” embedded in many other applications, often via the use of 3^rd-party platforms and APIs (application programming interfaces). There needs to be stronger guidance on how “categories” are defined and how disputed or ambiguous categorisation can be addressed.

#40 & #45 – a possible implementation option is to require ISPs to report the % of overall traffic (or % of particular user-classes) that is zero-rated.  If the total amount provided “for free” is less than (say) 10% of the total, it can a-priori be considered acceptable as it is unlikely to materially affect users’ choices. However, if it is higher this could trigger closely investigation by the NRA.

#43 – this section seems to focus more on established CAPs or possible new-entrants. It is unclear if this explicitly covers the needs open-source initiatives and general software-developers

#56 – There is a possible implementation option for NRAs to collect and hold configuration details for ISPs’ network equipment or software-equivalent VNFs, to allow retrospective analysis of network setup if disputes occur. This could be done on an encrypted / escrowed basis to maintain normal commercial confidentiality

#57 – the reference to encryption needs to explicitly include both app-level encryption (eg HTTPS / HTTP2) and more general “all-traffic” encryption using corporate or personal VPN “tunnels”

#57 & 58 – an implementation option for NRAs could be provision of a contact-point for internal ISP whistle-blowers to report infringement, or 3^rd-party monitoring organisations (eg that use pattern-recognition to detect abuses)

#60 & #61 & #63 – categorisation is extremely hard, owing to application differentiation, complex hybrid and “mashup” applications, different levels of fault-tolerance built into applications by developers etc. For example, different VoIP applications use different approaches to error-correction, or are used differently (eg ordinary telephony vs. karaoke). In future there will also be a difference based on whether the application (at either end) is a machine rather than a person. Implied QoS when speaking to “Siri” or “Alexa” may have very different characteristics to speaking to a friend, despite being carried over VoIP. There may also be other dependencies – eg if network conditions have worse impact on badly-designed applications, or devices with other constraints (memory, CPU power, processing chips etc)

#64 – does “network management traffic” also include other types of operational (internal) ISP traffic such as billing records, customer-service inquiries & apps and so forth?

#71 – does “alteration” cover so-called “optimisation”, whereby various content such as a video or image can be paused, down-rated, reformatted etc.? Does it also cover “insertion” of additional data such as tracking codes / “supercookies”, or additional overlay advertising? Are “splash pages” (eg for WiFi registration) allowed?

#89 – Dimensioning may well be affected by other constraints, such as spectrum availability, location, economics of network coverage/capacity, or “emergent” unexpected trends in demand

#98 & #123 – this appears to define specialised services as “actually being special” rather than those capabilities that are normally delivered over IAS. How are hybrid specialised/non-specialised services to be treated?

#101 & #104 – technologies such as SD-WAN (software-defined WAN) allow improved QoS by linking together multiple IAS connections, which in aggregate can perform as well (or even better/cheaper) than one QoS-optimised connection. Should NRAs consider this option when determining if specialised services are valid? See http://disruptivewireless.blogspot.co.uk/2016/06/arbitrage-everywhere-inevitable.html  and http://disruptivewireless.blogspot.co.uk/2016/03/is-sd-wan-quasi-qos-overlay-for.html for more detailed discussion of this point

#111 – It is important to recognise that VPNs are increasingly used by consumers as well as businesses, often to provide a secure & privacy-protected path to the Internet over both public IAS and localised WiFi hotspots. The guidelines should specifically reference consumer VPNs.

#113 to #115 & #117 & #119 – It may be difficult to guarantee coexistence of IAS and specialised services over cellular/other radio networks, where factors such as location in a cell, mobility, density of users, coverage/interference etc are non-deterministic. Potentially the guidelines could advise use of different spectrum bands for IAS and specialised services, to mitigate these problems.

#113 & #116 – in future 5G architectures, we may see a concept called “network slicing”, where the radio and core networks are logically divided into “slices” suitable for different application classes – either broadly between Internet & specialised services of different types, or resold more granularly a bit like “super-MVNOs” to particular 3^rd-parties on a wholesale basis. Where those parties are themselves CAPs, this could make interpretation of this section very difficult. If Netflix or Google or even a rival ISP/telco buy rights to a “slice”, how do the guidelines apply?

#131 – This guideline should potentially also include information/transparent guidance for application developers, who may be creating applications intended to run over the IAS provided

#152 – should coverage maps be 2-dimensional, or also include z-axis detail (eg speed in a basement / on the 50^th floor of a tower block)? How can such maps cope with the trend towards self-optimising / self-reconfiguring networks of various types?

#167 & #180 – NRAs should potentially seek to maintain records of network configuration status (which may change abruptly with the advent of NFV & SDN). This could perhaps be stored securely & reliably using technologies such as Blockchain.

#172 & #179 – monitoring of aggregate volumes of traffic subject to price-discrimination (eg % of IAS traffic that is zero-rated) would be useful

General comments:

• There needs to be consideration of meshed, relayed or shared connections which run directly between users’ devices. In device-to-device scenarios, does the owner/operator of an intermediate device become responsible for the neutrality of the “onward” link to 3^rd parties? (which could be via any technology such as WiFi, Bluetooth, wired USB port etc) 
•  There needs to be consideration that some of the more invasive mechanisms for traffic discrimination and control will in future move from “the network” to becoming virtualised software (provided by an ISP) that reside in edge-nodes at the customer premise, or even in customers’ mobile devices. It is unclear how the implementation guidelines deal with predictable near/mid-term trends in NFV/SDN technology, especially where there is no clear “demarcation point” in ownership between ISP and end-user. 
• Equally, in future there may well be CAP companies that offer their services “in the network” itself, also with NFV/SDN. There needs to be careful thought given to how this intersects with Net Neutrality guidelines 
• The evolution of artificial intelligence & machine-learning means that workarounds or infringements may become automated, and perhaps even invisible to ISPs, in future. This may also impact the nature of QoS as used for different applications. See http://disruptivewireless.blogspot.co.uk/2016/04/telcofuturism-will-ai-machine-learning.html for more details 
•  Where wholesale relationships occur – eg MNO/MVNO, “neutral host” networks using unlicenced-band LTE, or secondary ID on the same WiFi hotspot – and the traffic-management / IAS functions are co-managed, how do the guidelines apply? Which party/parties is responsible?