Measuring the Earth with Traceroute (2002)(arxiv.org)
arxiv.org
Measuring the Earth with Traceroute (2002)
https://arxiv.org/abs/physics/0208087
7 comments
If there was a shorter route and you took longer one you are dealing with suboptimal routing :)
However, "is a bit sad in a way" part of sentence is interesting one. Edge services hosted within AWS/Cloudflare/Akamai improved customer experience significantly given that waiting for trans-Atlantic or trans-Pacific latencies is not thing any more.
However, "is a bit sad in a way" part of sentence is interesting one. Edge services hosted within AWS/Cloudflare/Akamai improved customer experience significantly given that waiting for trans-Atlantic or trans-Pacific latencies is not thing any more.
Routing is money, ISPs need to pay more for better routing
It just shows how much the internet has changed. Now all our online traffic is increasingly being limited to a smaller and smaller set of networks/companies. You get less of a "We're a community of networks all throwing packets around for each other to make the internet happen" feeling and more of a "We're just another source of data to mine by a small number of cloud services." sort of feeling I guess.
> with suboptimal routing
Or, perhaps optimal surveillance [1][2]. I can only assume this sort of thing has expanded substantially since then.
1. https://theintercept.com/2018/06/25/att-internet-nsa-spy-hub...
2. https://tcf.org/content/report/surveillance-without-borders-...
Or, perhaps optimal surveillance [1][2]. I can only assume this sort of thing has expanded substantially since then.
1. https://theintercept.com/2018/06/25/att-internet-nsa-spy-hub...
2. https://tcf.org/content/report/surveillance-without-borders-...
In most cases, route from Japan to Europe is routed via US. It takes over 200ms. CDN improved our life much but I agree which is a bit sad in a way.
One thing about traceroute that I doubt most casual users think about (maybe I'm wrong) is that its output only shows you the forward path. That is, it shows you the path your packet takes from when it leaves your machine to when it gets to the destination. The path that a response packet originating at that destination and travelling back to you can take a different path (sometimes wildly different) and - while you'd see that captured in latency - you wouldn't see it captured in the list of routers.
So a packet from Seattle to Hawaii may take the most direct undersea cable, but the response packet may be routed through California, adding significant geographic distance.
So a packet from Seattle to Hawaii may take the most direct undersea cable, but the response packet may be routed through California, adding significant geographic distance.
A similar mistake can easily be made when using iperf to measure throughput or identify performance problems.
In TCP mode the results reflect a combination of forward and return path effects, though the return path usually has less effect on total throughput than forward path. Only with UDP mode can you accurately measure unidirectional path performance.
In TCP mode the results reflect a combination of forward and return path effects, though the return path usually has less effect on total throughput than forward path. Only with UDP mode can you accurately measure unidirectional path performance.
This comment is spot on. This is asynchronous nature of the computer networks. While it is easy to control the path within smaller or enterprise networks, it is very likely that the reverse path on the internet is going to be different compared to forwarding path. Following that, the real challenge is, in case that you are dealing with some issue, to detect where the issue is, given that it might be happening on the reverse path that you don't have visibility into.
This is an interesting and fun class exercise but the results were much worse than I expected.
I'm reminded of Carl Sagan's Cosmos where he explains how Eratosthenes calculated the radius of the earth, to a great degree of accuracy, by comparing the shadows of two distant obselisks. I wonder if there is a modern equivalent that would give similar accuracy by observing side-effects of our telecom architecture, or our other very futuristic systems in comparison to Eratosthenes' obelisks.
I'm reminded of Carl Sagan's Cosmos where he explains how Eratosthenes calculated the radius of the earth, to a great degree of accuracy, by comparing the shadows of two distant obselisks. I wonder if there is a modern equivalent that would give similar accuracy by observing side-effects of our telecom architecture, or our other very futuristic systems in comparison to Eratosthenes' obelisks.
taking a geostationary satellite and measuring the delay it takes from two positions and assuming a perfectly round earth should get you there
mmm that is pretty cool but I feel like that's cheating if I can't do it personally from my computer.
Can traceroute be used to prove that the Earth is spherical? Or at least show the statistical probability that it is shaped more like a sphere than a flat surface?
Not sure about definitive proof, but one could trace between a few directly-connected nodes i.e. along the pacific rim. Then, making the same assumptions as the article (i.e. cables lie along great circles, most of the measured time is spent in traversing the cable, etc), demonstrate that those connected nodes do not lie on a flat plane.
The more nodes one has mapped, (i.e. distance measured to surrounding nodes) the less likely one is able to orient those nodes into any shape other than a sphere.
The more nodes one has mapped, (i.e. distance measured to surrounding nodes) the less likely one is able to orient those nodes into any shape other than a sphere.
I think yes. If we assume reliable conversion of traceroute results to implied distances, and can generate selected data (routes) of our choice. That is, we can see results of remote hops that aren't directly connected to us. Then, ultimately, the resulting matrix of results would (mathematically, ++) conform to a spheroidal shape and no other.
++ think Map Projections, and the associated math.
++ think Map Projections, and the associated math.
Does graphviz take edge lengths as input? One could let it do its magic and should, for correct data, get a map.
(I've used it with street intersection data from Wikidata and it came up with a surprisingly good map of Berlin, only mirrored.)
(I've used it with street intersection data from Wikidata and it came up with a surprisingly good map of Berlin, only mirrored.)
In architecture school, my partner had to map a landscape using old-fashioned triangulation: using measurements between fixed points to build a map of triangles. The problem is, your measurements are usually a bit off (e.g. you measure from different points on a tree's trunk, the tape was sagging, you assume measurements are planar but there is topography, etc. If you aren't careful about the order in which you build your map, errors compound.
We developed some software to optimize for least squared error and then plot points. Not a sophisticated algorithm, but it worked well! https://github.com/cproctor/triangulation
We developed some software to optimize for least squared error and then plot points. Not a sophisticated algorithm, but it worked well! https://github.com/cproctor/triangulation
Doesn't traffic and network device CPU load make all this hogwash? Just asking for a friend.
It'll add some minor noise but if you suspect it to be at significant factor you can effectively completely eliminate the noise by picking the lowest values over multiple runs. Something like mtr will report jitter statistics for you.
I miss xtraceroute.
These days traceroute to a random .jp or .au just gets you to the nearest CloudFlare or AWS, which is a bit sad in a way.