idnits 2.17.1 draft-nieminen-ippm-nn-measurements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2017) is 2427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Working Group K. Nieminen 3 Internet-Draft FICORA 4 Intended status: Informational August 28, 2017 5 Expires: February 28, 2018 7 Net Neutrality Measurements: Regulatory Use Case and Problem Statement 8 draft-nieminen-ippm-nn-measurements-01.txt 10 Abstract 12 This document describes a regulatory use case for net neutrality 13 measurements based on the new European open internet regulation. 14 The purpose of this document is to give sufficient details for 15 developing the actual net neutrality measurement metrics. 17 This document describes the problem statement. According to the 18 Regulation European regulators has to supervise and enforce the net 19 neutrality obligations. Especially the reliability of measurement 20 results is important. However, monitoring net neutrality is a 21 complex topic lacking standardized measurements. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 28, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Regulatory use cases . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Monitoring the performance of internet access services . . 5 61 3.2. Detecting traffic management practices that impact the 62 availability of individual applications . . . . . . . . . . 7 63 3.3. Detecting traffic management practices that impact the 64 quality of service for individual applications . . . . . . 7 65 3.4. Detecting end-user dependent factors that may impact the 66 measurement results . . . . . . . . . . . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Informative References . . . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 According to the European open internet regulation [1], providers of 75 internet access services shall treat all traffic equally, when 76 providing internet access services, without discrimination, 77 restriction or interference, and irrespective of the sender and 78 receiver, the content accessed or distributed, the applications or 79 services used or provided, or the terminal equipment used. 81 The Regulation allows only few exceptions for this rule that are 82 subject to strict interpretation and to proportionality requirements. 84 The Regulation imposes an obligation for European regulators to 85 closely monitor and ensure compliance with the Regulation. 86 Regulators must also promote the continued availability of non- 87 discriminatory internet access services at levels of quality that 88 reflect advances in technology. 90 The Regulation imposes also new transparency obligations for 91 internet access service contract conditions. Regarding fixed 92 networks, internet access service providers must publish among other 93 things a clear and comprehensible explanation of the minimum, 94 normally available, maximum and advertised download and upload 95 speeds. 97 The Body of European Regulators for Electronic Communications 98 (BEREC) has given guidelines on implementation of the Regulation 99 [2]. The guidelines provide further information regarding the 100 regulatory use cases. 102 This document strives to provide sufficient details about regulatory 103 use cases for developing the actual net neutrality measurement 104 metrics. 106 Although legal challenges can change the status of policy, the take- 107 away for IPPM purposes is that many policy-makers are looking for 108 measurement solutions to assist them in discovering discriminatory 109 treatment of traffic flows. The exact definitions and requirements 110 vary from one jurisdiction to another. 112 2. Problem statement 114 The regulators have a need to reliably assess violation of net 115 neutrality with respect to the recently published BEREC guidelines 116 on net neutrality and the underpinning EU legislation. In the 117 broader sense, the regulators' need is to determine whether illegal 118 traffic management practices is being applied to end-user traffic as 119 per application, as well as monitor the evolution of the performance 120 of the internet access service (IAS) over time. 122 It is envisaged that in order to carry out such assessment reliably, 123 a reliable technical measurement of end-user Internet traffic 124 behaviour needs to be conducted. 126 In 2015, Ofcom (communications regulator in the UK) commissioned a 127 study to better understand the existing techniques that could be 128 potentially used to detect traffic management. The study identified 129 a number of techniques that have been developed and that are able to 130 detect presence of particular kinds of differential traffic 131 management. The study also found that a gap exists for effective 132 detection of the presence of traffic management along the digital 133 delivery chain, but that a potential standardized solution may still 134 be possible. The study concluded that further work is required to 135 develop a broader framework for traffic management detection 136 solution. 138 When measurement tasks are run by an end-user, end-user environment 139 specific factors like cross-traffic, measurement interface 140 (fixed/wireless), firewalls, client operating system and hardware 141 can influence the measurement result. These factors have to be 142 detected and taken into account when assessing measurements 143 performed by end-users. The topic is discussed further under 144 Section 3.4. 146 According to BEREC guidelines speed should be calculated based on IP 147 packet payload. Currently BEREC is also considering using TCP 148 packet payload as raw sockets are not universally available to 149 standard users on most operating systems. For software based 150 crowdsourcing approach it is essential that measurements can be 151 performed using all common operating systems. Measurements should 152 also support measurement client software installed by the end-user 153 and as well as web browser based measurements. 155 The European Regulation requires internet service providers (ISPs) 156 to specify new speed values for example minimum, maximum, and 157 normally available speeds in fixed network. The measurement use 158 case is to assess if these contractual speed values are met. The 159 problem is to define measurements that can be run by end-users and 160 is accurate enough to have legal value. 162 In addition to the mandatory requirements there are features that 163 should be taken into account when planning the measurements to make 164 them more usable and user friendly such as that the measurement does 165 not block the internet access usage for whole day and does not 166 generate excessive network load. 168 In principle, any solution should be equally applicable to both 169 fixed and mobile Internet access services from narrow band to multi- 170 gigabit connections. Certain variations may be accepted if they can 171 be justified. 173 3. Regulatory use cases 175 Some regulatory use cases are already listed at a high level in RFC 176 7536 [3]. The purpose is to build on these use cases to 177 further elaborate what is needed to fulfil EU regulatory 178 requirements in view of the recent EU legislation and BEREC 179 guidelines publications. This document targets the level of detail 180 that is sufficient for developing actual measurement metrics and 181 methodologies. 183 The goal of this document is to help to understand what metrics need 184 to be defined and how they should be measured in order to produce 185 repeatable results with high degree of accuracy. This document also 186 gives a high level explanation of how these measurement tasks and 187 results can be used for assessing net neutrality in different 188 regulatory use cases. 190 The identified high-level measurement tasks are: 192 - Monitoring the performance of internet access services 193 - Detecting traffic management practices that impact the 194 availability of individual applications 195 - Detecting traffic management practices that impact the quality 196 of service for individual applications 197 - Detecting end-user dependent factors that may impact the 198 measurement results 200 An end-user should be able to run a measurement process from an 201 appropriate client. A regulator may provide additional 202 complementary tests as part of a larger suite of testing. Both 203 panel based and crowdsource solutions could be considered. It is 204 possible to use both active and passive measurements to fulfil the 205 regulatory requirements. 207 The solutions should be based on a minimum measurement time and data 208 volume in order to ensure the validity of the measurements while 209 taking care to avoid the possibility of harmful effect on end-user's 210 Internet consumption. 212 3.1. Monitoring the performance of internet access services 214 This use case is used to measure speed and other relevant internet 215 access service (IAS) quality of service (QoS) parameters (e.g. 216 delay, jitter and packet loss) for the IAS as a whole. It enables 217 end-users to check their individual internet access speed and 218 whether the IAS performance meets what has been specified in the 219 contract. This has traditionally been the main motivation for end- 220 users to use the tool provided by regulators. 222 Regulators may also run these measurements independently of any net 223 neutrality assessment and use this information for multiple purposes 224 such as increasing transparency in service provisioning (e.g. 225 coverage maps) and monitoring the overall IAS quality, which may be 226 aimed at: 228 - Ascertaining whether (or not) specialised services are 229 provided at the expense of IAS, and/or 230 - Determining whether IAS performance is evolving in tandem 231 with advances in technology. 233 The European open internet regulation [1] states that an end- 234 user may use a monitoring mechanism certified by the regulator to 235 check that the performance meets what has been specified in the 236 contract. This measurement information can be used for triggering 237 the remedies available to the consumer in accordance with national 238 law. 240 BEREC guidelines [2] defines further that the certified 241 monitoring mechanism should mitigate, to the extent possible, 242 confounding factors which are internal to the user environment. 243 Examples of these factors include existing cross-traffic and the 244 usage of wireless/wireline interfaces. 246 According to BEREC guidelines speed should be calculated based on IP 247 packet payload. Measurements should also be performed beyond the 248 internet service provider (ISP) leg. 250 According to the Regulation ISPs must specify the minimum, normally 251 available, maximum and advertised download and upload speed in their 252 fixed network contracts. For mobile network subscriptions ISPs must 253 specify estimated maximum and advertised download and upload speeds. 255 According to the recitals of the Regulation the normally available 256 speed is understood to be the speed that an end-user could expect to 257 receive most of the time when accessing the service. BEREC has 258 given further guidance that the speed should be available during the 259 specified daily period. For example a regulator may set a 260 requirement that the normally available speed should be available 261 during off-peak hours and 90% of time over peak hours, or 95% over 262 the whole day. 264 Other factors that require special attention are how the minimum and 265 maximum speed should be measured. According to BEREC guidelines the 267 - maximum speed is the speed that an end-user could expect to 268 receive at least some of the time (e.g. at least once a day). 270 - minimum speed is the lowest speed that the ISP undertakes to 271 deliver to the end-user. In principle, the actual speed should 272 not be lower than the minimum speed, except in cases of 273 interruption of the IAS. 275 Number and distribution of measurement tasks should be defined so 276 that the adequate confidence level such as 95% is achieved. 278 3.2. Detecting traffic management practices that impact the 279 availability of individual applications 281 The goal of this use case is to detect traffic management practices 282 that affect the connectivity and availability of content, 283 applications and services. Examples of this kind of practices may 284 include blocking communication ports, VoIP and P2P file sharing 285 applications in addition to other web content like streaming 286 services, network based parental control and ad-blocking. 288 Internet service providers may use several different traffic 289 management practices that block the connectivity to content, 290 applications and services. Examples of these traffic management 291 practices include: - Blocked communication ports 293 - IP addresses blocking 294 - DNS manipulation and HTTP proxy blocking 295 - Content or application based blocking with deep packet 296 inspection 298 The challenge is to define specific measurement tasks that allow 299 regulators to detect any blocked applications. A solution should 300 minimise the probability of false positives. In principle, the 301 solution is to comprise of measurement metric(s) and respective 302 measurement methodology(s); as well as quantification of the 303 probability of false positives. 305 3.3. Detecting traffic management practices that impact the quality of 306 service for individual applications 308 The goal of this use case is to detect possible unequal treatment of 309 traffic namely prioritisation and/or throttling of applications. 311 These traffic management practices may be detected by measuring the 312 QoS experienced by the application and comparing the results with 313 the QoS measurement results for the same IAS subscriptions and with 314 the similar application specific QoS measurement results from other 315 users and ISPs. Other techniques may also be possible. 317 A solution is required that correctly identifies whether 318 prioritisation and/or throttling of applications is taking place, 319 with minimum probability of false positives. In principle, the 320 solution is to comprise of measurement metric(s) and respective 321 measurement methodology(s); as well as quantification of the 322 probability of false positives. 324 For this case, in particular, regulator may need to conduct 325 additional complementary measurement tasks as part of a larger suite 326 of testing, in order to eliminate any false positives. 328 3.4. Detecting end-user dependent factors that may impact the 329 measurement results 331 Especially when measurements are run by an end-user in a 332 crowdsourcing measurement setup, the local environment specific 333 factors like cross-traffic, interface type (fixed/wireless), 334 firewalls, processor load, client operating system and hardware can 335 influence the measurement result. 337 It is preferred that the measurement client should capture this 338 additional data of the end user local environment. This environment 339 data can then be used in assessing the validity of the measurement 340 results with the aim of improving overall accuracy and minimising 341 false positives. 343 In principle, the solution is to comprise of measurement metric(s) 344 and respective measurement methodology(s), and how this environment 345 data can be used to ascertain measurement reliability in each use 346 case. 348 4. Security Considerations 350 This document defines a use case and problem statement for net 351 neutrality measurements. Security considerations for specific 352 measurements will be discussed in solution documents. 354 5. IANA Considerations 356 This document includes no requests to the IANA. 358 6. References 360 6.1. Informative References 362 [1] Regulation (EU) 2015/2120 of the European Parliament and 363 of the Council of 25 November 2015 laying down measures 364 concerning open internet access and amending Directive 365 2002/22/EC on universal service and users' rights 366 relating to electronic communications networks and 367 services and Regulation (EU) No 531/2012 on roaming on 368 public mobile communications networks within the Union, 369 November 2015, . 372 [2] BEREC Guidelines on the Implementation by National 373 Regulators of European Net Neutrality Rules, August 2016, 374 . 379 [3] Linsner, M., Eardley, P., Burbridge, T. and Sorensen, F., 380 "Large-Scale Broadband Measurement Use Cases", RFC 7536, 381 May 2015, . 383 7. Acknowledgements 385 The author wish to thank Ahmed Aldabbagh, Mick Fox, Jose Hernan, 386 Frode Sorensen and Volker Sypli for their invaluable comments and 387 contributions. 389 This document was prepared using 2-Word-v2.0.template.dot. 391 Author's Address 393 Klaus Nieminen 394 FICORA 395 Itamerenkatu 3 A, P.O Box 313 396 Finland 398 Email: klaus.nieminen@ficora.fi