New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member
[Apologies for duplicate mails] Dear colleagues, RIPE Atlas has made steady progress in its first year. But we have more ambitious plans. Read in this new article on RIPE Labs how we want to achieve these plans and why we need your support: http://labs.ripe.net/Members/dfk/a-ripe-atlas-probe-for-each-ripe-ncc-member Kind Regards, Mirjam Kuehne RIPE NCC
At 09:52 02/11/2011 +0100, Mirjam Kuehne wrote:
[Apologies for duplicate mails]
Dear colleagues,
2.5MEuro for a "nice to have" system? What crucial Internet problem are you trying to solve with this amount of money? -Hank
RIPE Atlas has made steady progress in its first year. But we have more ambitious plans. Read in this new article on RIPE Labs how we want to achieve these plans and why we need your support:
http://labs.ripe.net/Members/dfk/a-ripe-atlas-probe-for-each-ripe-ncc-member
Kind Regards, Mirjam Kuehne RIPE NCC
On 02/11/2011 15:32, Hank Nussbacher wrote:
At 09:52 02/11/2011 +0100, Mirjam Kuehne wrote:
[Apologies for duplicate mails]
Dear colleagues,
2.5MEuro for a "nice to have" system? What crucial Internet problem are you trying to solve with this amount of money?
I asked myself a similar question. 20,000 probes translates roughly to 1 per active AS, 0.25 per active prefix or 2 per current member. Let's assume for a second that we indeed install those 20,000 probes equally distributed amongst the membership. Costs are now 2.5M/8000 = 300 euro/member. Now look at my current provider. They will have 2 probes installed in a network with O(100,000) customers. That is by any standard way too low to provide any useful information in case of an operational problem. It is also way too low to do any meaningful random sampling of performance that the average customer will see. In short, one will collect lots of data but it is unclear what operational use it will have. Now turn it around: let's say we want to install the probes such that meaningful information about an AS/prefix/member can be obtained. That means installing O(100) probes per unit. But 20000/100=200, so 7800 members will not benefit from this service. In this case, you'd think that the 200 members using the service pay for it (and the others don't). However, 2.5M/200 = 12,500 euro/participant. Looking at the TTM service, I seriously doubt that there will be 200 members willing to pay for this, plus that providing a service for only a small group is not what the RIPE NCC is supposed to be doing. Either way, I have to agree with Hank that the usefulness of this project is very limited. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project)
Henk, good to hear from you again. RIPE Atlas is not intended for intra-AS measurements. Operators generally have their networks very well instrumented. RIPE Atlas is about situational awareness about the inter-AS mesh. Of course we want to have a number of probes inside big ASes, but most stub ASes are nicely covered with one or two. We would not provide other than incidental intra-AS measuremenets from the proposed funding unless the operator concerned provides additional funding and the results will be both available and useful for the community. So I am indeed proposing to distribute the probes and benefits as equally among the membership as possible. And the cost of 300 EUR for each member that you quote is for the deployment and two years of operations, so it comes down to EUR150/member/year for the first two years. About the usefulness of RIPE Atlas let me say just this much: At least one active probe in the network of each member would make for an unprecedented level of comprehensive active measurmenets. Products from these measurements are useful for detecting anomalies, monitoring trends and for analysing faults. Daniel
At 15:31 03/11/2011 +0100, Daniel Karrenberg wrote:
Henk,
good to hear from you again.
RIPE Atlas is not intended for intra-AS measurements. Operators generally have their networks very well instrumented. RIPE Atlas is about situational awareness about the inter-AS mesh. Of course we want to have a number of probes inside big ASes, but most stub ASes are nicely covered with one or two. We would not provide other than incidental intra-AS measuremenets from the proposed funding unless the operator concerned provides additional funding and the results will be both available and useful for the community.
So I am indeed proposing to distribute the probes and benefits as equally among the membership as possible. And the cost of 300 EUR for each member that you quote is for the deployment and two years of operations, so it comes down to EUR150/member/year for the first two years.
I believe only 1% of the RIPE membership would make weekly use of such probes - you might believe I am way off and feel 10% of the RIPE membership would make use of such probes. Well, there is a simple way to determine whether the membership wants to spend a few million Euro on this - ask them via a poll. If a majority of those responding feel it is important - then you have your mandate. If a majority think otherwise, you don't have a mandate to spend all that money. It is called democracy. -Hank
About the usefulness of RIPE Atlas let me say just this much: At least one active probe in the network of each member would make for an unprecedented level of comprehensive active measurmenets. Products from these measurements are useful for detecting anomalies, monitoring trends and for analysing faults.
Daniel
On 03/11/2011 17:47, Hank Nussbacher wrote:
Well, there is a simple way to determine whether the membership wants to spend a few million Euro on this - ask them via a poll.
I'd make it a line-item in the annual budget, together with a few others, not a poll. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project)
Daniel,
good to hear from you again.
I never stopped talking ;-)
So I am indeed proposing to distribute the probes and benefits as equally among the membership as possible. And the cost of 300 EUR for each member that you quote is for the deployment and two years of operations, so it comes down to EUR150/member/year for the first two years.
150 euro/year is of the order of 2-3 engineer hours, somewhat depending on the economy where you are living.
Products from these measurements are useful for detecting anomalies, monitoring trends and for analysing faults.
What product is currently included in the probes that solves an issue that most AS's have _and_ where the data from the probe can be used to solve the problem much faster, where much faster means 2-3 hours less work on an annual basis? Right now, I don't see such application. Is there something in the pipeline that we haven't heard about? The question isn't new in itself, it was raised with different parameters for TTM years ago. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project)
[cronss-posting to MAT WG as it is pertinent there as well] On 04.11 08:21, Henk Uijterwaal wrote:
...
150 euro/year is of the order of 2-3 engineer hours, somewhat depending on the economy where you are living.
Products from these measurements are useful for detecting anomalies, monitoring trends and for analysing faults.
What product is currently included in the probes that solves an issue that most AS's have _and_ where the data from the probe can be used to solve the problem much faster, where much faster means 2-3 hours less work on an annual basis? Right now, I don't see such application. Is there something in the pipeline that we haven't heard about?
Thank you Henk for putting the cost in terms of something as tangible as this. This message is long because of the number of scenarios. If youa are pressed for time, jump to "Summary". Here are a few scenarios that come to mind: - Monitor Traffic Engineering Results How does my traffic engineering affect actual latencies and losses? Does TE even do what I expect? Today traffic engineering is mostly monitored by comparing inbound flows from different peers before and after some actions. It can be difficult to even tell what path traffic takes or will take from a specific source. With RIPE Atlas widely deployed and user defined measurements (UDM) in place you can check inbound trajectories by running traceroutes and inbound latencies by running pings and application measurements from distant areas of interest towards your network. This gives you insights that are very hard to obtain otherwise in a comprehensive manner. Also the measurements will be useful when debugging with your peers and upstreams because they come from the RIPE NCC, a well respected source and everyone will be familiar with them. I can easily see how you can save 2-3 engineer hours per year right here by eliminating guessing time and speeding up analysis. - Is it slow for just me ? We all know this scenario: An important customer complains that he cannot get to his favourite content in Distanistan. Or a content customer complains that for "weeks" their hits from Distanistan have decreased. Of course you can check it out right now from the perspective of your network. But how about the pespective from Distanistan or a comparison with others in your region? With RIPE Atlas widely deployed you could set up a measurement from many different places around your region to Distanistan for a week or so and compare. It is even likely that there is a probe in close vicinity of Distanistan which can measure towards your network. If others have had problems with Distanistan too, it is likely that they have set up measurements already. All measurements are available in the RIPE Atlas pool of measurements. You can access those measurements right when the customer complains. At a minimum this may give you the opportunity to explain to the customer that everyone, not just you, has a problem and to prove it with measurements from an independent source, the RIPE NCC. The measurements will also allow you to concisely point out the problem to your peers and up-streams. I can easily see how this will both save hours of engineering time, make the results of trouble shooting better and help you be more credible with customers. - Situational Awareness Today, the routing plane is very well instrumented and we regularly see "events" discussed on operational lists. Very often the effects of these events on the transport plane are subject of speculation, guessing and the occasional isolated measurement. A widely deployed RIPE Atlas will improve our situational awareness by giving us near real time insight into the changes in latencies, packet trajectories and packet losses which are caused by events on the routing plane. The pool of RIPE Atlas measurements will be a treasure trove from which we can isolate signals both on the geographical and topological level. We can correlate them with events in the routing plane and gain a much better insight into the state of the Internet as a whole. A widely deployed RIPE Atlas will become a common frame of reference for dealing with regional and global events that involve many ASes. Having such a global frame of reference will in itself save many engineering hours by enabling quick, concise and unambiguous communication about events on the transport plane between routing engineers. - Long Term Comparative Analysis How are we doing compared to others in our market, region, the world? This is a common question. A widely deployed RIPE Atlas will help you answer those questions from an outside view in terms of stability, packet loss and latency. The measurements will be comparable and they come from a trusted external source. Building an infrastructure to do this ourselves is beyond the resources of most or even all of us. Doing it together makes this possible. For the equivalent of just 2-3 engineering hours per year we can make it happen. - Summary Referring to a common, well known measurement platform for the transport plane will save many engineer hours just by speeding up communication and preventing misunderstandings. RIPE Atlas will improve communications with your peers, up-streams and sophisticated customers by introducing hard transport plane data and a common frame of reference. RIPE Atlas will bring to the transport plane what we already have for the routing plane with route views and RIS. This alone will save more than 3 engineering hours per year for everyone. Add the unprecedented situational awareness of actual latencies, packet losses and packet trajectories and the credibility of the RPE NCC as a source of data, then one RIPE Atlas probe for every RIPE NCC member becomes a baragin. I realise thatwe have not realised most of the products I talk about. However we do have the architecture in place and almost 900 probes out there now. We also have some first examples of useful products: http://atlas.ripe.net/atlas/rtt_maps.html?msm_id=1001 http://atlas.ripe.net/atlas/comparative_root_rtt.html https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making AS a probe host you can also look at measurement results from a large number of public probes at http://atlas.ripe.net/atlas/myprobes.html after registering. In the coming 6 months we will deploy user defined measurements and the measurement pool. We will also show more "map" products for situational awareness. We will convince you that speeding up RIPE Atlas deployment by providing at least one probe for every member is worth it. I am sure we can even convince the executive board that we should start this already in 2012 and not wait for the 2013 budget cycle. Watch this space. Daniel
On 08/11/2011 10:16, Daniel Karrenberg wrote:
In the coming 6 months we will deploy user defined measurements and the measurement pool. We will also show more "map" products for situational awareness. We will convince you that speeding up RIPE Atlas deployment by providing at least one probe for every member is worth it. I am sure we can even convince the executive board that we should start this already in 2012 and not wait for the 2013 budget cycle. Watch this space. Daniel
The board is unlikely to be convinced until we see something concretely useful. Whilst I agree that the presence of a huge array of widely distributed probes gives us enormous potential, we still have to see concrete proposals of how they may easily be used for remote monitoring and debugging. What we have seen so far, is a tremendous start, but only a start. However, Daniel and his team being the professionals they are, I have no doubt that we will see this in the coming months and I look forward to it with great anticipation. Wearing my day-job hat for a moment, this would be extremely useful for us and we would be prepared to spend considerably more that 2 - 3 engineer hours (on top of our normal registry fees) for this functionality. All the best Nigel
* Daniel Karrenberg:
Also the measurements will be useful when debugging with your peers and upstreams because they come from the RIPE NCC, a well respected source and everyone will be familiar with them. I can easily see how you can save 2-3 engineer hours per year right here by eliminating guessing time and speeding up analysis.
On the other hand, you could be forced to deal with additional complaints from people who use these tools and misinterpret the results, similar to what happens with traceroute and WHOIS today, but with the appeal to authority that RIPE NCC has detected a network problem. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
participants (6)
-
Daniel Karrenberg
-
Florian Weimer
-
Hank Nussbacher
-
Henk Uijterwaal
-
Mirjam Kuehne
-
Nigel Titley