{% extends "base.html" %} {% block content %}

What is this?

This tool allows you to find "good" peerings for dn42, by measuring the latency from various points in the network towards you.

How does it work?

  1. you enter your (Internet) IP address or hostname
  2. various routers participating in dn42 will ping you over the Internet
  3. after a short while, you get back all the latency results
  4. you can then peer with people close to you (low latency)

Target:

Why look at latency?

The problem of peering quality

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.

Looking at latency

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.

Situations this tool aims to solve

To sum up, this tool can help in several situations:

  1. Detecting when somebody is in the same datacenter as you, so that it's mostly free to peer
  2. When you are far from everybody, find the peering with the lowest latency

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).

I want to participate!

This tool relies on a pool of workers, all over dn42, that process requests, perform ping measurements, and report back the results. You're welcome to add your own machines to the pool!

You need to separately register each computer that will provide measurements. Manual validation is performed for each registration.

The contact information is free-form, and will be shown to users when they launch measurements. This allows users to contact you if they want to peer.

Machine name (required):
Mean of contacting you, like IRC nick, mail address, ... (optional):

Known issues

Current limitations:

  1. Only the average RTT is measured, we should include other simple statistics (jitter, min/max RTT, packet loss)
  2. The API is not documented (just look at the code)
Unavoidable facts that cannot be fixed:
  1. Latency measured today might be meaningless tomorrow, as routing on the Internet is always changing
  2. Low latency does not guarantee high throughput

Source code

The source code is available here

Privacy

Privacy for users of this service:

  1. Only participants in the measurement pool have access to your IP address (so that they can ping you, obviously)
  2. New participants (see below) are moderated manually
  3. Results have an unpredicatble URL. Of course, if you share the link to the results, anybody can see them.
Privacy for participants in the measurement pool:
  1. Users only get access to the machine name and contact information you provided
  2. In particular, users don't get access to your IP address (of course, users can always use tcpdump to see where do the ping requests come from)

{% endblock %}