M-Lab

The Internet Can Be Up and Still Fail: Introducing HERMES

2026-08-18T00:00:00+00:00

HERMES turns user-initiated M-Lab speed tests into an open, path-aware view of Internet slowdowns — helping operators, researchers, and policymakers see not only that performance changed, but where along the route the problem may be.

HERMES is joint work with collaborators Kevin Vermeulen, Dave Choffnes, Ethan Katz-Bassett, and Phillipa Gill.

Public Internet observatories typically focus on outages: events in which networks or services become unreachable and produce visible changes in reachability, routing, or traffic.

Loss of connectivity, however, is only one form of Internet failure. A network may remain reachable while rising latency or faltering throughput makes online applications unusable. Because these degradations do not result in loss of connectivity, outage-focused observatories may miss them.

Observing these degradations requires a different approach that measures end-to-end performance instead of monitoring reachability and routing changes. M-Lab’s Network Diagnostic Tool (NDT) provides end-to-end performance data from real user connections at scale. Each user-initiated speed test measures latency, throughput, and loss between a user’s device and an M-Lab server, producing millions of observations across networks and locations each day. While individual tests can reflect local conditions, M-Lab’s large data set of comparable tests can reveal broader performance problems.

M-Lab also collects complementary network-path measurements, including traceroutes and reverse traceroutes, that provide information about the infrastructure traversed by these connections. By combining performance measurements with path information, we can identify network segments shared by affected users and localize whether a degradation is associated with the access network, an interconnection, a transit network, or infrastructure near the destination.

We call our system that detects and localizes performance problems using M-Lab speed test data: HERMES. It is the first public system to quantify performance degradations at scale based on fully open data.

From individual speed tests to evidence of a wider problem

One slow speed test indicates that an end-to-end connection performed poorly but does not give us enough evidence to identify problems with the wider network. A single poor performing test may reflect a problem with the user’s Wi-Fi, device, background traffic, or service plan, which will not impact other network users. Conditions inside individual homes vary independently and are unlikely to deteriorate simultaneously, whereas congestion or failure in shared infrastructure is likely to produce a common change across many connections. HERMES, therefore, looks for performance changes that are consistent across multiple users with similar network contexts.

To identify these shared changes, HERMES groups tests from users in the same access network and metropolitan area that connect to the same M-Lab site. The access network is represented by its Autonomous System Number, or ASN. This grouping holds three important factors relatively constant: users’ access network, location, and test destination. It also increases the likelihood that the tests traverse the same network infrastructure. Grouping cannot eliminate local noise, but it makes changes affecting shared infrastructure easier to distinguish from isolated problems affecting individual users.

HERMES analyzes a group only when it has enough data to distinguish a genuine performance change from ordinary variation. Specifically, we require at least 25 tests from at least 5 distinct client IPs to establish baseline performance measurements over the week preceding the tests we analyze. HERMES also caps the number of tests per IP to prevent a small number of frequent tests from dominating results and excludes measurements with inconsistent location metadata.

There is no universal threshold for “normal” latency or throughput: performance that is typical for one network and location may represent a serious degradation in another. The relevant question is therefore not whether a group is objectively fast or slow, but whether its users are performing substantially worse than usual. To account for this, HERMES compares current performance for the user group with the group’s recent baseline performance and identifies changes in performance relative to the baseline.

HERMES primarily looks for two signals:

Increased latency: Data takes longer to make a round trip, causing interactive applications to feel delayed or unstable.
Reduced throughput: Less data can be transferred over time, disrupting streaming, large downloads, and other high-capacity uses.

HERMES uses statistical tests to determine whether the distribution of measurements has changed and whether the degradation is sufficiently large and widespread to be of interest (see the paper for more details).

The Internet is a two-way trip

Once HERMES detects a performance degradation, it examines which network segments are associated with the affected connections and attempts to localize the source of the problem.

HERMES does this by combining performance measurements with traceroutes, which reveal the sequence of network hops along a path. Unlike most transportation networks, Internet paths are not negotiated end to end. Instead, each network independently chooses how to forward the traffic it carries. The networks carrying traffic from the server to the user may make a different sequence of routing decisions than those carrying traffic back to the server, which produces different paths. HERMES examines both the forward traceroute measured after each NDT test and, when available, a reverse traceroute from the user toward the server.

Our evaluation highlights the importance of taking a bidirectional view of network paths between the client and server. Half of the links implicated in performance events could be identified only by considering both directions. Among anomalous paths, the user-to-server route was geographically longer than the server-to-user route in 72% of cases and at least twice as long in 10% of cases.

HERMES uses two complementary forms of evidence to narrow down the source of the degradation. Specifically it asks:

What changed over time? HERMES compares paths observed during the degradation with those seen during normal periods. This can reveal a new detour, a disappearing link, or a shift to a different interconnection.

What distinguishes affected users? HERMES compares affected and unaffected connections to identify network segments that repeatedly appear on degraded paths. This can expose congestion or other problems even when the route itself has not changed.

