M-Lab

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

Open Measurement Hackathon at the ACM Internet Measurement Conference (IMC) 2025

2025-11-12T00:00:00+00:00

M-Lab, OONI, IIJ, Dioptra Research Group, Cloudflare Radar, Reverse Traceroute, and IODA hosted the Open Measurement Hackathon, October 31, 2025, following the ACM Internet Measurement Conference (IMC) 2025 in Madison, Wisconsin, USA.

Over 40 participants from academia and industry gathered to “Measure All the Frights”, exploring and comparing data from our projects over the eight-hour hackathon. Each host organization suggested potential projects to participants in advance, and those who planned to attend formed teams via Discord or in person to select a project or propose their own ideas. Teams worked on a variety of projects, including:

Aggregating and visualizing metrics across multiple platforms/datasets
Analyzing and visualizing internet censorship data
Examining encrypted client hello (ECH) blocking
Examining TLS certificate diversity across countries/networks
Exploring aggregated country level internet performance data
Reproducing and extending key results from a recent study on web centralization
Comparing IPv4 versus IPv6 performance

The event concluded with teams presenting their findings to the group. The hackathon GitHub repository lists the projects that teams worked on at the event as well as code, presentations, images, etc. that participants shared with the hackathon organizers.

We’re grateful for everyone who brought their energy and ideas to the IMC 2025 hackathon. We enjoyed meeting you, talking about your research, and appreciate your interest in our open source and open data projects! Thanks as well to Internet Society for sponsoring the venue, beverages, and dinner for those who attended.

Measurement Lab publishes new dataset of NDT7 measurements

2025-07-15T00:00:00+00:00

A new dataset of ndt7 measurements is now available in BigQuery, offering access to measurements from a set of servers whose data had not been previously published.

These servers and their corresponding datasets are still in the experimental phase. We invite users to explore this new dataset and provide feedback. If you encounter any issues or notice any inconsistencies, please let us know so that we can continue to improve the quality and reliability of this dataset.

Where do these data come from?

Measurement Lab is in the second pilot phase to test a new dynamic method for deploying and managing measurement servers. As mentioned in our Community Call in November 2024, M-Lab’s platform is evolving to better measure the Internet today, by enabling the addition of new servers to the M-Lab fleet through the Host Managed Deployment Program.

M-Lab’s platform consists of more than 400 servers in more than 40 countries and 100 metros. The majority of these servers belong to the “legacy” fleet, whose measurements are already available in BiqQuery, e.g., in the table `measurement-lab.ndt.ndt7`.

Figure 1: The “legacy” fleet of M-Lab servers. It consists of more than 370 servers.

A new set of servers, which we call as the dynamic¹ fleet of servers–including those deployed through the Host Managed Deployment Program–has been gradually rolled out as part of a pilot phase. Although data collection from these servers has been ongoing for the past year, these data have not been publicly available until now.

Figure 2: The “dynamic” fleet of M-Lab servers as of July 2025. It consists of more than 35 servers in 9 countries.

Accessing the new data in BigQuery

Until recently, data from the dynamic fleet was withheld to ensure integrity while we piloted the dynamic deployment system. Now, we would like to make the data available. However, we are still in an experimental stage and maintain separate tables to make it easy for researchers to see how the data is changing.

There have been no changes to NDT itself, but the BigQuery schemas are slightly different due to changes in server metadata and the methods used to import the data into BigQuery.

Specifically, to accommodate these schema differences, we’re publishing three new views in the measurement-lab.ndt dataset:

ndt.ndt7_legacy - The full legacy ndt7 view as currently published as ndt.ndt7. This view will be preserved to support investigating the provenance of the legacy data. It supports locating the raw data that was processed in order to populate BigQuery.
ndt.ndt7_dynamic - Fully annotated data from the dynamically registered fleet, including the provenance of the data, so researchers can locate the raw data in the archive.
ndt.ndt7_union - The union of ndt7_legacy and ndt7_dynamic, but without provenance because it is incompatible between the sources.

