Archives

These are unedited transcripts and may contain errors.


MAT Working Group
4 p.m.
17 October 2013

CHAIR: Good evening. Welcome to the MAT Working Group. Before we start, one question, is Special in the room? Then I guess we are safe.

So, first of all, we have two co?chairs. That's Richard here in the first row and me, I will moderate today, and go through. As usual, we have a scribe and the stenographer. We also have a Jabber channel, who is looking after the channel? Nobody have a Jabber channel? Not today? Ah, you are.

Microphone etiquette: After the various presentations we have, if you have a question or comment then please state your name that everybody who doesn't know you and your affiliation knows you you are.

The minutes: As usual we have sent out the minutes from the last meeting and published on the mailing list quite a while ago. Any comments to the minutes? Questions? No. Anyone objecting that we approve the minutes? No. Then the minutes are approved and we come to the more interesting part.

The agenda for today. So, as usual, we have a colourful mix out of more NCC related topics like the RIPE Atlas and the RIPE stats, but we also have other external talks like, for example, the mapping of the Dutch critical infrastructure. Something slightly more exotic. Network measurement maps. And what I'm very much looking forward to is geolocation talk from Robert which is actually will be given by Emilio.

So let's start with the mobile network measurement app for Android.

ENRICO GREGORI: Good afternoon. I'm here to present you an application we developed for doing some probing of the Internet using a mobile phone and a crowdsourcing approach.

First of all why we wrote this application. I had a couple of projects for monitoring the Internet infrastructure, I am Italian, and one we think we are monitoring and is interesting is we are interconnectivity between aut?num system level. We are studying this interconnectivity boast with passive BGP based activity measurement, and, which is called ?? this is what we call the Isolario project, and we started this interconnectivity also with active probing and this is the reason why we developed this application.

This application is, in this application the mobile phones are the starting point of proofing messages for active measurement. We decided to go for crowdsourcing approach on the smartphone. Why?

First of all, we do believe from experience that multiple observation point from different users are very important. And these observation points should be well distributed according on the population where it is exploiting the network. And having performance measure from our end user device gives you what is the end user perspective on network performance. It's a very different point from measuring things inside the network and it's very important because it's what the user perceive.

The smartphone are powerful enough definitely are growing, very interesting devices. They have a lot of sensors inside that could be used that could add the important information.

Smartphone stay with their user, the owner, so they move and they are always on. A smartphone is frequently connected to several networks during a day, so it's ?? it gives you other different probing opportunity because we know the geolocation of a phone. We know the network location of a phone, so the net address of the phone, so we know when things are changing and we can decide if it is a good time to do probing or not.

So smartphone are very interesting. The last point I want to mention was that a real driving force for us to go on smartphone is that deployment is not so difficult, but what is very easy is maintaining the user up to date with the new release where the market is a good mechanism to continue to update your application and the users are used to updating their application to every last, let's say, release of the application.

So, we started ?? I mean, I and Lucien started this activity with some student, some very young researcher, we started with some ?? and then some of the students started a Ph.D. programme, and it was initially just curiosity, to see how far we could go. We developed this application, I will tell you the functionality is still growing, but the first nucleus was developed and released in Italy on the 6th December. A smart advertisement to our academic community and we have some installation around Italy. We did some experiment and in June, we released the worldwide version. And now, we have some, let's say, the instant the application is installed, I will tell you the figure later on. It's not bad. It's not going too fast, but it's not going bad. We had, in this year, 500 users have installed this application with the limited publicity with did so far.

The methodology for the application. The application is made up of two different measurement, what we call user driven and what we call background. User?driven measurement is triggered by the user. That means you want the measure, you push a button, start, and receive your result of the measurement and you get the result. We store the result in our database.

What can we do with the user measurement? We will see later on, but I will go quickly to the type of measurement that we already have implemented.

Background measurement are different. We are the server that don't know who you are, but knows your position and your network. And from time to time we ask you to do some measurement, some traceroute or, in a very passive way, you can have some download to be, to download some RSS that is signal sample.

Background measurement is a contract we have of a user. The contract is that we never consume more than 1% of your battery in a day and we never ask a user as a bigger measure to transmit more than 2 megabits. So, you accept to download this application, you accepted to help the community to do some measurement that the public utility and that will be accessible to everyone, but the amount of energy and traffic you generate are very limited.

User measurement, let's go quickly to what we did.

Traceroute is visible. It's possible to implement a traceroute. It's unique traceroute only because we don't have Android ICMP access.

We had also traceroute in which the path is presented not at the route level but autonomous level.

We started the visual traceroute and we are not completely happy with that. So, once we located the router, we use in this first release, geolocation service that is not working very well sometime to know exactly the path but we are working on visual trace router to improve it.

And last we have a measurement, a user measurement that is not easy to find. The maximum through the estimation. You can find a lot of application that gives you instantaneous throughput but the maximum throughput is what is the maximum you can get from your network and that is something that is quite interesting we have developed and it's available in the application today.

We have the ping and shortly we are finishing the /EUPLGS of a wit torrent test and the application of the Internet is BitTorrent a shape or blocks, you can get the tester and discover these things.

And then we have also some other user driven measurement related to signal coverage tools. Signal coverage is not an absolute measurement. It's what your mobile phone is measuring as a signal. So, it's very ?? what is perceived by the user. And we could use ?? it's not difficult, reading the signal, knowing the GPS, it's easy to build a map of a coverage of a signal, at least we did a lot of experiment nearby in our city. The signal coverage tools is automatically started whenever you use a GPS enabled application like driving system or something like that, or you can start it manually and you can measure the coverage in your path to your depth nation.

All this application where something that we developed to stimulate the user to download our application. So if you are interested in it, you download this application, you get free of charge this measurement, and then you help us in background measurement.

Background measurement, I told you at the beginning, are focused on understanding ?? having a better understanding of Internet infrastructure. What we call regional campaign. We have implemented in this application Paris trace router and the multipath detection algorithm, that is a way to do work with this campaign but we also implemented the simplified version because in terms of energy consumption and load, we are not optimised so we have also an optimised version of Paris and multipath.

In this background measurement we started what we called regional trace router campaigns. What are these? The target is to understand the Internet infrastructure and the target is not to have a starting point and the point of a trace router not find, what we call the short range measurement. Why? This is because you must be close to the starting point to have a higher probability to discover a new link. If your target is very far, you will end up to go throughen tier 1 and then go down to your destinationnd the path from the tier one downwards is already known because BGP is able to discover it.

And this is what we call smart measurements driven by collected BGP data. So in our project, we have the BGP path and the trace router path and all the expert are smartly using both knowledge, what we call passive and active techniques cooperation.