HERMES considers both of these questions in parallel and combines the results.

Sometimes the set of available path measurements is not adequate to uniquely localize the source of a performance degradation. In these cases, HERMES can request a small number of targeted “forward” and reverse traceroutes, chosen to distinguish among the candidates. In our evaluation, these additional measurements reduced ambiguity by 47% on average and identified a single likely link in 31% of previously ambiguous cases.

HERMES does not claim to prove that a particular network caused a degradation. Instead, it reports the segments best supported by the available evidence and classifies each event as localized, ambiguous, or unresolved.

A slowdown in Chicago and a detour through Singapore

Figure 1. HERMES detects a sustained performance degradation (top) by comparing latency and throughput measurements against their recent baseline. It then localizes the degradation (bottom) by combining forward and reverse path measurements, identifying a routing change that diverted traffic through San Jose and Singapore instead of the usual Chicago–New York path.

On July 4 2024, HERMES found something unusual in Chicago. Cogent users were testing to a nearby M-Lab server hosted on Tata Communications’ network, yet their round-trip latency increased by more than 210 milliseconds and their throughput fell sharply. This was not an isolated slow test: the change appeared across the group relative to its recent performance.

The server-to-user paths provided only part of the explanation. Traffic was detouring through Texas, but that added only about 30 milliseconds. Reverse traceroutes revealed that most of the remaining delay originated from users’ traffic back to the server traveling through Singapore. Together, the two detours accounted for roughly 190 milliseconds of the increase.

The Chicago and New York interconnection points normally seen on these paths were absent that day. The evidence is consistent with traffic shifting to distant alternatives after the usual paths became unavailable, though it does not conclusively establish the cause.

Users noticed the degradation, prompting a Reddit discussion that generated more than 100 comments. The public outage observatories we checked did not. Connectivity had never disappeared, but HERMES could detect the shared performance change and use paths in both directions to investigate what had changed.

HERMES can also be used in the other direction: a user who notices poor performance can look up their network and location to see whether HERMES observes the same degradation, whether other nearby users are affected, and what network paths or components are associated with the change. In this way, HERMES can also be used as a tool for diagnosing an individual user’s performance problem in its broader context.

What we found at Internet scale

HERMES has been online since August 2024. In the paper, we evaluated HERMES using approximately 4 billion speed tests collected over five months. It identified about 65,000 performance events affecting user groups across 16,000 cities, 9,710 networks, and 166 countries.

We compared these results with several independent sources:

Cloud-scale monitoring: A reimplementation of Blame-IT, a peer-reviewed monitoring system, using denser measurements from a large cloud provider, also detected 91.4% of HERMES events. Among events detected by both systems, the identified path segment agreed in 94.5% of cases.
Provider reports: HERMES detected 25 of 27 documented incidents and identified a source consistent with the report in 23 cases.
Operator and user reports: HERMES detected roughly ten times as many publicly discussed performance problems as the public observatories in our comparison.

No source provides complete ground truth because no comprehensive catalog of Internet performance incidents exists. Still, agreement across these independent sources suggests that sparse, public measurements can identify meaningful events without private operational data.

Seeing how disruptions affect usable connectivity

HERMES allows us to study how real-world disruptions affect performance even when connectivity does not disappear entirely.

During severe flooding in Andhra Pradesh, India, in September 2024, HERMES compared the share of monitored networks experiencing anomalies before and during the flooding. Metropolitan areas near the most heavily flooded region showed large increases in degraded performance, and the effects extended into some neighboring areas.

That wider footprint matters. Communications infrastructure is interdependent: damage or congestion at one location can reroute traffic onto shared fallback routes, affecting communities beyond the immediate disaster area.

Figure 2. Change in the fraction of monitored networks experiencing a HERMES-detected performance anomaly during the September 2024 flooding in Andhra Pradesh, relative to the pre-flood period. Red areas indicate an increase in the fraction of monitored networks with a detected performance anomaly; blue areas indicate a decrease. The overlay marks the main flooded region. The map shows a temporal and geographic association, not proof that flooding caused every anomaly.

We observed similarly distinct patterns around flooding in Valencia, Typhoon Shanshan in Japan, a Baltic Sea cable cut, and major hurricanes. Some disruptions produced broad regional degradation; others remained sharply localized. That difference can help resilience planners understand whether redundancy and rerouting contained an incident or shifted its impact elsewhere.

How to use HERMES

HERMES provides public, end-to-end evidence about how Internet infrastructure performs during real-world disruptions. That evidence can be useful to several different groups.

Internet users and communities can determine whether a problem extends beyond their own connection. When a user experiences unusually slow Internet, it is often difficult to know whether the problem is local, specific to their provider, or part of a broader incident. HERMES can show whether similar degradations are affecting other users in the same region or network and whether the problem appears to involve shared infrastructure.