Notes for researchers and future plans

Most researchers using ndt7 data won’t need to take any action. Your existing queries using ndt.ndt7 should continue to work seamlessly through this transition.

If you would like to explore all data (both from legacy and dynamic fleets), we recommend temporarily switching to ndt7_union. Researchers using server metadata such as server DNS names, IP addresses, routing information and Anonymous System Numbers (ASNs) should still be able to parse the data, possibly with a few minor changes to generalize regular expressions. (Site names may now include more than two digits, e.g., abc1234).

Currently, the dynamic fleet of servers provides tests and data only for ndt7; in the future, it will support measurements for other tools (reverse traceroute, WeHe, Neubot, etc).

At some point in the future we will redeploy ndt.ndt7_union as ndt.ndt7, and ask that you update your queries accordingly. Although we are not aware of any problems with the data from the dynamic fleet, we have not yet systematically validated the calibration of this data.

Moreover, if you’re currently using the unified or intermediate views and are unable to easily switch to ndt7 or ndt7_union, we’d like to hear from you. These views were originally developed to support the transition from ndt5 to ndt7, but as part of an upcoming update, we plan to revise our recommendations regarding their use (today, ndt5 accounts for less than 0.5% of newly collected data).

If you have any questions about these changes or how they might affect your work, please let us know at support@measurementlab.net

The term “dynamic” refers to the more dynamic way of setup and operation, as well as the availability of the servers. ↩

OMG! Summary of the 3rd Open Measurement Gathering (OMG) Ask Me Anything (AMA) event

2025-07-15T00:00:00+00:00

On June 25, 2025, the Open Measurement Gathering (OMG) held a public event, “Open Measurement Gathering AMA”, featuring Censored Planet, IODA, OONI, and Measurement Lab. This was a chance for the OMG group to share project updates, future plans, and gather questions and feedback from the Internet freedom community. Each measurement group presented for 30 minutes followed by Q&A.

This public virtual event was inspired by the past two OMG convenings (public reports 1 and 2) at which OMG groups have shared exciting updates to their platforms, tools, and/or datasets before sharing with the broader Internet freedom community. For the third OMG convening, the groups decided to share previewing updates publicly to encourage community feedback.

During the event, OMG groups gathered feedback and answered questions from the Internet freedom community directly.

Detailed summaries of the presentations and Key Community Questions can be found in the OMG3 public report

You can also watch the presentations and listen to the full Q&A for each session. Links to each group’s presentation:

Full OMG AMA Playlist
Censored Planet Slides and Recording
Measurement Lab Slides and Recording
OONI Slides and Recording
IODA Slides and Recording

The OMG AMA event was especially intended for advocacy organizations, digital rights researchers, anti-censorship tool developers, journalists, lawyers, activists, policy makers, and funders. At its peak, we had about 60 folks joining us from around the world. The OMG groups truly appreciate those who could attend, and we hope to host more joint events in the future!

Measurement Lab publishes the Internet Quality Barometer Framework

2025-06-30T00:00:00+00:00

Measurement Lab is happy to announce the publication of the Internet Quality Barometer Framework! The Internet Quality Barometer (IQB) is an initiative funded by the Internet Society Foundation’s Research Grant program motivated by the need to redefine how we measure and understand Internet performance to keep pace with evolving technological demands and user expectations.

Read more about the IQB framework in our

For decades, policymakers, advocates, Internet researchers, Internet service providers and more have relied on speed test data to tell us if our Internet connections are performing well. But as the Internet has evolved so have its use cases and “high-speed” alone is no longer representative of “high-quality” Internet.

IQB is a comprehensive framework for collecting data and calculating a composite score, the “IQB Score”, which reflects the quality of Internet experience. IQB takes a more holistic approach than “speed tests” and evaluates Internet performance across various use cases (web browsing, video streaming, online gaming, etc.), each with its own specific network requirements (latency, throughput, etc.).

