RFC 7536

Large-Scale Broadband Measurement Use Cases

📅 published May 2015, from ietf

Title Block 🎀

Okay bestie, here's the ID card for RFC 7536 🪪✨ It's called Large-Scale Broadband Measurement Use Cases, and it came out in May 2015. The authors are M. Linsner (Cisco Systems), P. Eardley (BT), T. Burbridge (BT), and F. Sorensen (Nkom). It's in the Informational category, with ISSN 2070-1721, and the header doesn't list anything it obsoletes or updates 💅

Abstract 🌸

Measuring broadband performance at scale is a big deal for network diagnostics, whether it's providers or users doing the checking, and it matters for public policy too 📊 Knowing the different scenarios and the different people who measure broadband is essential for building the Large-scale Measurement of Broadband Performance (LMAP) framework, its information model, and its protocol 🧠 This doc walks through two use cases that can help shape that framework 🦋 The details of the measurement metrics themselves are out of scope here, so don't go looking for those in this one 🙈

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes only 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story 🧐

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7536 🔗

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶

Table of Contents 🗺️

1. Introduction ....................................................3
2. Use Cases .......................................................3
   2.1. Internet Service Provider (ISP) Use Case ...................3
   2.2. Regulator Use Case .........................................4
3. Details of ISP Use Case .........................................5
   3.1. Understanding the Quality Experienced by Customers .........5
   3.2. Understanding the Impact and Operation of New Devices
        and Technology .............................................6
   3.3. Design and Planning ........................................6
   3.4. Monitoring Service Level Agreements ........................7
   3.5. Identifying, Isolating, and Fixing Network Problems ........7
4. Details of Regulator Use Case ...................................8
   4.1. Providing Transparent Performance Information ..............8
   4.2. Measuring Broadband Deployment .............................9
   4.3. Monitoring Traffic Management Practices ...................10
5. Implementation Options .........................................10
6. Conclusions ....................................................12
7. Security Considerations ........................................13
8. Informative References .........................................15
Contributors ......................................................17
Authors' Addresses ................................................17

1. Introduction ✨

Okay so this document describes two use cases for the Large-scale Measurement of Broadband Performance (LMAP) 🦋 The first is the Internet Service Provider Use Case, and the second is the Regulator Use Case 💅 In the first, a network operator wants to understand how its network performs and what quality customers are actually experiencing. In the second, a regulator wants to publish information about how the ISPs in its jurisdiction are doing 📊

There are other use cases that aren't the main focus of the initial LMAP work. For example, end users would love to use measurements to figure out problems in their home network and keep an eye on their broadband provider 👀 The expectation is that the same mechanisms work for those too 🌸

Large-scale measurements bring along several security concerns, including privacy issues 🔐 Section 7 gives you the summary, and [Framework] goes way deeper into them 🧠

2. Use Cases 💖

From the LMAP perspective, there's no difference between fixed service and mobile (cellular) service used for Internet access. So like measurements will happen on both fixed and mobile networks 🌐 Fixed services include technologies like Digital Subscriber Line (DSL), Cable, and Carrier Ethernet. Mobile services include everything advertised as 2G, 3G, 4G, and Long Term Evolution (LTE) 📱

A metric designed to measure end-to-end services will run similarly on all access technologies, while other metrics may be specific to one access technology 🧚 And the LMAP architecture covers both IPv4 and IPv6 networks, so no one gets left out 🌈

2.1. Internet Service Provider (ISP) Use Case 🏢

