- mat-wg - mailman.ripe.net

Apply for the RIPE Atlas data visualisation hackathon
by Vesna Manojlovic 08 Jan '15

08 Jan '15

Dear colleagues, 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 in the RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-hackathon-20… Hope to see you there! Regards, Vesna

1 1

MAT-WG proposal for WLAN measurements on RIPE Atlas
by Brook Schofield 26 Dec '14

26 Dec '14

MAT-WG, thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69. You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40 To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points: #1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host. #2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement. For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process. #3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network. The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case. #4: The schedule for implementation will be determined by the RIPE NCC R&D team ...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community. #5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different. My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further. Thanks, -Brook -- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.géant.org <http://www.xn--gant-bpa.org>

8 11

New on RIPE Labs: Visualising RIPE Atlas Probe Distribution
by Mirjam Kuehne 16 Dec '14

16 Dec '14

Dear colleagues, Please find a new article on RIPE Labs showing a visualisation of the distribution of RIPE Atlas probes compared to population: https://labs.ripe.net/Members/emileaben/distribution-of-ripe-atlas-probes Kind regards, Mirjam Kuehne RIPE NCC

1 0

Sixteen new RIPE Atlas anchors joined the community
by Michela Galante 08 Dec '14

08 Dec '14

Dear colleagues, We are proud to announce that sixteen new RIPE Atlas anchors have been activated since our previous announcement: * nl-ams-as12041 hosted by Afilias in Amsterdam, Netherlands. * kz-ala-as21299 hosted by 2Day Telecom LLP in Almaty, Kazakhstan. * Two anchors hosted by Booking.com: nl-ams-as43996 located in Amsterdam, Netherlands and uk-slo-as43996 located in Slough, United Kingdom * sk-bts-as201702 hosted by skHosting.eu in Bratislava, Slovakia. * kz-plx-as21282 hosted by KazNIC Organization in Semey, Kazakhstan. * lk-cmb-as38229 hosted by Lanka Education & Research in Colombo, Sri Lanka and sg-sin-as45494 hosted by openmirror.asia in Singapore, Singapore. These are the first two of ten anchors that APNIC will sponsor. * qa-doh-as8781 hosted by Ooredoo in Doha, Qatar on behalf of RIPE NCC since they are one of our K-root hosts. First anchor in Middle East! * uk-lon-as5459 hosted by LINX in London, United Kingdom on behalf of RIPE NCC since they are one of our K-root hosts and RIS Remote Route Collector locations. * si-lzp-as198644 hosted by the Go6 Institute in Skofja Loka, Slovenia, and sponsored by SIDN, Netherlands. * it-mil-as16004 hosted by Milan Internet eXchange (MIX) in Milan, Italy on behalf of RIPE NCC since they are one of our k-root hosts and RIS Remote Route Collector locations. * Three anchors hosted by Wikimedia Foundation in United States: us-qas-as14907 located in Ashburn, us-cax-as14907 located in Carrollton and us-sfo-as14907 located in San Francisco. * us-lan-as32244 hosted by Liquid Web Inc in Lansing Charter Township, United States. This brings the total number of anchors to 94. You can follow the activation rate on the graph here: https://atlas.ripe.net/results/maps/network-coverage/ The map of all anchor locations: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from individuals and organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb(a)ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Kind regards, Michela Galante Measurements Community Building Team RIPE NCC

1 0

Updated Draft RIPE Atlas Service Terms and Conditions, v3.2
by Vesna Manojlovic 01 Dec '14

01 Dec '14

Dear colleagues, Here is an update on RIPE Atlas Service Terms and Conditions: On 15 September, we announced a draft version of new RIPE Atlas Service Terms and Conditions, along with a proposed implementation procedure: https://labs.ripe.net/Members/becha/ripe-atlas-moving-to-production-service We published version 3.1 on 29 October, after incorporating feedback received from the community. During RIPE 69 in London last month, more feedback was received, and we’ve now published a third version (3.2), available here: https://atlas.ripe.net/legal/terms-conditions-draft/ Summary of changes: - Extended clarification of point 8.5.a - Minor modifications to grammar and references The revised implementation plan, with adjusted dates, is as follows: - December: last call for comments. If consensus is reached: - In January 2015, existing probe hosts will be notified by email about the upcoming transition to the new terms and conditions. - In addition to email notification, existing users and probe hosts will be presented with a pop-up window when they log in to the RIPE Atlas website, to inform them of the upcoming transition. - From 1 February 2015, RIPE Atlas will become a production service; new probe hosts will be asked to agree to the new terms and conditions when applying for a probe and all existing probe hosts will be subject to the new terms and conditions. We are coordinating with the MAT Working Group Chair to have a final call for comments for both the draft document and the implementation plan. Kind regards, Vesna Manojlovic Senior Community Builder Measurements Community Building

