> VPNs pay for address delegation, I would guess.

Depends on how you look at it. I havent been in the NSP industry for a decade but usually customers would get a /24 or /22 of the NSPs allocation for free as part of the actual network service cost. Once you're bigger than that the customer (eg VPN provider) should be getting allocations/assignments directly. https://www.arin.net/resources/registry/reassignments/#alloc...

> I'll need to check whether any of the ping services allow TCP or UDP. But yes, ICMP being slow just reduces the chance of finding superluminal signal velocity.

For your methodology its probably fine. But you can see intersting artifacts in advanced networks. Like ICMP might be terminated (replied to) early at teh network edge, where actual TCP session setup happens deeper inside, and then layer 7 (http) is tunneled even further. So ping (icmp), traceroute (udp), and wireshark (tcp/http) would show different latencies by a few ms.

>> Many/most NSPs handily include some sort of location identifier (like iata code) in their device names.
> I'm not sure what that means. Where would I get that information?

The DNS records (PTRs) on the 'point to point' interconnects is where I would look. Both sides are probably a /32 that is owned by the NSP. For general sanity and ease of use they populate those PTRs with operational data. Try https://www.caida.org/publications/papers/2019/learning_rege... or http://www.caida.org/~mjl/pubs/rnc.pdf

The ICMP ttl exceeded replies from traceroute (hopefully) include those device or port addresses. And a quick DNS lookup will give you the PTR/A record. From here in australia to eu1.vyprvpn.com I pass through:

> 4 be10-3999.core1.vdc01.syd.aussiebb.net (180.150.2.88) 7.169 ms 5.369 ms 6.191 ms
> 5 be1.bdr1.coresite-sv1.sjc.aussiebb.net (180.150.2.107) 164.582 ms 161.045 ms 153.770 ms

This is a single layer 3 link from Sydney Australia (SYD) to CoreSite SV1 in San Jose (SJC) California.

> 6 ce-0-17-0-0.r01.snjsca04.us.bb.gin.ntt.net (128.242.179.33) 153.749 ms 153.840 ms 157.461 ms

Where its handed off to an NTT backbone device; probably site #4 in San Jose CA (snjsca04), router #1 (r01), interface ce-0-17-0-0.

> 7 sjo-b21-link.telia.net (62.115.12.52) 157.553 ms 164.782 ms 166.938 ms
> 8 nyk-bb2-link.telia.net (62.115.119.228) 892.775 ms *
> 9 ldn-bb3-link.telia.net (62.115.113.21) 528.821 ms 427.296 ms 405.795 ms
> 10 adm-bb3-link.telia.net (62.115.113.210) 311.039 ms

And I don't know telia naming offhand, but this looks like San Jose border router #21 (sjo-b21), across their backbone of New York (and/or Newark?) router 2 (nyk-bb2), London and Amsterdam.

> 11 adm-b2-link.telia.net (62.115.141.39) 308.913 ms
> 12 ic-311014-adm-b2.c.telia.net (80.239.128.234) 307.252 ms 410.241 ms 409.498 ms

And here we see a single Amsterdam border device or site (adm-b2) with what looks like two different interfaces. Im guessing #12 has a circuit identifier or similar, with the acutal end customer on the other side there.

> I did find quite a few minrtts under 1 msec. Suggesting that the VPN server and ping probe are very close. Perhaps hosted in the same facility. But I didn't know where to look for relevant information.

Yes. As a rule of thumb <1ms is same building or location, ~2-3ms is same metro area or a very large network topology in between the two. For more information I'd probably look a the device path (traceroute) or the BGP announcements to see what addresses are announced, and by which networks. You can infer network topology from the AS Path in the BGP announcements. All of that should be available from looking glasses or groups like caida & cymru.

> I'm not sure what this means. Wouldn't adding a tunnel just increase latency? Or rather, is there any way that using "underlying networks (ie MPLS, or GRE tunnels)" could obscure the use of PoPs?

The tunnel itself wouldnt necessarily add meaningful latency or interfere with your methodology. But it would obscure the topology that you'd see at the IP/ICMP (trceroute or BGP) level. So maybe the router is in AMS-IX, but that router could tunnel the packets to another device in Germany. Traceroute or DNS might not show that, but you'd see a latency anomaly there. Related to my geo-political comment if a user cares about law enforcement the physical location of the end device could very much matter.