From robert at ripe.net Mon Jan 5 13:59:27 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 05 Jan 2015 13:59:27 +0100 Subject: [atlas] Proposal for public HTTP measurements Message-ID: <54AA8AAF.9060304@ripe.net> Dear RIPE Atlas users, The topic of publicly available HTTP measurements in RIPE Atlas comes up from time to time. There were a number of discussions about pros and cons for this feature over the years (including exposing probe hosts to unnecessary risks of other users "measuring" just about any kind of HTTP content out there), with no firm outcome. While we understand that this feature would come handy for some of our users, it does not benefit everyone. Therefore our proposal is the following: 1. We'll enable HTTP measurements to be performed by all atlas users, from any probes. 2. The targets of such measurements can only be RIPE Atlas anchors (these already run HTTP servers, see https://atlas.ripe.net/docs/anchors/). 3. Parameters like costs, minimum frequency, maximum number of probes involved, etc. will be set by the development team, just as with the other measurements. 4. The RIPE NCC will still be able to support other, vetted HTTP measurements as long as it benefits the community, as well as other HTTP measurements that we deem operationally useful. These will be evaluated on a case by case basis. Please speak up at the MAT working group list (mat-wg at ripe.net) if you support / don't support this proposal, of if you have any other opinion about it. Regards, Robert Kisteleki RIPE NCC R&D manager, for the RIPE Atlas team From trammell at tik.ee.ethz.ch Mon Jan 5 14:35:48 2015 From: trammell at tik.ee.ethz.ch (Brian Trammell) Date: Mon, 5 Jan 2015 14:35:48 +0100 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <54AA8AAF.9060304@ripe.net> References: <54AA8AAF.9060304@ripe.net> Message-ID: <64F1E253-0C9D-43C1-980F-28DE3DF5ADC5@tik.ee.ethz.ch> hi Robert, all, This seems, in general, like a good balance of the tradeoff in utility and security with respect to research questions. > On 05 Jan 2015, at 13:59, Robert Kisteleki wrote: > > > Dear RIPE Atlas users, > > The topic of publicly available HTTP measurements in RIPE Atlas comes up > from time to time. There were a number of discussions about pros and cons > for this feature over the years (including exposing probe hosts to > unnecessary risks of other users "measuring" just about any kind of HTTP > content out there), with no firm outcome. > > While we understand that this feature would come handy for some of our > users, it does not benefit everyone. Therefore our proposal is the following: > > 1. We'll enable HTTP measurements to be performed by all atlas users, from > any probes. > > 2. The targets of such measurements can only be RIPE Atlas anchors (these > already run HTTP servers, see https://atlas.ripe.net/docs/anchors/). Since the target will be an anchor which has known expected content, will these measurements include some indication of whether application-layer rewriting was detected? Thanks, cheers, Brian > 3. Parameters like costs, minimum frequency, maximum number of probes > involved, etc. will be set by the development team, just as with the other > measurements. > > 4. The RIPE NCC will still be able to support other, vetted HTTP > measurements as long as it benefits the community, as well as other HTTP > measurements that we deem operationally useful. These will be evaluated on a > case by case basis. > > > Please speak up at the MAT working group list (mat-wg at ripe.net) if you > support / don't support this proposal, of if you have any other opinion > about it. > > Regards, > Robert Kisteleki > RIPE NCC R&D manager, for the RIPE Atlas team From collin at averysmallbird.com Wed Jan 7 05:37:29 2015 From: collin at averysmallbird.com (Collin Anderson) Date: Tue, 6 Jan 2015 23:37:29 -0500 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <64F1E253-0C9D-43C1-980F-28DE3DF5ADC5@tik.ee.ethz.ch> References: <54AA8AAF.9060304@ripe.net> <64F1E253-0C9D-43C1-980F-28DE3DF5ADC5@tik.ee.ethz.ch> Message-ID: Hi Robert and the MAT-WG, This is an interesting proposal and I'm happy to see RIPE open up HTTP requests a bit more. I hope that as you do, the WG can share thoughts on the balance of privacy and security with measurement objectives, since that will better inform concurrent efforts. On Mon, Jan 5, 2015 at 8:35 AM, Brian Trammell wrote: > Since the target will be an anchor which has known expected content, will > these measurements include some indication of whether application-layer > rewriting was detected? > Case in point ? there are interesting parallels between this proposal and OONI's Header Field Manipulation Test [1]. RIPE might be interested in exploring similar services to return headers to potentially detect inflight modification, or better yet to whitelist OONI's helper services. Cordially, Collin [1] https://github.com/TheTorProject/ooni-spec/blob/master/test-specs/ts-006-header-field-manipulation.md -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Jan 7 06:01:27 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 Jan 2015 21:01:27 -0800 Subject: [atlas] Proposal for public HTTP measurements In-Reply-To: <54AA8AAF.9060304@ripe.net> References: <54AA8AAF.9060304@ripe.net> Message-ID: <8309DAE1-4521-4AD9-A374-B96575C9AF92@puck.nether.net> I would be interested in letting us start measurements against ourselves from probes globally. One could publish a DNS record similar to how Google validates domains for receiving requests to authorize the traffic. Jared Mauch > On Jan 5, 2015, at 4:59 AM, Robert Kisteleki wrote: > > > Dear RIPE Atlas users, > > The topic of publicly available HTTP measurements in RIPE Atlas comes up > from time to time. There were a number of discussions about pros and cons > for this feature over the years (including exposing probe hosts to > unnecessary risks of other users "measuring" just about any kind of HTTP > content out there), with no firm outcome. > > While we understand that this feature would come handy for some of our > users, it does not benefit everyone. Therefore our proposal is the following: > > 1. We'll enable HTTP measurements to be performed by all atlas users, from > any probes. > > 2. The targets of such measurements can only be RIPE Atlas anchors (these > already run HTTP servers, see https://atlas.ripe.net/docs/anchors/). > > 3. Parameters like costs, minimum frequency, maximum number of probes > involved, etc. will be set by the development team, just as with the other > measurements. > > 4. The RIPE NCC will still be able to support other, vetted HTTP > measurements as long as it benefits the community, as well as other HTTP > measurements that we deem operationally useful. These will be evaluated on a > case by case basis. > > > Please speak up at the MAT working group list (mat-wg at ripe.net) if you > support / don't support this proposal, of if you have any other opinion > about it. > > Regards, > Robert Kisteleki > RIPE NCC R&D manager, for the RIPE Atlas team From bryan at digitalocean.com Wed Jan 7 21:34:18 2015 From: bryan at digitalocean.com (Bryan Socha) Date: Wed, 7 Jan 2015 15:34:18 -0500 Subject: [atlas] Proposal for public HTTP measurements In-Reply-To: <54AA8AAF.9060304@ripe.net> References: <54AA8AAF.9060304@ripe.net> Message-ID: I love the idea but unless you can profile what available capacity the probe/anchor has I don't think the resulting measurements will be useable. There is no way to know your http request was slow because someone with the end point is a hard core torrent user maxing their location out. Also valid for the areas where you have a hard limit and minimal extra bandwidth. ping/traceroute while not always a good test does squeeze through with minimal variance in result when the site bandwidth is congested. also as an anchor host, can I limit the max bps because some locations is not low cost if everyone decides to http test some speedtest file. Our singapore anchor for example would cost more per month then we spent on the hardware to host an anchor in the first place. I suspect the probe/anchor hosts in other areas like africa, australia, new zealand, and south america would get even larger monthly bills. Bryan Socha Network Engineer DigitalOcean On Mon, Jan 5, 2015 at 7:59 AM, Robert Kisteleki wrote: > > Dear RIPE Atlas users, > > The topic of publicly available HTTP measurements in RIPE Atlas comes up > from time to time. There were a number of discussions about pros and cons > for this feature over the years (including exposing probe hosts to > unnecessary risks of other users "measuring" just about any kind of HTTP > content out there), with no firm outcome. > > While we understand that this feature would come handy for some of our > users, it does not benefit everyone. Therefore our proposal is the > following: > > 1. We'll enable HTTP measurements to be performed by all atlas users, from > any probes. > > 2. The targets of such measurements can only be RIPE Atlas anchors (these > already run HTTP servers, see https://atlas.ripe.net/docs/anchors/). > > 3. Parameters like costs, minimum frequency, maximum number of probes > involved, etc. will be set by the development team, just as with the other > measurements. > > 4. The RIPE NCC will still be able to support other, vetted HTTP > measurements as long as it benefits the community, as well as other HTTP > measurements that we deem operationally useful. These will be evaluated on > a > case by case basis. > > > Please speak up at the MAT working group list (mat-wg at ripe.net) if you > support / don't support this proposal, of if you have any other opinion > about it. > > Regards, > Robert Kisteleki > RIPE NCC R&D manager, for the RIPE Atlas team > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Thu Jan 8 15:39:36 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 08 Jan 2015 15:39:36 +0100 Subject: [atlas] Coming soon: RIPE Atlas data visualization hackathon! In-Reply-To: <5488B803.1040809@ripe.net> References: <5488B803.1040809@ripe.net> Message-ID: <54AE96A8.4020605@ripe.net> Dear all, a month ago we announced the first RIPE Atlas open data hackathon: Dates: 27-28-29 March 2015 (Friday to Sunday) Place: Amsterdam If you want part of your travel expenses covered, you need to hurry up with the application, since the deadline is 21st January. After that, we will inform those who got selected, and how many more places do we still have available. To apply: https://www.ripe.net/s/XUJy Hope to see you there! Regards, Vesna On 10-dec.-14 22:15, Vesna Manojlovic wrote: > Dear all, > > we are happy to invite you to the first RIPE Atlas open data hackathon! > > In short: various groups will come together during the long weekend in > Amsterdam, to make new visualisations (or modify existing ones) based on > RIPE Atlas data, and to give that SW back to the community. We are > inviting: programers, designers, operators, data-lovers, hackers, > students... help us spread the word! > > Comcast is generously offering prizes and some coverage for travel > expenses for several people -- to be awarded/selected by a jury. > > Dates: 27-28-29 March 2015 (Friday to Sunday) > > How to apply: https://www.ripe.net/s/XUJy > > More information, as always, in the RIPE Labs article: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-hackathon-2015 > > > Hope to see you there! > > Regards, > Vesna > > From hsalgado at nic.cl Thu Jan 8 17:02:29 2015 From: hsalgado at nic.cl (Hugo Salgado) Date: Thu, 08 Jan 2015 13:02:29 -0300 Subject: [atlas] Proposal for public HTTP measurements In-Reply-To: References: <54AA8AAF.9060304@ripe.net> Message-ID: <54AEAA15.90008@nic.cl> On 01/07/2015 05:34 PM, Bryan Socha wrote: > > also as an anchor host, can I limit the max bps because some locations > is not low cost if everyone decides to http test some speedtest file. > Our singapore anchor for example would cost more per month then we spent > on the hardware to host an anchor in the first place. I suspect the > probe/anchor hosts in other areas like africa, australia, new zealand, > and south america would get even larger monthly bills. That's right. As an ambassador here in Chile, the first question i receive asking for hosts is the bandwidth a probe takes. This will be a major concern and it'll mean to review all the probes installed, and I think it'll be a showstopper for future ones. Hugo From trammell at tik.ee.ethz.ch Thu Jan 8 12:02:46 2015 From: trammell at tik.ee.ethz.ch (Brian Trammell) Date: Thu, 8 Jan 2015 12:02:46 +0100 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: References: <54AA8AAF.9060304@ripe.net> Message-ID: <5AC90771-B77E-4541-8168-F1925EBFB75E@tik.ee.ethz.ch> > On 07 Jan 2015, at 21:34, Bryan Socha wrote: > > I love the idea but unless you can profile what available capacity the probe/anchor has I don't think the resulting measurements will be useable. There is no way to know your http request was slow because someone with the end point is a hard core torrent user maxing their location out. Also valid for the areas where you have a hard limit and minimal extra bandwidth. ping/traceroute while not always a good test does squeeze through with minimal variance in result when the site bandwidth is congested. > > also as an anchor host, can I limit the max bps because some locations is not low cost if everyone decides to http test some speedtest file. Our singapore anchor for example would cost more per month then we spent on the hardware to host an anchor in the first place. I suspect the probe/anchor hosts in other areas like africa, australia, new zealand, and south america would get even larger monthly bills. So the proposal as I understand it has very low limits on the amount of payload that will be sent in the response (4kB, i.e. four packets), which I presume will reduce the temptation to misuse this measurement for bulk transfer capacity estimation (...and please don't get me started on how utterly pointless using a single TCP flow to estimate bulk transfer capacity is in the first place :) ) In the aggregate, though, you're right, this could lead to significant bandwidth usage, which I presume could be capped by the controller...? Cheers, Brian > Bryan Socha > Network Engineer > DigitalOcean > > > On Mon, Jan 5, 2015 at 7:59 AM, Robert Kisteleki wrote: > > Dear RIPE Atlas users, > > The topic of publicly available HTTP measurements in RIPE Atlas comes up > from time to time. There were a number of discussions about pros and cons > for this feature over the years (including exposing probe hosts to > unnecessary risks of other users "measuring" just about any kind of HTTP > content out there), with no firm outcome. > > While we understand that this feature would come handy for some of our > users, it does not benefit everyone. Therefore our proposal is the following: > > 1. We'll enable HTTP measurements to be performed by all atlas users, from > any probes. > > 2. The targets of such measurements can only be RIPE Atlas anchors (these > already run HTTP servers, see https://atlas.ripe.net/docs/anchors/). > > 3. Parameters like costs, minimum frequency, maximum number of probes > involved, etc. will be set by the development team, just as with the other > measurements. > > 4. The RIPE NCC will still be able to support other, vetted HTTP > measurements as long as it benefits the community, as well as other HTTP > measurements that we deem operationally useful. These will be evaluated on a > case by case basis. > > > Please speak up at the MAT working group list (mat-wg at ripe.net) if you > support / don't support this proposal, of if you have any other opinion > about it. > > Regards, > Robert Kisteleki > RIPE NCC R&D manager, for the RIPE Atlas team > > From robert at ripe.net Fri Jan 9 10:44:34 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 09 Jan 2015 10:44:34 +0100 Subject: [atlas] Proposal for public HTTP measurements In-Reply-To: References: <54AA8AAF.9060304@ripe.net> Message-ID: <54AFA302.6020106@ripe.net> Dear All, I'd like to provide some background information mostly about bandwidth usage that can help this discussion. For RIPE Atlas anchors, we're always asking the host to be prepared for traffic up to 10Mb/sec. However, in reality we're very far from using this much at the moment: anchors that are involved in DNSMON measurements use about 256kb/sec, whereas anchors that don't do DNSMON measurements use about 50kb/sec. About probes: a v4 only probe uses ~4kb/sec, a v4+v6 probe uses ~7kb/sec. See also: https://atlas.ripe.net/about/faq/#how-much-bandwidth-will-the-probe-consume All of these numbers are on average, based on checking some random anchors/probes. Surely there are probes that use more (or less) average bandwidth than the numbers I mentioned. The HTTP service provided by the anchors limits the response size to about 4KB, so even with all the overhead it fits in a few TCP packets, which is practically in the same ballpark as the other measurements we already allow (or even less, if one thinks about traceroutes...) We'll also enforce the usual limits like maximum number of probes per measurement and minimum measurement frequency. Regards, Robert On 2015-01-07 21:34, Bryan Socha wrote: > I love the idea but unless you can profile what available capacity the > probe/anchor has I don't think the resulting measurements will be > useable. There is no way to know your http request was slow because > someone with the end point is a hard core torrent user maxing their location > out. Also valid for the areas where you have a hard limit and minimal > extra bandwidth. ping/traceroute while not always a good test does > squeeze through with minimal variance in result when the site bandwidth is > congested. > > also as an anchor host, can I limit the max bps because some locations is > not low cost if everyone decides to http test some speedtest file. Our > singapore anchor for example would cost more per month then we spent on the > hardware to host an anchor in the first place. I suspect the probe/anchor > hosts in other areas like africa, australia, new zealand, and south america > would get even larger monthly bills. > > > > > Bryan Socha > Network Engineer > DigitalOcean From robert at ripe.net Fri Jan 9 13:41:58 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 09 Jan 2015 13:41:58 +0100 Subject: [atlas] Deprecating the old measurement UI Message-ID: <54AFCC96.2050703@ripe.net> Dear all, In October last year, we introduced a new UI for browsing and scheduling measurements. For details, see: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-new-measurements-ui-and-tagging Your feedback about this was predominantly positive, and we?d like to thank everyone who helped this development with suggestions and bug reports. As stated at the time, we plan to deprecate and eventually remove the old interface (both the UI and the "API" it used). Our timeline is the following: 1. We'll make the new UI the default, and remove links to the old UI from the RIPE Atlas main menu, around 21 January. The old pages will still be accessible if one reaches them from somewhere else, such as a browser bookmark or hard-coded scripts. 2. Around the beginning of March, we'll remove the old pages from the system (/atlas/udm.html and related pages). This step will include the "deep links" that some of our users directly access to schedule and manage measurements from scripts (notably /atlas/*udm*.json). We'd like to encourage all of our users to switch to the new UI and API in the following weeks, if you haven't already done so. As always, we're happy to answer any questions or hear any feedback you might have. Regards, Robert Kisteleki, for the RIPE Atlas team From astracha at ripe.net Tue Jan 13 14:57:05 2015 From: astracha at ripe.net (Alastair Strachan) Date: Tue, 13 Jan 2015 14:57:05 +0100 Subject: [atlas] Nordiska Servercentralen (Solna, Sweden) has joined RIPE Atlas Anchors. Message-ID: <27E7D3CD-39D0-437F-9E5A-E57BFC10EEC7@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called se-sln-as49515 and it is hosted by Nordiska Servercentralen in Solna, Sweden. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From Sisi.Wei at propublica.org Tue Jan 13 18:44:34 2015 From: Sisi.Wei at propublica.org (Sisi Wei) Date: Tue, 13 Jan 2015 17:44:34 +0000 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <54AFA302.6020106@ripe.net> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> Message-ID: Hi Robert and everyone, I?m excited to see RIPE take this step in allowing more HTTP measurements across the system. I certainly support this proposal. In addition, along similar lines to what Brian Trammell has brought up, I?m particularly interested in detecting any type of impairment on the HTTP level. Therefore, I would love to see HTTP measurements be performed with not only RIPE Atlas anchors as targets (though that is a great start), but the rest of the web as well. Along with Jared?s idea for expanding it to allow testing of your own website, perhaps we could even expand this idea to the ability to test any website that gives you permission (which we could prove we obtained, to RIPE). Of course all such tests should be limited in both size and frequency, as appropriate with the current test restrictions such as the credit system and the 4 KB limit. I know however, there are privacy and security issues that would come into play on the side of probe hosts, which must be considered. I would certainly appreciate suggestions on how we could allow HTTP measurements against the general web, while protecting probe hosts from being held reliable by their local governments for their probe?s test histories. At ProPublica, our research interest lies in detecting whether large news sites are available all over the world ? as well as how they come to be unavailable or censored. One of our recent projects did not use RIPE Atlas, but instead relied on other existing testing mechanisms in China, to detect the availability of 18 international news homepages: https://projects.propublica.org/firewall/. We would love to do our own tests using the RIPE network, testing in many more countries than just China, but complete test results could not be created without being able to use HTTP measurements. Sincerely, Sisi --- Sisi Wei News Apps Developer ProPublica On Jan 9, 2015, at 4:44 AM, Robert Kisteleki > wrote: Dear All, I'd like to provide some background information mostly about bandwidth usage that can help this discussion. For RIPE Atlas anchors, we're always asking the host to be prepared for traffic up to 10Mb/sec. However, in reality we're very far from using this much at the moment: anchors that are involved in DNSMON measurements use about 256kb/sec, whereas anchors that don't do DNSMON measurements use about 50kb/sec. About probes: a v4 only probe uses ~4kb/sec, a v4+v6 probe uses ~7kb/sec. See also: https://atlas.ripe.net/about/faq/#how-much-bandwidth-will-the-probe-consume All of these numbers are on average, based on checking some random anchors/probes. Surely there are probes that use more (or less) average bandwidth than the numbers I mentioned. The HTTP service provided by the anchors limits the response size to about 4KB, so even with all the overhead it fits in a few TCP packets, which is practically in the same ballpark as the other measurements we already allow (or even less, if one thinks about traceroutes...) We'll also enforce the usual limits like maximum number of probes per measurement and minimum measurement frequency. Regards, Robert On 2015-01-07 21:34, Bryan Socha wrote: I love the idea but unless you can profile what available capacity the probe/anchor has I don't think the resulting measurements will be useable. There is no way to know your http request was slow because someone with the end point is a hard core torrent user maxing their location out. Also valid for the areas where you have a hard limit and minimal extra bandwidth. ping/traceroute while not always a good test does squeeze through with minimal variance in result when the site bandwidth is congested. also as an anchor host, can I limit the max bps because some locations is not low cost if everyone decides to http test some speedtest file. Our singapore anchor for example would cost more per month then we spent on the hardware to host an anchor in the first place. I suspect the probe/anchor hosts in other areas like africa, australia, new zealand, and south america would get even larger monthly bills. Bryan Socha Network Engineer DigitalOcean -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Tue Jan 13 23:28:55 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 13 Jan 2015 23:28:55 +0100 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> Message-ID: <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> sisi, ripe atlas was built for monitoring the infrastructure. the direction you are suggesting bears a significant risk of destroying ripe atlas because we will be regarded as breaking our agreement with probe hosts and probe hosts will disconnect their probes. i am opposed to risking ripe atlas for the sake of the http measurements; specifically meaurements that are bound to make ripe atlas a target. i am all for doing the work you suggest, but i have to suggest that you find people willing to cooperate while knowing the consequences. if we proceed like you suggest we may very well end up with no useful platform for any purpose. daniel ---------- Sent from a hand held device. > On 13.01.2015, at 18:44, Sisi Wei wrote: > > Hi Robert and everyone, > > I?m excited to see RIPE take this step in allowing more HTTP measurements across the system. I certainly support this proposal. > > In addition, along similar lines to what Brian Trammell has brought up, I?m particularly interested in detecting any type of impairment on the HTTP level. Therefore, I would love to see HTTP measurements be performed with not only RIPE Atlas anchors as targets (though that is a great start), but the rest of the web as well. > > Along with Jared?s idea for expanding it to allow testing of your own website, perhaps we could even expand this idea to the ability to test any website that gives you permission (which we could prove we obtained, to RIPE). > > Of course all such tests should be limited in both size and frequency, as appropriate with the current test restrictions such as the credit system and the 4 KB limit. > > I know however, there are privacy and security issues that would come into play on the side of probe hosts, which must be considered. I would certainly appreciate suggestions on how we could allow HTTP measurements against the general web, while protecting probe hosts from being held reliable by their local governments for their probe?s test histories. > > At ProPublica, our research interest lies in detecting whether large news sites are available all over the world ? as well as how they come to be unavailable or censored. One of our recent projects did not use RIPE Atlas, but instead relied on other existing testing mechanisms in China, to detect the availability of 18 international news homepages: https://projects.propublica.org/firewall/. We would love to do our own tests using the RIPE network, testing in many more countries than just China, but complete test results could not be created without being able to use HTTP measurements. > > Sincerely, > Sisi > > --- > > Sisi Wei > News Apps Developer > ProPublica > >> On Jan 9, 2015, at 4:44 AM, Robert Kisteleki wrote: >> >> >> Dear All, >> >> I'd like to provide some background information mostly about bandwidth usage >> that can help this discussion. >> >> For RIPE Atlas anchors, we're always asking the host to be prepared for >> traffic up to 10Mb/sec. However, in reality we're very far from using this >> much at the moment: anchors that are involved in DNSMON measurements use >> about 256kb/sec, whereas anchors that don't do DNSMON measurements use about >> 50kb/sec. >> >> About probes: a v4 only probe uses ~4kb/sec, a v4+v6 probe uses ~7kb/sec. >> See also: >> https://atlas.ripe.net/about/faq/#how-much-bandwidth-will-the-probe-consume >> >> All of these numbers are on average, based on checking some random >> anchors/probes. Surely there are probes that use more (or less) average >> bandwidth than the numbers I mentioned. >> >> The HTTP service provided by the anchors limits the response size to about >> 4KB, so even with all the overhead it fits in a few TCP packets, which is >> practically in the same ballpark as the other measurements we already allow >> (or even less, if one thinks about traceroutes...) >> >> We'll also enforce the usual limits like maximum number of probes per >> measurement and minimum measurement frequency. >> >> Regards, >> Robert >> >> >>> On 2015-01-07 21:34, Bryan Socha wrote: >>> I love the idea but unless you can profile what available capacity the >>> probe/anchor has I don't think the resulting measurements will be >>> useable. There is no way to know your http request was slow because >>> someone with the end point is a hard core torrent user maxing their location >>> out. Also valid for the areas where you have a hard limit and minimal >>> extra bandwidth. ping/traceroute while not always a good test does >>> squeeze through with minimal variance in result when the site bandwidth is >>> congested. >>> >>> also as an anchor host, can I limit the max bps because some locations is >>> not low cost if everyone decides to http test some speedtest file. Our >>> singapore anchor for example would cost more per month then we spent on the >>> hardware to host an anchor in the first place. I suspect the probe/anchor >>> hosts in other areas like africa, australia, new zealand, and south america >>> would get even larger monthly bills. >>> >>> >>> >>> >>> Bryan Socha >>> Network Engineer >>> DigitalOcean >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Jan 13 23:41:29 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Jan 2015 17:41:29 -0500 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> Message-ID: > On Jan 13, 2015, at 5:28 PM, Daniel Karrenberg wrote: > > sisi, > > > > ripe atlas was built for monitoring the infrastructure. the direction you are suggesting bears a significant risk of destroying ripe atlas because we will be regarded as breaking our agreement with probe hosts and probe hosts will disconnect their probes. i am opposed to risking ripe atlas for the sake of the http measurements; specifically meaurements that are bound to make ripe atlas a target. i am all for doing the work you suggest, but i have to suggest that you find people willing to cooperate while knowing the consequences. if we proceed like you suggest we may very well end up with no useful platform for any purpose. Perhaps this is a good use-case of having a ?hosted VM? type probe? The NLNOG RING is an example of something where it?s a pure full-mesh community but without credits. If there was something like a software probe, i could ask our systems team to deploy one VM per site we have for these purposes, and it could provide this capability with reasonable constraints. - Jared From Sisi.Wei at propublica.org Wed Jan 14 00:15:03 2015 From: Sisi.Wei at propublica.org (Sisi Wei) Date: Tue, 13 Jan 2015 23:15:03 +0000 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> Message-ID: <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> Jared, I?d love to know more about this. Daniel ? let me be clear that I have no intention of endangering RIPE atlas, and your concerns are the same as mine when it comes to the system, as well as all of the probe hosts. That?s why we specifically haven?t used RIPE to power any projects. Hence, I?m extremely interested in whether there?s any way that limited HTTP measurements could exist without being a threat. Sisi > On Jan 13, 2015, at 5:41 PM, Jared Mauch wrote: > > >> On Jan 13, 2015, at 5:28 PM, Daniel Karrenberg wrote: >> >> sisi, >> >> >> >> ripe atlas was built for monitoring the infrastructure. the direction you are suggesting bears a significant risk of destroying ripe atlas because we will be regarded as breaking our agreement with probe hosts and probe hosts will disconnect their probes. i am opposed to risking ripe atlas for the sake of the http measurements; specifically meaurements that are bound to make ripe atlas a target. i am all for doing the work you suggest, but i have to suggest that you find people willing to cooperate while knowing the consequences. if we proceed like you suggest we may very well end up with no useful platform for any purpose. > > Perhaps this is a good use-case of having a ?hosted VM? type probe? The NLNOG RING is an example of something where it?s a pure full-mesh community but without credits. > > If there was something like a software probe, i could ask our systems team to deploy one VM per site we have for these purposes, and it could provide this capability with reasonable constraints. > > - Jared From astracha at ripe.net Wed Jan 14 11:19:35 2015 From: astracha at ripe.net (Alastair Strachan) Date: Wed, 14 Jan 2015 11:19:35 +0100 Subject: [atlas] DK Hostmaster A/S (Ballerup, Denmark) has joined RIPE Atlas Anchors. Message-ID: Dear RIPE Atlas users, We're very excited to announce that the 100th RIPE Atlas anchor has joined the network! This anchor is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called dk-blp-as39839 and it is hosted by DK Hostmaster A/S in Ballerup, Denmark. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From the.lists at mgm51.com Wed Jan 14 16:32:38 2015 From: the.lists at mgm51.com (Mike.) Date: Wed, 14 Jan 2015 10:32:38 -0500 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> Message-ID: <201501141032380102.005BF586@smtp.24cl.home> My only request in this discussion: If the decision is to allow http measurements, please allow me to select whether or not I want to avail the probe I host for public http measurements. A checkbox on the website for the probe (similar to the ~allow for public use~ selection) would be fine. Thanks. From BECHA at ripe.net Fri Jan 16 11:56:10 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 16 Jan 2015 11:56:10 +0100 Subject: [atlas] One hundred RIPE Atlas anchors online In-Reply-To: <2E35EFF4-8FA0-41C2-8EB4-9C30AE443C5D@ripe.net> References: <2E35EFF4-8FA0-41C2-8EB4-9C30AE443C5D@ripe.net> Message-ID: <54B8EE4A.2030409@ripe.net> Dear all, You have been hearing about each RIPE Atlas anchor as they get activated - and now we have reached a milestone with one hundred anchors online! We wrote an article on RIPE Labs to cover all the details: https://labs.ripe.net/Members/suzanne_taylor_muzzin/one-hundred-ripe-atlas-anchors-online To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Kind regards, Vesna Manojlovic Measurements Community Building Team RIPE NCC From klaus.mailinglists at pernau.at Wed Jan 21 13:49:48 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 21 Jan 2015 13:49:48 +0100 Subject: [atlas] problems creating measurements with old web interface Message-ID: <54BFA06C.5090305@pernau.at> Hi! Today I created some DNS tests with the old web interface. The creation process was fine, but the measurements did not work. (my target was ignored and "use probe's resolver" was automatically enabled). See UDMs: 1841832, 1841839, 1841840 btw: I can not stop 1841839 and 1841840 via the new web interface The DNS measurements only work if I create them via the new web interface. regards Klaus PS: IMO the new web interface is not very user friendly when choosing the probes - eg I failed to select 100 probes word wide (how to do this in the map)? It would be nice to have a textual alternative as my browser gets incredibly slow when showing all the probes on the map. From robert at ripe.net Wed Jan 21 14:24:12 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 21 Jan 2015 14:24:12 +0100 Subject: [atlas] problems creating measurements with old web interface In-Reply-To: <54BFA06C.5090305@pernau.at> References: <54BFA06C.5090305@pernau.at> Message-ID: <54BFA87C.9030709@ripe.net> Hi, On 2015-01-21 13:49, Klaus Darilion wrote: > Hi! > > Today I created some DNS tests with the old web interface. The creation > process was fine, but the measurements did not work. (my target was > ignored and "use probe's resolver" was automatically enabled). > See UDMs: 1841832, 1841839, 1841840 It's unlikely that we've introduced bugs in those pages (not impossible though). However: * we deployed significant internal upgrades yesterday and some remaining kinks were ironed out today. your measurements may have been caught in this * as advertised earlier, we're about to abandon and remove the "old UI", please use the new API/UI instead > btw: I can not stop 1841839 and 1841840 via the new web interface The stop button is on the measurement general page, somewhat below where it really should be :-) > The DNS measurements only work if I create them via the new web interface. > > > regards > Klaus > > PS: IMO the new web interface is not very user friendly when choosing > the probes - eg I failed to select 100 probes word wide (how to do this > in the map)? It would be nice to have a textual alternative as my > browser gets incredibly slow when showing all the probes on the map. Indeed we realise that the map can be a bottleneck sometimes. We're looking at possibilities to remedy this. Regards, Robert From robert at ripe.net Wed Jan 21 14:28:44 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 21 Jan 2015 14:28:44 +0100 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <201501141032380102.005BF586@smtp.24cl.home> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> <201501141032380102.005BF586@smtp.24cl.home> Message-ID: <54BFA98C.50001@ripe.net> On 2015-01-14 16:32, Mike. wrote: > > My only request in this discussion: > > If the decision is to allow http measurements, please allow me to > select whether or not I want to avail the probe I host for public > http measurements. > > A checkbox on the website for the probe (similar to the ~allow for > public use~ selection) would be fine. > > Thanks. Hi, Our proposal restricts the target to be safe sites with little bandwidth requirements -- this addresses most of the concerns of probe hosts. Of course we can look into opting out from these if there's consensus that we should. Regards, Robert From mcandela at ripe.net Wed Jan 21 15:05:01 2015 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 21 Jan 2015 15:05:01 +0100 Subject: [atlas] problems creating measurements with old web interface In-Reply-To: <54BFAD51.9040102@ripe.net> References: <54BFA06C.5090305@pernau.at> <54BFAD51.9040102@ripe.net> Message-ID: <1BE6131F-9DA5-4DCE-9405-05DB8A700D11@ripe.net> Hi, Thanks for the feedback! > > Subject: [atlas] problems creating measurements with old web interface > Date: Wed, 21 Jan 2015 13:49:48 +0100 > From: Klaus Darilion > To: ripe-atlas at ripe.net > > Hi! > > Today I created some DNS tests with the old web interface. The creation > process was fine, but the measurements did not work. (my target was > ignored and "use probe's resolver" was automatically enabled). > See UDMs: 1841832, 1841839, 1841840 > > btw: I can not stop 1841839 and 1841840 via the new web interface > > > The DNS measurements only work if I create them via the new web interface. > > > regards > Klaus > > PS: IMO the new web interface is not very user friendly when choosing > the probes - eg I failed to select 100 probes word wide (how to do this > in the map)? You can do it by searching for ?worldwide? (there is autosuggestion) and the widget will ask the number of probes and the tags you want to use. The number of probes is suggested and bounded according to the maximum number of probes selectable for the measurement. The idea is that whatever you write in the text field, it will try to help/guide you creating the valid (and, if needed, complex) selection you were looking for. E.g. you can do a combination by searching for ?Canada ipv6? to select all the ipv6 probes in Canada Of course it can be improved, so let us know if you have other feedback! Best regards, Massimo > It would be nice to have a textual alternative as my > browser gets incredibly slow when showing all the probes on the map. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From the.lists at mgm51.com Wed Jan 21 17:51:36 2015 From: the.lists at mgm51.com (Mike.) Date: Wed, 21 Jan 2015 11:51:36 -0500 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <54BFA98C.50001@ripe.net> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> <201501141032380102.005BF586@smtp.24cl.home> <54BFA98C.50001@ripe.net> Message-ID: <201501211151360869.00898528@smtp.24cl.home> On 1/21/2015 at 2:28 PM Robert Kisteleki wrote: |On 2015-01-14 16:32, Mike. wrote: |> |> My only request in this discussion: |> |> If the decision is to allow http measurements, please allow me to |> select whether or not I want to avail the probe I host for public |> http measurements. |> |> A checkbox on the website for the probe (similar to the ~allow for |> public use~ selection) would be fine. |> |> Thanks. | |Hi, | |Our proposal restricts the target to be safe sites with little bandwidth |requirements -- this addresses most of the concerns of probe hosts. Of |course we can look into opting out from these if there's consensus that we |should. | |Regards, |Robert ============= Part of my concern is that the definition of "safe sites" can be country-dependent, and is continually changing. What may be a "safe site" this month may not be a "safe site" next month, due to some over-eager political cause somewhere. From Ondrej.Caletka at cesnet.cz Thu Jan 22 08:40:22 2015 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Thu, 22 Jan 2015 08:40:22 +0100 Subject: [atlas] [mat-wg] Proposal for public HTTP measurements In-Reply-To: <201501211151360869.00898528@smtp.24cl.home> References: <54AA8AAF.9060304@ripe.net> <54AFA302.6020106@ripe.net> <1C42B335-9880-437C-BDDC-0FCBD5048BCC@ripe.net> <419B36D0-47F2-44BD-944E-67BDC78AF516@propublica.org> <201501141032380102.005BF586@smtp.24cl.home> <54BFA98C.50001@ripe.net> <201501211151360869.00898528@smtp.24cl.home> Message-ID: <54C0A966.8010101@cesnet.cz> Dne 21.1.2015 v 17:51 Mike. napsal(a): > Part of my concern is that the definition of "safe sites" can be > country-dependent, and is continually changing. > > What may be a "safe site" this month may not be a "safe site" next > month, due to some over-eager political cause somewhere This is probably not the case for RIPE Atlas anchors. I can't imagine how could possibly the JSON returned by Anchors become unsafe in any country :) -- Regards, Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5580 bytes Desc: Elektronicky podpis S/MIME URL: From klaus.mailinglists at pernau.at Thu Jan 22 10:40:46 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 22 Jan 2015 10:40:46 +0100 Subject: [atlas] problems creating measurements with old web interface In-Reply-To: <54BFA87C.9030709@ripe.net> References: <54BFA06C.5090305@pernau.at> <54BFA87C.9030709@ripe.net> Message-ID: <54C0C59E.1050301@pernau.at> On 21.01.2015 14:24, Robert Kisteleki wrote: > Hi, > > On 2015-01-21 13:49, Klaus Darilion wrote: >> Hi! >> >> Today I created some DNS tests with the old web interface. The creation >> process was fine, but the measurements did not work. (my target was >> ignored and "use probe's resolver" was automatically enabled). >> See UDMs: 1841832, 1841839, 1841840 > > It's unlikely that we've introduced bugs in those pages (not impossible > though). However: > * we deployed significant internal upgrades yesterday and some remaining > kinks were ironed out today. your measurements may have been caught in this > * as advertised earlier, we're about to abandon and remove the "old UI", > please use the new API/UI instead > >> btw: I can not stop 1841839 and 1841840 via the new web interface > > The stop button is on the measurement general page, somewhat below where it > really should be :-) I found the stop button - I clicked it multiple times - but hours later the measurement was still running. Maybe it was also caused by your upgrades. >> The DNS measurements only work if I create them via the new web interface. >> >> >> regards >> Klaus >> >> PS: IMO the new web interface is not very user friendly when choosing >> the probes - eg I failed to select 100 probes word wide (how to do this >> in the map)? It would be nice to have a textual alternative as my >> browser gets incredibly slow when showing all the probes on the map. > > Indeed we realise that the map can be a bottleneck sometimes. We're looking > at possibilities to remedy this. The old text-interface without map would be a remedy. Please do this before removing the old GUI. Thanks Klaus From astracha at ripe.net Fri Jan 23 11:26:25 2015 From: astracha at ripe.net (Alastair Strachan) Date: Fri, 23 Jan 2015 11:26:25 +0100 Subject: [atlas] VNET a.s. (Bratislava, Slovakia) has joined RIPE Atlas Anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sk-bts-as29405 and it is hosted by VNET a.s. in Bratislav, Slovakia. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From BECHA at ripe.net Fri Jan 23 14:41:35 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Jan 2015 14:41:35 +0100 Subject: [atlas] Implementing new RIPE Atlas Service Terms and Conditions In-Reply-To: <54C22F0B.7020908@ripe.net> References: <54C22F0B.7020908@ripe.net> Message-ID: <54C24F8F.9060201@ripe.net> Dear colleagues, As agreed on the MAT-WG mailing list, we are in the process of implementing the new RIPE Atlas Service Terms and Conditions that clearly state the role and responsibilities for the RIPE NCC, RIPE Atlas hosts and users: https://atlas.ripe.net/legal/terms-conditions/ This is the implementation plan: - End of January, existing probe hosts will be notified by email about the upcoming transition to the new terms and conditions. - From next week (during February), existing users and probe hosts will be presented with a banner when they log in to the RIPE Atlas website, to inform them of the upcoming transition. - As of 2 March 2015, the new RIPE Atlas Service Terms and Conditions will come into effect; new probe hosts will be asked to agree to the new terms and conditions when applying for a probe; all existing probe hosts will be subject to the new terms and conditions. Thank you for your feedback and for helping us to refine these new terms. Regards, Vesna Manojlovic Measurements Community Building RIPE NCC From astracha at ripe.net Tue Jan 27 14:33:42 2015 From: astracha at ripe.net (Alastair Strachan) Date: Tue, 27 Jan 2015 14:33:42 +0100 Subject: [atlas] Hitech Service LLC (Kiev, Ukraine) has joined RIPE Atlas Anchors Message-ID: <5D596DAD-3F77-4235-A35A-379A59A7F673@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ua-iev-as29632 and it is hosted by Hitech Service LLC in Kiev, Ukraine). Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From BECHA at ripe.net Fri Jan 30 13:36:29 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 30 Jan 2015 13:36:29 +0100 Subject: [atlas] Implementing new RIPE Atlas Service Terms and Conditions - summary of changes In-Reply-To: <54C24F8F.9060201@ripe.net> References: <54C22F0B.7020908@ripe.net> <54C24F8F.9060201@ripe.net> Message-ID: <54CB7ACD.7040905@ripe.net> Dear all, due to the popular demand, here is a reminder on where you can see the summary of changes between "Pilot Service Rules" and new RIPE Atlas Terms and Conditions, in the updated RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-moving-to-production-service#update & https://labs.ripe.net/Members/becha/ripe-atlas-moving-to-production-service#comparison Regards, Vesna On 23-jan.-15 14:41, Vesna Manojlovic wrote: > Dear colleagues, > > As agreed on the MAT-WG mailing list, we are in the process of > implementing the new RIPE Atlas Service Terms and Conditions that > clearly state the role and responsibilities for the RIPE NCC, > RIPE Atlas hosts and users: > https://atlas.ripe.net/legal/terms-conditions/ > > This is the implementation plan: > > - End of January, existing probe hosts will be notified by email about > the upcoming transition to the new terms and conditions. > > - From next week (during February), existing users and probe hosts will > be presented with a banner when they log in to the RIPE Atlas website, > to inform them of the upcoming transition. > > - As of 2 March 2015, the new RIPE Atlas Service Terms and Conditions > will come into effect; new probe hosts will be asked to agree to the new > terms and conditions when applying for a probe; all existing probe hosts > will be subject to the new terms and conditions. > > Thank you for your feedback and for helping us to refine these new terms. > > Regards, > > Vesna Manojlovic > Measurements Community Building > RIPE NCC > > From mgalante at ripe.net Fri Jan 30 15:11:29 2015 From: mgalante at ripe.net (Michela Galante) Date: Fri, 30 Jan 2015 15:11:29 +0100 Subject: [atlas] Web Werks (IN) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called in-bom-as33480 and it is hosted by Web Werks in Mumbai, India, and sponsored by APNIC. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From bortzmeyer at nic.fr Sat Jan 31 16:57:59 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 31 Jan 2015 16:57:59 +0100 Subject: [atlas] Glitch in measurements today? Message-ID: <20150131155759.GA26640@nic.fr> Many: {u'id': 7, u'name': u'Failed'} when querying measurements. It seems OK, now.