RIPE 70 MAT Working Group Minutes

Date: 13 May 2015, 14:00-15:30
Chair: Christian Kaufmann
Scribe: Suzanne Taylor

A. Introduction

  • Welcome
  • Scribe
  • Jabber
  • Agenda

Christian welcomed everyone to the session and introduced Nina Bargisen, the new MAT Working Group Co-chair. He also thanked the scribe and stenographer.

He asked whether there were any comments regarding the RIPE 69 minutes or any objections to them. There were no comments or objections and the minutes were approved.

B. New Co-chair

Christian explained the process of selecting a new co-chair and how consensus was reached on the MAT Working Group Mailing List to approve Nina. He then went over the agenda for the session.

C. RIPE Atlas News

Vesna Manojlovic , RIPE NCC

This presentation is available at:

Ondrej Filip, CZ.NIC, commented about the policy to maintain RIPE Atlas anchors for three years only when they are still fully functional and said he doesn't like the idea of throwing out functional hardware just because it is no longer being supported once its warranty expires.

Vesna responded that when RIPE Atlas began, they weren't sure how long the anchors would last and they wanted to ensure stability, but that she appreciates Ondrej's point and that it might be time to review the three-year service policy. She said she would take that feedback back to the development team and the other anchor hosts.

Jen Linkova, Google, said she is a RIPE Atlas user and happy to learn about the new features that Vesna presented. She said she had a feature request, to be able to make a selection of probes located in different ASNs to use in measurements.

Vesna responded that this is a good feature request and that she would take note of it.

Thomas King, DE-CIX Management, thanked Vesna for the IXP tool, which he said was really useful for the ISP community. Vesna gave credit to Emile Aben, RIPE NCC, who was in attendance and received applause.

Marcos Sanz Grosson, DENIC, asked about the security review that Vesna mentioned in her talk. Vesna said she would defer to her colleague, Robert Kisteleki, to answer the question.

Robert Kisteleki, RIPE NCC, first commented in response to Jen's feature request about selecting probes that are widely distributed. Robert explained that it's complicated because, for example, if there is only one probe in Antarctica, then everyone would select that probe and it would quickly become overloaded. He said the team is working on how to tackle this issue. Vesna also said that in her presentation on the RIPE Atlas hackathon later in the session, she would show an example of code that allows for a more evenly distributed probe selection.

Regarding the question about the security review, Robert said that they would be asking external consultants to look at what the RIPE Atlas team has developed as well as their processes, and that it might include a code review. He said the point is to have an external view of the system to ensure the development team hasn't overlooked anything.

There were no further questions or comments.

D. A Basic ISP Ranking by Market Share, from Random Measurements

George Michaelson, APNIC

This presentation is available at:

Emile Aben, RIPE NCC, thanked George for mentioning OpenIPMap and asked anyone interested in open-source geolocation data to look into it. George also encouraged everyone to look into the project, which he said is extremely useful and helpful to everyone.

Bart Braem, University of Antwerp – iMinds, urged George to study the mobile landscape. George said that he understands the importance of this and that they have ideas about how to do this, but that modifying how they currently make measurements to become acceptable for mobile devices is complicated and taking longer than they originally thought.

Bart said that the Belgians are perhaps even worse than the Netherlands, and so it's worth investigating. George said he thought that mobile data would improve the figures, but asked whether Bart agreed. Bart said that they hear from operators in the Belgian IPv6 Council that it's ongoing but they are not there yet, so they're not yet at the rates for CPE or fixed deployments.

George said that one of the biggest reasons he's heard for why people don't deploy IPv6 is that most modern mobile deployments are what's called a virtual overlay, and that even the prime providers are no longer in-house, that you have to be a big economy to run your own. He said that IPv6 deployment is simply not a priority. George asked whether this is what Bart sees. Bart responded that it might be, but there are other issues and that they could discuss this topic together later on.

Dave Wilson, HEAnet, said George's presentation was really interesting and asked how he calculates the number of users – namely, whether he's assuming that each user has one ISP.