A network operator needs to understand how its own networks perform, how its suppliers perform (the downstream and upstream networks), how Internet access services perform, and how all of that affects what its customers experience 😭 Mostly, the processes ISPs run (which are built on network measurement) include:

  • Identifying, isolating, and fixing problems. These might sit in the network, with the service provider, or in the end-user equipment 🔧 Such problems might be common to one point in the network topology (e.g., a single exchange), common to one vendor or equipment type (e.g., line card or home gateway), or unique to a single user line (e.g., copper access). Part of this process can also be helping users figure out whether the problem is in their home network or with a third-party application service, rather than with their broadband (BB) product 🫠
  • Design and planning. By monitoring the end-user experience, the ISP can design and plan its network to make sure specified levels of user experience are met 🗺️ Services might get moved closer to end users, services might get upgraded, the impact of QoS might get assessed, or more capacity might get deployed at certain locations. Service Level Agreements (SLAs) may be defined at network or product boundaries 📐
  • Understanding the quality experienced by customers. The network operator wants better insight into the end-to-end performance its customers get 👑 "End-to-end" could, for instance, cover home and enterprise networks, plus the impact of peering, caching, and Content Delivery Networks (CDNs) 🌍
  • Understanding the impact and operation of new devices and technology. When a new product rolls out, or a new technology gets introduced into the network, its operation and impact need to be measured 🚀 This also helps quantify how much advantage the new tech is bringing, and it supports the business case for a bigger roll-out 💰

2.2. Regulator Use Case 🏛️

A regulator may want to evaluate the performance of the Internet access services offered by operators 🔍

Every jurisdiction responds to its own consumer, industry, and regulatory concerns, but there's a lot of common ground in needing datasets that can compare multiple Internet access service providers, diverse technical solutions, geographic and regional distributions, and the marketed and provisioned levels and combinations of broadband Internet access services 📊✨

Regulators may want to publish performance measures for different ISPs as background info for end users 🫶 They may also want to track how high-speed broadband deployment is growing, or keep an eye on the traffic management practices of Internet providers 👀

A regulator's role in developing and enforcing broadband Internet access service policies means the measurement approaches need a high level of verifiability, accuracy, and provider-independence. That's what makes comparisons of Internet access service performance valid and meaningful 💅 Standards can help with regulators' shared needs for measurement and collection of broadband Internet access service performance information that's scalable, cost-effective, and scientifically robust 🧪💖

3.2. Understanding the Impact and Operation of New Devices and Technology ✨

Okay so another kind of measurement is testing new stuff before it gets rolled out 🧚. For example, the operator may want to:

  • Check whether a customer can be upgraded to a new broadband option. 💖
  • Understand the impact of IPv6 before it is made available to customers. Questions like these could be assessed: Will v6 packets get through? What will the latency be to major websites? What transition mechanisms will be most appropriate? 🌈
  • Check whether a new capability can be signaled using TCP options (how often it will be blocked by a middlebox -- along the lines of the experiments described in [Extend-TCP]). 🎀
  • Investigate a QoS mechanism (e.g., checking whether Diffserv markings are respected on some path). 💅

3.3. Design and Planning 🗺️

Operators can use large-scale measurements to help with their network planning, which is basically being proactive about making the network better 🌸.

For example, by probing from several different vantage points, the operator can see that a particular group of customers has performance below what's expected during peak hours. That should help with capacity planning 📊. Naturally, operators already have tools for this, since a network element reports its individual utilization (and perhaps other parameters) 🙈. However, making measurements across a path rather than at a point may make it easier to understand the network. There may also be parameters like bufferbloat that aren't currently reported by equipment and/or that are intrinsically path metrics 🫶.

With information gained from measurement results, capacity planning and network design can be more effective ✨. Such planning typically uses simulations to emulate the measured performance of the current network and understand the likely impact of new capacity and potential changes to the topology. Simulations, informed by data from a limited panel of probes, can help quantify the advantage that a new technology brings and support the business case for a larger roll-out 💜.

It may also be possible to use probes to run stress tests for risk analysis. For example, an operator could run a carefully controlled and limited experiment in which probing is used to assess the potential impact if some new application becomes popular 😭.

3.4. Monitoring Service Level Agreements 📝

Another example is that the operator may want to monitor performance where there is a Service Level Agreement (SLA). This could be with its own customers; in particular, enterprises may have an SLA. The operator can proactively spot when the service is degrading near the point of the SLA limit, and get information that will enable more informed conversations with the customer at contract renewal 👑.

An operator may also want to monitor the performance of its suppliers, to check whether they meet their SLA or to compare two suppliers if it is dual-sourcing. This could include its transit operator, CDNs, peering, video source, or local network provider for a global operator in countries where it doesn't have its own network. A virtual operator may monitor the whole underlying network 🧠.