The default measurement campaign is something we have defined and it's quite easy to understand. We select a region, let's sake an example, Italy, that's what we did at the beginning, or whatever the country, and since all our user are geolocated we can select which user is a good starting point for an Italian campaign, that means it's a user who is geographical location is within the Italian board. Then we select a destination, a set destination. We set the destination is ?? I mean simplifying the description is the Italian periphery, that means what we call stub, a stub is an autonomous system that does not traffic. It's a source or a destination of IP packet and we do traceroute from all the starting point in this region to this target of our destination, we stop in that region. And the idea we have in mind when we set this campaign is to build Internet connectivity information not all together, not a huge expert but but as a set of the parallel expert.

And so the idea we had in mind is to have a growing environment in which a different group analysed some portion of the connectivity and when we put all the data together, all together.

And in addition to this default measurement campaign, which is automatically and continuously running, we added a user interface to tell a specific measurement campaign and the target here is as I told you, to discover Internet periphery.

To give you an example of what we have been doing. This is some result that we obtained last May just, it was the first experiment after we start up. The first user we had. These users were located in 12 autonomous systems and the destination were in obviously the traceroute campaign where all the 566 stub in Italy.

It's quite interesting to see where our users were immediately located. You can see that, it's easy to understand the GAR, GAR is the ?? knows I have been working with the research community for a life together, so we have a lot of friends that downloaded our application. But the other autonomous systems that are very interesting and already immediately in our, let's say, measuring campaign are the big provider, WIND, Fastweb, TIM, both mobile and home services. ADSL access, because even though you have a mobile phone, most of the users have a wi?fi access at home and then goes through ADSL access.

So this campaign is something that is already interesting, in my view, because it's a starting point, it's not complete, but it is what it is perceived by more than 90% of Italian user because all these providers are providing Internet access to the vast majority of Italian population. So this is what we get is the Internet that is perceived by the End Users.

We ran this campaign. I don't care about numbers, they are interesting but we are not the most important thing of this presentation. We discovered, compared to the previous let's say start, the previous discovered topology property of the network, we discovered 528 links more, and as expected, most of them were peering links going through IXPs. It's well known that we most weak, or less accurate data in Internet topology analysis is the knowledge of peering links going through IXP. So, it's quite well known, but just the first experiment has shown us that the methodology was not bad.

So, after, as I told you, after June we released the application on the worldwide Android market, and that's a picture today. Today we have currently 300 installations of our application worldwide active. Obviously the most densely populated is Italy but they are well spread across Europe, North America, some in South America, most of them, at least the one you can spot I know we pro if he ever downloaded because it's a research community so far has mostly downloaded this application. I don't know who are the three in Africa, but this is the situation.

Some user, not everyone that has installed the application has continued to use the application, because the total installation were 500 and only 300 are currently active. This means someone may not like it or someone has maybe an old operating system or an old hardware and something is not running, is not happy and we can't control it.

Just to conclude the presentation, so I am perfectly on time ?? I want to give you, let's say, a comment of what we have learned from this experience.

First of all, mobile phones are not bad. Are not bad because they have enough power most of the time, they have a nice characteristics like a lot of sensors, always on, they move across different networks. The bottleneck, the limit point is the operating system. Android is the most flexible and that's why we have used them in the presentation. The student analysed the possibility to implement and we had an implementation IOS and we started the feasibility of the application in Windows phone. IOS and Windows phone are much more limited and the major limitation is that they don't accept the background application and doing measurement only 3 gig by the user is a very strong limitations for this type of application.

The challenge is reaching a large user base, but frankly speaking, we are happy because in one year we have very good effort, we have an installation of 300 probing systems worldwide, it is not bad. I mean when power required, students and two Ph.D. students working on this environment.

Traceroute in this environment should be smart because, I mean, you must be very careful about energy consumption. User very sensitive to energy consumption, cannot do too much traceroute, you must do when it is shortly needed.

And last point, and this is the main reason we are here is that it's very important to have a collaboration with legacy traceroute infrastructures. I mean both can add advantages.

First of all, having a bigger infrastructure increased the number of starting point. Second of all, as I told you, we are doing UDP traceroute, they could run ICMP traceroute and sometimes in some router, UDP traceroute is blocked and the ICP traceroute is not.

Okay. If you are interested in results, go to our website. The results are there. And if you are interested on the application, go to the Google play store.

(Applause)

CHAIR: Thanks a lot. Apparently we have some questions and comments.

AUDIENCE SPEAKER: Alex or yen. It was not very clear for me, do you allow people to look into all the statistics like with RIPE Atlas?

ENRICO GREGORI: Yes of course, if you go to our website. We are a research institution, I work for the Italian national Council and lieu tan is from the city of Pisa. The data is completely public and the methodology we use for our measurement was presented in paper.

AUDIENCE SPEAKER: So if I manage a mobile network and I install say one hundred copes of this application on my customers or some different people, can I run some measurements and see the specific results which are of my interest? Is it possible?

ENRICO GREGORI: Yes, that's what we call user measurement. As I told you from a traceroute stem point. I mean as a user you can do what you want. You push the button, start, stop, you get your data. As a single user, but you can also ask ?? you can ask ?? you can entail a campaign with your web interface, we are building an interface to tiler a measurement company.

AUDIENCE SPEAKER: Thanks.

AUDIENCE SPEAKER: Benno: Small follow?up question. Do you think to provide a similar interface as the Atlas? Would be very convenient for me.

ENRICO GREGORI: I mean just frankly speaking, we are open. I mean, we are still working on interface, the Ph.D. student is working on it and we had a meeting with people this morning, so, it's not a problem to find an interface that is well accepted to be community. I mean the target is to have something that is useful to the community. I mean that's the reason of crowdsourcing.

AUDIENCE SPEAKER: Daniel Karrenberg, RIPE NCC. It's interesting that Atlas has already received the legacy status or were you referring to legacy traceroute, nonParis traceroute because Atlas does Paris traceroute, just to clarify that. Coming to the question, what is your experience so far with the people who actually download the application and do some measurements for a period like, say, a week or two so it's not the people who download it and are immediately dissatisfied or it doesn't work on the operating system, but people where it actually works, how many of those drop out?

ENRICO GREGORI: I mean, I don't have exactly statistics, but the feeling is that we still have a partial number because, I mean, the way we understand the application it was through our community. So, I mean, I don't have a real feedback, but if the people perceive that some of what we call the user measurement is interesting for them, they leave the application because the application is not affecting their performance. I mean, having less than 1% of battery per day, is nothing for most of the people as a down grade of their quality of service. So the idea to ?? we have in mind about, we had to wait at least one year to see how far it goes, is to continue to build services that the people feel is interesting and this is the reason why we developed this BitTorrent test, because a lot of young people is very interesting in BitTorrent, and knowing if your provider is shaping the BitTorrent or not is important information.

DANIEL KARRENBERG: Let me leave with you a suggestion is one idea is what we might do is advertise your application among the Atlas probe hosts and then do a little bit of collaboration when they are at home, because if they have an Atlas probe at home and they have their phone at home going over the wi?fi, we could see whether there is differences in the performance based on the wi?fi, just an idea.