Network operators can use HERMES as an independent starting point for troubleshooting. Some incidents cross organizational boundaries, leaving no single provider with a complete view. In the Chicago incident, for example, the degradation was associated with a path crossing the Cogent–Tata handoff. HERMES provides shared end-to-end measurements and path evidence that can help identify the networks, locations, and interconnections most relevant to further investigation. It complements rather than replaces operators’ internal telemetry.

Researchers, policymakers, and public-interest organizations can study Internet resilience beyond outages. During the flooding in Andhra Pradesh, affected networks remained reachable even as HERMES detected widespread performance degradation. More broadly, HERMES can reveal recurring problems around particular metropolitan areas, interconnections, or transit segments; identify where additional measurement or infrastructure investment may be warranted.

In each case, HERMES exposes the measurements and localization evidence underlying an event. Users of the data can therefore inspect the evidence behind a conclusion rather than relying only on an aggregate score or provider assertion.

HERMES does not establish the root cause of an incident on its own, nor does it replace provider telemetry, field investigations or existing outage observatories. But it adds public end-to-end evidence that can reveal otherwise overlooked degradations, identify the networks and locations most relevant to an incident, and guide the additional investigation needed to establish its cause.

Important limits

HERMES provides public evidence about Internet performance, but that evidence must be interpreted within the limits of the underlying measurements. The most important caveats are:

The testing population is not representative of all Internet users. NDT tests are user initiated, and people may be more likely to run a test when they suspect a problem. This makes the data useful for surfacing potential incidents, but it means that speed tests (and HERMES by extension) should not be treated as a random survey of Internet performance.

Coverage varies across networks, locations, and time. HERMES reports on a user group only when enough measurements are available to support a comparison. The absence of a detected event may therefore mean either that performance remained stable or that there was insufficient evidence to evaluate it. It should not automatically be interpreted as proof that the network was healthy.

Daily analysis favors sustained degradations. By default, HERMES compares performance at daily resolution. This provides more robust evidence and reduces sensitivity to short-term noise, but it may miss incidents that last only a few minutes or hours.

Measurements to M-Lab do not represent every destination. Paths to M-Lab servers overlap with infrastructure used to reach many popular services, but routing is destination dependent. A degradation visible on an M-Lab path may not affect every application, while a problem on a path to another destination may not appear in HERMES.

Localization identifies association, not definitive responsibility. HERMES can identify network segments that are strongly associated with a degradation, but it cannot by itself establish the underlying cause or determine legal or operational responsibility. Provider telemetry, maintenance records, contractual relationships, and evidence of physical damage may still be needed to explain what happened and who was positioned to address it.

HERMES analyzes M-Lab’s public measurements in aggregate and does not attempt to identify individual test participants. Anyone working directly with NDT data should review M-Lab’s Privacy Policy and follow its guidance for responsible use.

These limitations are consistent with our broader guidance for policy and advocacy research: no single measurement source is appropriate for every question, coverage determines what can be observed, and changes in the testing population must be considered when interpreting results.

Conclusion: An open observatory built on open measurements

M-Lab’s mission is to measure the Internet, save the data, and make it universally accessible and useful. HERMES demonstrates what becomes possible when that long-running public record is combined with careful statistical analysis and bidirectional path measurements. The result is an observatory for the failures between “online” and “offline”: the slowdowns, detours, and congested interconnections that impact whether people can actually use the Internet.

You can:

explore detected events and their supporting evidence on the HERMES public dashboard;
inspect the methodology and open-source pipeline in the HERMES GitHub repository; and
read the peer-reviewed paper, “HERMES: Repurposing User-Driven Speed Tests to Monitor the Internet”.

Network operators can also help expand what HERMES can observe. HERMES’s visibility ultimately depends on where M-Lab measurements are available. Deploying an M-Lab server can increase measurement coverage in a region and expose Internet paths and interconnections that might otherwise be sparsely observed. ISPs, network operators, universities, and other eligible organizations can contribute infrastructure through M-Lab’s host-managed server program.

Open measurement cannot eliminate Internet failures, but it can make them harder to overlook and easier for operators, researchers, civil society, and policymakers to investigate from the same set of facts.

IQB Meets Reliability: New Research on M-Lab’s Internet Quality Barometer

2026-08-05T00:00:00+00:00

Measurement Lab (M-Lab) is excited to announce that Zeynep Arslan (M-Lab Research Fellow, affiliated with the Sorbonne Université) was awarded an Internet Society Pulse fellowship to conduct research exploring the stability and reliability of the Internet Quality Barometer (IQB) framework.

The IQB is a composite index that translates speed test measurements (including M-Lab’s NDT measurements) — download and upload throughput, latency, and packet loss — into a single, interpretable score for assessing Internet quality. Since its initial development, the framework has been made publicly available alongside an open-source code library and a preliminary sensitivity analysis that explored variation in IQB scores depending on methodological choices. This new research builds directly on those findings.

The Problem

Policy decisions on infrastructure investment, funding eligibility, and regulatory classification increasingly depend on Internet quality metrics. Yet the stability of those metrics under varying methodological approaches has not been systematically tested — especially for countries with heterogeneous infrastructure, where the stakes of getting measurement right are highest.

