RIPE 73 MAT Working Group Minutes

Date: 26 October 2016, 15:00-16:30
Chair: Nina Bargisen
Scribe: Suzanne Taylor

A. Introduction: Welcome, Scribe, Jabber, Agenda

Nina welcomed everyone to the session and thanked the scribe, chat monitor and stenographers.

She reviewed the rules for asking questions using the room's microphone set-up and asked everyone to be respectful.

She asked whether there were any objections to the draft minutes from the RIPE 72 MAT Working Group session. There were no comments.

She pointed out a few changes to the previously posted agenda, which were already reflected online.

B. Wireless Performance Measurement and Verification Using the End-User Mobile Device Feedback

Anna Wilson, HEAnet

This presentation is available at:
https://ripe73.ripe.net/presentations/117-ripe73-mat-wifimon.pdf

There were no questions or comments.

C. What's Hiding Behind IPv6 Extension Headers?

Luuk Hendriks, University of Twente

This presentation is available at:
https://ripe73.ripe.net/presentations/124-slides_mat-wg_luuk_v2.pdf

Daniel Karrenberg, RIPE NCC, asked what kind of performance impact there was using multiple extension headers.

Luuk said that their probe is software based, so it is slow to begin with, but this makes it easy to develop the plugin. He said that, in the end, it didn't matter much because they were able to filter in the hardware what was going to the software. He said they didn't look into the performance impact, but that none of the software crashed. He said he had no hard numbers in terms of the impact on CPU or RAM.

Daniel asked whether Luuk had any additional information on the packets they lost that wasn't included in the aggregation. Luuk asked whether Daniel meant packets that were exported to the collector, and Daniel replied that you usually get an idea of how many packets were not captured and were not aggregated. Luuk said that as far as he knows, everything was included in the aggregation.

Benno Overeinder, NLnet Labs, asked about the fragmented IPv6 traffic they found. He said a large ISP in the Netherlands told him several years ago that they would block every IPv6 fragment on their networks, and said that he also knows of a global CDN that doesn't accept any fragmented IPv6 traffic. He asked about the DNS traffic they observed being fragmented, and whether it was really DNS traffic.

Luuk said that he had the same information for UDP and there is even more than 86%, which is port 53. He said he cannot say for sure that it is DNS, because he doesn't have payload information, as it's flow-based. He said this was a reason for the research, because operators, ISPs and CDNs are scared of fragmentation, but are unsure what is there.

There were no further questions or comments.

D. RIPE Atlas Update

Robert Kisteleki, RIPE NCC

This presentation is available at:
https://ripe73.ripe.net/presentations/121-ripe73-mat-atlas-update.pdf

Tim Armstrong, speaking on his own behalf, asked about the recent issues with the USB sticks dying unexpectedly, and joked about whether this would be an issue with the virtual machines.

Robert responded that the RIPE Atlas team had looked into the issue and published several articles about the extent and potential causes of the problem. He said they believe that flaky power supplies were contributing to the issue, which may affect some regions more than others. He said they are addressing the problem by enhancing the probes' firmware and that the software is now behaving better than it was. In addition, he said they are looking into next generation probe hardware that will remain more stable. He said the problem is not too bad but that they do recognise that it affects some users.

Sebastian Castro, NZRS Ltd, asked how frequently the Internet topology measurements happen.

Robert replied that every probe performs these measurements either every 10 or 15 minutes, by picking an address and performing a traceroute, and that they could get that down to once per minute if they wanted to. He said that he thinks they do one on ICMP and one on UDP.

Sebastian asked what the time frame was for making that available, and Robert responded that it is already available under the built-in measurements.

There were no further questions or comments.

E. Add System Tag for the Probes Behind "Nanny Filter"

Remco van Mook

This presentation is available at:
https://ripe73.ripe.net/presentations/87-MAT-RIPE73.pdf

Tim Armstrong, Nerdalize B.V., said he previously ran a small anycast network for DNS stuff and found the RIPE Atlas stuff really useful, but that he did see the kinds of issues Remco pointed out and thought the proposed tagging would be very useful for a lot of other anycast operators.

Daniel Karrenberg, RIPE NCC, said that he would be interested to know what Remco's definition of tempered DNS is, because he suspects that most of the locations of RIPE Atlas probes are in some way tagged with DNS. He also said that if people don't want the DNS influence, they can always measure based on IP address.

