Anchors as target hosts for SLA
hi, do you think could be a good idea to use Ripe Atlas Anchors as target hosts for measuring respect of SLA terms of an Internet transit? SLA example 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? thank you -- antonio
Hi, 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. With the large amount of anchors nowadays, just using the anchor matrix is actually quite similar to what TTM had, just better... :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 6/6/17 7:03 PM, Gert Doering wrote:
Too simple. What if that anchor is down, or the anchor host network has a network bottleneck towards the transit provider you are using?
well, I selected two anchors placed in two different NAPs where all ISPs in my scenario are present. so, not a big concern if one anchor is down. the other issue about possible bottlenecks is not applicable in that context.
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.
I like the idea and it should definitely be the way to go. thank you -- antonio
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
participants (3)
-
Antonio Prado -
Colin Petrie -
Gert Doering