<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Really good question..</div>
<div><br>
</div>
<div>An ISP or organization is hard pressed to capture metrics outside their system I contend � unless you pay for a commercial service and even then you don't get the span of coverage that Atlas has.</div>
<div><br>
</div>
<div>What I have done is use the probes to be part of the overall measurements and a way to accrue credits to run tests to monitor
<strike>availability</strike> reachability qualities OUTSIDE my overall network.</div>
<div><br>
</div>
<div>If your 'network' spans multiple regions/geo-locations, have a few probes and capture reachability metrics to capture quality of experience as a matter of operation. </div>
<ul>
<li>Often it's "I think it's slow, it must be the network"</li><li>Or "I can't get to X but get to Y, it must be the network"</li></ul>
<div>But is it really 'the network' all the time? </div>
<div>Highly unlikely, but when it is, how could you triangulate a problem that is intermittent by time and locale?</div>
<div>If you have measurement nodes (probes), this becomes slightly easier and is one datapoint to add to the diagnosis mix.</div>
<div>They aren't a replacement for Nagios/Big Brother/PerfSONAR infrastructures, but there is no way you can economically achieve the same network coverage as Atlas does. </div>
<div><br>
</div>
<div>For example, I have a service located in Canada and identified Canadian probes to attempt to do a certificate check as a way to exhibit reachability (not a content check) to my host. This allows me to assess 'How reachable am I across Canada from these
probes to my host?'. I have done the same for 'outside the country to my host' reachability as well.</div>
<div><br>
</div>
<div>The other aspect is that probes can be operated on consumer connections. These allow a true 'end to end' measurement that would more accurately depict user experience � not only from Internet exchange(IX) to IX. This is sometimes overlooked.</div>
<div><br>
</div>
<div>To sum it up: </div>
<ul>
<li>The probes add additional capabilities for network measurement and diagnosis of problems.
<ul>
<li>understand your use cases & have a metrics plan to begin with.</li></ul>
</li><li>They can run autonomously without you setting up infrastructure regardless of IX or home cable modem install site.
<ul>
<li>Slim to small operational management overhead.</li></ul>
</li><li>They allow you to tap into a global measurement network without having to run the backend stats aggregation at scale.
<ul>
<li> a very big plus!</li></ul>
</li></ul>
<div><br>
</div>
<div>Chris.</div>
<div>
<div>
<div>
<div>___________________________________________________________________________________________</div>
<div>Chris Phillips </div>
<div>Technical Architect, Canadian Access Federation | CANARIE| <a href="mailto:chris.phillips@canarie.ca">chris.phillips@canarie.ca</a> | W: 613.943.5370 |GPG: 0x0380811D </div>
</div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>RIPE-Atlas-Ambassadors <<a href="mailto:ripe-atlas-ambassadors-bounces@ripe.net">ripe-atlas-ambassadors-bounces@ripe.net</a>> on behalf of "<a href="mailto:dp@datasoftcomnet.com">dp@datasoftcomnet.com</a>" <<a href="mailto:dp@datasoftcomnet.com">dp@datasoftcomnet.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, August 25, 2015 at 12:18 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:emile.aben@ripe.net">emile.aben@ripe.net</a>" <<a href="mailto:emile.aben@ripe.net">emile.aben@ripe.net</a>>, "<a href="mailto:sebastian@nzrs.net.nz">sebastian@nzrs.net.nz</a>" <<a href="mailto:sebastian@nzrs.net.nz">sebastian@nzrs.net.nz</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:ripe-atlas-ambassadors@ripe.net">ripe-atlas-ambassadors@ripe.net</a>" <<a href="mailto:ripe-atlas-ambassadors@ripe.net">ripe-atlas-ambassadors@ripe.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [RIPE Atlas Ambassadors] Deploying RIPE Atlas probes in more locations and networks<br>
</div>
<div><br>
</div>
<div>
<div>
<div>Hello all, </div>
<div>Can someone share an elevator pitch on why an ISP or an organisation that is on 24/7 needs to put a probe in their network. </div>
<div>What are the benefits they would get? </div>
<div>Has someone prepared a case study. </div>
<div><br>
</div>
<div id="composer_signature">
<div style="font-size:9px">Regards DP </div>
<div style="font-size:9px">9849111010. </div>
<div style="font-size:9px"><br>
</div>
<div style="font-size:9px">Sent from my phone. Please excuse brevity and typos if any. </div>
</div>
<br>
<br>
<div style="font-size:100%;text-align:left;color:#000000">-------- Original message --------<br>
From: Emile Aben <<a href="mailto:emile.aben@ripe.net">emile.aben@ripe.net</a>> <br>
Date: 25/08/2015 09:25 (GMT+05:30) <br>
To: Sebastian Castro <<a href="mailto:sebastian@nzrs.net.nz">sebastian@nzrs.net.nz</a>>
<br>
Cc: <a href="mailto:ripe-atlas-ambassadors@ripe.net">ripe-atlas-ambassadors@ripe.net</a>
<br>
Subject: Re: [RIPE Atlas Ambassadors] Deploying RIPE Atlas probes in more locations and networks
<br>
<br>
</div>
On 24/08/15 23:53, Sebastian Castro wrote:<br>
> <br>
> <br>
> On 24/08/15 11:27 pm, Vesna Manojlovic wrote:<br>
>> Dear ambassadors,<br>
> <br>
> Hi Vesna:<br>
> <br>
>><br>
>> You�ve helped us do a great job in distributing RIPE Atlas probes to<br>
>> many networks and regions of the world, but we still have work to do!<br>
>> There are a few ways to find out exactly where we need your help:<br>
>><br>
>> 1) Networks with the most users and fewest probes<br>
>><br>
>> In order to increase topological diversity, it would be good to "target"<br>
>> the users of the networks that don�t have a lot - or any - coverage.<br>
>><br>
>> This RIPE Labs article lists the top 20 ASNs:<br>
>> <a href="https://labs.ripe.net/Members/emileaben/improving-ripe-atlas-coverage-what-networks-are-missing">
https://labs.ripe.net/Members/emileaben/improving-ripe-atlas-coverage-what-networks-are-missing</a><br>
>><br>
>><br>
>> Or you can see the raw-text table here, sorted by the network size:<br>
>> <a href="http://sg-pub.ripe.net/emile/atlas_eyeball_coverage.txt">http://sg-pub.ripe.net/emile/atlas_eyeball_coverage.txt</a><br>
>><br>
> <br>
> Emile's work is really valuable and much appreciated. Is it possible to<br>
> have a date of generation on that file? It seems to be the same as few<br>
> months ago, considering we have deployed probes in the last two months<br>
> that increase coverage.<br>
<br>
This was a one-off, timestamp on the file says I did that on 26 June.<br>
I've just put a new one here:<br>
<a href="http://sg-pub.ripe.net/emile/atlas-coverage/">http://sg-pub.ripe.net/emile/atlas-coverage/</a><br>
<br>
>> 2) Comparing population density with the distribution of RIPE Atlas probes<br>
>><br>
>> Emile Aben used CartoDB to plot, population and probe density on the<br>
>> same map:<br>
>> <a href="https://emileaben.cartodb.com/viz/3caa5144-823e-11e4-8025-0e018d66dc29/public_map">
https://emileaben.cartodb.com/viz/3caa5144-823e-11e4-8025-0e018d66dc29/public_map</a><br>
>><br>
>><br>
>> <a href="https://labs.ripe.net/Members/emileaben/distribution-of-ripe-atlas-probes">
https://labs.ripe.net/Members/emileaben/distribution-of-ripe-atlas-probes</a><br>
>><br>
>> 3) Comparing coverage between countries<br>
>><br>
>> This map shows the percentage of probes per country:<br>
>> <a href="https://atlas.ripe.net/results/maps/density/">https://atlas.ripe.net/results/maps/density/</a><br>
>><br>
>> Whichever method you choose, we trust your instincts and your knowledge<br>
>> of the local community to make the right decision and give probes to the<br>
>> best people!<br>
> <br>
> We have a different method, that uses address space to determine which<br>
> ASNs are relevant to cover.<br>
> <br>
> The eyeball method works for ISP that serve customers, but not for those<br>
> that provide transit. Our methodology, that picks a BGP table dump and<br>
> calculates the ratio of /24 versus number of probes helps us to have<br>
> more coverage and to quickly identify targets.<br>
<br>
Heh. We had a discussion last week in the office which boiled down to<br>
pretty much what you describe here, as an alternative to 'eyeball' data.<br>
I expect more in this space soon :)<br>
<br>
Cheers and many thanks to all our ambassadors for the great work they<br>
are doing!<br>
Emile<br>
<br>
_______________________________________________<br>
RIPE-Atlas-Ambassadors mailing list<br>
<a href="mailto:RIPE-Atlas-Ambassadors@ripe.net">RIPE-Atlas-Ambassadors@ripe.net</a><br>
<a href="https://www.ripe.net/mailman/listinfo/ripe-atlas-ambassadors">https://www.ripe.net/mailman/listinfo/ripe-atlas-ambassadors</a><br>
</div>
</div>
</span>
</body>
</html>