ENRICO GREGORI: I will talk with you later on because I'm not sure I understand everything about this. I think it's interesting and it's worth speaking about.

AUDIENCE SPEAKER: Last person.

AUDIENCE SPEAKER: Titiana, Google, involved in the measurement lab project. The first question is: Is the code available? Is it open source and is the raw data available? I was looking on the website I couldn't find it but maybe you are planning to do that?

ENRICO GREGORI: Okay. Sorry, repeat the second one because ??

AUDIENCE SPEAKER: The first question ?? the raw data.

ENRICO GREGORI: So far what is available is the application is free of charge, but it's not open source in the sense that you can you download the code and build another application starting from this code. Raw data are completely available. Let's see what the community and what is the interest of the community. I mean we are open for discussion.

AUDIENCE SPEAKER: My second question is ?? maybe you mentioned it in your presentation, I missed that. Where is the server infrastructure? You are running measurements against some servers, what are those?

ENRICO GREGORI: What do you mean reconstruction?

AUDIENCE SPEAKER: Infrastructure.

ENRICO GREGORI: Oh, infrastructure. I mean, what we have measured for just to test the system is what we call in this experiment Italian region infrastructure. And this is the Internet that you cross when you start from an Italian node and your target is located in Italy.

AUDIENCE SPEAKER: Basically your server is the network.

ENRICO GREGORI: So far we only used this one. We could do much more but so far this is what we did.

CHAIR: Good. Thank you. Sorry, let me cut off here because we are already running late. Can we take it off line? Thanks a lot again.

(Applause)

CHAIR: So, the next one is Vesna talking about an update of the RIPE stats.

VESNA MANOJLOVIC: I only have ten minutes for this update so I'll speak very fast.

RIPE Stat is the main tool for visualising the data that RIPE NCC has about Internet resources. So, it's a one?stop shop for all the information that you want to know about IPv4 addresses, IPv6 addresses, AS numbers and we have two sources for this information, one is the RIPE NCC data, so the registration information that we have, the WHOIS database, routing information collected by the routing information service, reverse DNS data and measurements by RIPE Atlas and on the other hand, we have data sets from external organisations about Internet resources. So you can see on the slide that's the other routing registries, the registration information from other RIRs, regional Internet registries, geolocation, blacklists and since recently, the network activity measurements from M labs.

The main way of looking at all this data is through the web interface. However, we have many other ways of accessing the data, so you can query by an IP prefix, an IP address, either v4 or IPv6. AS number, but you can also see the aggregated views per country so if you type in the country code you receive the information for that specific country or a host name if you are interested more into to approach it from the DNS side, let's say.

And apart from the main website, there are also widgets that we use, but you can reuse yourselves, so, here at the bottom of the screen, it says that these widgets are em beddable, so you can take them and put them on any other website and they'll be getting the information from the RIPE Stat.

There is the data PI, so you can programme your own visualisation, you can script based on that. If you are quite old?fashioned, you can also use a text service, and we also have mobile app. So these are the kind of main characteristics and then we have some highlights from the previous updates which is folks BGPlay. This is the most powerful visualisation that we have that let's you you see in a kind of movie way how did the routing change in a certain time period. So you asked for an AS number and then it shows you all the prefixes that were announced and revoked and how did they change over time and that looks quite pretty on the screen.

Then we have something much more practical, which is abuse finder. Then we have the way to group the widgets in your own fashion, so, you don't have to do it in the way how we grouped it like routing in DNS and IPv6, but you can make customised views.

If you are a member of the RIPE NCC, if you log in with your LIR access account you can also see historical information. About RIPE database object, the routing historical information is available to everybody.

So, how does Greece look like if you type in GR in RIPE Stat? Well this is the routing history, and this is the number of probes that are there, or here, let me say, and we distributed a lot of probes during this RIPE Meeting so we are looking forward to seeing a much different picture soon.

And this is how it looks like in RIPE Stat based on the recent data set from M labs. So the bandwidth capacity and the network activity.

So since the previous RIPE Meeting we were mostly working on comparison of the data that is already available in RIPE Stat and adding new data sets as the network activity. We also migrated the old interfaces of RIS, so RIS dashboard and some other tools and closed them down and moved all of that into RIPE Stat, and we are also making a much tighter integration with Hype Stat and using ?? with RIPE Atlas and using RIPE Stat visualisations in RIPE Atlas. I'll talk more about that in my next presentation when I have a bit more time.

So, this is something that be be useful, for example, when you want to make up new peering agreement with somebody and you want to make a research about their network. So, you can open several widgets about the same AS number in this comparison mode. It's there on your left?hand side. Or if there is some event that is causing disruption in a certain country, you can open mum the widgets that describe a country or a specific important network in that country here on your right?hand side.

We wrote a labs article about this so you can read much more about that on RIPE Labs.

If you want to compare two countries on a specific topic, for example, the history of the routing in certain countries, here is the example of Greece and Serbia, a bit of local favourtism in there. And so you can zoom in and you can find a lot of details in these graphs. You can choose which resources you want to focus on, only AS numbers, only IPv6, so there is a lot of wealth in these visualisations.

You can also compare the BGP updates and you can switch on or off the monitoring. So if you have the monitoring on, then the updates are going to automatically appear in your window and then if you find it too much you switch it off after a certain moment and so on.

Again there is a labs article about this.

So, we are going to use RIPE Stat as a visualisation engine for DNSMON in the future. We are migrating more of the features of RIS and the extra features that users requested again to RIPE Stat. And in BGPlay we want to highlight certain events in the far distant past, so if you want to tell us of some events that are important for you, we can he is pose that data in BGPlay.

For the rest, we are mostly working on improving the back end stability and consistency of data. You can see all those details on our road maps.

That was all. Maybe there is even sometime for questions? This is how you can contact us where you can find more information, where you can ask questions and if there are any discussions, there is the Working Group mailing list.

CHAIR: Thanks Vesna. That was really quick. I see two people lining up.

AUDIENCE SPEAKER: One thing you should have mentioned in your talk is the really excellent mobile interface for it. I just took a look at it.

VESNA MANOIJOVIC: We'd prefer if users praise us rather than ourselves praising us. So thank you.

AUDIENCE SPEAKER: Titiana, Google. The speaking about praises, I really happy with integration of the update in RIPE stats, like the integration is amazing. I really think ?? since I am working in M labs and since the integration, lots more people are looking in the data, it's way more effective, it's really fun to look at that and see correlation, so that's, I mean, my first comment.

Then I have a question. I was wondering if your team is looking into possibly adding things like network events to tag events on a timeline? Because we keep seeing spikes and things like that. Sometimes when it's related to my own prefix, I know of, like I know what is happen there, but it might not be the case.

VESNA MANOIJOVIC: That's an excellent idea and I would like to refer toey meal who is our events specialist and I am sure he would want us to work on that too. Is there something that you want me to add Tore can you comment?