Through a better understanding of its own network and its suppliers, the operator should be able to focus investment more effectively, in the right place at the right time with the right technology 🍓.

3.5. Identifying, Isolating, and Fixing Network Problems 🔧

Operators can use large-scale measurements to help identify a fault more rapidly and decide how to solve it 🕵️‍♀️.

Operators already have Test and Diagnostic tools, where a network element reports some problem or failure to a management system. However, many issues are not caused by a point failure but by something wider, so they will trigger too many alarms. Other issues will cause degradation rather than failure, so they won't trigger any alarm at all 🙃. Large-scale measurements can help provide a more nuanced view that helps network management identify and fix problems more rapidly and accurately. The network management tools may use simulations to emulate the network and so help identify a fault and assess possible solutions 🦋.

An operator can obtain useful information without measuring the performance on every broadband line. By measuring a subset, the operator can identify problems that affect a group of customers. For example, the issue could be at a shared point in the network topology (such as an exchange), or common to a vendor or equipment type. For instance, [IETF85-Plenary] describes a case where a particular home gateway upgrade had caused a (mistaken!) drop in line rate 😂.

A more extensive deployment of the measurement capability to every broadband line would enable an operator to identify issues unique to a single customer. Overall, large-scale measurements can help an operator fix the fault more rapidly and/or allow the affected customers to be informed of what's happening. More accurate information enables the operator to reassure customers and take more rapid and effective action to cure the problem 💖.

Often, customers experience poor broadband due to problems in the home network, and the ISP's network is fine. For example, they may have moved too far away from their wireless access point 📶. Anecdotally, a large fraction of customer calls about fixed BB problems are due to in-home wireless issues. These issues are expensive and frustrating for an operator, as they are extremely hard to diagnose and solve 😩. The operator would like to narrow down whether the problem is in the home (a problem with the home network, edge device, or home gateway), in the operator's network, or with an application service.

The operator would like two capabilities. Firstly, self-help tools that customers use to improve their own service or understand its performance better, for example, to reposition their devices for better Wi-Fi coverage 🛜. Secondly, on-demand tests that the operator can run instantly, so that the call center person answering the phone (or e-chat) could trigger a test and get the result while the customer is still in an online session 📞.

4. Details of Regulator Use Case 🏛️✨

4.1. Providing Transparent Performance Information 🔍

Some regulators publish information about the quality of the various Internet access services provided in their national market. Quality information about service offers could include speed, delay, and jitter. Such information can be published to facilitate end users' choice of service provider and offer. Regulators may check the accuracy of the marketing claims of Internet service providers, and may also encourage ISPs to all use the same metrics in their service level contracts. The goal of these transparency mechanisms is to promote competition for end users and potentially also help content, application, service, and device providers develop their Internet offerings 🌈.

The published information needs to be:

  • Accurate - the measurement results must be correct and not influenced by errors or side effects. The results should be reproducible and consistent over time. ✅
  • Comparable - common metrics should be used across different ISPs and service offerings, and over time, so that measurement results can be compared. ⚖️
  • Meaningful - the metrics used for measurements need to reflect what end users value about their broadband Internet access service. 💜
  • Reliable - the number and distribution of measurement agents, and the statistical processing of the raw measurement data, need to be appropriate. 🛡️

In practical terms, regulators may measure network performance from users towards multiple content and application providers, including dedicated test measurement servers. Measurement probes are distributed to a 'panel' of selected end users. The panel covers all the operators and packages in the market, spread over urban, suburban, and rural areas, and often includes both fixed and mobile Internet access 🗺️. Periodic tests running on the probes can, for example, measure actual speed at peak and off-peak hours, but can also measure other detailed quality metrics like delay and jitter ⏱️. Collected data goes afterwards through statistical analysis, deriving estimates for the whole population. Summary information, such as a service quality index, is published regularly, perhaps alongside more detailed information 📈.

The regulator can also help end users monitor the performance of their own broadband Internet access service. They might use this information to check that the performance meets what's specified in their contract, or to understand whether their current subscription is the most appropriate one 🧾.