Preliminary findings from the IQB’s analysis identified that measurement aggregation configurations, use-case definitions, and data sparsity all meaningfully impact scores. But a systematic evaluation connecting these sensitivities to real-world infrastructure and market conditions was beyond the scope of that initial study.

The Research

The work is structured around four interconnected questions:

Does IQB score volatility vary by development context? And, do countries with uneven infrastructure shift more dramatically in rankings across threshold choices?
Where are the policy-relevant tipping points at which a country crosses minimum or high-quality classification boundaries?
Do use-case profiles need contextual adaptation for different development settings?
Does the urban–rural gap explain score instability at the national level?

To answer these questions, the research will calculate IQB scores under different configurations at both country and city levels, conduct bootstrap resampling to establish minimum measurement requirements, design and evaluate context-specific use-case profiles, and correlate IQB scores against external indicators including GDP per capita, ITU broadband penetration, and ISP market concentration.

Why It Matters

If methodological choices produce less stable scores for countries with heterogeneous networks or fragmented markets, policymakers in those regions are operating with a disadvantage — and potentially being misrepresented by the very tools designed to help them. This research aims to ensure that the IQB, and the resilience assessments it informs, accurately reflect ground-level conditions.

Findings will be contributed back to the IQB open-source repository, shared with the M-Lab community, and made available to support Internet Society Pulse Country Reports and the Internet Resilience Index.

If you are interested in this research workstream and want to join forces with, drop us a message at iqb@measurementlab.net

About Zeynep Arslan

Zeynep is a researcher at Sorbonne Université focusing on mapping global network topology and routing patterns. With nearly a decade in industry, working in Consulting, FinTech and HealthTech, she is interested in the intersection of distributed systems, data visualization, and the way networks shape how information moves around the world.

Connectivity CoP — July Session Recap

2026-07-30T00:00:00+00:00

On July 23, 2026, M-Lab and Giga hosted the monthly Connectivity Community of Practice (CoP) call. Hunter Thompson, Director of Telecommunications and Connectivity for the Vermont Department of Public Service, walked the group through Vermont’s Mobile Wireless Drive Test Program, and the community shared updates on the IQB-Edu framework, M-Lab’s historical stats dataset, a new QoE measurements design document, and UNHCR’s cellular data work in displacement contexts.

Fifteen people participated in the call, from a wide swath of internet measurement perspectives, including: international development, independent consultants, and researchers.

Community updates

IQB-Edu notebook updated. Pavlos Sermpezis (M-Lab) shared an update to the IQB-Edu policy linkage notebook (source on GitHub), now runnable for Moldova. The goal is a framework flexible enough to tune for other countries and education contexts.

Monthly stats data, 2009-2026. M-Lab’s historical stats dataset — 18GB, broken out by country, subdivision, and ASN, for both upload and download tests — is available now, with example Jupyter notebooks coming soon.

QoE measurements design document. M-Lab and Giga co-authored a first public draft spec’ing out Quality of Experience measurements for schools (blog post, design document) and are asking the community whether the measurement set is adequate, what’s missing, and what default scheduling makes sense.

Cellular data capture in forced displacement contexts. John Warnes of the UNHCR Innovation Accelerator gave an overview of UNHCR’s work capturing connectivity data in refugee and displacement settings. Related resources: Refugee Connectivity, the Rwanda Connectivity and Digital Work Report 2026, and testing findings on access and barriers to connectivity. Drive tests in the camps combine both driving and walking, depending on terrain and road access.

Vermont’s Mobile Wireless Drive Test Program

🛝 Slides (PDF) / Slides (PPTX)
📃 Mobile Wireless Drive Test program page
📃 MDT mobile experience map
📃 Tower locations

Hunter Thompson presented the state’s drive test program for mapping mobile wireless coverage.

The state publishes its results publicly and uses them to push providers toward better service. Coverage quality is color-coded on the mobile experience map: red means no results, yellow (poor) covers 0-5 Mbps, light green (good) covers 5-25 Mbps, and dark green (great) is 25 Mbps and above.

Thompson noted the test kit itself has evolved over time and now runs on a custom Android app; as a state employee he wasn’t sure the software could be shared publicly. The program is expanding to use M-Lab endpoints so it can run tests year-round. A participant also flagged that the UK’s move of emergency services radio traffic to LTE included its own coverage-checking effort, with background here, as a possible parallel data source / approach to study.

What’s next

These CoP calls happen regularly, with room on the agenda for 5-minute community updates on connectivity projects and M-Lab data research — email jonah@measurementlab.net if you’d like a slot. On the community announcements front, several attendees are weighing a trip to IGF in December — reach out on the mailing list if you’re planning to be there and want to connect.

Join the Group for discussions and further announcements of activities
CoP GitHub
About the CoP

As the world’s largest open collection of Internet performance data, M-Lab provides powerful, real-world telemetry that helps illuminate how networks actually perform. Through this collaboration, we’re working with Giga to strengthen how connectivity is measured and understood for public facilities, especially schools, using open measurement approaches that reflect on-the-ground conditions.