Plenty of Internet quality data, tools, and methodologies exist, but it is unclear how to effectively integrate them with one another.

IQB’s primary goal is to fill that gap and build consensus for a more nuanced definition of Internet quality. By moving beyond a narrow focus on speed, IQB seeks to provide stakeholders with actionable insights that support smarter policies and a more equitable Internet.

To create the IQB framework, M-Lab engaged with more than 60 experts across various fields, including academic network research, public policy, digital inclusion advocacy, Internet service provision, speed test data analysis, content provision, and other related domains from November 2023 to March 2025.

This is the first phase of the project and we’ll continue iterating on. In future phases, we aim to build an accessible tool for putting the framework to use. The first public report introduces the IQB framework that will be the basis for an IQB tool that will provide stakeholders with actionable insights to support smarter policies and a more equitable Internet.

For more details about the IQB Framework, read the detailed report or the executive summary, and our ACM IMC 2025 poster paper!

IP Route Survey (IPRS) data published in M-Lab

2025-06-16T00:00:00+00:00

We are excited to announce that the Dioptra research group at Sorbonne University is making its IP Route Survey (IPRS) available on M-Lab.

IPRS is an initiative to continuously monitor IP-level routing across the internet. This is done through the regular collection of traceroute-style measurements from multiple vantage points towards a significant portion of the internet’s routable address blocks. IPRS consists of distributed route traces from, currently, 10 vantage points to all routable IPv4 prefixes.The survey is conducted by the Dioptra research group at Sorbonne University’s LIP6 computer science laboratory.

IPRS is similar to CAIDA’s Archipelago (Ark) data, consisting of multipath route traces. The data is available in the iprs1 schema, designed to be consistent with scamper1 schema used for M-Lab’s existing large collection of traceroutes. We hope that the compatible formats will make it easier for researchers to use both datasets.

With the IPRS data, you can get a broader picture of routes through the internet at times when particular M-Lab tests were being performed. This could be useful if you are examining anomalies, for instance, to better understand if those anomalies were restricted to the path over which tests were run, or were part of a broader phenomenon.

IPRS data is gathered using the Iris infrastructure, the Zeph and Diamond-Miner algorithms, and the Caracal prober as described in Zeph & Iris map the internet: A resilient reinforcement learning approach to distributed IP route tracing, an ACM SIGCOMM Computer Communication Review article from 2022. This work was funded by the French Ministry of Armed Forces on a cybersecurity grant.

For purposes of economizing storage space and processing on M-Lab’s BigQuery, we provide a subset of the data. The entire set and historical data from early 2021, IPv6 data, and other datasets, are available upon request from Dioptra. Specifically, Dioptra has provided the following two tables:

iprs_data1 IPRS data (a representative subset of all IPRS data)
iprs_index1 an index of all IPRS meatada data

You can access IPRS data and metadata in the BigQuery tables iprs_data1 and iprs_index1 in the sorbonne dataset. For details on how IPRS data was converted from Iris native format to be compatible with scamper1, please see the Data page.

We encourage you to test this new dataset and write to us at iprs@dioptra.io with your feedback!

How M-Lab Determines User Location and Selects Servers

2025-05-27T00:00:00+00:00

This blog post describes the two geolocation systems M-Lab uses for server selection and data annotation and how researchers can leverage metadata about the server selection to identify potentially erroneous client geolocation results in the annotated data.

This post was contributed by a member of the M-Lab community. We value input from our community and invite others to share their insights on internet measurement, research, and related topics.

Interested in contributing? Please email us at hello@measurementlab.net.

Geolocation at Test Time

The user’s location for server selection is determined using metadata from the HTTP request, including the IP address and other client hints provided by Google’s App Engine. This method offers a relatively accurate view of where the user is, and it’s used to make sure the test runs against an appropriate nearby server.

