Web Performance | Aqualab - Northwestern University

Mobile and Cellular Networks from the Edge

Sat, 01 Nov 2014 00:00:00 +0000

Project Overview

For most people on Earth, the Internet is reached over a cellular network. Yet cellular infrastructure is among the hardest of all networks to observe: the interesting behaviour happens inside operator networks that publish little, use private addressing, and terminate traffic at gateways whose location bears no simple relation to the user’s.

The consistent move in this thread is to measure from the client, where a handset can see what an outside prober cannot, and to keep asking a question that outsiders usually assume away: for a mobile user, where is the network actually, and what does that cost?

Cellular Networks in the Internet

Cell Spotting mapped where cellular traffic enters the Internet, showing that the gateways serving mobile users are far more concentrated and far less local than the geography of their users implies. Behind the Curtain followed the consequence into content delivery: if a CDN sees a query arriving from a distant gateway, the replica it picks is wrong for the user holding the phone — the same problem our DNS work had found on fixed lines, sharper in cellular.

Anycast on the Move asked what happens to anycast routing when the client itself is moving, and Where Things Roam turned to cellular IoT and M2M connectivity, a population of devices that roams permanently by design.

Aggregators and Roaming

Roaming is no longer a bilateral arrangement between two operators. A layer of global aggregators now sits between the SIM and the networks that serve it, which changes the performance a device gets and makes the path it takes hard for anyone to predict. Our MobiSys paper laid out a taxonomy of these aggregators and measured their roaming performance and optimization, and the later TNSM article extends the comparison.

The Mobile Web

Mobile web performance has been shaped as much by intermediaries as by protocols. AMP up your Mobile Web Experience characterized what Google’s Accelerated Mobile Pages actually delivers, separating the gains attributable to the format from those attributable to serving from Google’s cache. Reining in Mobile Web Performance looked at what document and permission policies can recover, and Mobile AD(D) examined app session times, which determine what an ad — or any load — is worth paying for.

Connectivity in Motion

In-flight Internet is a useful extreme case: a satellite path, a shared cell with a hundred passengers, and a network stack designed for none of it. Mile High WiFi was a first look at in-flight connectivity in the wild, and When IPs Fly made the case for rethinking airline communication rather than treating the aircraft as an ordinary subscriber.

Papers

Cellular networks in the Internet

Behind the Curtain – Cellular DNS and Content Replica Selection — IMC 2014
Behind the Curtain: The Importance of Replica Selection in Next Generation Cellular Networks — SIGCOMM 2014 (poster)
Cell Spotting: Studying the Role of Cellular Networks in the Internet — IMC 2017
Anycast on the Move: A Look at Mobile Anycast Performance — TMA 2018
Where Things Roam: Uncovering Cellular IoT/M2M Connectivity — IMC 2020

Aggregators and roaming

Global Mobile Network Aggregators: Taxonomy, Roaming Performance and Optimization — MobiSys 2022
A Comparative Analysis of Global Mobile Network Aggregators — IEEE TNSM, 2025

The mobile web

Mobile AD(D): Estimating Mobile App Session Times for Better Ads — HotMobile 2015
AMP up your Mobile Web Experience — MobiCom 2019
Reining in Mobile Web Performance with Document and Permission Policies — HotMobile 2022

Connectivity in motion

When IPs Fly: A Case for Redefining Airline Communication — HotMobile 2016
Mile High WiFi: A First Look at In-Flight Internet Connectivity — WWW 2018

Coverage

In-flight WiFi — Northwestern McCormick News, ChicagoInno, and the Chicago Tribune (2016)
The in-flight browsing extension — Network World, New Atlas, ScienceDaily, CACM News, Indian Express, and Travel+Leisure (2017)
Phone usage — Northwestern McCormick News and ACM TechNews (2016)

People

Lead & PI

Fabián E. Bustamante (Northwestern University)

Students

Collaborators

Andra Lutu (Telefónica Research)
Sergi Alcalá-Marín, Marcelo Bagnulo (Universidad Carlos III de Madrid)
Özgü Alay (University of Oslo)
Moritz Steiner (Akamai)
Vishnu Navda, Ranjita Bhagwan, Saikat Guha (Microsoft Research India)

namehelp

Tue, 09 Oct 2012 00:00:00 +0000

Overview

namehelp improved web performance by obtaining more accurate redirections to nearby content delivery network servers. In short: it helped whenever you, or your ISP, used a remote DNS service.

The Problem

DNS is the Internet’s phone book, and it is invisible to almost everyone. Every site you visit, every message you send, begins with a lookup; a complex page may need dozens, and a browser may perform hundreds in a day. Most people never think about it, because their ISP provides the service transparently.