Giga is a joint initiative of UNICEF and the International Telecommunication Union (ITU), working to connect every school to the internet and every young person to information, opportunity, and choice. Through its global focus on school connectivity, Giga supports governments and partners with data, technical expertise, and financing tools to accelerate meaningful access to the internet for education.

RFC: Design Document on Quality of Experience Measurements for Schools

2026-07-16T00:00:00+00:00

We are excited to announce the first public draft of a design document describing Quality of Experience (QoE) measurements for schools. This design document has been co-authored by M-Lab and Giga staff members as part of our collaboration to strengthen how connectivity is measured and understood for public facilities, and especially schools. We encourage all members of the Connectivity Community of Practice (CoP) to review, provide feedback, and contribute to our initial design.

Background

Measurement Lab (M-Lab) runs the world’s largest open collection of Internet performance data and provides real-world telemetry that helps illuminate how networks actually perform. Giga is a joint initiative by UNICEF and the ITU aiming to connect every school to the Internet and every young person worldwide to information, opportunity, and choice.

The Connectivity Community of Practice (CoP), launched by M-Lab and Giga, brings together researchers, network engineers, implementers, and policymakers, to advance network measurement approaches for public facilities with specific focus on schools. The CoP goals include supporting the design of network measurements that are technically rigorous, globally comparable, and practical for real-world connectivity contexts and underserved regions.

Currently, Giga measures schools using the Giga Meter computer program, which schools can install to periodically run network measurements including M-Lab’s flagship network performance test, ndt7.

Part of the CoP’s research agenda is to extend and improve upon the measurements currently performed by Giga Meter.

This effort produced a draft design document that today we are opening up and sharing with our community for additional comments, feedback, and suggestions.

Design Document Overview

The draft design document’s main objective is to perform additional network measurements for surfacing network metrics related to the QoE. The basic idea is the following:

ndt7 collects network metrics including tcp-info providing a baseline of the expected network performance for a single user (who, in the context of the collaboration with Giga, is a student in a school facility).

However, ndt7 exercises the network under a bulk transfer regime (e.g. how fast can I download software updates or how fast can I start streaming a video?) and additional Internet usage regimes exist, including the latency-bound (e.g. resolving domain names using the DNS and browsing the web) and real-time (e.g. audio or video calls using the Internet) regimes.
Therefore, while ndt7 helps to characterize the envelope, additional network measurements could pinpoint how the Internet connection behaves under different stress regimes.

To this end, the design document introduces additional network measurements including:

DNS (over UDP and HTTPS) lookups towards public resolvers.
The fetching of web resources relevant for education (including collecting the time spent in the DNS, TCP, and TLS stages before getting the actual resource itself).
TCP streaming at set speeds (e.g. 5 Mbit/s).
Multi-stream tests using MSAK.

The plan is to co-develop this set of extra measurements side by side with Giga Meter, taking advantage of planned improvements that should allow for scheduling this kind of extra measurements through the day. In other words, the design document defines the measurement plane and Giga Meter will be the control plane for scheduling the measurements.

Prototype

An initial prototype implementing part of the design document is available at bassosimone/sonda.

Asks for the CoP

In light of the above context, we are now asking the CoP to review the design document providing feedback and comments. In doing this exercise, one should keep in mind that the design document is focused only on the measurement capabilities and that Giga Meter will provide the control layer, as mentioned above.

Beyond doing a review of the document text itself, we are specifically asking the CoP the following questions:

Do you find the set of measurements adequate?
Is there any specific detail that we missed in speccing out the measurements and that may provide undesired bias?
Is there any other measurement you would suggest?
Which scheduling would you recommend as default for the proposed set of measurements?
Is there anything else that our questions above do not cover and do you think it is important that we take into account?

You can share your feedback directly by opening an issue on the CoP GitHub repository or by emailing connectivity-cop@measurementlab.net.

Thank you for your time!

Connectivity CoP — May Session Recap: Shaping the Internet Quality Barometer for Education (IQB-Edu)

2026-06-12T00:00:00+00:00

Two months after our March launch, the Connectivity Community of Practice (CCoP) gathered again on May 18–19, spanning time zones from Michigan to Uganda, Washington DC to Barcelona. The conversation centered on the Internet Quality Barometer for Education (IQB-Edu) — a new measurement framework designed specifically for school connectivity.

Who Was in the Room

The session drew a diverse mix of researchers, engineers, policy advisors, and practitioners from Merit Network, UC Santa Barbara, Michigan State University, the Internet Society, UCL, the Africa Raspberry Pi Foundation, Giga, M-Lab, and more. The range of expertise — broadband research, Indigenous community networking, rural connectivity in Uganda and Kenya — is a good reminder of how broad the application areas for Internet measurement data are.

Community Updates

Interactive Jupyter Notebooks