4.2. Measuring Broadband Deployment 🚀

Regulators may also want to monitor the improvement over time of actual broadband Internet access performance in a specific country or a region. The motivation is often to evaluate the effect of the stimulated growth over time, when government has set a strategic goal for high-speed broadband deployment, whether in absolute terms or benchmarked against other countries. An example of such an initiative is [DAE]. The actual measurements can be made in the same way as described in Section 4.1 🌟.

4.3. Monitoring Traffic Management Practices 🚦

A regulator may want to monitor traffic management practices, or compare the performance of Internet access service with specialized services offered in parallel to, but separate from, Internet access service (for example, IPTV) 📺. A regulator could monitor for departures from application agnosticism, such as blocking or throttling of traffic from specific applications, or preferential treatment of specific applications. A measurement system could send, or passively monitor, application-specific traffic and then measure in detail the transfer of the different packets. While it is relatively easy to measure port blocking, how to detect other types of differentiated treatment is a research topic in itself 🔬. The "Glasnost: Enabling End Users to Detect Traffic Differentiation" paper [M-Labs_NSDI-2010] and follow-on tool "Glasnost" [Glasnost] provide an example of work in this area.

A regulator could also monitor the performance of the broadband service over time, to try and detect if the specialized service is provided at the expense of the Internet access service. Comparison between ISPs or between different countries may also be relevant for this kind of evaluation 👀.

The motivation for a regulator monitoring such traffic management practices is that regulatory approaches related to net neutrality and the open Internet have been introduced in some jurisdictions. Examples of such efforts are the Internet policy as outlined by the Body of European Regulators for Electronic Communications guidelines for quality of service [BEREC-Guidelines], and the US FCC's "Preserving the Open Internet" Report and Order [FCC-R&O]. Although legal challenges can change the status of policy, the take-away for LMAP purposes is that policy-makers are looking for measurement solutions to assist them in discovering biased treatment of traffic flows 🕊️. The exact definitions and requirements vary from one jurisdiction to another 🌍.

5. Implementation Options ✨

okay so there are a bunch of ways to build a measurement system, and which one you pick depends on the use case and what matters most to whoever is running it (a regulator, an ISP, or a third party) 🎀

First up, the probe is a special hardware device plugged straight into the home gateway 🔌 These get deployed to a carefully picked panel of end users, and they run measurements on a schedule. The schedule can run all day long so you get continuous monitoring 💖 The big thing is that the design has to make sure the tests don't wreck the home user's experience, and don't mess up the results by running while the user is also on the broadband line 🙈 Because of that, the operator of the measurement system keeps really tight control over it. The upside is you can get reliable benchmarks for a network with only a few devices 🔥 The downside is that putting hardware everywhere at mass scale would be super expensive, so understanding performance for each individual broadband user is a whole thing 💀

Second, the probe can be a webpage or an "app" that end users are encouraged to download onto their phone or computer 📱 Here the end user is the one who starts each test, like with a button that says "test my broadband now" 🦋 The big perk is that performance gets measured to the end user, not just the home gateway, so the home network is included in the picture 🌸 It's also way looser: the end users pick the panel and the schedule, not the measurement system. This makes large-scale measurement easier, but comparing benchmarks gets harder, because the home network is always in the mix 😭 And the population is self-selecting, so it could be biased toward people who already think they have a problem 🧚 This can be helped by encouraging lots of people to download the app and by doing careful post-processing of the results to cut down on bias ✨

There are a few other options too. As a variant of the first approach, the measurement capability could live as software built into the home gateway, which makes it way more practical to have on every user line 🍓 As a variant of the second approach, the end user could start measurements whenever the measurement system asks them to 👑

Now, the operator of the measurement system should be careful to make sure measurements don't hurt users, because there are some real risks here:

  • Measurement traffic on a particular user's line may affect that end user's quality of experience. This gets worse for tests that send a lot of traffic over a long period 😬
  • The measurement traffic may affect that user's bill or traffic cap 💸
  • Measurement traffic from several end users may, all together, congest a shared link 🚦
  • The traffic used to control and report measurements may overload the network. This is more of a problem when the traffic from lots of end users is synchronized 🫠

