Summary

  • A RIPE Labs account published on 8 September describes a small RIPE Atlas round across ten countries. The traces showed selected landing points, not the platforms’ internal mapping rules.
  • In one access network, separate Google and Meta portal exports showed 72% and 77% within different definitions and time windows. The source explicitly says the figures are not directly comparable.
  • Physical presence, an observed endpoint and a provider aggregate are three different records. None alone proves cache-hit share, cost relief, resilience or control.
  • Operators need a service-specific placement record that joins public measurement to provider-defined scope and an authorised fallback test without pretending the private control plane is public.

An edge is also a decision

A local edge looks tangible: a box in a facility, a route that ends nearby, a shorter round trip. Yet delivery is not selected by distance alone. A platform decides which service or object is eligible, maps a request to an endpoint and chooses what should happen when the local system is full, withdrawn or unavailable. The access operator supplies the site, power, ports, routing and last mile. The platform may still control the decision that turns placement into delivery.

That distinction is the useful part of “The Internet’s New Edge Builders”, published on RIPE Labs on 8 September. Its author, Arman Obosyan, says he ran a small RIPE Atlas round across ten countries in June. Landing points varied by hostname and source network, including between probes in the same country. The result was a diagnostic snapshot. In the source’s own formulation, public measurement showed the selected path but not the internal mapping logic behind it.

This is not a defect in RIPE Atlas. A traceroute is an observation made from a defined probe, toward a defined target, at a defined time, with a measurement configuration and a returned result. RIPE Atlas documents those inputs and notes that result structures can vary with probe firmware. The measurement can be preserved and repeated. What it does not contain is a platform’s complete eligibility table, cache state, private-backbone load or commercial rule.

Two percentages that must remain separate

The SkyTel example gives the boundary a physical setting. The RIPE Labs account says Google Global Cache and a Meta appliance operate inside the same access network, AS49628. SkyTel provides space, power, routing and local connectivity. Google and Meta determine what their systems may serve, which users reach them and how traffic moves when the local system is unavailable.

The account reports that named GGC assets represented 72% of delivery within a Google portal split from 5 August to 4 September 2026. It separately reports 77% for the Meta appliance within its portal split from 29 August to 5 September. SkyTel authorised publication of the aggregates, according to the article.

Those numbers invite a neat comparison that the evidence does not permit. The periods differ. The provider definitions differ. Neither private export is present here. The two shares must not be added, averaged or promoted into a measure of all SkyTel traffic. Each is evidence only inside its provider’s stated population and interval.

The same discipline applies to a RIPE Atlas result. A trace toward a selected hostname is not the denominator of either portal. It can show an endpoint reached from a probe. It cannot establish that every request for a platform, every subscriber or every object used the same edge. Nor can a local route establish that the cache produced a lower bill: committed transit, internal transport, power, ports and standby capacity may set the economic result elsewhere.

A placement claim needs its own record

An operator deciding whether a first-party edge has changed the network should preserve a record at the level of the service, not the company logo. It should name the tested hostname or object class, probe and source network, address family, measurement identifier, observation time, selected endpoint and visible path. If a provider aggregate is used, the record should also name its denominator, eligibility rule and reporting window.

Unknowns should remain fields, not be filled with inference. Cache-hit share may be unknown. Private-backbone carriage may be unknown. The reason for a mapping choice may be unknown. A useful record says so, then separates the operator’s responsibilities for hosting and local routing from the platform’s responsibilities for software, eligibility, mapping and withdrawal.

Failover requires a different observation. An authorised test window can record the fallback path, upstream demand, latency, loss and capacity assumption when the local system is bypassed. A normal-path trace cannot certify that state in advance. Neither can a provider dashboard percentage prove that transit can safely be removed.

This placement record is an editorial proposal from Theo March, not a requirement announced by RIPE NCC, SkyTel, Google or Meta. Its value is narrower: it keeps a reproducible public observation beside, rather than in place of, the private evidence needed for an operational decision.

What the sources do and do not establish

The RIPE Labs account establishes the author’s reported field round, the SkyTel configuration, the two bounded portal aggregates and their non-comparability. RIPE Atlas documentation establishes the measurement controls and result-format boundary. Meta’s own engineering account describes its broad edge and point-of-presence build-out. None of these sources discloses the private mapping algorithms, proves a universal edge pattern, measures all traffic, demonstrates a saving or reports an outage, breach or policy violation.

Sources