EMILE ABEN: Well, I'd love that too.

AUDIENCE SPEAKER: Is that in your road map?

VESNA MANOIJOVIC: I will make sure that that appears in a more, let's say, clarified way on our road map. I will contact you later and see exactly how do you ?? how would you like to see that.

DANIEL KARRENBERG: I just wonder from at this time Jan an ace suggestion F I understand it right, it's to line up different widgets on a timeline so that you can see, you can characterise an event. We had the idea a couple of years back to actually make something where you could do that and add some comments to it in order to document something that happened. And I was wondering, so if we were offering like a way to make a story inside RIPE Stat, basically saying I saw this and here this widget saw this and from the M?Lab data we have that and so on and write a comment to it, who in the room would at least consider using something like this?

CHAIR: Thanks. Good. Thanks a lot Vesna.

EMILE ABEN: I am Emile Aben, I work at the RIPE NCC, I do stuff with data, and I want to talk about router geolocation. So, what do I mean with router geolocation?

If people talk about IP geolocation it's typically the edge that people are talking about. So that's the stuff that MaxMind and a couple of other commercial and non commercial parties are doing. When I say the router geolocation, I'm talking about figuring out the rest of it. So the things that form packets because the current methods that at least that I know of are not sufficient to do useful stuff with it.

So why would you want to do this in the first place? It's just if you have a sequence of IP addresses, of routers for instance in a traceroute, it's kind of nice to see where these packets on a forward path actually go. So you can detect hair pinning; does stuff go to places you don't expect it to go; does your path traverse a specific country, or a region or anything, any place where you're afraid to they look at your packets maybe or stuff like that? So in case of events and structuraley, so, where this comes from is we did a little bit of analysis on Hurricane Sandy, I think everybody here will remember. We had tonnes of interesting RIPE Atlas traceroutes from that, and first stab of looking at that data was just too naive geolocation with like our case MaxMind, but I don't wand to bash or praise any specific product. All the outer edge geolocation databases, they basically don't work. It's not that all of Hurricane Electric is in California, which I think MaxMind says.

So, what I ended up with was just doing reverse look ups for all the IP addresses and doing a couple of regular expressions on these host names and they already get far better information. It's still little bit messy but for the next event we thought can we do better? Is that's sort of the background of this idea.

So, the idea finds ways to geolocate the Internet infrastructure better. Part of the idea is ask the experts, so that is you, this room, people outside of this room, anybody who thinks they know better, to participate. And the other idea is to make the data that you collect from that publicly available. So this is not something to compete with any geolocation provider. It is actually the opposite. This is something that potentially geolocation providers could use to make their data also better.

And I listened a little bit to the earlier days, RFC 1925, rule number 11, there is existing router geolocation bits and pieces. There is on DNS and IS maps, threw the problem with these is that they are either unmaintained or have a very limited scope, for instance IX maps is very Canadian, Canada oriented. I have no problems with Canada but I would want this for the rest of the world too. There is a couple of visual traceroutes type of things like Portolan for instance also had, but they typically use MaxMind by, yeah, doesn't really work for this type of stuff. And there is the the draft that Google presented at the Database Working Group and that's kind of complimentary to this effort. Or this idea.

So a proposed method for this is to just combine all these data sources so use the existing edge geolocation, it's not perfect, or it's far from perfect actually, but it's somewhere to start from. Look at the host names from the reverse DNS and I recently found a reverse DNS again of all v4 address space by respected 7 and there is only one little bit over 1 billion reverse IP addresses in the current ?? in DNS currently. So that's actually a manageable data set. And from that, you can ?? there is a lot of IANA airport codes in there, all kinds of indicators of locality in there. But it's a bit fuzzy, so that needs help, so people can, or the idea is that people can tag specific things, specific strings, specific ?? or specific naming schemes even. You can also add into the mix round trip times to specific IP addresses from locations that you know, so you can do some triangulation. There is of course packets that don't go faster than the speed of light typically unless somebody invented quantum routing or stuff like that.

So you have some constraints on where something can be, and you can actually use that to make your geolocation a little better. And IXPs have, or kind of have a location, I mean this whole remote peering makes that a bit more fuzzy and there is like bigger and smaller IXP, but there is locality there, and just put that in a big funnel, have some fun algorithm to process that and you get out an answer. This is not about being right a hundred percent all of the time, but answers like oh, we think with 95% certainty that this thing is Athens, Greece, would be a whole lot better than what we currently have, I think.

And then the key is ?? well I can do it again ?? the key here is to crowd source parts of this, the parties in red I think you can crowd source, that's where people can actually put in input if we make a nice interface for that.

And so that was the talk and now the pictures. And I don't think this is very visible in the back of the room unless you have very good eyes, but if you don't have good eyes, then it's available in the presentation that's online. So, what you see here is a representation of how a packet ?? what we think was the path for a packet from Amsterdam to Torino in Italy, and as you can maybe able to read from here, there is an AMS in this string, so it's very likely we did a string matching and it looks like that thing is in Amsterdam actually, whereas geoloc says it's in Austria. It has a little bit of a weird round trip time, but that's something else. And then we're pretty sure, level 3 is pretty consistent in their naming scheme so that's New York, could he gen also says it's New York, it goes to Paris, Marseilles, Milan. Whereas if you just look at Geoloc, it's Austria, US, EU, US, Italy. So it goes all over the place. So just doing some simple string matching already gives you far far better results and actually tells you a story here.

Another one, there is other fun shapes you can make. Hungry to Bratislava, which is right here, so back it goes, Hungary, Budapest, then it goes to Bratislava. It's already there, Munich, France ?? Frankfurt, sorry. And then we come to Tillia and I think they derive their names from the Swedish names of cities, and I don't speak Swedish, so ?? so, but that's Frankfurt, Prague ?? Win is ?? we didn't have maps, but I think that is ?? any Swedish speakers? Win is Vienna maybe? Okay, so ?? you see this is already the crowdsourcing right, this is...

But we sort of want to do it a little bit more systemic. So, you can actually see if this was like very latency sensitive and high volume traffic, then there is like a case here where you can say wow, why don't we do something here in Bratislava directly?

So for the improved crowd source is you give info on networks, info on other networks potentially, just give us the information ?? also the Swedish language example, there is English is a predominant language but I have also seen Italian and Swedish type names where, nobody speaks all languages of the world. And what you get back from this potentially is better router geolocation for for everybody.

Cooperation. I know at least one organisation, CAIDA's running related project and I have been talking a little bit and thinking of data exchange. If you have a related project to this, please talk to Robert who is here in the audience, or me, or anybody who is involved in the RIPE Atlas project.

So, let's conclude. What I'd really like is a sense from the audience is: Are you out of your minds, this is never going to work? Or, this is really useful for me, this is geolocation data for geolocation providers. Maybe a show of hands. I want to know how you people think this is going to be ?? if we should develop this further to give better, and so the results would be better tools for Atlas, a data you can build your tools on and geolocation and data for geolocation providers. So that's it from me.