Remco replied that there is always the question of what constitutes tampering (e.g. is adjusting a TTL, or changing an A record, or redirecting tampering?). He said the reason you don't necessarily want to look up an IP address is because figuring out what the world thinks of a certain domain name or host name can be very interesting in terms of determining whether someone is trying to hack your website. For example, he said, there is interest in having consensus about the IP address of certain websites, such as your bank's website, and you could do that in a number of ways, but that using RIPE Atlas for that is not very useful because you can't do that simply by looking up an IP address.

Robert Kisteleki, RIPE NCC, said that from the RIPE NCC's perspective, the system tagging is extendable and that they just need good definitions for when the tagging should take place. Speaking for himself, he asked why this couldn't be done as a DNS measurement, looking at A records.

Remco responded that he could measure for this specifically, but that if he doesn't measure specifically for this then he gets all sorts of “fuzz” in measurements that shouldn't be there. So, he said, even if he doesn't consider that there might be people doing strange things with DNS recursive queries, he might end up with all sorts of strange answers in different measurements that he can't make sense of. Therefore, he said, being able to filter out RIPE Atlas probes based on a system tag or user tag means the results could be improved.

Robert said that, again, it boils down to the definition.

There were no further questions or comments.

F. Country Topology Map Using Atlas

Sebastian Castro, NZRS Ltd

This presentation is available at:
https://ripe73.ripe.net/presentations/86-Country-Topology-Map-using-RIPE-Atlas.pdf

There were no questions or comments.

G. Speed Checker Comparison with RIPE Atlas

Cristián Varas, Speedchecker

This presentation is available at:
https://ripe73.ripe.net/presentations/126-RIPE73-Presentation.pdf

Daniel Karrenberg, RIPE NCC, asked a question during the presentation about the Microsoft example in Japan and whether Cristián did DNS resolution on the probes for those. Cristián said that he did, and that he also tested the Google DNS points directly, but that there was no difference when resolving the address. He said it was a bit of a mystery. Daniel said that it must have something to do with the DNS, as Akamai's “secret sauce” is in the DNS, and he was very suspicious that Cristián didn't get the same IP addresses when he queried for Microsoft.com. Cristián said he would be happy to look into it, and then continued with the presentation.

Peter Hessler asked whether Cristián had compared the network types for the probes from RIPE Atlas and ProbeAPI, in terms of whether they were located in home networks or data centres, etc.

Cristián said that they did not look into that.

Massimo Candela, RIPE NCC, said that he checked and found that Cristián didn't use resolving probes in their Akamai test, which could have explained the results.

Daniel Karrenberg, RIPE NCC, explained that the DNS measurements ran in Amsterdam, so Cristián would have gotten the optimal Akamai node for Amsterdam, and if you go from Japan to the optimal node in Amsterdam, it will obviously take longer.

Daniel then asked about Cristián's assertion that the bigger volatility they saw in the software probe was due to a number of factors, including more diverse locations. He said he was more interested in the other things that were running on the machines, which are not on RIPE Atlas probes, and whether Cristián knew how big of an influence that had. He also asked whether Cristián had thought about monitoring the system to see whether probes were too busy for measurements.

Cristián said the only factor they had considered was whether there was WiFi, and that it would be interesting to include system variables in the analysis. He referred Daniel's second question to his Speedchecker colleague, Janoz Jezowicz.

Janusz said that, by definition, you cannot monitor cross-traffic on software probes, and that there are other limitations on the software. He said you can only monitor what's on the machine itself, such as user activity. He said you need to use a lot more probes to get a comparable level of data quality.

Robert Kisteleki, RIPE NCC, asked how Cristián determined where the agents were located.

Janusz responded that they used two geolocation methods: Mozilla's geolocation API, which uses WiFi, as well as IP geolocation tools from commercial vendors. He said that Mozilla's locates about 50% of the probes in the WiFi range, which they scramble for privacy reasons.

There were no further questions or comments.

Z. AOB

Nina reminded everyone to vote in the RIPE Programme Committee election and to rate the talks at RIPE 73. She also encouraged everyone to use the MAT Working Group mailing list for interesting discussions, and to submit a lightning talk.

She asked for any final remarks. There were none, and she closed the session.