Geolocation in the Public Dataset

When test results are stored in BigQuery, M-Lab uses a different system to determine location: MaxMind’s GeoLite2 database. The processing pipeline applies this annotation within a few hours of each test using a fresh copy of the MaxMind database. This database maps IP addresses to cities and countries, but it may be less accurate in certain contexts, especially for mobile users, VPNs, or users behind NATs. Specifically, MaxMind reports accuracies of 99.8% and 66% at the country and city levels, respectively.

Depending on the type of research being done with the data, country-level accuracy may be sufficient, but other applications benefit from identifying erroneous geolocation results at finer granularities. Below, we describe how to leverage these two geolocation systems to identify potentially incorrect client geolocation results in the BigQuery data.

Identifying Geolocation Inconsistencies

Recall, there are two geolocation systems in play:

Google/App Engine geolocation: Used at test time to select a server.
MaxMind geolocation: Used in the dataset to report user location.

This can lead to inconsistencies between where the test was served and where the user appears to be in the data that we can leverage to identify potentially incorrect client geolocation in the BigQuery data.

Specifically, we recommend looking at cases where the “metro_rank”¹ field is 0 (indicating that the Locate API served it to the closest site). You can then compute the nearest server metro to the client location published in BigQuery. If the nearest server metro does not match the metro of the server that was used for the test, this indicates a potential discrepancy between the geolocation result of the Locate API (used for server selection) and the one of MaxMind (used to annotate the data). Note that this does not tell you which geolocation result was correct, but it indicates a potential error in the client geolocation that can be filtered for applications that are sensitive to the specific client location.

The SQL below gives an example of performing this process.

Query to Select Consistent Geolocations

The following query identifies and keeps only the client IPs that show consistent geolocation behavior across server selection and reporting.

-- Replace ${DAY} with your date of choice in 'YYYY-MM-DD' format, e.g., '2025-05-01'
-- This query filters for client IPs that are located close to their nearest M-Lab server
-- and are likely not affected by test location inconsistencies.

WITH All_Client_Locations AS (
  -- Step 1: Get all unique client locations (by city + state + country),
  -- along with their lat/lon on the given day
  SELECT DISTINCT
  CONCAT(client.Geo.City, '-', client.Geo.Subdivision1ISOCode, '-', client.Geo.CountryCode) AS client_city,
  client.Geo.Latitude  AS client_lat,
  client.Geo.Longitude AS client_lon
  FROM `measurement-lab.ndt.ndt7`
  WHERE
  date = '${DAY}' -- 🟡 Replace this with your desired date
  AND client.Geo.Latitude IS NOT NULL
  AND client.Geo.Longitude IS NOT NULL
),

All_Server_Locations AS (
  -- Step 2: Get all unique server locations with valid lat/lon and city
  SELECT DISTINCT
  server.Geo.City     AS server_city,
  server.Geo.Latitude   AS server_lat,
  server.Geo.Longitude  AS server_lon
  FROM `measurement-lab.ndt.ndt7`
  WHERE
  date = '${DAY}' -- 🟡 Replace this with your desired date
  AND server.Geo.Latitude IS NOT NULL
  AND server.Geo.Longitude IS NOT NULL
  AND server.Geo.City IS NOT NULL
),

MinDistancesPerCity AS (
  -- Step 3: For each client city, compute the great-circle distance to its closest server
  SELECT
  c.client_city,
  MIN(ST_DISTANCE(
      ST_GEOGPOINT(c.client_lon, c.client_lat),
      ST_GEOGPOINT(s.server_lon, s.server_lat)
  ) / 1000) AS min_gcd_km -- convert meters to kilometers
  FROM All_Client_Locations c
  CROSS JOIN All_Server_Locations s
  GROUP BY c.client_city
),

