Determining what is a "good" peering in dn42 is quite difficult: many criteria come into play, such as latency, jitter, capacity, packet loss, stability, or even the price your ISP will pay (peering vs. transit).
On the other hand, a "bad" peering is easy to picture: if you are in Paris and peer with somebody in Australia, then you might end up doing Paris → Australia → Hamburg if you want to send packets to Germany. This does not feel very efficient. People usually solve this problem with policy routing (local preference and path-prepending). But it's still a good idea to build good links and avoid terrible links.
Of course, you need to build long-distance links sometimes. Otherwise, dn42 would be made of small, independent islands. This tool can also help you to choose the best long-distance links.
Latency is actually a good enough indicator of "distance". For instance, two machines located at the same ISP are expected to have low latency towards each other. On the other hand, a latency above 200 ms usually indicates that the two machines are quite far away geographically (but not always).
Additionally, latency can vary widely for long-distance links, depending on the quality of transit and peering agreements between ISPs. For instance, to reach a specific destination in Singapore from France, we have the following latency as of September 2014:
| ISP | Latency |
|---|---|
| Online | 177 ms |
| tetaneutral.net | 264 ms |
| SFR | 267 ms |
| Free | 365 ms |
| OVH | 402 ms |
Of course, this is only a snapshot, and reflects the situation for a specific source and destination. Still, the latency more than doubles depending on the ISP, which in this case strongly favours a peering with somebody hosted by Online instead of OVH.
To sum up, this tool can help in several situations:
By building low-latency links in dn42, it's actually possible to have lower latency in dn42 than over the Internet, for the same destination (it's called detour routing).
{% endblock %}