This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] Anchors as target hosts for SLA
- Previous message (by thread): [atlas] Anchors as target hosts for SLA
- Next message (by thread): [atlas] Probe does not request IPv4 address via DHCP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Colin Petrie
colin at spakka.net
Tue Jun 6 20:05:04 CEST 2017
On 06/06/2017 19:03, Gert Doering wrote: > On Tue, Jun 06, 2017 at 06:48:33PM +0200, Antonio Prado wrote: >> This Internet transit should meet the following criteria: >> >> average round trip delay (echo request, echo reply) toward >> $NEAREST_ATLAS_ANCHOR should be less than 100ms on a 10k packets stream >> of pings; packet loss equal or less than 0.02% >> >> pros, cons, recommendations? > > Too simple. What if that anchor is down, or the anchor host network has > a network bottleneck towards the transit provider you are using? > > So you need something that averages over multiple anchors - we used to > do that via TTM ("if our TTM hosts can reach more than 80% of all other > TTM hosts, we declare the Internet to be in good working condition" - note > the "80%", because something is always down somewhere) but haven't come > around to define & implement something based on ATLAS yet. You could also check the new stability system-tags on the anchors. That way you only compare with the anchors that are believed to currently have 'good' reachability. Cheers, Colin
- Previous message (by thread): [atlas] Anchors as target hosts for SLA
- Next message (by thread): [atlas] Probe does not request IPv4 address via DHCP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]