We’re working to make it easier to explore M-Lab data without any local setup. Using MyBinder.org — an open-science project from the JupyterHub community — anyone can click a link and immediately work with M-Lab data in an interactive Jupyter notebook, right in their browser. No login required. The current notebook explores school connectivity data from Moldova, and the community response was enthusiastic. Many participants expressed interest in adapting notebooks for their own data and contexts, and we plan to build on that energy to help others create and share their own. We have also created a simpler view of IQB-Edu in Moldova:

Detailed IQB-Edu for Moldova MyBinder notebook: contains code, data and visualizations; how to use the IQB library, calculate IQB-Edu scores, and adapt the parameters of the framework; detailed insights on school connectivity in Moldova
Simple IQB-Edu for Moldova MyBinder notebook: (hidden code) notebook with simple UI for easy parametrization of IQB-Edu and visualization of scores; can be used for experimentation and quick insights

To learn more about how Giga and M-Lab are helping countries around the world with their internet, have a look at this recent blog post about work in Mongolia.

Knowledge Base Coming Soon

The M-Lab and CCoP teams also previewed an upcoming knowledge base — a shared hub for guides, data tutorials, and community documentation. The community had plenty of ideas for what to include: an “M-Lab data bootcamp,” code libraries for speed and traceroute analysis, guidance on how measurement server distance affects results, country-level summaries of download/upload speeds, jitter, and latency, and thresholds for characterizing connectivity quality at different levels of aggregation. Stay tuned, the team are working to bring out several knowledge base articles soon.

IQB-Edu: Vision, Data, and Discussion

During the call, Pavlos Sermpezis walked the group through the IQB-Edu framework — a school-specific adaptation of M-Lab’s existing Internet Quality Barometer. You can find the presentation and related material at the CCoP GitHub repository. The initial prototype draws on data from 66 urban and 15 rural schools in Moldova’s “Model School” cohort, using two key metrics: 95th percentile performance as a proxy for network capacity, and 50th percentile performance as a proxy for typical user experience. Measurements currently run four times per day, timed around when devices are active and sized to avoid overwhelming data-capped networks.

What the Community Wants to Fine-Tune

The discussion surfaced a rich set of open questions:

IQB-Edu weights — and how you can help shape them. The IQB framework works in two layers: first, network thresholds that define minimum and high-quality performance for each use case (video conferencing, content delivery, administrative tasks, etc.); second, weights that determine how much each use case counts toward the overall score for a given setting — schools look different from homes or offices. Both layers are currently calibrated from expert opinion, and both need real-world validation.

This is where researchers and practitioners in the community can make a concrete contribution. The IQB-Edu Jupyter notebook is designed to be hands-on: you can adjust the parameters yourself and see how different threshold or weight choices change what the scores say about Moldova’s schools. Does a configuration that emphasizes video conferencing match what you’d expect from your own context? Does it flag the schools you’d expect to flag? That kind of ground-truth check from you would be a great contribution to the community.

Contributions could take several forms: written recommendations on thresholds grounded in existing research or policy standards; analysis using the notebook showing which parameter choices produce meaningful or misleading results in your context; or a list of research questions and ways to visualize the data to better support policy decisions. Share whatever form works best for you with connectivity-cop@measurementlab.net (we want it to be an iteractive space) or open an issue on the CoP GitHub.

Measurement density. Community feedback suggested that four measurements per day may not be enough. US anchor institution data showed clear performance dips between 11am and 7–8pm — patterns that hourly speed tests or more frequent pings could help explain.

Adjusting for school size. Thresholds don’t yet account for the number of students or expected concurrent connections. M-Lab has per-school enrollment data; the community will help figure out how best to use it.

Schools as community hubs. School networks often serve the surrounding neighborhood, not just enrolled students. Whether a network is school-only or shared with the community changes how measurements should be read.

eduroam as a measurement opportunity. One participant raised the idea of using eduroam connection data — as more locations (cafés, libraries, museums) broadcast eduroam signals — to understand student and staff Internet experience beyond the school campus.

Policy engagement. The Moldova prototype is a first step toward making IQB-Edu useful for policymakers. The team hopes to present progress at TPRC later this year.

Resources
📃 CCoP GitHub Repository
🔗 Join the CCoP Google Group
📧 connectivity-cop@measurementlab.net
📊 IQB-Edu Moldova Notebooks

Can’t make it live? Join the CCoP Google Group for materials and updates. Meeting notes and resources live on the CoP Community GitHub.

Whether you’re a researcher, engineer, educator, or policy advocate — your perspectives are welcome here! We hope to see you in June.

Connectivity Community of Practice Launch!

2026-03-18T00:00:00+00:00

On March 11, 2026, M-Lab and Giga formally launched the Connectivity Community of Practice (CCoP) and held the inaugural session with 51 global participants representing backgrounds from academia, industry, civil society and international NGOs. The event introduced the CoP’s initial focus areas and invited participants to help shape its first-year agenda through an interactive Community document.

Resources
🛝 Slides
🎥 Recording
📃 Community Doc
🔗 GitHub
🖊️ Join the CoP Group