Over the preceding years, third-party public DNS services from Google, OpenDNS and Norton had become popular, and for good reasons — better security, better privacy, faster resolution. Through a large-scale study spanning over 10,000 hosts in nearly 100 countries, we found that while public DNS may indeed resolve names faster, web performance could suffer badly.

The cause is a hidden interaction with another invisible service. More than 70% of the top 1,000 websites rely on CDNs, which replicate content across thousands of servers and steer each user to a nearby copy — using the location of the user’s resolver as a proxy for the user. When the resolver is a public service somewhere else entirely, that proxy fails: users were being sent to replicas three times farther away than necessary.

CDNs and public resolvers were working on a fix, but the proposed standard had not achieved broad adoption, leaving users choosing between good web performance and the security and privacy they had switched for.

What namehelp Did

namehelp let users have both. It ran personalized benchmarks in the background, from the user’s own machine, to determine the optimal DNS configuration, and when it detected less than optimal web performance it corrected it by interacting with DNS and CDNs so content came from the nearest available replica.

Beyond benchmarking, which existing tools such as namebench and DNS Benchmark already did, namehelp added:

automatic DNS server configuration based on the sites a user actually visits
caching so frequently-visited sites resolved instantly
faster failover when a DNS server went down

It installed as a local system service — users pointed their machine at 127.0.0.1 — with browser extensions for Chrome and Firefox providing a dashboard.

The dashboard’s DNS view. In this example namehelp resolved in 9.51 ms against the network default’s 148.28 ms.

Where the gain came from: the CDN-hosted domains for which namehelp found a nearer replica.

Reception

The first release went out on 9 October 2012 for Windows, macOS and Debian/Ubuntu, with RHEL and CentOS packages following. Within a month it had 10,000 users. Coverage in McCormick News led to ACM TechNews, Computerworld and Network World, and from there to Lifehacker — which brought 2,000 new users in a single day — and on to outlets in France, Poland, Russia, Turkey, Brazil and Vietnam. Several reported the tool as speeding up web performance by 40%.

Source was released on 26 October 2012. A Firefox extension followed in 2013, a 2.0 beta for macOS in January 2018, and Namehelp Mobile brought DNS performance comparison to Android.

Privacy

The privacy policy was deliberately short: namehelp never collected personally identifiable information or the sites a user visited. Anonymous reporting — usage statistics, performance-improvement results, benchmark results for a generic set of popular sites, and results of other network measurements — could be switched off entirely.

Sinopsis y ¿por qué usar namehelp? (español)

La página original de namehelp se publicó en inglés y español. Se conserva aquí la versión en español.

Sinopsis. namehelp mejora el rendimiento web obteniendo redirecciones más apropiadas hacia servidores de contenido más cercanos. Básicamente, namehelp mejora tu rendimiento web si vos o tu proveedor de internet utiliza un servicio de DNS remoto.

¿Por qué usar namehelp? El Servicio de Nombres de Dominio (DNS) es una especie de guía telefónica para el Internet y es esencial para su funcionamiento. La mayoría de nosotros no nos percatamos de su existencia porque nuestro proveedor generalmente lo ofrece de manera transparente.

Los últimos años han visto el surgimiento de servicios de DNS público ofrecidos por compañías como Google, OpenDNS y Norton DNS, que presentan ventajas de seguridad, privacidad y velocidad de resolución. Aun así, a través de un estudio de gran escala que incluyó a más de 10,000 usuarios en más de 100 países, nuestro laboratorio descubrió que tu rendimiento web puede sufrir seriamente, aún cuando el servicio de DNS público efectivamente reduce el tiempo de resolución.

El problema se debe a la interacción del servicio DNS con las redes de entrega de contenido (redes CDN). Aproximadamente el 70% de los 1,000 sitios más populares utilizan redes CDN, que replican el contenido en miles de servidores y redireccionan a los usuarios al más cercano. La utilización de servicios de DNS público puede ocasionar que los usuarios sean redireccionados a servidores ¡mucho más lejos de lo necesario!

namehelp te permite obtener lo mejor de ambos mundos — utilizar un servicio de DNS público sin reducir tu rendimiento web. Ejecuta pruebas desde tu computadora para determinar tu configuración óptima de DNS y, si determina que estás recibiendo un rendimiento sub-óptimo, lo corrige automáticamente interactuando con DNS y CDNs para asegurar que el contenido sea entregado desde la copia más cercana.

Availability

namehelp is no longer distributed. It was released for Windows, macOS, and Debian- and RHEL-based Linux, with source available from October 2012.