2 1

RIPE 69 presentation atlas vs nlring : data publicly available
by Thomas Holterbach 10 Nov '14

10 Nov '14

Hi, The results of the experiments that have been presented during the MAT session of the RIPE 69 meeting by Randy Bush (*On the Suitability of Two Large-Scale Internet Measurement Platforms)* are now publicly available in http://psg.com/~thomas/. Best regards, Thomas

1 0

Nine new RIPE Atlas anchors joined the community
by Vesna Manojlovic 07 Nov '14

07 Nov '14

Dear colleagues, We are proud to announce that nine new RIPE Atlas anchors have been activated since my previous announcement: * de-cal-as39702, S-IT Informationstechnologie Betreiber, Calw, Germany. * nz-hlz-as681, hosted by the University of Waikato, Hamilton. This is the first RIPE Atlas anchor in New Zealand! * Three anchors by DigitalOcean: uk-slo-as202109 located in Slough, United Kingdom, us-sfo-as14061 located in San Francisco, United States, & sg-sin-as133165 in Singapore City, Singapore. * de-ett-as202040, hosted by SCT Schiele GmbH in Ettlingen, Germany. * nl-ams-as3265, hosted by XS4ALL in Amsterdam, Nederland. * us-den-as7922, second anchor hosted by Comcast, this time in Denver, United States. * de-nue-as33988, hosted by teamix GmbH in Nuremberg, Germany. This brings the total number of anchors to 78. Due the summer holidays, the growth in RIPE Atlas anchors have slowed down, but we do expect a new "surge" in the last quarter of this year. You can follow the activation rate on the graph here: https://atlas.ripe.net/results/maps/network-coverage/ The map of all anchor locations: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from individuals and organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. 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

2 3

atlas vs nlring data available
by Randy Bush 06 Nov '14

06 Nov '14

From: Thomas Holterbach <thomasholterbach(a)gmail.com> > did you hear daniel karrenberg on making the data public? Yes, the data of the first experiment is already public and available on http://psg.com/~thomas/ Tomorrow I'll add the data of the second experiment.

1 0

Atlas Light Map
by Daniel Karrenberg 05 Nov '14

05 Nov '14

In the meeting George Michaelson referred to the light maps from space that were part of the the inspiration for RIPE Atlas as shown in http://www.slideshare.net/ripencc/ripe-atlas-a-real-big-measurement-network… Attached is a map of the RIPE Atlas probes in a similar colour scheme which I did a couple of months ago. It is large, you can zoom in. I leave it to your judgement how similar these are. Personally I am amazed how how well one can see things around Europe. Daniel

1 0

Atlas Sagan library and UDP tarceroute results: bug or feature?
by Jen Linkova 31 Oct '14

31 Oct '14

Hello, I've just found that using Sagan library for analyzing UDP traceroute measurement results may produce incorrect results: 'target_responded' variable is not be set to 'True' if the source address of the traceroute reply is not the target address of the traceroute, but any other address that belongs to the node. (From the traceroute.py code: def target_responded(self): if self._target_responded is not None: return self._target_responded self._target_responded = False if self.hops and self.hops[-1].packets: destination_address = IP(self.destination_address) for packet in self.hops[-1].packets: if packet.origin and destination_address == IP(packet.origin): self._target_responded = True return self.target_responded ) I don't think that's a valid assumption that a target node is *always* choosing the probe packet's destination address as a reply source. In particular, in case of UDP packets addressed to anycast, it might fail because the node can reply from another address. In particular, rfc4443 (ICMP for IPv6) says: 2.2. Message Source Address Determination A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: (a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. == and in the same RFC source address selection for ICMP echo reply messages is defined: The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. ==== So, I'm sending this email, first, to warn those of you who is using Sagan to analyze UDP traceroute results, and, secondly, to discuss, if Sagan behavior is a bug (I believe it is) or a feature ;) -- SY, Jen Linkova aka Furry

1 0