The event began with presentations from Giga and Measurement Lab, introducing the organizations and their work. Maria Antonia Bravo, Technology Programme Manager, described various school connectivity contexts and how current tools and measurement methodologies fail to capture the data and insights needed to solve their real-world challenges, and how the CCoP could help resolve those gaps in measurement and application.

Melissa Newcomb, Director, Programs and Partnerships at Measurement Lab, provided an overview of what the CCoP’s objectives are and how it will be stewarded. Grounded in open data, open tools, and open collaboration, the CoP brings together researchers, engineers, implementers, policymakers, and advocates working to ensure that connectivity measurement is:

Technically rigorous
Globally comparable
Practical for real-world connectivity contexts, including underserved regions

Pavlos Sermpezis, Director, Technical Lead at Measurement Lab, introduced the M-Lab platform and the initial research agenda for the CCoP. The four initial workstreams for the CCoP are:

Improving measurement tools
Characterization of facility-based connectivity
Internet Quality Barometer for Education (“IQB - Edu”)
New insights from existing measurement data

In addition, we invited CCoP members to BYOI (Bring Your Own Ideas)! Initial questions and areas of work participant mentioned included:

Insights into usage of the Internet by students in addition to the connectivity
Exploring the proximity of content delivery networks, IXPs and educational facilities
Connectivity providers and infrastructure development
Access to content, regulation and right to information

As the CCoP evolves we expect the areas of research and work to change to reflect the interests of the community.

Going forward, Measurement Lab and Giga will steward the CCoP for the first year with support from Superbloom Design. In the coming weeks, we will disseminate governance documents and invite CCoP members to formulate working groups, participate in research, share their findings and provide feedback. We already have 53 members in the CCoP Google group!

The Connectivity Community of Practice reflects a shared commitment to building durable, inclusive, and representative approaches to connectivity measurement — ensuring that data serves the communities it is intended to support.

M-Lab and Giga to Launch Community of Practice to Advance School Connectivity Measurement

2026-02-26T00:00:00+00:00

M-Lab and Giga to Launch Community of Practice to Advance School Connectivity Measurement

Measurement Lab (M-Lab) is excited to announce the early launch of a new Connectivity Community of Practice for applied Internet measurement in collaboration with Giga.

As the world’s largest open collection of Ιnternet performance data, M-Lab provides powerful, real-world telemetry that helps illuminate how networks actually perform. Through this collaboration, we’re working with Giga to strengthen how connectivity is measured and understood for public facilities, especially schools, using open measurement approaches that reflect on-the-ground conditions.

Giga is a joint initiative of UNICEF and the International Telecommunication Union (ITU), working to connect every school to the Internet and every young person to information, opportunity, and choice. Through its global focus on school connectivity, Giga supports governments and partners with data, technical expertise, and financing tools to accelerate meaningful access to the Internet for education.

Objectives
This Community of Practice (CoP) builds on that shared foundation. It brings together researchers, network engineers, implementers, and policymakers to advance measurement approaches that are:

Technically rigorous
Globally comparable
Practical for real-world connectivity contexts, including underserved regions

Together, the community will first explore what meaningful measurement looks like for schools, align on indicators that support better decision-making, and translate open telemetry into insights that enable smarter, evidence-based connectivity planning.

At its core, the CoP reflects a shared commitment to openness in data, in tools, and in collaboration. As the community grows, we look forward to shaping inclusive participation and governance models with contributors, ensuring this work remains durable, representative, and grounded in shared priorities.

Join us!
We’ll host a virtual launch event on March 11, 2026 at 14:00 CET / 9:00 Eastern Time to introduce the Community of Practice’s initial focus areas and invite input into its first-year agenda.

Whether you’re an engineer, researcher, educator, advocate, or policymaker, we welcome everyone working at the intersection of Ιnternet measurement and school connectivity to join us and help shape what comes next. If you’re interested in joining the CoP, click on the registration link below.

Register to attend here!

Can’t attend live? Join the CoP Connectivity group to receive event materials and updates on future activities.

OMG! The Fourth Open Measurement Gathering Report is Out Now

2025-12-22T00:00:00+00:00

The Open Measurement Gatherings
From 2024 to 2025, Measurement Lab, Censored Planet, IODA, and OONI organized four convenings called the Open Measurement Gatherings (OMG). The intention of these convenings was to build understanding, trust, and collaboration across open Internet measurement groups and this initiative was made possible with the support of the Open Technology Fund (OTF).

From September 8-12, 2025, the Open Measurement Groups groups gathered in Estoril, Portugal for the fourth convening of the two-year program.

Open Measurement Village
From Sept 8-10, 2025, OMG groups hosted an Open Measurement Village at the Global Gathering (GG). At the Village, OMG groups took turns hosting a booth, circle discussions, and a game called “Are You My Measurement Tool?” to help compare the use cases and data of each OMG group’s measurement tool. Balancing innovation in Internet measurement with accessibility is a key challenge that came up throughout the Global Gathering. Open measurement groups must keep up with increasingly sophisticated Internet interference while educating the non-technical community.