Questions? Comments? Maybe a show of hands? Like or not like? Like? No like? Okay.

CHAIR: That was easy. Questions?

AUDIENCE SPEAKER: Jared Mauch, NTT. So, do you have a list of the ones that you already know what they are? Because for us we have most of them documented on our website actually, you know, that as well as for the route communities what we tag for based on each route origin as well and so, is there a place where you are going to centrally reposit these and also there is a place where you are going to post the ones where you don't know so we can actually crowd source and provide feedback.

EMILE ABEN: That's the type of things that we ?? what is the best interface? I don't have the answer right now but it's definitely something we want to see how to make as easy as possible for people.

AUDIENCE SPEAKER: Mike Hughes. Jared actually said something I was going to say about the crowd sourcing.

The other thing is that are you concerned that people will try some interesting policy routine so they can spell things out and draw things on the map? Once you have done this we can have a competition at a RIPE meeting to do it.

EMILE ABEN: I thought a bit about a contest about who could make the most beautiful visual traceroute. I don't know.

AUDIENCE SPEAKER: You got the right sort of crowd in this room to do crazy stuff like that. In terms of serious research I have been doing some work with people on regional and small exchanges it would be really useful for for them to see what's happening.

WILFRIED WOEBER: Wilfried here and this is just based on the fact that I have an Atlas probe hanging off my DSL wire and I am involved in some organisations spending a couple of routers. I really love the idea and I would really like to see something which is as fancy as BGP play, like a traceroute play, but the question that I'm always running against whether this is in the context of the RIPE database where we started to do something with geoloc technology or tools or whatever, is that the people who do have the raw information, the authoritative credible information in quite a few cases are not the people who do have access no either reverse DNS or to update my address block which is in the higher key of my ISP and being in a company where they know where the box is but it's a different department actually deciding whether you are allowed to publish or not. So it's this sort of this administrative thing like who controls, or who enables the people in the know to actually put the data into the correct place to be accessible.

EMILE ABEN: For now the idea is to not sort of constrain that to have access to reverse ?? I mean you could for instance use triangulation to see where stuff is approximately and that may give you like a couple of hundred kilometre type of proximity, and the other thing is that anybody could, in an organisation, potentially could just for IP addresses put information in.

WILIFRIED WOEBER: But then it is not put into the authoritative place but it's put in some web interface that you would be providing at the RIPE NCC, and this would not be necessary. I don't get it sort of how you think that you can actually collect the data from the people and still be assigned with policies in a company or in an exchange point and that sort of thing.

EMILE ABEN: We are not necessarily. Could I provide information for your network, or try to, and... Daniel, you want to answer?

DANIEL KARRENBERG: One of the things that we were thinking about was, first of all, I think the way to start this is to be open, that anybody can contribute to this, but maybe what we should do in the UI is ask the people who put in information for the quality of the information, so to get categories like from here say I operate this network, and then maybe sort of give it a bit of a wait.

EMILE ABEN: Or maybe from the LIR portal we pretty much know who the LIR is.

DANIEL KARRENBERG: I think we are wasting time here. I think Wilfried's point. If that was Wilfried's point, I think we already have it on board. The other thing I wanted to say to Wilfried is that we are actually already working on a traceroute play thing. It's just not ready for prime time.

CHAIR: Actually as more and more people line up, can we take the discussion how we want to do the best probably to the mailing list. That's actually what the mailing list is for, then the mailing list isn't too board as it happens during the year. The people that have suggestions or comments if you could move it it the mailing list that would actually be cool.

AUDIENCE SPEAKER: Kurtis Jean from ECIX. I just want to suggest that the whole geolocation thing which is rather broken right now, we run a conference every year and a net block which moves around 20 towns a year and countries so, to take the geolocation thing to the more upper level just don't do specific on router, make it more easier to say a net block is this year in Hamburg and the next year it is somewhere else or something. So way more easier, it must be easier, it's unable to fix it in a few days or something.

EMILE ABEN: Yes, in the Database Working Group there was a presentation on ?? from there was a presentation by Zoltan, but he basically proposed some kind of data feed for that, that's specifically solving the edge case.

CHAIR: So, last one, Robert.

AUDIENCE SPEAKER: Robert, partner in crime. This presentation was really about an idea that we had and we just wanted to pitch it out to the community and get the feeling whether this is a good idea to actually do it or not. I think the message is clear we are going to do some prototyping on here and expect the whole lot of questions in the mailing list on labs around you.

CHAIR: Thanks a lot Emile Razvan, the next one.

RASVAN OPREA: Hello everyone, my name is Razvan Oprea. This presentation that I'm giving now has been given again in, at the beginning of this week at the European network and information security agency workshop. And for those of you lucky not so many that were present there, this will be a double dose of the same presentation.

A bit of a background. This project has been done as part of the final master thesis research project of University of Amsterdam in cooperation with NetLabs and SIDN which is the foundation for domain registration in the Netherlands.

A couple of months ago, actually three or four months ago, we were with NLnet Labs thinking about a good idea for research project. And the evaluation, the discovery and the liability of critical infrastructure was a topic that came on in our discussions very often. And we had an idea given by a presentation from pan 2012 last year, by two universities in Germany and federal office for information security, v? SI, I actually had the please user of meeting tomorrow as had he been err lane in the workshop this week and he was one of the authors of the study, they did analyse the German critical Internet infrastructure at an AS level, they started from IP prefixes and then they moved Monday discovering actually the ASs announces those prefixes and then building out maps. We looked at this problem from a different angle.

On one hand, we were focused in our research considering only how the AS structure looks like. It's easy that in the Netherlands the Government defines clearly which are the sectors and goods and services which are forming the critical infrastructure. There are 12 actually main sectors. And our question was all right, entities, organisations which are part of these sectors, how do they connect to the Internet? How do they relate to other organisations which provide Internet services? What kind of Internet services do they provide? And mainly this Internet representation, fingerprint, is it part of a critical infrastructure or not?

We didn't know much about how they actually connect to the Internet. We didn't know about the private back up links, we had no such ideas. We decided actually from the very beginning that we are going to use only public sources of information. So we didn't have to send in an NDA so we can actually present the results freely. We decided to work on an AS level and we had this initial idea that we are going to take a bottom up discovery approach. We get the AS numbers that are allocated to Dutch entities, we look at them one by one to see actually whom they are registered to and then, hey, we map them and we draw conclusions.

Unfortunately you are going to see we weren't that successful, so we had to employ a top down approach as well. Many thanks for initial feedback on the methodology goes to Emile Aben from the RIPE NCC as well.

The analysis and visualisation part is going to be represented later on, I'm going to show you a small recording as well, to see how it looks like, and encompasses both methods of discovery ASs. From the bottom up broach, it's pretty straightforward. We use the ASN allocation list published by the RIPE NCC and it was non trivial because we had actually to look at all those organisations and then the EU and find out which the EU ones actually represent the Netherlands.

