idnits 2.17.1 draft-nieminen-ippm-nn-measurements-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 5) being 64 lines == It seems as if not all pages are separated by form feeds - found 9 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2017) is 2613 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 February 27, 2017 5 Expires: August 28, 2017 7 Net Neutrality Measurements: Regulatory Use Case and Problem Statement 8 draft-nieminen-ippm-nn-measurements-00.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 [1]. The purpose of this document is to give sufficient details 15 for 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 August 28, 2017. 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. This has to be taken into account when specifying 148 the measurement metrics. It is noted that support for raw sockets 149 is not universally available to standard users on most operating 150 systems. For software based crowdsourcing approach it is essential 151 that measurements can be performed using all common operating 152 systems. Measurements should also support measurement client 153 software installed by the end-user and as well as web browser based 154 measurements. 156 The European Regulation requires internet service providers (ISPs) 157 to specify new speed values for example minimum, maximum, and 158 normally available speeds in fixed network. The measurement use 159 case is to assess if these contractual speed values are met. The 160 problem is to define measurements that can be run by end-users and 161 is accurate enough to have legal value. 163 In addition to the mandatory requirements there are features that 164 should be taken into account when planning the measurements to make 165 them more usable and user friendly such as that the measurement does 166 not block the internet access usage for whole day and does not 167 generate excessive network load. 169 In principle, any solution should be equally applicable to both 170 fixed and mobile Internet access services from narrow band to multi- 171 gigabit connections. Certain variations may be accepted if they can 172 be justified. 174 3. Regulatory use cases 176 Some regulatory use cases are already listed at a high level in RFC 177 7536 [3]. The purpose is to build on these use cases to 178 further elaborate what is needed to fulfil EU regulatory 179 requirements in view of the recent EU legislation and BEREC 180 guidelines publications. This document targets the level of detail 181 that is sufficient for developing actual measurement metrics and 182 methodologies. 184 The goal of this document is to help to understand what metrics need 185 to be defined and how they should be measured in order to produce 186 repeatable results with high degree of accuracy. This document also 187 gives a high level explanation of how these measurement tasks and 188 results can be used for assessing net neutrality in different 189 regulatory use cases. 191 The identified high-level measurement tasks are: 193 - Monitoring the performance of internet access services 194 - Detecting traffic management practices that impact the 195 availability of individual applications 196 - Detecting traffic management practices that impact the quality 197 of service for individual applications 198 - Detecting end-user dependent factors that may impact the 199 measurement results 201 An end-user should be able to run a measurement process from an 202 appropriate client. A regulator may provide additional 203 complementary tests as part of a larger suite of testing. Both 204 panel based and crowdsource solutions could be considered. It is 205 possible to use both active and passive measurements to fulfil the 206 regulatory requirements. 208 The solutions should be based on a minimum measurement time and data 209 volume in order to ensure the validity of the measurements while 210 taking care to avoid the possibility of harmful effect on end-user's 211 Internet consumption. 213 3.1. Monitoring the performance of internet access services 215 This use case is used to measure speed and other relevant internet 216 access service (IAS) quality of service (QoS) parameters (e.g. 217 delay, jitter and packet loss) for the IAS as a whole. It enables 218 end-users to check their individual internet access speed and 219 whether the IAS performance meets what has been specified in the 220 contract. This has traditionally been the main motivation for end- 221 users to use the tool provided by regulators. 223 Regulators may also run these measurements independently of any net 224 neutrality assessment and use this information for multiple purposes 225 such as increasing transparency in service provisioning (e.g. 226 coverage maps) and monitoring the overall IAS quality, which may be 227 aimed at: 229 - Ascertaining whether (or not) specialised services are 230 provided at the expense of IAS, and/or 232 - Determining whether IAS performance is evolving in tandem 233 with advances in technology. 235 The European open internet regulation [1] states that an end- 236 user may use a monitoring mechanism certified by the regulator to 237 check that the performance meets what has been specified in the 238 contract. This measurement information can be used for triggering 239 the remedies available to the consumer in accordance with national 240 law. 242 BEREC guidelines [2] defines further that the certified 243 monitoring mechanism should mitigate, to the extent possible, 244 confounding factors which are internal to the user environment. 245 Examples of these factors include existing cross-traffic and the 246 usage of wireless/wireline interfaces. 248 According to BEREC guidelines speed should be calculated based on IP 249 packet payload. Measurements should also be performed beyond the 250 internet service provider (ISP) leg. 252 According to the Regulation ISPs must specify the minimum, normally 253 available, maximum and advertised download and upload speed in their 254 fixed network contracts. For mobile network subscriptions ISPs must 255 specify estimated maximum and advertised download and upload speeds. 257 According to the recitals of the Regulation the normally available 258 speed is understood to be the speed that an end-user could expect to 259 receive most of the time when accessing the service. BEREC has 260 given further guidance that the speed should be available during the 261 specified daily period. For example a regulator may set a 262 requirement that the normally available speed should be available 263 during off-peak hours and 90% of time over peak hours, or 95% over 264 the whole day. 266 Other factors that require special attention are how the minimum and 267 maximum speed should be measured. According to BEREC guidelines the 269 - maximum speed is the speed that an end-user could expect to 270 receive at least some of the time (e.g. at least once a day). 271 - minimum speed is the lowest speed that the ISP undertakes to 272 deliver to the end-user. In principle, the actual speed should 273 not be lower than the minimum speed, except in cases of 274 interruption of the IAS. 276 Number and distribution of measurement tasks should be defined so 277 that the adequate confidence level such as 95% is achieved. 279 3.2. Detecting traffic management practices that impact the 280 availability of individual applications 282 The goal of this use case is to detect traffic management practices 283 that affect the connectivity and availability of content, 284 applications and services. Examples of this kind of practices may 285 include blocking communication ports, VoIP and P2P file sharing 286 applications in addition to other web content like streaming 287 services, network based parental control and ad-blocking. 289 Internet service providers may use several different traffic 290 management practices that block the connectivity to content, 291 applications and services. Examples of these traffic management 292 practices include: - Blocked communication ports 294 - IP addresses blocking 295 - DNS manipulation and HTTP proxy blocking 296 - Content or application based blocking with deep packet 297 inspection 299 The challenge is to define specific measurement tasks that allow 300 regulators to detect any blocked applications. A solution should 301 minimise the probability of false positives. In principle, the 302 solution is to comprise of measurement metric(s) and respective 303 measurement methodology(s); as well as quantification of the 304 probability of false positives. 306 3.3. Detecting traffic management practices that impact the quality of 307 service for individual applications 309 The goal of this use case is to detect possible unequal treatment of 310 traffic namely prioritisation and/or throttling of applications. 312 These traffic management practices may be detected by measuring the 313 QoS experienced by the application and comparing the results with 314 the QoS measurement results for the same IAS subscriptions and with 315 the similar application specific QoS measurement results from other 316 users and ISPs. Other techniques may also be possible. 318 A solution is required that correctly identifies whether 319 prioritisation and/or throttling of applications is taking place, 320 with minimum probability of false positives. In principle, the 321 solution is to comprise of measurement metric(s) and respective 322 measurement methodology(s); as well as quantification of the 323 probability of false positives. 325 For this case, in particular, regulator may need to conduct 326 additional complementary measurement tasks as part of a larger suite 327 of testing, in order to eliminate any false positives. 329 3.4. Detecting end-user dependent factors that may impact the 330 measurement results 332 Especially when measurements are run by an end-user in a 333 crowdsourcing measurement setup, the local environment specific 334 factors like cross-traffic, interface type (fixed/wireless), 335 firewalls, processor load, client operating system and hardware can 336 influence the measurement result. 338 It is preferred that the measurement client should capture this 339 additional data of the end user local environment. This environment 340 data can then be used in assessing the validity of the measurement 341 results with the aim of improving overall accuracy and minimising 342 false positives. 344 In principle, the solution is to comprise of measurement metric(s) 345 and respective measurement methodology(s), and how this environment 346 data can be used to ascertain measurement reliability in each use 347 case. 349 4. Security Considerations 351 This document defines a use case and problem statement for net 352 neutrality measurements. Security considerations for specific 353 measurements will be discussed in solution documents. 355 5. IANA Considerations 357 This document includes no requests to the IANA. 359 6. References 361 6.1. Informative References 363 [1] Regulation (EU) 2015/2120 of the European Parliament and 364 of the Council of 25 November 2015 laying down measures 365 concerning open internet access and amending Directive 366 2002/22/EC on universal service and users' rights 367 relating to electronic communications networks and 368 services and Regulation (EU) No 531/2012 on roaming on 369 public mobile communications networks within the Union, 370 November 2015, . 373 [2] BEREC Guidelines on the Implementation by National 374 Regulators of European Net Neutrality Rules, August 2016, 375 . 380 [3] Linsner, M., Eardley, P., Burbridge, T. and Sorensen, F., 381 "Large-Scale Broadband Measurement Use Cases", RFC 7536, 382 May 2015, . 384 7. Acknowledgements 386 The author wish to thank Ahmed Aldabbagh, Mick Fox, Jose Hernan, 387 Frode Sorensen and Volker Sypli for their invaluable comments and 388 contributions. 390 This document was prepared using 2-Word-v2.0.template.dot. 392 Author's Address 394 Klaus Nieminen 395 FICORA 396 Itamerenkatu 3 A, P.O Box 313 397 Finland 399 Email: klaus.nieminen@ficora.fi