DistanceCalc AS (
  -- Step 4: For each test, calculate:
  -- - the distance from client to server
  -- - the metro rank
  -- - the client type (e.g., ist or not)
  SELECT
  CONCAT(client.Geo.City, '-', client.Geo.Subdivision1ISOCode, '-', client.Geo.CountryCode) AS client_city,
  raw.ClientIP AS client_ip,
  ST_DISTANCE(
    ST_GEOGPOINT(client.Geo.Longitude, client.Geo.Latitude),
    ST_GEOGPOINT(server.Geo.Longitude, server.Geo.Latitude)
  ) / 1000 AS gcd_km,
  cm.Value AS metro_rank,
  (
    SELECT cm2.Value
    FROM UNNEST(ndt.raw.Download.ClientMetadata) AS cm2
    WHERE cm2.Name = 'client_name'
  ) AS client_type
  FROM `measurement-lab.ndt.ndt7` ndt
  CROSS JOIN UNNEST(ndt.raw.Download.ClientMetadata) cm
  WHERE
  date = '${DAY}' -- 🟡 Replace this with your desired date
  AND cm.Name = 'metro_rank'
),

FilteredIPs AS (
  -- Step 5: Keep tests where:
  -- - the distance from client to chosen server is within 250km of the *nearest* server
  -- - OR the client is not of type 'ist' (e.g., from a automated tool)
  SELECT
  d.client_ip,
  md.min_gcd_km
  FROM DistanceCalc d
  JOIN MinDistancesPerCity md
  ON d.client_city = md.client_city
  WHERE
  (
    ABS(d.gcd_km - md.min_gcd_km) < 250
    AND d.metro_rank IN ('0', '1')
  )
  OR (d.client_type != 'ist')
),

ConsistentIPs AS (
  -- Step 6: Return only the unique set of IPs that passed the filter
  SELECT DISTINCT client_ip
  FROM FilteredIPs
)

-- Final result: set of IPs that have geolocation + test location consistency
SELECT
  *
FROM ConsistentIPs

Impact of Filtering on Dataset Size

The effectiveness of our filtering depends on how many servers are available nearby. Figure 1 defines the region in which each server is the nearest server. In dense regions, cells are small and the filter can finely distinguish between client locations; in sparse regions (e.g., much of Africa), large cells group many cities under the same server, making the filter less selective.

Figure 1. Voronoi partition of the globe overlaid on M-Lab server locations. Each colored cell shows the region of longitude/latitude space closest to its red-dot server by great-circle distance.

To assess the impact of filtering, we computed the number of unique client IPs retained versus removed when applying the consistency criteria on the 1st of April 2025. The filter excludes 18% of the measured IPs in Africa to 7.88% in South America. These results highlight a trade-off: while filtering improves geolocation reliability, it also reduces coverage, potentially in regions where measurement density is already limited. Therefore, users should really run these queries only if their results hinge on accurate geolocations.

Continent	Total IPs	Consistent IPs	Removed IPs	% Removed
Africa	112,293	91,605	20,688	18.42%
Asia	1,123,951	933,007	190,944	16.99%
Europe	526,951	463,247	63,704	12.09%
Oceania	58,656	52,316	6,340	10.81%
North America	519,671	465,723	53,948	10.38%
South America	127,903	117,822	10,081	7.88%

About the authors

Loqman Salamatian is a Ph.D. candidate in Computer Science at Columbia University, advised by Professors Ethan Katz-Bassett, Vishal Misra, and Daniel Rubenstein. His research focuses on Internet measurement, topology inference, and the relationship between virtual and geographical aspects of network structure. While grounded in theory and mathematical modeling, his work emphasizes building systems that leverage these foundations to uncover hidden properties and dynamics of the Internet.

Phillipa Gill is a research scientist at Google. Her research interests include network measurement, BGP security, broadband connectivity and network operations. She was previously a faculty member at the University of Massachusetts – Amherst and Stony Brook University.

The metro_rank flag can be found in the ndt.raw.Download.ClientMetadata array ↩