Then we use the WHOIS database to select those organisations and then we used the K v? K, which is the Dutch chamber of commerce, ISDN for the mapping, and we actually found out from all those list of about 1,000 entities, which ones belong to the critical infrastructure.

Of course cannot be entirely sure that all the organisations are there. We have had to actually make virtual ASNs where some organisations were allocated just more than one AS number. And from 700 plus AS numbers, roughly half related to critical infrastructure secretary sectors, but 80% of or so of them were allocated to Internet services organisations. And this actually made everything so skewed that we could not draw any kind of conclusions, we needed more data. And then we looked at the top down approach and we looked at well known entities in each of the critical sectors and then we looked for records which rep data flow, bio directional data flow and this is the A, AAAA and MX records, and whatever else record would not represent necessarily a die owe directional data flow but when you look at e?mails, yes, basically all the e?mails that comes into the country comes through those words records. When you look at A, or AAAA, that means what portal websites, there is a dual flow of information.

Then we used RIPE Stat to find the prefix which is part of the originating AS. We called this a proxy AS.

Of course there is also limitations. Complete mapping of every sector is almost impossible without not necessarily privilege, but very specialised information. Think about the food industry, how many organisations actually function in the Netherlands in the food industry? Well, we found more than 1,000 farms for a single type of cattle breeding, it's just enormously amount of organisations. We also do not know about the back up links as I said, but we did try to find representatives samples from each sector and we got roughly 150 of them.

We combined this to list into a master AS list, and we want to see what kind of relationships do we see that links this organisations among them. And we looked at projects which aggregate this data for us, and UCLA, CAIDA and university of washing tonne they all do projects that aggregate data. We automatically chose the UCLA Internet research lab data for the single reason that it was the most recent, to have an idea the data that we used for this project, which was June this year year, the data was from November 2012.

How did we actually look at the mapping? Since many AS numbers have evolved, the proxy, the ASs that represent the MX, the A and the AAAA records, the initial graph that shows only the direct connections shows a lot of disconnected nodes. We added the proxy ASs but then since the graph is disconnected, our goal was to provide the minimum graph that mostly connects all the nodes. So, for each node we added its direct provider. And then we had enough data to actually see something on those graphs. For visualisation, we chose significant may dot JS an open source Java script visualisation library, and this allowed us to actually see the nodes, to zoom into the nodes, to move the graph around, basically the bigger nodes represent those that have no links coming into them and from them.

And these are some examples. And for instance, the energy sector. The energy sector you see on the left hand forecast numbers on the right side you see Dutch AS numbers, and some links. What information, what conclusions can you draw from this? Well none, absolutely none. Once we add the providers though, you can already see some statistical information, you can draw some conclusions, you see that actually the energy sector in the Netherlands is using, clearly, more foreign ASs than the Dutch ones. You also see exceptions like this one over there which is LE Anders, which is a major energy transport company which has its own AS, but never in their lives that announced any prefix in it. They are simply outsourcing their web mail infrastructure to outside parties; and in this case, foreign ones. The food sector is exactly the same situation.

Now, in terms of observations, we have seen that related companies in some industry are using the same providers, they outsource their services, the IT services to the same providers. We also see, for instance, as I said that some have their own AS, we only discovered al and err for this, and then they outsource their e?mail and web hosting. The biggest mail providers were message labs, and actually, Message Labs, I had to make just a slide for them because they are just simply amazing, they got the service of so many critical infrastructure sector companies in the Netherlands and it's simply semantic corporation and they have service provided in the US and also in the UK. (Symantec)

There are some conclusions to be drawn out of all this.

They have reliable connections to the Internet, most of these companies. But they rely a lot on foreign provider for the communication needs. Why? It's an exercise for the listener. But it could be that it's simply cheaper, or it's simply more convenient than running their own. And also, we do not know, for instance, if we take the case of nuclear power plant, how important is the e?mail and web for them for their safe operations? We have no idea. Probably very low. But on the other hand, when we're talking about energy providers and when they offer you a portal in which you go to my energy provider.nl, you enter there and you have all your billing information and you have all your history of how much energy you are consuming and when, then it starts to have some implications for you personally. And when you move this forward and you are thinking about perhaps medical insurance companies or hospitals, then it goes into areas which are not critical for the reliability of inter?connections but they are very important for your own privacy.

And most of the companies that offer services to critical infrastructure organisations in the Netherlands are hosted within the European Union but this can change at any time. The contract that you have signed with your provider, when they outsourced their services to, I don't know, an unknown country, they never notified you, you have no idea what is going on in that data.

And in this respect, we do not see that critical infrastructure organisations regard the network infrastructure as being of critical importance. One more point I'd like to make, and that is you have seen that we tried to make this discovery starting from the bottom up to discover making a mapping of Internet connections of AS connections and we didn't go paragraph with this. It's not that once you have made it, this kind of map is irrelevant within five minutes. It's because it still has statistical relevance. But, you need privileged information to get every single prefix that they are using internally, and then the top down approach is more useful but you need a lot of information, and such a project could be extended in several ways. You could say, for instance, all right with the help of say chamber of commerce we bet get the full list of critical infrastructure organisations in your country and see how they use Internet services, do they outsource it or what?

I would like to thank very much to my colleague from University of Amsterdam, Fahime Alizade. She worked with me jointly on this project with me. Unfortunately, she couldn't come to Athens. But her work on this is in equal measure as mine. Thank you to the RIPE NCC, we use their services a lot, and their advice. Emile Aben in particular and of course to NLnet Labs and their support in running this joint project and I'd be very happy to take any questions or comments.

CHAIR: Thanks, Razvan.

(Applause)

Comments? Questions?

AUDIENCE SPEAKER: Andrea /SRAS jest key, internet society. One question. So to what extent did you map the kind of external facing interface, right, versus corporate infrastructure, corporate IT infrastructure? Because I assume that they may have corporate e?mail system, they may have corporate databases, you know, different IT systems that you will not discover by that mapping.

RASVAN OPREA: Absolutely. The only interface that we looked towards was the A, AAAA and MX records, there is very little cases if any if you could avoid your e?mail coming through your MX records, even if you have a corporate e?mail system, unless you are using different organisation names, different domain names, sub domains, you know, and we tried to be, because we looked at ?? I understand that this data is not complete, that's clear. But whatever set of data we have been using, be we rely on them because we check them one by one. And databases in other, as I said we have no idea what kind of prefixes they use internally or what kind of information from the top down approach. From the bottom up in which we looked at ASs, yes, that would be a different story, but this could be extended further, Andrei, it could be extended if somebody would have privileged information access and we simply did not want that for this specific project.

CHAIR: Well, in that case, thanks a lot, Razvan.

(Applause)
So last but not least, Vesna who will give us an update of RIPE Atlas.

VESNA MANOIJOVIC: Hi again, this is going to be show and tell session. More probes...