New OMG User Guide
Based on the feedback from the GG community, the OMG groups created the OMG User Guide as a public resource to help users determine which measurement tool they should use or how to compare data from OMG groups.

OMG 4
The OMG groups remained in Estoril from September 11-12 to reflect on community feedback and the previous OMG convenings, share updates, and strategize on how to continue the momentum to deepen collaboration following the completion of the OTF-funded program. OMG groups face shared challenges; to counter those challenges we need to increase coordination, and to continue the work the open measurement groups must become sustainable.

Impact of the OMG Convenings
The OMG convenings deepened mutual understanding among the groups about each platform, tools, data pipelines, and users. Most importantly though, these convenings deepened the interpersonal relationships across OMG groups and built trust so that OMG groups can hold joint public events, preview upcoming changes, solve problems together, and strategize for the future of open measurement to meet a moment of unprecedented challenges.

These convenings developed a default habit to collaborate, incorporate data across groups, and build collective awareness of each group with our users. Going forward, the OMG groups have several actionable, short and long term plans to continue collaboration. Despite reduced resources, open measurement matters now more than ever given current global trends in policy and technology.

OMG 4 Report
For all the details about the Open Measurement Village, the Open Measurement Gathering, and our plans going forward, check out the full report!

M-Lab at Pulse Research Week with Internet Society and Giga

2025-12-18T00:00:00+00:00

From December 8-11, 2025, Measurement Lab (M-Lab) joined the Internet Society Pulse Research Week. On Day 4 Pavlos Sermpezis, M-Lab’s Director, Technical Lead, presented the Internet Quality Barometer prototype at the Giga offices in Barcelona. M-Lab discussed with the audience how IQB could be adapted for education.

During the closing session, Melissa Newcomb, M-Lab’s Senior Program Manager, led a reflection session featuring Georgia Bullen (M-Lab Advisory Committee Chair), Steve Song (Internet Society), and Shilpa Arora (Giga). The panel discussed how to take the knowledge gathering throughout the week and how to apply it to solve challenges in connectivity.

Throughout Pulse Research Week, the M-Lab team learned from diverse stakeholders and experts who are passionate about improving connectivity worldwide. The Internet Society and Giga are critical partners for M-Lab and it was powerful to combine our shared expertise and apply it to the issue of improving connectivity in underserved regions. We look forward to carrying the momentum of last week into 2026!

A Hands-On Tutorial with Reverse Traceroute

2025-11-13T00:00:00+00:00

Internet paths are often asymmetric: packets from A to B usually take a different route than packets in the reverse direction from B to A. This post walks through a reproducible case study using Reverse Traceroute (RevTr) to compare forward and reverse paths for NDT speed tests. We’ll show how to:

Select a test where both the forward and reverse traceroutes reached their destinations.
Pull the data directly from BigQuery.
Visualize where and how the two directions differ.

This post focuses on the workflow: how to pull tests, line up forward and reverse traceroutes, and compare them. If you want a more detailed walk-through of the Reverse Traceroute output itself: what each entry in the table means, how to interpret its output, and how to understand the details of the technique, please refer to the detailed documentation of the reverse traceroute dataset.

Why do forward and reverse paths differ?

Internet routing is policy-driven. Business relationships, peering choices, and traffic-engineering decisions can send return traffic through a completely different set of networks or cities than the forward path. For example, traffic from a device in NYC to a device in LA may flow through Chicago and Denver, while traffic on the way back from LA to NYC may flow through Dallas and Atlanta. To properly diagnose performance problems, it’s essential to see both directions.

Data sources

In this case study, we’ll use:

NDT speed tests collected by M-Lab.
Reverse paths (client → server) from the RevTr system, stored in BigQuery at
measurement-lab.revtr_raw.revtr1.
Forward traceroutes (server → client) from
Measurement-lab.revtr_raw.trace1.
Hop annotations collected by M-Lab.

What the notebook does

Not every NDT test has a reverse traceroute — in fact, only about 25% do. We’ll focus on that subset and:

Pick a day and select tests where both forward and reverse paths reach their destinations.
Extract hop-by-hop IP addresses and map to AS numbers, geolocation, and RTT from the source.
Compare forward and reverse directions by looking at:
- AS-path overlap (common subsequences).
- Geographic path length (sum of great-circle distances).
- Map overlays to see where the paths diverge.

What to look for

When you visualize the two directions, ask:

Where do the AS paths diverge?
Does one direction cross different cities than the other?
Is one direction significantly longer in kilometers or showing higher RTT growth?
Do you notice any suspicious geographic loops that could indicate policy quirks?

Try it yourself

The notebook cells below are ready to run:

It will find a candidate test with both directions.
Fetch and parse the paths.
Compute overlap metrics.
Generate simple visualizations (AS-level, geographic, and RTT-based).

If the first run does not yield an interesting pair of paths, simply change the index (or the date) and try again.

RevTr_UseCase.ipynb