Papers

Content Delivery and the Natural Evolution of DNS — IMC 2012
namehelp: Intelligent, Client-Side DNS Resolution — SIGCOMM 2012 poster, also in CCR

Coverage

Network World, Computerworld, ACM TechNews and McCormick News (2012); Lifehacker and ghacks.net (2012); MakeUseOf (2013); and coverage in France (Korben), Poland (Spider’s Web), Russia (Софт@Mail.Ru), Turkey (chip.com.tr), Brazil (IDG Now!, Dicas para Computador) and Vietnam (PC World VN, Mía Lùi).

People

Lead & PI

Fabián E. Bustamante (Northwestern University)

Students

With thanks to Andrés Bustamante for the logo, Mario Sánchez for the Spanish translation, and Richard Campbell and Keith Petersen for early feedback.

namehelp built on namebench, BeautifulSoup, dnspython, Flask, Jinja2, Werkzeug, graphy, httplib2, ntplib, PyASN1, pydhcplib and Python-RSA.

Client-Side DNS and Content Delivery — the project namehelp was built for

Client-Side DNS and Content Delivery

Fri, 01 Jun 2012 00:00:00 +0000

Project Overview

Content delivery networks decide which replica should serve you based on where your DNS query appears to come from. For most of the Web’s history that was a reasonable proxy: your resolver belonged to your ISP, so it sat near you, and a CDN steering toward the resolver was steering toward you.

Public resolvers broke that assumption. When users moved to third-party DNS services for speed, reliability, or filtering, their queries began arriving at CDNs from somewhere else entirely — and the CDN, doing exactly what it was designed to do, sent them to a replica near the resolver rather than near the user. Users adopting a service to make browsing faster could end up fetching content from much further away.

This project measured that interaction at scale and then did something about it.

Measuring the Interaction

Content Delivery and the Natural Evolution of DNS measured the end-to-end cost of remote DNS on CDN performance, and gave the first evaluation of the industry’s answer to it: the EDNS client-subnet extension, which attaches a truncated client address to the query so a CDN can steer on the client rather than on the resolver.

The extension works where it is deployed. The difficulty is that it requires both the resolver and the CDN to participate, and adoption was thin — so the performance cost kept falling, unevenly and invisibly, on precisely the content CDNs work hardest to place well. That gap is what made a client-side answer worth building.

namehelp

namehelp is the response, built on what the paper calls Direct Resolution: a proxying DNS server on the user’s own machine that keeps a third-party resolver for general queries — so users keep the reliability and speed they chose it for — while resolving CDN-hosted names directly, so the query carries the client’s own network position rather than the resolver’s. It recovers most of the performance that remote resolution gives away, and it needs neither the CDN nor the resolver to agree to anything.

Running at the client is the point. It needs no cooperation from the CDN, no change at the resolver, and no support from the ISP, which is what made it deployable by an individual user rather than by agreement among providers.

Software

namehelp — a proxying DNS server that keeps the benefits of third-party DNS while avoiding the performance penalty for CDN-hosted content. Ten thousand users within a month of release.

Papers

Content Delivery and the Natural Evolution of DNS — IMC 2012
namehelp: Intelligent, Client-Side DNS Resolution — SIGCOMM 2012 (demo)
Behind the Curtain – Cellular DNS and Content Replica Selection — IMC 2014. Carries the same question into cellular networks, and also belongs to the mobile thread.

Coverage

namehelp was covered by Network World in 2012, and picked up by outlets in France, Turkey, Brazil, Vietnam, Poland, and Russia.

People

Lead & PI

Fabián E. Bustamante (Northwestern University)

Students

Ongoing Work

The questions namehelp raised — where resolution should happen, and what it costs the user when it happens somewhere else — are still open, and two efforts currently under submission continue them: Onoma, and a study of hidden DNS resolvers. Both have been presented as posters.

Decentralization, Privacy and Performance for DNS — SIGCOMM 2021
The Aleph — decoding geographic information from DNS records
AquaLab Research Group

Web Performance | Aqualab - Northwestern University

Mobile and Cellular Networks from the Edge

Project Overview

Cellular Networks in the Internet

Aggregators and Roaming

The Mobile Web

Connectivity in Motion

Papers

Coverage

People

Related Links

namehelp

Overview

The Problem

What namehelp Did

Reception

Privacy

Availability

Papers

Coverage

People

Related Links

Client-Side DNS and Content Delivery

Project Overview

Measuring the Interaction

namehelp

Software

Papers

Coverage

People

Ongoing Work

Related Links