I am Vesna from RIPE NCC, I will talk about RIPE Atlas. This is our view of the world. This is where the RIPE Atlas probes deployed currently, and in Europe you can see it's very concentrated group of probes. But we wanted to show you the whole world.

So, there are more than 4,000 probes active right now. So that's on the previous RIPE Meeting there was about 3,000. So that's a great growth. We have almost 9,000 registered users, they come and go, and there is few that are really very active and about 3 and a half thousand are from the members of the RIPE NCC, from the LIRs. They have access to customised measurements, so if you are running an Atlas probe you can do the customised measurements that are listed here. I will cover them again in detail.

So how can you take part? Anybody can apply for one of these RIPE Atlas probes, we have distributed about 200 at this meeting and there are still a few available, so you can come over and grab them after when the session is finished, or you can apply on our website and we are going to ship it. We are having more and more ambassadors, I will talk about that a bit later, so you can get these probes from other people.

Why would you want one? Well you can use the RIPE Atlas network to do the measurements that will show you how is your network visible from the outside? How do other people see your network? And you can do that by performing the measurements.

On the other hand, RIPE NCC is also performing the measurements using all the probes and the data is publicly available to everybody. We create maps, you saw one of them, but we have many more, and we have, also, the other ways in which you can access the data.

So, what are the measurement devices? The one on the left is the old version of the probe. The version 1 and 2 they looked more or less the same. The current version that we are distributing is this, and if you have an old one, please don't switch it off, please don't give it back to us, just keep it because they do the same. And if you want another one of the new one, we ask you to put it in a different network because they do the same, there is no point in hosting two next to each other. And then we have something else. This is big box is the Atlas Anchor. And then it's a box with some numbers behind.

So, how many probes are in Greece? Well I already covered that, there were 53, I am sure there are more already, and there will be many more after this meeting. You can see it in RIPE Stat. You can also see it in the Atlas web better face. And so what else is new?

Well, today we are launching the RIPE Atlas anchors project as a production service. So we started more than a year ago with this idea that we want to have larger boxes that will serve as a target as well as a probe and be able to do more measurements. So, the benefit of having such larger box is to be able to show the regional view, and also to have a lot of baseline measurements in the region so that in the future you can look back and say okay, how did Internet historically develop in this region? In the pilot we had 15 anchors, they are all up and running and we have currently the full mesh of measurements between them with their own visualisation, we are actually using the seismograph that I will cover later and we also are now including more and more probes that targeting specific anchor. So each anchor will have about 100, two hundred, three hundred probes performing these regional measurements.

So, if you want one ?? so if you missed the pilot, you can apply now for this different server in the pilot, we were actually testing the possibility to have multiple services on the same box and in the meantime we gave up on that idea and we are now continuing with this one service which is just the RIPE Atlas anchor on a smaller box and a cheaper box and the one that is using less electricity. This is going to replace some of the functionality of TTM which we are planning to commission quite soon.

If you want to know more about anchors you can find more information on our website. There is instructions how to apply, you can approach us later and we can chat about it. We also received several applications, so, yeah, be quick, but don't be too quick, because it will take a while until we actually roll this route so be quick and then be patient.

So, what else is new? Well we have new visualisations basically. So here are the details and I'll move quickly to the pictures.

The seismograph shows you multiple ping measurements on the same graph. So, this one actually shows some random probes, so if you do the measurement for multiple probes then it will show you this visualisation, and it also works for the Atlas Anchors. And the other new thing is our replacement for the RRDs, and now we have one zoomable ping route. So instead of having the one graph for hourly view and then daily view and monthly and yearly, you can now zoom in to those time frames within the same graph, and there are more features available in this graph. You can also em bed it somewhere else because it's based in the RIPE Stat visualisation framework, and of course we already published all this in the RIPE Labs so you can read it all there.

And at the previous RIPE Meeting, we announced the quick look measurements, so for the impatient people again, so if you only want to perform one measurement and see results immediately and you don't want to be bothered with all the options that exist, you can go to the LIR portal and only insert the target and then choose the type of the measurement and immediately you get results as they are rolling in, and it shows the list of probes that are taking part, where are they located? You see them on the map and later you can also download all the results and do your own analysis. So for the previous RIPE Meeting we had this for ping measurements and now we have them for DNS and traceroute. And of course they do v6 and v4.

And then the list of new features is kind of extensive. People ask can we do these measurements more frequently. We are enabled that. We have added more targets so the ring nodes, NL ring project, has servers deployed all around the world and now they are available adds targets for the Atlas users, if you are sponsoring probes or if you are using multiple probes in your own network or distributing them to other people, now he can see that on the map, there are more visualisations and so on.

And people tell us how they use Atlas and what did they achieve with that. So, for example, when the Serbian Internet Exchanges in Belgrade ?? you can now hear where I am coming from ?? have installed the local instance of L?root, they said can you see that in Atlas? And actually we could, because the round trip times went from about 50 milliseconds to 3. On this graph it looks like 5 but you can actually see when you go into details that the round trip time went to 3 milliseconds. So that was a great thing for them to show back to their management and say see, this was actually a good thing to do, we told you it's going to improve our connectivity and it did.

Then there are other users present here who did experts with Atlas and published results on RIPE Labs so you can read more about how is FR, Anycast servers, how are they visible from all around the world and which one is the most popular and so on. And then there are some events, outages in a country and so on, Emile did analysis and you can also read about that on RIPE Labs.

So, what I wanted to also ask you is if you have similar success stories, please tell us so then we can brag about it next time when we do a presentation and mention you as one of our users, and you can also write about it yourself on RIPE Labs.

So, we also have a vibrant community, people who want to promote RIPE Atlas either by giving presentations or by distributing probes. We call them ambassadors, and there is more than 20 of them, there were before the RIPE Meeting and now after this meeting there will be many, many more because we met a lot of people during this week who want to help us out. And so, if you are still interested, approach us afterwards.

Then there is a lot of code being published at GIT hub in the community repository and if you have photos, don't just tweet them so then we have to scrape them from Twitter and put them online. You can upload them yourself. We are a web interface for that. And if you are curious about our who you are users are we publish regular lists about top users and new arrivals, so you can check that out.

And again if you want to be a sponsor or annum Bass Dear.

So, this is how we promote the organisations that support us. We publish the logo on our community page so these are the logos of the anchor hosts, so, on the operational level you can see the list and a map and so on, but on the PR level you can also see their logos there.

The question is to the audience, can you see where theey nothing was, because we distributed a lot of probes and they all appeared here so this blue and yellow map ?? flag is ?? soey nothing was in Ukraine and we lot a lot of new a rifles and new users in Ukraine and it's nice to see that visually by looking at these flags.

These are the sponsors. We have two more since the previous RIPE Meeting, so we are very grateful for your support. And thank you very much again.

This is what's on our road map currently. So, again, using Atlas and RIPE Stat to visualise and to do measurements for DNSMON. A lot of people want us to do alerts, so we started working on that so expect some news about that soon.

