Summary

  • An Internet Society Pulse fellowship project trained a model to distinguish bilateral IXP connections from multilateral route-server exchange using public BGP data and verified records from a handful of exchanges.
  • The 3 September release reports accuracy above 90% on exchanges withheld from training. The checked public project pages do not name the test exchanges, population, geography, class balance, per-class errors or abstentions.
  • Before the result informs policy on resilience or centralization, it needs an applicability card. The card should preserve what was eligible, tested, misclassified and left unknown without exposing private peering contracts.

The strongest sentence in the new Internet Society Pulse article is also the one most likely to travel without its boundary. A classifier trained on a small set of documented Internet Exchange Points maintained accuracy above 90% on exchanges that had been withheld from training.

That is the right kind of test. Checking a model only on relationships it has already seen would say little about transfer. Holding out whole exchanges asks a harder question: can the learned pattern survive a different operating environment?

But “above 90%” is not yet a portable description of the world. The public article does not state how many exchanges were in that test, which regions they represented, how many bilateral and route-server relationships were eligible, or how errors were divided between the two classes. It does not report whether the model can decline to classify an unfamiliar case. Those facts may exist in later or private research material. They are not on the two public project pages checked for this article.

The distinction matters because the release expressly points beyond the laboratory. It says researchers gain an open alternative to an outdated technique and that policymakers concerned with resilience and centralization can gain a more complete picture of traffic flows. The first claim concerns a measurement instrument. The second gives the instrument possible governing weight.

What the classifier is actually separating

At an IXP, two networks can exchange reachability information through a direct bilateral BGP session. They can also connect to a route server, which brokers reachability information among many participants. The Pulse project says the older clue—optional tags carried with routing announcements—has become inconsistent and can produce incomplete or misleading inference.

Its replacement looks at behaviour. The most useful clue described publicly is the number of Internet vantage points that see the same route. An announcement distributed through a route server tends to fan out; a bilateral exchange tends to remain more contained. Public BGP data are joined to verified records from a handful of exchanges, and a classifier learns the difference.

This is an inference about the route-exchange mechanism visible through selected observations. It is not a packet counter and it is not a contract registry.

RFC 7947 makes the boundary unusually clear. A route server brokers BGP reachability but does not forward the traffic itself. It normally leaves its own AS out of the AS path. RFC 7948 adds local export policies, communities, client databases and path-hiding behaviour. Two participants connected to the same broker need not receive identical routes. RFC 9234 can identify Route Server, Route Server Client and Peer roles in BGP policy, but those roles still do not reveal price, ownership or traffic volume.

Accordingly, a correct route-server label cannot prove that the relationship carried significant traffic, improved latency, reduced transit cost, increased dependence or created a single point of failure. A correct bilateral label cannot prove a private circuit, settlement-free terms, exclusivity or resilience. The classes are valuable precisely because they are narrower than those conclusions.

Accuracy and coverage are different accounts

Suppose a test contains nine hundred easy route-server cases and one hundred difficult bilateral cases. A model that labels every case “route server” achieves 90% accuracy while failing the smaller class completely. That is an illustration, not a claim about this project. It shows why one aggregate rate cannot disclose error direction.

For a topology study, the direction can matter more than the average. Calling a bilateral connection multilateral can exaggerate reliance on an IXP-operated broker. Calling a route-server connection bilateral can hide a shared control dependency. Both errors can distort a centralization claim, but in opposite directions.

Coverage adds another denominator. Did the model classify every eligible relationship, only those seen from enough vantage points, or a subset for which exchange records supplied labels? Were ambiguous observations forced into one of two classes, or could they remain unknown? A 92% result on a carefully bounded population and a 92% result after discarding half the difficult cases are not the same evidence.

The release already acknowledges two transfer questions. It calls for broader geographic diversity and for testing whether the patterns remain stable over time. That is good scientific restraint. A policy reader should preserve it, rather than rounding the sentence into “the hidden Internet is now 90% visible.”

The older method offers a useful precedent

CAIDA's 2013 multilateral-peering study did not solve the whole topology either. It used route-server communities, Route Views, RIPE RIS and selected looking glasses to infer 206,000 links at 13 large European IXPs. It published explicit limitations: the method missed bilateral links, depended on communities being present and unfiltered, and concentrated on a region where multilateral peering was prevalent.

The study also separated links from importance. It said traffic carried over those links remained an open question. That sentence prevented an inferred connection count from becoming a traffic-share claim.

The new classifier addresses a real weakness in that older community-based technique. It should inherit the older work's habit of publishing applicability, not its technology. A modern model card for this problem can be much shorter than a paper and still carry the boundaries a policy user needs.

Publish an applicability card before the map travels

The card should begin with the eligible population: collection sources, observation interval, minimum vantage-point evidence, exchange selection rule and the unit being classified. It should name or safely characterize the verified exchanges, their regions and structural features, then separate training exchanges from held-out exchanges.

Next come the labels. State who or what supplied ground truth, when it was valid and whether an IXP could review a disputed classification without revealing a confidential bilateral agreement. Report class counts, per-class precision and recall, the confusion matrix and confidence calibration. Keep an explicit unknown or abstain state and show how many cases enter it.

Finally, record transfer: per-exchange results, performance across geography and exchange size, model and feature versions, data cutoff, drift checks and a retirement trigger. If the model changes, old published maps should keep the version that produced them. If an exchange corrects a label, the correction should propagate without rewriting the historical observation.

None of this gives Internet Society, a researcher or a policymaker authority over private peering. The purpose is the opposite: to stop a public inference from silently acquiring more jurisdiction than its evidence.

Sources