RIPE 72 MAT Working Group Minutes

Date: 25 May 2016, 14:00-15:30
Chair: Nina Bargisen
Scribe: Suzanne Taylor

A. Introduction: Welcome, Scribe, Jabber, Agenda

Nina welcomed everyone to the session and thanked the scribe and stenographers.

She asked whether there were any objections to the draft minutes from the RIPE 71 MAT Working Group session. There were no objections and she declared the minutes approved.

She asked whether there were any changes or additions to the agenda; there were none.

B. Measuring DNSSEC Configuration of Upstream Resolvers with RIPE Atlas

Moritz Müller, SIDN

This presentation is available online:
https://ripe72.ripe.net/presentations/103-RIPE72_Measure_DNSSEC_with_Atlas.pdf

Vaibhav Bajpai, Jacobs University Bremen, asked what fraction of the 500 probes in the Netherlands that Moritz used are using 8888 as their resolver. Moritz replied that he would have to look up the exact figure, but that it was a large number.

Vaibhav then commented that its useful to know which resolver the probe will use, and asked the RIPE Atlas team to consider making this information available via the probe API. He added that any measurement done will be affected by which resolver the probe uses, so this would be useful information to have.

Philip Homburg, RIPE NCC, responded that the probe knows where it will send packets, so as soon as the first measurement runs, this information will be available for all the probes. He said that there are probably APIs for this already, but if not, then the team can add them. However, he said that where the packet will come out the other end can't be known by the RIPE Atlas infrastructure, so this is something that a user needs to discover on their own, as it's not something trivial for the RIPE Atlas team to deduce.

Sebastian Castro, NZRS Ltd, said that he loved Moritz's work. Sebastian challenged Moritz to find the resolver's addresses, adding that, with the data Moritz has for .NL, he could look up which resolvers query the data. Sebastian said that Moritz was in a position to find a pattern using the source addresses and traffic to discover validating resolvers in order to get a new view on the state of validation.

Mortiz thanked Sebastian for his comment and added that their research has indeed indicated that this kind of investigation would be possible.

There were no further questions or comments.

C. Vantage Point Selection for IPv6 Measurements: Benefits and Limitations of RIPE Atlas Tags

Vaibhav Bajpai, Jacobs University Bremen

This presentation is available online:
https://ripe72.ripe.net/presentations/116-index.pdf

Brian Trammell referred to a comment Vaibhav made during his presentation that user tags tend to become stale over time because the tags don't change. Brian asked whether Vaibhav had any information about how often the underlying properties that tags give information about tend to change. He said that usually the location of the probes don't tend to change, either, and he asked whether Vaibhav had looked at how many of the tags were wrong. Vaibhav said he would look at how many tags are wrong, compared to system tags, in the future. Brian said he looked forward to hearing about those results.

There were no further questions or comments.

D. Internet Path Transparency Measurements using RIPE Atlas

Brian Trammell, ETH Zürich

This presentation is available online:
https://ripe72.ripe.net/presentations/86-atlas-udpdiff.pdf

Vaibhav Bajpai, Jacobs University Bremen, referenced Brian's assertion that TCP seems more impaired than UDP, and asked whether this was a function of the destination port, and how things would look if you looked a well-known port. Brian said it looks bad, but more confusing and that they couldn't explain some of the things they saw when using a well-known port. He said that some of the RTTs they get on port 80 are faster than the speed of light, indicating that there's some spoofing happening on that path. He said this also plays havoc with the UDP/TCP connectivity figures.

Philip Homburg, RIPE NCC, said that part of the problem was that Brian was measuring a legacy protocol, which means you get an ICMP back and generally only get a little bit of data, and that they need those ports. He said it's perhaps possible to create another kind of traceroute where the results wouldn't be as accurate, but you would get more control over the destination points. Brian said that he didn't care about which hop it came from because he had his TTL set very high, or you run it all on IPv6. He said that Philip made a good point.

Vaibhav suggested that a good follow-up research question might be to look at whether UDP is blocked more over IPv4 or IPv6. Brian said that his research team didn't look into that and that they didn't use dual-stack as a criterion because they wanted to maximise the geographic diversity. He said that rerunning it using only dual-stack hosts is something they have planned for the future. Vaibhav said he would be interested in helping with that, and Brian thanked him.

There were no further questions or comments.

E. RIPE Atlas News

Vesna Manojlovic, RIPE NCC

This presentation is available online:
https://ripe72.ripe.net/presentations/127-BECHA-mat-wg-ripe-atlas-update-RIPE72-v42.pdf

