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 3rd-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 3rd-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?
#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 3rd-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 50th 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 3rd
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?
