Title: LARS: Keeping Local Traffic Local with Latency-Aware Route Servers at IXPs
Authors: David de Andres Hernandez, Yasin Alhamwy, Daniel Wagner, Maximilian Stephan, Matthias Wichtlhuber, Oliver Hohlfeld
Introduction
This paper studies a practical routing problem at Internet Exchange Points (IXPs): BGP is latency agnostic. Inside a large IXP layer-2 domain, near and far exits can look equally close to BGP because both appear as one-hop paths across the peering LAN. As a result, traffic that should stay local may be sent to a remote point of presence, even across continents. This is especially problematic for anycast services such as CDNs and DNS, where the goal is to attract users to nearby replicas.
LARS addresses this problem by adding latency awareness to IXP route servers. Route servers are natural control points because they collect routes from many IXP members, perform best-path selection, and redistribute selected routes to members. Instead of changing BGP or requiring bilateral coordination between members, LARS works within the existing route server infrastructure and lets each member decide how much latency-aware control it wants to enable.
Key idea and contribution
The key idea is to measure path RTTs from the route server perspective and use these measurements during route export. LARS supports two main functions. First, members can define a latency radius, so routes whose measured RTT exceeds the configured threshold are not exported to that member. Second, when multiple valid paths exist within the policy envelope, LARS can prefer lower-latency paths by influencing BGP best-path selection.
The paper makes four main contributions. C1 is a large-scale study of path diversity and latency at IXP route servers, based on looking glass data from 790 route servers across 34 IXP operators. C2 is a drop-in RTT-aware route server design that can be integrated into existing route server toolchains without protocol or router changes. C3 is a production-scale validation using real data from a large IXP. C4 is the release of measurement artifacts and implementation components for reproducibility.
Technically, LARS consists of a measurement component and a routing decision component. The measurement component uses ADD-PATH to obtain all candidate paths and an enhanced ZMap implementation to measure RTTs over specific next hops. The routing component converts measured RTTs into BGP communities or local preference values. Import filters tag routes with RTT information, while export filters either suppress high-latency routes or prefer lower-latency ones. Importantly, LARS does not invent new routes; it only filters or reorders routes that members would already be allowed to receive.
Evaluation
The evaluation combines global measurements with a production-scale deployment study. The global analysis shows that path diversity and latency inflation are common at IXPs. For large route servers, a significant fraction of prefixes have alternate paths, meaning that there is real opportunity for latency-aware selection. The geolocation-based analysis also shows that long-tail latency routes exist even at smaller IXPs, while large IXPs have more stable and predictable long-tail behavior.
In the production-scale evaluation, the authors collected data for 54 days at a large IXP, covering about 397K distinct prefixes and generating 14.15 billion RTT samples across 84 scan rounds. The measurements show that RTT estimates are stable over time: the minimum RTT estimator is more robust than mean or maximum RTT because it better approximates propagation delay and avoids short-term congestion noise. More than 95% of measurable prefix-next-hop pairs remain measurable for over 30 days.
The results show that latency-radius filtering can reduce tail latency while affecting very little real traffic. For example, a 200 ms radius can remove a large portion of long-tail latency routes, while the suppressed routes carry almost no traffic. LARS also provides measurable path optimization gains: around 5% of prefixes with alternate paths obtain at least 10% RTT improvement, and some cases see improvements above 10 ms or even up to 60 ms. The system overhead is modest: the route server configuration grows by about 7%, and convergence time increases only slightly.
Personal thoughts
My main takeaway is that LARS is valuable because it turns a long-standing routing inefficiency into a deployable IXP mechanism. The paper does not propose a new Internet routing protocol or require every member to coordinate with every other member. Instead, it uses the route server as an existing operational point and adds latency awareness within the boundaries of current routing policy.
I also think the paper is a good example of practical systems research. It starts from a real operational problem, validates the problem with large-scale measurement, designs a conservative mechanism, and evaluates both performance benefits and deployment overhead. This makes the work convincing not only as a routing optimization technique, but also as an example of how to introduce new capabilities into critical Internet infrastructure.
One broader implication is that IXPs should not be viewed only as places where networks connect. Once networks are connected, path quality, geographic location, business policy, and user experience still interact in complex ways. LARS shows that route servers can play a more active role in managing these interactions, while still preserving member control and operational safety.