6. Conclusions 🌈

okay wrap-up time, and honestly this part is so important 💅 Large-scale measurements of broadband performance are useful for both network operators and regulators 🫶 Operators want measurements to help them understand the quality their customers experience, find problems in the network, and plan network improvements 🔧 Regulators want measurements to help promote competition between operators, grow broadband access, and keep an eye on 'net neutrality' 👀 There are other use cases that aren't the main focus of the initial LMAP charter (though it's expected that the mechanisms developed would be easy to apply to them). For example, end users would love to use measurements to find problems in their home network and to check how their broadband provider is doing 🥹

Looking at all the use cases, a few common themes pop out, and there are also some detailed differences ✨ These traits are what guide LMAP's framework, information model, and protocol 💜

First, a measurement capability is needed across a huge range of different environments 🌍 Tests might be needed in the home network, the ISP's network, or beyond. They might be measuring a fixed or wireless network, and they might measure just the access network or go across several networks 🦋

Second, there's a place for both standardized and non-standardized measurements 🎀 A regulator wants to publish standardized performance metrics for every network operator, while an ISP might need its own tests to understand a feature that's special to its network 🧚 Most use cases need active measurements, which create and measure specific test traffic, but some need passive measurements of the end user's traffic 💖

Third, no matter which tests are running, there has to be a way to demand or schedule them ⏰ Most use cases need a regular schedule of measurements, but sometimes ad hoc testing is needed, like for troubleshooting 🔍 It needs to be ensured that measurements don't affect the user experience and aren't affected by user traffic (unless that's what's wanted) 🫶 There also needs to be a common way to collect the results. Standardizing this control and reporting part means the operator of a measurement system can buy the different components from different vendors 🛍️

Once the results are collected, they need to be understood and analyzed 🧠 Often it's enough to measure only a small subset of end users, but per-line fault diagnosis means being able to test every individual line 🔥 Analysis needs an accurate definition and understanding of where the test points are, plus context about the topology, the line, the product, and the subscriber's contract 📋 The actual analysis of results is outside the scope of LMAP, and so is the big challenge of fitting the measurement system into a network operator's existing diagnostics and network planning tools 🙈

Finally, the test data, along with any related network, product, or subscriber contract data, is commercial or private information and needs to be protected 🔐

7. Security Considerations 🚨

okay this section is SERIOUS, bestie, so read it carefully 😭 Large-scale measurements raise several potential security, privacy (data protection) [RFC6973], and business sensitivity issues:

  1. A malicious party may try to take control of probes to launch DoS (Denial of Service) attacks at a target. A DoS attack could be aimed at a particular end user or set of end users, a certain network, or a specific service provider 💀
  2. A malicious party may try to take control of probes to create a platform for pervasive monitoring [RFC7258] or for more targeted monitoring. [RFC7258] sums up the threats like this: "An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed." For example, a malicious party could push a new measurement test to the probes that recorded (and later reported) information of maleficent interest 👿 Similar concerns also come up if the measurement results get intercepted or corrupted 😱
    • From the end user's perspective, the concerns include a malicious party watching the traffic they send and receive, who they talk to, the websites they visit, and info about their behavior like when they're home and where their devices are 🏠 Some of these concerns may be bigger when the probe is on the end user's device rather than on their home gateway 📱
    • From the network operator's perspective, the concerns include leaking commercially sensitive information about how their network is designed and run, and about their customers and suppliers 🏢 Some threats are indirect. For example, an attacker could scope out possible weak spots, like open ports and paths through the network, and use that to attack later 🕵️
    • From the regulator's perspective, the concerns include distortion of the measurement tests or alteration of the measurement results 📉 Also, a malicious network operator could try to identify the broadband lines the regulator is measuring and give that traffic priority ("game the system") 🎮
  3. Another potential issue is a measurement system that doesn't get the end user's informed consent, doesn't specify a specific purpose in the consent, or uses the collected information for secondary uses beyond those specified 🙅‍♀️
  4. Another potential issue is a measurement system that doesn't say who is responsible for collecting and processing personal data, and who is responsible for fulfilling users' rights 🧾 The responsible party (often called the "data controller") should, as good practice, think about things like defining:
    • the purpose for which the data is collected and used,
    • how the data is stored, accessed, and processed,
    • how long the data is retained, and
    • how the end user can view, update, and even delete their personal data.