Filiz Yilmaz, Akamai Technologies, asked about the high number of abandoned probes and asked whether Vesna knew the underlying reason(s) for these probes being abandoned. Vesna said that abandoned probes are those that were connected at some point but have been offline for more than three months. Vesna said that they have sent reminders to probe hosts to try to get these probes online. Filiz said it would be nice to have more information about why these probes stay offline, and Vesna said that they will continue to look into it.

Randy Bush, IIJ, suggested that M-Lab might be in position to offer to store some of the large amount of RIPE Atlas data that Vesna referenced during her presentation. Kaveh Ranjbar, RIPE NCC, explained that the issue is not actually about storing the data, but being able to answer all the queries and serve the data live, which means expanding the platform. He said that in the future, they prefer not to expand that way, but asked whether people feel it's necessary to make live access to all the data available, from both a research and an operational point of view. Kaveh asked for feedback about this.

Randy responded that he wanted to give the RIPE Atlas team a potential method for making the data available forever online in an easily accessible way, and also to give an incentive to M-Lab to make their stored data universally available. He said that he's currently working on a longitudinal study trying to reproduce data from a five-year-old paper, and so having historical data available is important.

Emile Aben, RIPE NCC, said that he wanted to acknowledge the operators who had crowdsourced geolocation data for one of the RIPE Atlas visualisations, called OpenIPMap, and said their efforts were very much appreciated. Vesna asked for a round of applause for those people.

Vaibhav Bajpai, Jacobs University Bremen, asked about the possibility of forming a RIPE Atlas Working Group. MAT WG Chair Nina Bargisen asked whether there is really a need for this. Vaibhav said that he does think this is warranted and that there is a lot of published research using RIPE Atlas data.

Shane Kerr, Beijing Internet Institute, said he didn't think there's a need for a RIPE Atlas Working Group and that if the RIPE NCC wants to hold some workshops, etc. to connect with its constituency, that is sufficient, although he commented that many people find a lot of value in RIPE Atlas.

Daniel Karrenberg, RIPE Atlas and one of the founders of RIPE Atlas, commented that he didn't see the need for a RIPE Atlas Working Group but echoed comments from others that the MAT WG could focus more on other content. Daniel said that the MAT WG has been a good forum for providing feedback on RIPE Atlas.

Daniel continued “as a RIPE Atlas user” by agreeing with Randy's comment that there is value in having long time series data available. He said that he didn't believe the RIPE NCC had a cash problem and that the necessary hardware for storage is becoming cheaper, and that it was easier to keep the data stored at the RIPE NCC where there were no worries about it being subject to foreign jurisdiction, etc. so it seemed an obvious thing for the RIPE NCC to do.

Daniel also commented on the issue of private measurements and said that he though they should be getting rid of this option. He said that he believed only the metadata for the measurement, such as its creator, was still private, and that he was shocked to learn that the near real-time data was filtering out the data from private measurements. He proposed tasking the RIPE NCC with changing the terms and conditions to make all data public and that, if necessary, allowing to option to make only the measurement specifications (such as who created the measurement) private. He finished by saying that if you want to keep your measurements private, then RIPE Atlas should not be your tool of choice.

Vesna responded that while she personally agreed with Daniel, she also needed to represent the interests of RIPE Atlas users, several of whom had presented arguments for keeping some measurement data private. She said that there should be more discussion about this among the RIPE Atlas team.

Randy said he disagreed with Daniels' two comments. First, he suggested that the RIPE NCC may not have a “cash” problem but a “cache” problem, and that he doesn't want to conduct research by having to pull data piece by piece from a remote server removed from his computing machine. Second, he said that RIPE Atlas is a useful tool and that sometimes we're surprised by novel uses for such tools, and that he could understand network operators wanting to use RIPE Atlas to monitor their networks. He suggested making the back-end open source so people can buy 1,000 probes, set up their own back-end and run things for their own purposes.

Nina asked to direct further comments and questions to the RIPE Atlas mailing list in the interest of time.

F. RIPE Atlas Hackathon Winner

Shane Kerr and Désirée Milosevic

This presentation is available online:
https://ripe72.ripe.net/presentations/78-ripe-atlas-halo.pdf

There were no comments or questions.

Z. AOB

Nina suggested perhaps leaving more time during the next MAT Working Group session for more group discussion.

Randy Bush said he thinks that RIPE Atlas and the people responsible for it are “awesome”, which garnered applause from the audience.

Nina thanked everyone for attending the closed the session.