Summary

  • Across 76,700 successfully measured paths, 80.5% reported a 1,500-byte PMTU; the access-forward campaign showed substantially more non-1,500 results than the core or web-serving campaigns.
  • Among 10,989 bidirectional paths, 12.12% differed by direction; 18.5% of the 63,389 paths with MSS observations differed from measured PMTU. Neither percentage is a traffic-weighted Internet-wide rate.

A majority is useful only when its denominator travels with it. In “The Internet’s Path MTUs: How Big Can You Go?”, researchers report 76,700 paths where RIPE Atlas successfully discovered a path maximum transmission unit between February and April 2026. They observed 97 distinct PMTU values. The most common was 1,500 bytes, at 80.5%; 1,492 bytes accounted for 11.7%, while 1,480 and 1,476 bytes each represented about 1.5% and 1.4%.

Those figures describe measured paths, not the share of packets, customers or Internet traffic using each size. The distinction matters most at the edge. Across the access-forward campaign, 20.6% of observed paths had a non-1,500-byte result. The corresponding shares were below 4% in the web-serving campaign and below 3% in the core campaign. The campaigns use different vantage points and selection rules; their contrast is a reason to inspect the access path, not a controlled estimate of how much “the edge” differs from “the core.”

Direction adds another qualification. In a subset of 10,989 paths measured both ways, 12.12% had different PMTUs in the two directions. Among those asymmetric cases, the reverse direction had the larger value 92.3% of the time. In 64.1% of asymmetric paths, the reverse PMTU was at least 1,500 bytes while the forward PMTU was lower. A sender that assumes symmetry from a destination-wide number can therefore overstate what its own direction supports. The result does not say how much traffic traversed those paths or how often an application failed.

A second comparison tests a familiar shortcut: inferring an upper packet size from TCP’s advertised maximum segment size. The study found MSS observations on 63,389 paths; 51,644 (81.5%) matched the measured PMTU, leaving 18.5% of those paths with a mismatch. Across all 63,389 paths, the paper calculates approximately 11.26% underestimates and 7.2% overestimates, treating measured PMTU as the comparison baseline. Those are discrepancies between observation methods, not an application loss rate and not proof that one signal is universally wrong. MSS is informative, but it is not a direct receipt for every path’s network-layer ceiling.

The measurement design helps explain both the strength and the boundary of the result. The team ran separate campaigns involving core anchors, forward and reverse access paths, and web-serving infrastructure. Probes had to retain a stable tag for 90 days; measurements ran weekly over four weeks and were repeated about a month and a half later. Among paths remeasured, reproducibility exceeded 96%. That is encouraging evidence that the observed values were repeatable under the study’s conditions. It does not make the participating probes a random sample of the Internet.

RIPE Atlas depends on volunteer probes and anchors, and coverage is uneven. The authors note heavier representation among European and US providers and cloud services, different geographic density, and no weighting by traffic volume. Their network attribution uses BGP-derived ASN mappings; private-address break points were excluded from network-level analysis, while traceroute and ICMP filtering limit certainty about where some constraints occur. Patterns near a customer-premises boundary can suggest an access-device or encapsulation effect. They do not identify a responsible operator or box without direct evidence.

For an engineering team, the practical reading is modest but useful: 1,500 bytes is a strong starting hypothesis for many observed paths, while a directional and vantage-specific check remains necessary for the path that carries the workload. The evidence supports testing both directions and retaining provenance for each observation—endpoint, time, path or flow identity, and encapsulation context. It does not support replacing measurement with one global cap, nor does it say that a non-1,500 PMTU means an application cannot work.

Sources: Binkle et al., “The Internet’s Path MTUs: How Big Can You Go?” (IMC ’26); MPI paper record and preprint; Internet Society Pulse, “How Big Can a Packet Be?”; RIPE93 agenda; RIPE Atlas overview; RFC 1191; RFC 8201; RFC 8899.