Internet DRAFT - draft-nieminen-ippm-nn-measurements
draft-nieminen-ippm-nn-measurements
IP Performance Working Group K. Nieminen
Internet-Draft FICORA
Intended status: Informational August 28, 2017
Expires: February 28, 2018
Net Neutrality Measurements: Regulatory Use Case and Problem Statement
draft-nieminen-ippm-nn-measurements-01.txt
Abstract
This document describes a regulatory use case for net neutrality
measurements based on the new European open internet regulation.
The purpose of this document is to give sufficient details for
developing the actual net neutrality measurement metrics.
This document describes the problem statement. According to the
Regulation European regulators has to supervise and enforce the net
neutrality obligations. Especially the reliability of measurement
results is important. However, monitoring net neutrality is a
complex topic lacking standardized measurements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 28, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Nieminen Expires February 28, 2018 [Page 1]
Internet-Draft Net Neutrality Measurements August 2017
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Regulatory use cases . . . . . . . . . . . . . . . . . . . . . 4
3.1. Monitoring the performance of internet access services . . 5
3.2. Detecting traffic management practices that impact the
availability of individual applications . . . . . . . . . . 7
3.3. Detecting traffic management practices that impact the
quality of service for individual applications . . . . . . 7
3.4. Detecting end-user dependent factors that may impact the
measurement results . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
According to the European open internet regulation [1], providers of
internet access services shall treat all traffic equally, when
providing internet access services, without discrimination,
restriction or interference, and irrespective of the sender and
receiver, the content accessed or distributed, the applications or
services used or provided, or the terminal equipment used.
The Regulation allows only few exceptions for this rule that are
subject to strict interpretation and to proportionality requirements.
The Regulation imposes an obligation for European regulators to
closely monitor and ensure compliance with the Regulation.
Regulators must also promote the continued availability of non-
discriminatory internet access services at levels of quality that
reflect advances in technology.
Nieminen Expires February 28, 2017 [Page 2]
Internet-Draft Net Neutrality Measurements August 2017
The Regulation imposes also new transparency obligations for
internet access service contract conditions. Regarding fixed
networks, internet access service providers must publish among other
things a clear and comprehensible explanation of the minimum,
normally available, maximum and advertised download and upload
speeds.
The Body of European Regulators for Electronic Communications
(BEREC) has given guidelines on implementation of the Regulation
[2]. The guidelines provide further information regarding the
regulatory use cases.
This document strives to provide sufficient details about regulatory
use cases for developing the actual net neutrality measurement
metrics.
Although legal challenges can change the status of policy, the take-
away for IPPM purposes is that many policy-makers are looking for
measurement solutions to assist them in discovering discriminatory
treatment of traffic flows. The exact definitions and requirements
vary from one jurisdiction to another.
2. Problem statement
The regulators have a need to reliably assess violation of net
neutrality with respect to the recently published BEREC guidelines
on net neutrality and the underpinning EU legislation. In the
broader sense, the regulators' need is to determine whether illegal
traffic management practices is being applied to end-user traffic as
per application, as well as monitor the evolution of the performance
of the internet access service (IAS) over time.
It is envisaged that in order to carry out such assessment reliably,
a reliable technical measurement of end-user Internet traffic
behaviour needs to be conducted.
In 2015, Ofcom (communications regulator in the UK) commissioned a
study to better understand the existing techniques that could be
potentially used to detect traffic management. The study identified
a number of techniques that have been developed and that are able to
detect presence of particular kinds of differential traffic
management. The study also found that a gap exists for effective
detection of the presence of traffic management along the digital
delivery chain, but that a potential standardized solution may still
be possible. The study concluded that further work is required to
develop a broader framework for traffic management detection
solution.
Nieminen Expires February 28, 2017 [Page 3]
Internet-Draft Net Neutrality Measurements August 2017
When measurement tasks are run by an end-user, end-user environment
specific factors like cross-traffic, measurement interface
(fixed/wireless), firewalls, client operating system and hardware
can influence the measurement result. These factors have to be
detected and taken into account when assessing measurements
performed by end-users. The topic is discussed further under
Section 3.4.
According to BEREC guidelines speed should be calculated based on IP
packet payload. Currently BEREC is also considering using TCP
packet payload as raw sockets are not universally available to
standard users on most operating systems. For software based
crowdsourcing approach it is essential that measurements can be
performed using all common operating systems. Measurements should
also support measurement client software installed by the end-user
and as well as web browser based measurements.
The European Regulation requires internet service providers (ISPs)
to specify new speed values for example minimum, maximum, and
normally available speeds in fixed network. The measurement use
case is to assess if these contractual speed values are met. The
problem is to define measurements that can be run by end-users and
is accurate enough to have legal value.
In addition to the mandatory requirements there are features that
should be taken into account when planning the measurements to make
them more usable and user friendly such as that the measurement does
not block the internet access usage for whole day and does not
generate excessive network load.
In principle, any solution should be equally applicable to both
fixed and mobile Internet access services from narrow band to multi-
gigabit connections. Certain variations may be accepted if they can
be justified.
3. Regulatory use cases
Some regulatory use cases are already listed at a high level in RFC
7536 [3]. The purpose is to build on these use cases to
further elaborate what is needed to fulfil EU regulatory
Nieminen Expires February 28, 2017 [Page 4]
Internet-Draft Net Neutrality Measurements August 2017
requirements in view of the recent EU legislation and BEREC
guidelines publications. This document targets the level of detail
that is sufficient for developing actual measurement metrics and
methodologies.
The goal of this document is to help to understand what metrics need
to be defined and how they should be measured in order to produce
repeatable results with high degree of accuracy. This document also
gives a high level explanation of how these measurement tasks and
results can be used for assessing net neutrality in different
regulatory use cases.
The identified high-level measurement tasks are:
- Monitoring the performance of internet access services
- Detecting traffic management practices that impact the
availability of individual applications
- Detecting traffic management practices that impact the quality
of service for individual applications
- Detecting end-user dependent factors that may impact the
measurement results
An end-user should be able to run a measurement process from an
appropriate client. A regulator may provide additional
complementary tests as part of a larger suite of testing. Both
panel based and crowdsource solutions could be considered. It is
possible to use both active and passive measurements to fulfil the
regulatory requirements.
The solutions should be based on a minimum measurement time and data
volume in order to ensure the validity of the measurements while
taking care to avoid the possibility of harmful effect on end-user's
Internet consumption.
3.1. Monitoring the performance of internet access services
This use case is used to measure speed and other relevant internet
access service (IAS) quality of service (QoS) parameters (e.g.
delay, jitter and packet loss) for the IAS as a whole. It enables
end-users to check their individual internet access speed and
whether the IAS performance meets what has been specified in the
Nieminen Expires February 28, 2017 [Page 5]
Internet-Draft Net Neutrality Measurements August 2017
contract. This has traditionally been the main motivation for end-
users to use the tool provided by regulators.
Regulators may also run these measurements independently of any net
neutrality assessment and use this information for multiple purposes
such as increasing transparency in service provisioning (e.g.
coverage maps) and monitoring the overall IAS quality, which may be
aimed at:
- Ascertaining whether (or not) specialised services are
provided at the expense of IAS, and/or
- Determining whether IAS performance is evolving in tandem
with advances in technology.
The European open internet regulation [1] states that an end-
user may use a monitoring mechanism certified by the regulator to
check that the performance meets what has been specified in the
contract. This measurement information can be used for triggering
the remedies available to the consumer in accordance with national
law.
BEREC guidelines [2] defines further that the certified
monitoring mechanism should mitigate, to the extent possible,
confounding factors which are internal to the user environment.
Examples of these factors include existing cross-traffic and the
usage of wireless/wireline interfaces.
According to BEREC guidelines speed should be calculated based on IP
packet payload. Measurements should also be performed beyond the
internet service provider (ISP) leg.
According to the Regulation ISPs must specify the minimum, normally
available, maximum and advertised download and upload speed in their
fixed network contracts. For mobile network subscriptions ISPs must
specify estimated maximum and advertised download and upload speeds.
According to the recitals of the Regulation the normally available
speed is understood to be the speed that an end-user could expect to
receive most of the time when accessing the service. BEREC has
given further guidance that the speed should be available during the
specified daily period. For example a regulator may set a
requirement that the normally available speed should be available
during off-peak hours and 90% of time over peak hours, or 95% over
the whole day.
Other factors that require special attention are how the minimum and
maximum speed should be measured. According to BEREC guidelines the
- maximum speed is the speed that an end-user could expect to
receive at least some of the time (e.g. at least once a day).
Nieminen Expires February 28, 2017 [Page 6]
Internet-Draft Net Neutrality Measurements August 2017
- minimum speed is the lowest speed that the ISP undertakes to
deliver to the end-user. In principle, the actual speed should
not be lower than the minimum speed, except in cases of
interruption of the IAS.
Number and distribution of measurement tasks should be defined so
that the adequate confidence level such as 95% is achieved.
3.2. Detecting traffic management practices that impact the
availability of individual applications
The goal of this use case is to detect traffic management practices
that affect the connectivity and availability of content,
applications and services. Examples of this kind of practices may
include blocking communication ports, VoIP and P2P file sharing
applications in addition to other web content like streaming
services, network based parental control and ad-blocking.
Internet service providers may use several different traffic
management practices that block the connectivity to content,
applications and services. Examples of these traffic management
practices include: - Blocked communication ports
- IP addresses blocking
- DNS manipulation and HTTP proxy blocking
- Content or application based blocking with deep packet
inspection
The challenge is to define specific measurement tasks that allow
regulators to detect any blocked applications. A solution should
minimise the probability of false positives. In principle, the
solution is to comprise of measurement metric(s) and respective
measurement methodology(s); as well as quantification of the
probability of false positives.
Nieminen Expires February 28, 2017 [Page 7]
Internet-Draft Net Neutrality Measurements August 2017
3.3. Detecting traffic management practices that impact the quality of
service for individual applications
The goal of this use case is to detect possible unequal treatment of
traffic namely prioritisation and/or throttling of applications.
These traffic management practices may be detected by measuring the
QoS experienced by the application and comparing the results with
the QoS measurement results for the same IAS subscriptions and with
the similar application specific QoS measurement results from other
users and ISPs. Other techniques may also be possible.
A solution is required that correctly identifies whether
prioritisation and/or throttling of applications is taking place,
with minimum probability of false positives. In principle, the
solution is to comprise of measurement metric(s) and respective
measurement methodology(s); as well as quantification of the
probability of false positives.
For this case, in particular, regulator may need to conduct
additional complementary measurement tasks as part of a larger suite
of testing, in order to eliminate any false positives.
3.4. Detecting end-user dependent factors that may impact the
measurement results
Especially when measurements are run by an end-user in a
crowdsourcing measurement setup, the local environment specific
factors like cross-traffic, interface type (fixed/wireless),
firewalls, processor load, client operating system and hardware can
influence the measurement result.
It is preferred that the measurement client should capture this
additional data of the end user local environment. This environment
data can then be used in assessing the validity of the measurement
results with the aim of improving overall accuracy and minimising
false positives.
In principle, the solution is to comprise of measurement metric(s)
and respective measurement methodology(s), and how this environment
data can be used to ascertain measurement reliability in each use
case.
4. Security Considerations
This document defines a use case and problem statement for net
neutrality measurements. Security considerations for specific
measurements will be discussed in solution documents.
Nieminen Expires February 28, 2017 [Page 8]
Internet-Draft Net Neutrality Measurements August 2017
5. IANA Considerations
This document includes no requests to the IANA.
6. References
6.1. Informative References
[1] Regulation (EU) 2015/2120 of the European Parliament and
of the Council of 25 November 2015 laying down measures
concerning open internet access and amending Directive
2002/22/EC on universal service and users' rights
relating to electronic communications networks and
services and Regulation (EU) No 531/2012 on roaming on
public mobile communications networks within the Union,
November 2015, <http://eur-lex.europa.eu/legal-
content/en/TXT/?uri=CELEX:32015R2120>.
[2] BEREC Guidelines on the Implementation by National
Regulators of European Net Neutrality Rules, August 2016,
<http://berec.europa.eu/eng/document_register/subject_matt
er/berec/regulatory_best_practices/guidelines/6160-berec-
guidelines-on-the-implementation-by-national-regulators-
of-european-net-neutrality-rules>.
[3] Linsner, M., Eardley, P., Burbridge, T. and Sorensen, F.,
"Large-Scale Broadband Measurement Use Cases", RFC 7536,
May 2015, <http://www.rfc-editor.org/info/rfc7536>.
7. Acknowledgements
The author wish to thank Ahmed Aldabbagh, Mick Fox, Jose Hernan,
Frode Sorensen and Volker Sypli for their invaluable comments and
contributions.
This document was prepared using 2-Word-v2.0.template.dot.
Author's Address
Klaus Nieminen
FICORA
Itamerenkatu 3 A, P.O Box 313
Finland
Email: klaus.nieminen@ficora.fi
Nieminen Expires February 28, 2017 [Page 9]