If anonymized personal data is shared with a third party, the data controller should think about the possibility that the third party could de-anonymize it by combining it with other information 👀

These security and privacy issues need to be thought through carefully by any measurement system. In the context of LMAP, [Framework] looks at them further, along with some possible mitigations 🛡️

Other LMAP documents will specify one or more protocols that let the measurement system tell a probe which measurements to make, and that let the probe report the measurement results 📡 Those documents will need to talk about solutions to the security and privacy issues too. However, the protocol documents won't consider how the measurement information actually gets used 🤷‍♀️ There are lots of possible use cases, and earlier in this document we described some likely ones for the network operator and the regulator 💖

8. Informative References ✨

okay bestie, this is the reading list 📚 every citation the doc leans on lives here, so you can go check the sources yourself. the URIs are wrapped below only to keep them readable, so copy them as-is 🔗

[IETF85-Plenary] Crawford, S., "Large-Scale Active Measurement of Broadband Networks", 'example' from slide 18, November 2012, http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-7.pdf.

[Extend-TCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proceedings of IETF 82, November 2011, http://www.ietf.org/proceedings/82/slides/IRTF-1.pdf.

[Framework] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for Large-Scale Measurement of Broadband Performance (LMAP)", Work in Progress, draft-ietf-lmap-framework-14, April 2015.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, http://www.rfc-editor.org/info/rfc6973.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, http://www.rfc-editor.org/info/rfc7258.

[FCC-R&O] United States Federal Communications Commission, "Preserving the Open Internet; Broadband Industries Practices: Report and Order", FCC 10-201, December 2010, http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10-201A1.pdf.

[BEREC-Guidelines] Body of European Regulators for Electronic Communications, "BEREC Guidelines for quality of service in the scope of net neutrality", http://berec.europa.eu/eng/document_register/subject_matter/berec/download/0/1101-berec-guidelines-for-quality-of-service-_0.pdf.

[M-Labs_NSDI-2010] M-Lab, "Glasnost: Enabling End Users to Detect Traffic Differentiation", http://www.measurementlab.net/download/AMIfv945ljiJXzG-fgUrZSTu2hs1xRl5Oh-rpGQMWL305BNQh-BSq5oBoYU4a7zqXOvrztpJhK9gwk5unOe-fOzj4X-vOQz_HRrnYU-aFd0rv332RDReRfOYkJuagysstN3GZ__lQHTS8_UHJTWkrwyqIUjffVeDxQ/.

[Glasnost] M-Lab tool "Glasnost", http://mlab-live.appspot.com/tools/glasnost.

[MOS] Wikipedia, "Mean Opinion Score", January 2015, http://en.wikipedia.org/w/index.php?title=Mean_opinion_score&oldid=644494161.

[DAE] Digital Agenda for Europe, COM(2010)245 final, "Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions", http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52010DC0245&from=EN.

Contributors 🫶

the info in this doc is partly based on text written by these lovely people 💜

James Miller          jamesmilleresquire@gmail.com

Rachel Huang          rachel.huang@huawei.com

Authors' Addresses 🌸

these are the brains behind it, so here's where to find them 🎀

Marc Linsner
Cisco Systems, Inc.
Marco Island, FL
United States

EMail: mlinsner@cisco.com
Philip Eardley
BT
B54 Room 77, Adastral Park, Martlesham
Ipswich, IP5 3RE
United Kingdom

EMail: philip.eardley@bt.com
Trevor Burbridge
BT
B54 Room 70, Adastral Park, Martlesham
Ipswich, IP5 3RE
United Kingdom

EMail: trevor.burbridge@bt.com
Frode Sorensen
Norwegian Communications Authority (Nkom)
Lillesand
Norway

EMail: frode.sorensen@nkom.no
📦 where this page comes from