idnits 2.17.00 (12 Aug 2021) /tmp/idnits56066/draft-ietf-lmap-use-cases-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 24, 2014) is 3038 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Marc Linsner 3 Intended Status: Informational Cisco Systems 4 Expires: July 28, 2014 Philip Eardley 5 Trevor Burbridge 6 BT 7 Frode Sorensen 8 NPT 9 January 24, 2014 11 Large-Scale Broadband Measurement Use Cases 12 draft-ietf-lmap-use-cases-02 14 Abstract 16 Measuring broadband performance on a large scale is important for 17 network diagnostics by providers and users, as well as for public 18 policy. To conduct such measurements, user networks gather data 19 instructed by a measurement controller, and then upload the 20 measurement results to a designated measurement server. Understanding 21 the various scenarios and users of measuring broadband performance is 22 essential to development of the framework, information model and 23 protocol. The details of the measurement metrics themselves are 24 beyond the scope of this document. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1 Internet Service Provider (ISP) Use Case . . . . . . . . . . 3 68 2.2 Regulators . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3 Implementation options . . . . . . . . . . . . . . . . . . . 5 70 3 Details of ISP Use Case . . . . . . . . . . . . . . . . . . . . 7 71 3.1 Understanding the quality experienced by customers . . . . . 7 72 3.2 Understanding the impact and operation of new devices and 73 technology . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3 Design and planning . . . . . . . . . . . . . . . . . . . . 8 75 3.4 Identifying, isolating and fixing network problems . . . . . 9 76 4 Details of Regulator Use Case . . . . . . . . . . . . . . . . . 10 77 4.1 Promoting competition through transparency . . . . . . . . . 10 78 4.2 Promoting broadband deployment . . . . . . . . . . . . . . . 11 79 4.3 Monitoring "net neutrality" . . . . . . . . . . . . . . . . 12 80 5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 82 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 83 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 Normative References . . . . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1 Introduction 89 This document describes some use cases for the Large-scale 90 Measurement of Broadband Performance (LMAP), in particular use cases 91 for ISPs and regulators. 93 1.1 Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2 Use Cases 101 The LMAP architecture utilizes metrics for instructions on how to 102 execute a particular measurement. Although layer 2 specific metrics 103 can and will be defined, from the LMAP perspective, there is no 104 difference between fixed service and mobile (cellular) service used 105 for Internet access. Hence, like measurements will take place on 106 both fixed and mobile networks. Fixed services, commonly known as 107 "Last Mile" include technologies like DSL, Cable, and Carrier 108 Ethernet. Mobile services include all those advertised as 2G, 3G, 109 4G, and LTE. A metric defined to measure over-the-top services will 110 execute similarly on all layer 2 technologies. The LMAP architecture 111 covers networks utilizing both IPv4 and IPv6. 113 2.1 Internet Service Provider (ISP) Use Case 115 An ISP, or indeed another network operator, needs to understand the 116 performance of their networks, the performance of the suppliers 117 (downstream and upstream networks), the performance of services, and 118 the impact that such performance has on the experience of their 119 customers. In addition they may also desire visibility of their 120 competitor's networks and services in order to be able to benchmark 121 and improve their own offerings. Largely the processes that ISPs 122 operate (which are based on network measurement) include: 124 o Identifying, isolating and fixing problems in the network, 125 services or with CPE and end user equipment. Such problems may be 126 common to a point in the network topology (e.g. a single 127 exchange), common to a vendor or equipment type (e.g. line card or 128 home gateway) or unique to a single user line (e.g. copper 129 access). Part of this process may also be helping users understand 130 whether the problem exists in their home network or with an over- 131 the-top service instead of with their BB product. 133 o Design and planning. Through identifying the end user experience 134 the ISP can design and plan their network to ensure specified 135 levels of user experience. Services may be moved closer to end 136 users, services upgraded, the impact of QoS assessed or more 137 capacity deployed at certain locations. SLAs may be defined at 138 network or product boundaries. 140 o Understanding the quality experienced by customers. Alongside 141 benchmarking competitors, gaining better insight into the user's 142 service through a sample panel of the operator's own customers. 143 The end-to-end perspective matters, across home /enterprise 144 networks, peering points, CDNs etc. 146 o Understanding the impact and operation of new devices and 147 technology. As a new product is deployed, or a new technology 148 introduced into the network, it is essential that its operation 149 and impact on other services is measured. This also helps to 150 quantify the advantage that the new technology is bringing and 151 support the business case for larger roll-out. 153 2.2 Regulators 155 Regulators in jurisdictions around the world are responding to 156 consumers' adoption of Internet access services for traditional 157 telecommunications and media services by promoting competition among 158 providers of electronic communications, to ensure that users derive 159 maximum benefit in terms of choice, price, and quality. 161 Some jurisdictions have responded to a need for greater information 162 about Internet access service performance in the development of 163 regulatory policies and approaches for broadband technologies by 164 developing large-scale measurement programs. Programs such as the 165 U.S. Federal Communications Commission's Measuring Broadband America, 166 European Commission's Quality of Broadband Services in the EU reports 167 and a growing list of other programs employ a diverse set of 168 operational and technical approaches to gathering data to perform 169 analysis and reporting on diverse aspects of broadband performance. 171 While each jurisdiction responds to distinct consumer, industry, and 172 regulatory concerns, much commonality exists in the need to produce 173 datasets that are able to compare multiple Internet access service 174 providers, diverse technical solutions, geographic and regional 175 distributions, and marketed and provisioned levels and combinations 176 of broadband Internet access services. In some jurisdictions, the 177 role of measuring is provided by a measurement provider. 179 Measurement providers measure network performance from users towards 180 multiple content and application providers, included dedicated test 181 measurement servers, to show a performance of the actual Internet 182 access service provided by different ISPs. Users need to know the 183 performance that are achieving from their own ISP. In addition, they 184 need to know the performance of other ISPs of same location as 185 background information for selecting their ISP. Measurement providers 186 will provide measurement results with associated measurement methods 187 and measurement metrics. 189 From a consumer perspective, the differentiation between fixed and 190 mobile (cellular) Internet access services is blurring as the 191 applications used are very similar. Hence, regulators are measuring 192 both fixed and mobile Internet access services. 194 Regulators role in the development and enforcement of broadband 195 Internet access service policies also require that the measurement 196 approaches meet a high level of verifiability, accuracy and provider- 197 independence to support valid and meaningful comparisons of Internet 198 access service performance 200 LMAP standards could answer regulators shared needs by providing 201 scalable, cost-effective, scientifically robust solutions to the 202 measurement and collection of broadband Internet access service 203 performance information. 205 2.3 Implementation options 207 There are several ways of implementing a measurement system. The 208 choice may be influenced by the details of the particular use case 209 and what the most important criteria are for the regulator, ISP or 210 third party operating the measurement system. 212 One way involves a special hardware device that is connected directly 213 to the home gateway. The devices are deployed to a carefully selected 214 panel of end users and they perform measurements according to a 215 defined schedule. The schedule can run throughout the day, to allow 216 continuous assessment of the network. Careful design ensures that 217 measurements do not detrimentally impact the home user experience or 218 corrupt the results by testing when the user is also using the 219 broadband line. The system is therefore tightly controlled by the 220 operator of the measurement system. One advantage of this approach is 221 that it is possible to get reliable benchmarks for the performance of 222 a network with only a few devices. One disadvantage is that it would 223 be expensive to deploy hardware devices on a mass scale sufficient to 224 understand the performance of the network at the granularity of a 225 single broadband user. 227 Another approach involves implementing the measurement capability as 228 a webpage or an "app" that end users are encouraged to download onto 229 their mobile phone or computing device. Measurements are triggered by 230 the end user, for example the user interface may have a button to 231 "test my broadband now". Compared with the previous approach, the 232 system is much more loosely controlled, as the panel of end users and 233 the schedule of tests are determined by the end users themselves 234 rather than the measurement system. It would be easier to get large- 235 scale, however it is harder to get comparable benchmarks as the 236 measurements are affected by the home network and also the population 237 is self-selecting and so potentially biased towards those who think 238 they have a problem. This could be alleviated by stimulating 239 widespread downloading of the app and careful post-processing of the 240 results to reduce biases. 242 There are several other possibilities. For example, as a variant on 243 the first approach, the measurement capability could be implemented 244 as software embedded in the home gateway, which would make it more 245 viable to have the capability on every user line. As a variant on the 246 second approach, the end user could initiate measurements in response 247 to a request from the measurement system. 249 3 Details of ISP Use Case 251 3.1 Understanding the quality experienced by customers 253 Operators want to understand the quality of experience (QoE) of their 254 broadband customers. The understanding can be gained through a 255 "panel", i.e., a measurement probe is deployed to a few 100 or 1000 256 of its customers. The panel needs to be a representative sample for 257 each of the operator's technologies (FTTP, FTTC, ADSL...) and 258 broadband options (80Mb/s, 20Mb/s, basic...), ~100 probes for each. 259 The operator would like the end-to-end view of the service, rather 260 than (say) just the access portion. So as well as simple network 261 statistics like speed and loss rates they want to understand what the 262 service feels like to the customer. This involves relating the pure 263 network parameters to something like a 'mean opinion score' which 264 will be service dependent (for instance web browsing QoE is largely 265 determined by latency above a few Mb/s). 267 An operator will also want compound metrics such as "reliability", 268 which might involve packet loss, DNS failures, re-training of the 269 line, video streaming under-runs etc. 271 The operator really wants to understand the end-to-end service 272 experience. However, the home network (Ethernet, wifi, powerline) is 273 highly variable and outside its control. To date, operators (and 274 regulators) have instead measured performance from the home gateway. 275 However, mobile operators clearly must include the wireless link in 276 the measurement. 278 Active measurements are the most obvious approach, i.e., special 279 measurement traffic is sent by - and to - the probe. In order not to 280 degrade the service of the customer, the measurement data should only 281 be sent when the user is silent, and it shouldn't reduce the 282 customer's data allowance. The other approach is passive measurements 283 on the customer's ordinary traffic; the advantage is that it measures 284 what the customer actually does, but it creates extra variability 285 (different traffic mixes give different results) and especially it 286 raises privacy concerns. 288 From an operator's viewpoint, understanding customers better enables 289 it to offer better services. Also, simple metrics can be more easily 290 understood by senior managers who make investment decisions and by 291 sales and marketing. 293 3.2 Understanding the impact and operation of new devices and technology 295 Another type of measurement is to test new capabilities and services 296 before they are rolled out. For example, the operator may want to: 298 check whether a customer can be upgraded to a new broadband option; 299 understand the impact of IPv6 before it makes it available to its 300 customers (will v6 packets get through, what will the latency be to 301 major websites, what transition mechanisms will be most is 302 appropriate?); check whether a new capability can be signaled using 303 TCP options (how often it will be blocked by a middlebox? - along the 304 lines of some existing experiments) [Extend TCP]; investigate a 305 quality of service mechanism (eg checking whether Diffserv markings 306 are respected on some path); and so on. 308 3.3 Design and planning 310 Operators can use large scale measurements to help with their network 311 planning - proactive activities to improve the network. 313 For example, by probing from several different vantage points the 314 operator can see that a particular group of customers has performance 315 below that expected during peak hours, which should help capacity 316 planning. Naturally operators already have tools to help this - a 317 network element reports its individual utilisation (and perhaps other 318 parameters). However, making measurements across a path rather than 319 at a point may make it easier to understand the network. There may 320 also be parameters like bufferbloat that aren't currently reported by 321 equipment and/or that are intrinsically path metrics. 323 With better information, capacity planning and network design can be 324 more effective. Such planning typically uses simulations to emulate 325 the measured performance of the current network and understand the 326 likely impact of new capacity and potential changes to the topology. 327 It may also be possible to run stress tests for risk analysis, for 328 example 'if whizzy new application (or device) becomes popular, which 329 parts of my network would struggle, what would be the impact on other 330 services and how many customers would be affected'. What-if 331 simulations could help quantify the advantage that a new technology 332 brings and support the business case for larger roll-out. This 333 approach should allow good results with measurements from a limited 334 panel of customers. 336 Another example is that the operator may want to monitor performance 337 where there is a service level agreement. This could be with its own 338 customers, especially enterprises may have an SLA. The operator can 339 proactively spot when the service is degrading near to the SLA limit, 340 and get information that will enable more informed conversations with 341 the customer at contract renewal. 343 An operator may also want to monitor the performance of its 344 suppliers, to check whether they meet their SLA or to compare two 345 suppliers if it is dual-sourcing. This could include its transit 346 operator, CDNs, peering, video source, local network provider (for a 347 global operator in countries where it doesn't have its own network), 348 even the whole network for a virtual operator. 350 Through a better understanding of its own network and its suppliers, 351 the operator should be able to focus investment more effectively - in 352 the right place at the right time with the right technology. 354 3.4 Identifying, isolating and fixing network problems 356 Operators can use large scale measurements to help identify a fault 357 more rapidly and decide how to solve it. 359 Operators already have Test and Diagnostic tools, where a network 360 element reports some problem or failure to a management system. 361 However, many issues are not caused by a point failure but something 362 wider and so will trigger too many alarms, whilst other issues will 363 cause degradation rather than failure and so not trigger any alarm. 364 Large scale measurements can help provide a more nuanced view that 365 helps network management to identify and fix problems more rapidly 366 and accurately. The network management tools may use simulations to 367 emulate the network and so help identify a fault and assess possible 368 solutions. 370 One example was described in [IETF85-Plenary]. The operator was 371 running a measurement panel for reasons discussed in sub use case #1. 372 It was noticed that the performance of some lines had unexpectedly 373 degraded. This led to a detailed (off-line) investigation which 374 discovered that a particular home gateway upgrade had caused a 375 (mistaken!) drop in line rate. 377 Another example is that occasionally some internal network management 378 event (like re-routing) can be customer-affecting (of course this is 379 unusual). This affects a whole group of customers, for instance those 380 on the same DSLAM. Understanding this will help an operator fix the 381 fault more rapidly and/or allow the affected customers to be informed 382 what's happening and/or request them to re-set their home hub 383 (required to cure some conditions). More accurate information enables 384 the operator to reassure customers and take more rapid and effective 385 action to cure the problem. 387 There may also be problems unique to a single user line (e.g. copper 388 access) that need to be identified. 390 Often customers experience poor broadband due to problems in the home 391 network - the ISP's network is fine. For example they may have moved 392 too far away from their wireless access point. Perhaps 80% of 393 customer calls about fixed BB problems are due to in-home wireless 394 issues. These issues are expensive and frustrating for an operator, 395 as they are extremely hard to diagnose and solve. The operator would 396 like to narrow down whether the problem is in the home (with the home 397 network or edge device or home gateway), in the operator's network, 398 or with an over-the-top service. The operator would like two 399 capabilities. Firstly, self-help tools that customers use to improve 400 their own service or understand its performance better, for example 401 to re-position their devices for better wifi coverage. Secondly, on- 402 demand tests that can the operator can run instantly - so the call 403 centre person answering the phone (or e-chat) could trigger a test 404 and get the result whilst the customer is still on-line session. 406 4 Details of Regulator Use Case 408 4.1 Promoting competition through transparency 410 Competition plays a vital role in regulation of the electronic 411 communications markets. For competition to successfully discipline 412 operators' behavior in the interests of their customers, end users 413 must be fully aware of the characteristics of the ISPs' access 414 offers. In some jurisdictions regulators mandate transparent 415 information made available about service offers. 417 End users need effective transparency to be able to make informed 418 choices throughout the different stages of their relationship with 419 ISPs, when selecting Internet access service offers, and when 420 considering switching service offer within an ISP or to an 421 alternative ISP. Quality information about service offers could 422 include speed, delay, and jitter. Regulators can publish such 423 information to facilitate end users' choice of service provider and 424 offer. It may also help content, application, service and device 425 providers develop their Internet offerings. 427 The published information needs to be: 429 o Accurate - the measurement results must be correct and not 430 influenced by errors or side effects. The results should be 431 reproducible and consistent over time. 433 o Comparable - common metrics should be used across different 434 ISPs and service offerings so that measurement results can be 435 compared. 437 o Meaningful - the metrics used for measurements need to reflect 438 what end users value about their broadband Internet access service 440 o Reliable - the number and distribution of measurement agents, 441 and the statistical processing of the raw measurement raw data, 442 needs to be appropriate 444 A set of measurement parameters and associated measurement methods 445 are used over time, e.g. speed, delay, and jitter. Then the 446 measurement raw data are collected and go through statistical post- 447 processing before the results can be published in an Internet access 448 service quality index to facilitate end users' choice of service 449 provider and offer. 451 The regulator can also promote competition through transparency by 452 encouraging end users to monitor the performance of their own 453 broadband Internet access service. They might use this information to 454 check that the performance meets that specified in their contract or 455 to understand whether their current subscription is the most 456 appropriate. 458 4.2 Promoting broadband deployment 460 Governments sometimes set strategic goals for high-speed broadband 461 penetration as an important component of the economic, cultural and 462 social development of the society. To evaluate the effect of the 463 stimulated growth over time, broadband Internet access take-up and 464 penetration of high-speed access can be monitored through measurement 465 campaigns. 467 An example of such an initiative is the "Digital Agenda for Europe" 468 which was adopted in 2010, to achieve universal broadband access. The 469 goal is to achieve by 2020, access for all Europeans to Internet 470 access speeds of 30 Mbps or above, and 50% or more of European 471 households subscribing to Internet connections above 100 Mbps. 473 To monitor actual broadband Internet access performance in a specific 474 country or a region, extensive measurement campaigns are needed. A 475 panel can be built based on operators and packages in the market, 476 spread over urban, suburban and rural areas. Probes can then be 477 distributed to the participants of the campaign. 479 Periodic tests running on the probes can for example measure actual 480 speed at peak and off-peak hours, but also other detailed quality 481 metrics like delay and jitter. Collected data goes afterwards through 482 statistical analysis, deriving estimates for the whole population 483 which can then be presented and published regularly. 485 Using a harmonized or standardised measurement methodology, or even a 486 common quality measurement platform, measurement results could also 487 be used for benchmarking of providers and/or countries. 489 4.3 Monitoring "net neutrality" 491 Regulatory approaches related to net neutrality and the open Internet 492 has been introduced in some jurisdictions. Examples of such are the 493 Internet policy as outlined by the FCC Preserving the Open Internet 494 Report and Order [FCC R&O] and the Body of European Regulators for 495 Electronic Communications Guidelines for quality of service [BEREC 496 Guidelines]. The exact definitions and requirements vary from one 497 jurisdiction to another; the comments below provide some hints about 498 the potential role of measurements. 500 Net neutrality regulations do not necessarily require every packet to 501 be treated equally. Typically they allow "reasonable" traffic 502 management (for example if there is exceptional congestion) and allow 503 "specialized services" in parallel to, but separate from, ordinary 504 Internet access (for example for facilities-based IPTV). A regulator 505 may want to monitor such practices as input to the regulatory 506 evaluation. However, these concepts are evolving and differ across 507 jurisdictions, so measurement results should be assessed with 508 caution. 510 A regulator could monitor departures from application agnosticism 511 such as blocking or throttling of traffic from specific applications, 512 and preferential treatment of specific applications. A measurement 513 system could send, or passively monitor, application-specific traffic 514 and then measure in detail the transfer of the different packets. 515 Whilst it is relatively easy to measure port blocking, it is a 516 research topic how to detect other types of differentiated treatment. 517 The paper, "Glasnost: Enabling End Users to Detect Traffic 518 Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost" 519 [Glasnost] are examples of work in this area. 521 A regulator could also monitor the performance of the broadband 522 service over time, to try and detect if the specialized service is 523 provided at the expense of the Internet access service. Comparison 524 between ISPs or between different countries may also be relevant for 525 this kind of evaluation. 527 5 Conclusions 529 Large-scale measurements of broadband performance are useful for both 530 network operators and regulators. Network operators would like to use 531 measurements to help them better understand the quality experienced 532 by their customers, identify problems in the network and design 533 network improvements. Regulators would like to use measurements to 534 help promote competition between network operators, stimulate the 535 growth of broadband access and monitor 'net neutrality'. There are 536 other use cases that are not the focus of the initial LMAP charter 537 (although it is expected that the mechanisms developed would be 538 readily applied), for example end users would like to use 539 measurements to help identify problems in their home network and to 540 monitor the performance of their broadband provider. 542 From consideration of the various use cases, several common themes 543 emerge whilst there are also some detailed differences. These 544 characteristics guide the development of LMAP's framework, 545 information model and protocol. 547 A measurement capability is needed across a wide number of 548 heterogeneous environments. Tests may be needed in the home network, 549 in the ISP's network or beyond; they may be measuring a fixed or 550 wireless network; they measure just the access network or across 551 several networks, at least some of which are not operated by the 552 measurement provider. 554 There is a role for both standardized and non-standardized 555 measurements. For example, a regulator would like to publish 556 standardized performance metrics for all network operators, whilst an 557 ISP may need their own tests to understand some feature special to 558 their network. Most use cases need active measurements, which create 559 and measure specific test traffic, but some need passive measurements 560 of the end user's traffic. 562 Regardless of the tests being operated, there needs to be a way to 563 demand or schedule the tests. Most use cases need a regular schedule 564 of measurements, but sometimes ad hoc testing is needed, for example 565 for troubleshooting. It needs to be ensured that measurements do not 566 affect the user experience and are not affected by user traffic 567 (unless desired). In addition there needs to be a common way to 568 collect the results. Standardization of this control and reporting 569 functionality allows the operator of a measurement system to buy the 570 various components from different vendors. 572 After the measurements results are collected, they need to be 573 understood and analyzed. Often it is sufficient to measure only a 574 small subset of end users, but per-line fault diagnosis requires the 575 ability to test every individual line. Analysis requires accurate 576 definition and understanding of where the test points are, as well as 577 contextual information about the topology, line, product and the 578 subscriber's contract. The actual analysis of results is beyond the 579 scope of LMAP, as is the key challenge of how to integrate the 580 measurement system into a network operator's existing tools for 581 diagnostics and network planning. 583 Finally the test data, along with any associated network, product or 584 subscriber contract data is commercial or private information and 585 needs to be protected. 587 6 Security Considerations 589 This informational document provides an overview of the use cases for 590 LMAP and so does not, in itself, raise any security issues. 592 The framework document [framework] discusses the potential security, 593 privacy (data protection) and business sensitivity issues that LMAP 594 raises. The main threats are: 596 1. a malicious party that gains control of Measurement Agents to 597 launch DoS attacks at a target, or to alter (perhaps subtly) 598 Measurement Tasks in order to compromise the end user's privacy, 599 the business confidentiality of the network, or the accuracy of 600 the measurement system. 602 2. a malicious party that intercepts or corrupts the Measurement 603 Results &/or other information about the Subscriber, for similar 604 nefarious purposes. 606 3. a malicious party that uses fingerprinting techniques to 607 identify individual end users, even from anonymized data 609 4. a measurement system that does not obtain the end user's 610 informed consent, or fails to specify a specific purpose in the 611 consent, or uses the collected information for secondary uses 612 beyond those specified. 614 5. a measurement system that is vague about who is the "data 615 controller": the party legally responsible for privacy (data 616 protection). 618 The [framework] also considers some potential mitigations of these 619 issues. They will need to be considered by an LMAP protocol and 620 more generally by any measurement system. 622 7 IANA Considerations 624 None 626 Contributors 628 The information in this document is partially derived from text 629 written by the following contributors: 631 James Miller jamesmilleresquire@gmail.com 633 Rachel Huang rachel.huang@huawei.com 635 Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 [IETF85-Plenary] Crawford, S., "Large-Scale Active Measurement of 641 Broadband Networks", 642 http://www.ietf.org/proceedings/85/slides/slides-85-iesg- 643 opsandtech-7.pdf 'example' from slide 18 645 [Extend TCP] Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam 646 Greenhalgh, Mark Handley and Hideyuki Tokuda. "Is it Still 647 Possible to Extend TCP?" Proc. ACM Internet Measurement 648 Conference (IMC), November 2011, Berlin, Germany. 649 http://www.ietf.org/proceedings/82/slides/IRTF-1.pdf 651 [framework] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 652 Aitken, P., Akhter, A. "A framework for large-scale 653 measurement platforms (LMAP)", 654 http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ 656 [FCC R&O] United States Federal Communications Commission, 10-201, 657 "Preserving the Open Internet, Broadband Industries 658 Practices, Report and Order", 659 http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10- 660 201A1.pdf 662 [BEREC Guidelines] Body of European Regulators for Electronic 663 Communications, "BEREC Guidelines for quality of service 664 in the scope of net neutrality", 665 http://berec.europa.eu/eng/document_register/ 666 subject_matter/berec/download/0/1101-berec-guidelines-for- 667 quality-of-service-_0.pdf 669 [M-Labs NSDI 2010] M-Lab, "Glasnost: Enabling End Users to Detect 670 Traffic Differentiation", 671 http://www.measurementlab.net/download/AMIfv945ljiJXzG- 672 fgUrZSTu2hs1xRl5Oh-rpGQMWL305BNQh- 673 BSq5oBoYU4a7zqXOvrztpJhK9gwk5unOe-fOzj4X-vOQz_HRrnYU- 674 aFd0rv332RDReRfOYkJuagysstN3GZ__lQHTS8_UHJTWkrwyqIUjffVeDxQ/ 676 [Glasnost] M-Lab tool "Glasnost", http://mlab-live.appspot.com/tools/ 677 glasnost 679 Authors' Addresses 681 Marc Linsner 682 Cisco Systems, Inc. 683 Marco Island, FL 684 USA 686 EMail: mlinsner@cisco.com 688 Philip Eardley 689 BT 690 B54 Room 77, Adastral Park, Martlesham 691 Ipswich, IP5 3RE 692 UK 694 Email: philip.eardley@bt.com 696 Trevor Burbridge 697 BT 698 B54 Room 77, Adastral Park, Martlesham 699 Ipswich, IP5 3RE 700 UK 702 Email: trevor.burbridge@bt.com 704 Frode Sorensen 705 Norwegian Post and Telecommunications Authority (NPT) 706 Lillesand 707 Norway 709 Email: frode.sorensen@npt.no