about.html 2.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384
  1. {% extends "base.html" %}
  2. {% block content %}
  3. <h2>Why look at latency?</h2>
  4. <h3>The problem of peering quality</h3>
  5. <p>Determining what is a "good" peering in dn42 is quite difficult: many
  6. criteria come into play, such as latency, jitter, capacity, packet loss,
  7. stability, or even the price your ISP will pay (peering vs. transit).</p>
  8. <p>On the other hand, a "bad" peering is easy to picture: if you are in
  9. Paris and peer with somebody in Australia, then you might end up doing
  10. Paris → Australia → Hamburg if you want to send packets to Germany. This
  11. does not feel very efficient. People usually solve this problem with
  12. policy routing (local preference and path-prepending). But it's still a
  13. good idea to build good links and avoid terrible links.</p>
  14. <p>Of course, you need to build long-distance links sometimes. Otherwise,
  15. dn42 would be made of small, independent islands. This tool can also help
  16. you to choose the best long-distance links.</p>
  17. <h3>Looking at latency</h3>
  18. <p>Latency is actually a good enough indicator of "distance". For
  19. instance, two machines located at the same ISP are expected to have low
  20. latency towards each other. On the other hand, a latency above 200 ms
  21. usually indicates that the two machines are quite far away geographically
  22. (but not always).</p>
  23. <p>Additionally, latency can vary widely for long-distance links,
  24. depending on the quality of transit and peering agreements between ISPs.
  25. For instance, to reach a specific destination in Singapore from France, we
  26. have the following latency as of September 2014:</p>
  27. <table>
  28. <tr>
  29. <th>ISP</th>
  30. <th>Latency</th>
  31. </tr>
  32. <tr>
  33. <td>Online</td>
  34. <td>177 ms</td>
  35. </tr>
  36. <tr>
  37. <td>tetaneutral.net</td>
  38. <td>264 ms</td>
  39. </tr>
  40. <tr>
  41. <td>SFR</td>
  42. <td>267 ms</td>
  43. </tr>
  44. <tr>
  45. <td>Free</td>
  46. <td>365 ms</td>
  47. </tr>
  48. <tr>
  49. <td>OVH</td>
  50. <td>402 ms</td>
  51. </tr>
  52. </table>
  53. <p>Of course, this is only a snapshot, and reflects the situation for a
  54. specific source and destination. Still, the latency more than doubles
  55. depending on the ISP, which in this case strongly favours a peering with
  56. somebody hosted by Online instead of OVH.</p>
  57. <h3>Situations this tool aims to solve</h3>
  58. <p>To sum up, this tool can help in several situations:
  59. <ol>
  60. <li>Detecting when somebody is in the same datacenter as you, so that
  61. it's mostly free to peer</li>
  62. <li>When you are far from everybody, find the peering with the lowest
  63. latency</li>
  64. </ol>
  65. </p>
  66. <p>By building low-latency links in dn42, it's actually possible to have
  67. lower latency in dn42 than over the Internet, for the same destination
  68. (it's called <em>detour routing</em>).</p>
  69. {% endblock %}