[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/