People would like to see specific probes and specific measurements in their web interface, so instead of book marking somewhere in your browser we are going to provide a functionality of my favourite probe. And somebody asked for the traceroute BGPlay. Well here it is. It's already on the road map. We had the same idea. So...

We are working on it.

And we are going to cooperate with RIRs and other organisations in distributing more probes.

So, the questions that are not answered yet, we still have this audience the requested features on the road map and now if there is time we can have a discussion about it. People keep asking for these other things, and some other people say no, we don't like it and yes we do like it and it's still not clear what does the community really want us to do. So, HTTP measurements, technically they are possible; however, there are other implications and what should we be careful about, how can we limit the damage that can be done? Certain cases and so on.

Alerts: How do you want us to implement it? On which level of complexity? We'd like to hear more about that.

IPv6: We have a lot of research done using IPv6 measurements but what would the operators like to see?

And currently, we have about a quarter of the measurements done as private measurements, but most of the people actually publish their measurement information and make public measurements and we would like to move more in that direction, so how do you feel about it?

And finally the BCP 38, the controversial topic that keeps coming up so let's talk about that.

These are the contact details and going back to the questions and thank you very much.

(Applause)

CHAIR: Thanks Vesna.

VESNA MANOIJOVIC: Is there time for discussion and questions.

CHAIR: Sure. Let me ask a question first. Can you put the questions for the people who haven't been in the room on the mailing list as well so that we have them there too for completeness.

VESNA MANOIJOVIC: I will do that.

CHAIR: Have now on, we basically are already overrun so now we have all the time in the world till the dinner. Questions? Comments?

AUDIENCE SPEAKER: Stefan lots mere from AFNIC. Regarding the big questions for the future of Atlas, there is also another one which was discussed in the mailing list without any clear result right now, that today the terms of views of Atlas allow for unlimited commercial use, you can sell results gathered from a class, system /SPAOEPL think it may be a good idea to make this knowledge procedure, with some restriction of what you can do and what you cannot. There have been discussions on the MAT mailing list so I advise people to go back and read it and if they have something to say about this issue, to talk about it or on the mailing list.

VESNA MANOIJOVIC: Thank you for the reminder indeed I forgot to put that on the slide but I will add it in the list of questions circulated on the mailing list.

AUDIENCE SPEAKER: Just an addition, so the terms and conditions, because we didn't have a clear terms and conditions and contract, we had something which was very basic. We are adding that we will send all proposal or just some basic ideas for the start of the discussion to the list and we expect to get feedback from the community and whatever the community wants we will send that back to NCC for legal review and all of that, but this is one of the things that should be answered. So we already have worked on a draft to be proposed to the community. We are waiting to finalise that and will send that shortly to the list. Thank you.

CHAIR: Thanks. Robert?

ROBERT KISTELEKI: One thing was missing from your slides and that's a thanks for Stefan, he actually did an Atlas tutorial on the Monday morning with a full room of people, 50 people or so and they did hands?on programming using the API getting results, doing measurements. We had nothing to do with it. Stefan wanted to do it and did it.

(Applause)

CHAIR: Good. Then.

VESNA MANOIJOVIC: I have one more point. So, this anchor that we brought here to show off, it's very pretty, but it's actually also working. So it's example of the hardware that we will be using for the RIPE Atlas anchors. People can order them but we also have other plans from the RIPE NCC side to implement these, to install these anchors at all of our K?root locations and the route collectors RIS, and since we have a K?root location in Athens, and we are here and we would also like to thank the hosts of this RIPE Meeting, then I would like to present ceremonially this anchor to Andreas. So this was your surprise. And this is a photo opportunity, so please I'd like to see some flashes.

SPEAKER: I admitted I didn't see this coming. Thank you for this great gift. We are about to get one, so I will make sure that we'll use it in our data centre.

VESNA MANOIJOVIC: This is how fast our procedures are. You just think about it and then you receive the anchor.

SPEAKER: I would like to take the opportunity to thank you guys for organising another great meeting, you had great guests, our job as local host was actually very, very easy. We are very, very honoured to have all you guys here that affect the Internet of tomorrow. I hope I will see you at the dinner tonight and in the next meetings. Thank you very, very much for your gift.

CHAIR: Just on behalf of RIPE NCC and race, because I have heard from my colleagues, meeting organisation, they actually said you have been a fantastic host, GRNET and yourself to thank you very much and we hope to see that anchor up and running ASAP. Thank you.



CHAIR: So thanks to the hosts. Thanks to Vesna. Last point on the agenda is AOB. I was already pre?warned, here we go.

AUDIENCE SPEAKER: Hello I'm Michael Abrahamson. I pitched this in Stockholm at the IETF four years ago. Nobody took it up, as far as I know and did this, so I'm going to pitch it here again. This is a lot of information stuck in my TCP stack on my computer that I can't get to. It knows every packet loss, it knows round trip times of all connections and all this overtime. If I could collect this and statistically present this in, I don't know, in some way this, would be an excellent opportunity to know what's going on in the network and what my user experience is. Instead of sending a lot of test traffic that people are doing, this would actually be something you could have on all hosts that would send in information or present it to the user or whatever, not intrusive testing, it's actually getting information about the traffic the user is actually running. If the ISP is prioritising traffic to the test server, that is not helping them.

CHAIR: Are you applying for a speaking slot?

AUDIENCE SPEAKER: No.

CHAIR: This is pretty much it sounding like it.

AUDIENCE SPEAKER: So ?? anyhow, someone ?? I'm just ?? subscribe to the list, I am happy to discuss it there. I might write down a little bit more there, but please, just pitching an idea.

CHAIR: Cool. Thanks. Randy.

AUDIENCE SPEAKER: Randy Bush, IIJ. To go back to your question back in the nineties, Vern Paxon did a thing called vital signs, which was an app you ran on your computer and indeed monitored the stack and monitored the passive monitoring on your TCP connections, it was designed for the end user so it would say, you have a poor connection or the server over there is half asleep, etc., etc.

So, we have been there. He actually ?? some company bought it, made a product, but it never caught on. But that's stuff has been out there.

CHAIR: Other comments?

AUDIENCE SPEAKER: Hans Petter Halen. I think we are running such a commercial project, edge site from sit risks which does most of what you are saying. So there are things out there that do this.

AUDIENCE SPEAKER: Titiana, Google. I don't know if you are aware of the RFC 1498 that, I don't know if you are aware of that that allows to collect advance means on euro host. Right now they are working on a Linux patch to actually have that on any Linux machine. We can talk more about this later.

CHAIR: Good. So, with that I think we are coming to an and. I am sorry for the people I cut off today. That was actually more than usual. Thanks for the discussion. Sorry for cutting off and please if you still have comments, questions, take your points and bring them to the mailing list so we can all get something out of it. Good. Thanks a lot.

(Applause.)