George responded that Dave got to the heart of the other side of the ITU reporting with that question, because the number of users is a crude measure that could be based on registered customer premises or the actual consumer IP end points, and those two numbers could be off by a factor of two. He said that, whichever figure is used, it is at least a consistent figure, because all figures are reported the same way. He said he believes it is random eyeballs that are visiting the ads, and so those figures roughly equate to market share within an economy.

George asked Dave if he knew of a better way of measuring users. Dave responded that he didn't and that he was shocked when he looked at the absolute numbers and wondered whether they could include the same users on different devices. George responded that indeed, if you look at Australia as an example, there are 12 million declared Internet users out of a population of 25 million, but he believes the number of users is actually much larger and that the 12 million figure refers to domiciles or end points declared in provider broadband plans.

There were no further questions or comments.

E. “BGPStream” (An Open Source Framework for Live/Historical BGP Data Analysis)

Chiara Orsini, CAIDA/SDSC

This presentation is available at:

Martin Levy, CloudFlare, thanked Chiara for her presentation and said it was very interesting. He asked whether you could use your own source of BGP data in her work by putting your own private collector into her framework of code.

Chiara responded that you could do that, and that BGPStream supports data in MRT format. She said the easiest way would be to have MRT files saved in the system, and then use a CSV file to allow BGPStream to access the data.

Martin then asked why Chiara uses MySQL and not one of the other time-based databases available. Chiara responded that it was simply easy to implement because there are no specific requirements for storing metadata.

Colin Petrie, RIPE NCC, said he also found Chiara's work interesting. He mentioned that he is also doing some similar work as part of the RIPE NCC's Route Information Service (RIS) and that he would be presenting tomorrow during the Routing Working Group session about a real-time streaming interface for RIS and how it would hopefully plug into a system like BGPStream. Chiara said she would attend the session.

Mathias Handsche, DE-CIX, asked where he could download and try BGPStream. Chiara said the software is not yet available online but that Mathias should contact her directly.

There were no further questions or comments.

F. Measuring Delay and Packet Loss at an IXP

Christoph Dietzel, DE-CIX

This presentation is available at:

During the presentation, there was a question about whether the packets are UDP or ICP. Christoph responded that it's just a hack and is an ICMP port unreachable. The audience member commented that the load balancing for ICMP packets often happens on the checksum of the packets, which can be a problem. Christoph responded that this isn't the case, and that the measurements from A to B are using UDP packets and only the response to measure the round-trip time uses ICMP.

The audience member said that different probes can have the same port number, but Christoph replied that they only use one probe per port number. The audience member said it's hard to know whether all the ICMP messages are returning over the same path because of Christoph's implementation. Christoph thanked him for his comments.

Once the presentation had ended, Eric Vyncke, Cisco, asked why Christoph used a random UDP port number, and didn't use random IPv6 addresses as the source addresses. Christoph asked whether Eric was referring to spoofing, and Eric said he wasn't, but instead meant using multiple IPv6 addresses on one machine. Christoph said that, in theory, they would have liked to do that, but that, in practice, there are some limitations because of the provisioning system they use for their measurements, which provide fixed IP addresses.

Gert Doering, SpaceNet, said he's a member of DE-CIX and was quite happy to not have to see the neighbour discovery traffic for the return path trying to resolve 65,000 IP addresses in addition to all the noise Christoph already has, so he didn't want them to look at the ICMPs coming back.

Roman Florea, Tampere University of Technology, asked Christoph to elaborate on the nodes from which they are measuring, how they measure time and how they ensure their time measurements are precise since they are using software for this and the measurement equipment is very expensive for a reason. He asked whether they measure time in kernel or driver, or pick up packets from the user space. Christoph responded that they use NTP time synchronisation as the basis for their time measurements.

There were no further questions or comments.

G. Result of the RIPE Atlas Hackathon

Vesna Manojlovic, RIPE NCC

This presentation is available at:

Robert Kisteleki, RIPE NCC, jumped in at the start of Vesna's talk to show some recent RIPE Atlas results from that morning's connectivity issues, which clearly showed there was a problem.

There were no comments or questions regarding Robert's or Vesna's presentations.


Christian announced that there is a new rating system in place for the working group sessions and encouraged everyone to rate the session so the RIPE Programme Committee can learn what attendees want. He thanked everyone for attending and closed the session.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum