These are unedited transcripts and may contain errors.

MAT Working Group session at 4 p.m. on 5 May, 2011:

CHAIR: I would like to invite people to take seats. This is the measurement analysis and tools Working Group or MAT, depending on pronunciation. We have got a rather full agenda today, reports on measurement projects, Robert is going to give us an update on Atlas and Darren on the other Atlas, so we have two Atlases on the agenda today for you. It's a special day. Emile on work she has been doing on measuring networks from the edge and job has some information about some work that NL NOG has been doing and at the end more updates from RIPE, from Emile and Christian on some of the work they have been doing. I think we have one more update on the next slide. So obviously, we have a web page and mailing list for the group. We are using the MAT Working Group mailing list as ?? you may have seen the past couple of days as a forum now for soliciting suggestions for awful the different NCC based activities so we are very eager to get suggestion on the list for things like RIPE stat and Atlas and all measurement activities that the NCC supports so, please, if you are interested subscribe to the list. I don't think you need to subscribe in order to send suggestions, so submit any comments on that, on those programmes. That is the list for it. .



CHRISTIAN TEUSCHEL: As you might know RIPE has not just the RIPE meeting here but also takes care of regional RIPE meeting, so there is a regional RIPE meeting in Moscow, basically the E NOG meeting and we actually, this time, have a RIPE day, so we have different sessions; we have, if I remember correctly, in IPv6, one or two other Working Groups and an MAT session in Moscow on that particular day. The session is a little bit shorter and smaller than usual so it's something like 45 minutes and we will have, so far, we have basically topics about RIPE Atlas, not a big surprise, but we also will have, hopefully, Russian or ENOG content so from Eastern Europe or from Russia. Which means we also looking still for speakers. So if you know someone who either, doesn't matter, speaks English or Russian but has some content about measurement and analysis from that particular region so it fits for that audience, send us an e?mail or find me so we can fill that slot, too. Thanks.

That's Robert.

ROBERT KISTELEKI: Thank you very much. My name is Robert, I work for the RIPE NCC and the team is building RIPE Atlas for you and this is just an update on where we are and where we have been and where we want to be, so I am not going to give a whole overall of what RIPE Atlas is.

So the one sentence story about RIPE Atlas that is the next generation measurement. We are building so you can do your own measurement and our community can benefit from the data coming out of it. I am going to talk about what we have been doing, what we are doing and what we are going to do and after that I am going to show you some interesting results that are coming out from both in terms of more or less maps and videos. Everyone likes videos.

So before going there, this is where we are. This graph is actually on?line, you can see it on the Atlas website, it's refreshed every hour. What you can see here is that we had an unusual goal of 300 probes up and running and we made that goal in January, so that was roughly between mid?November until November, two?and?a?half months. That is pretty good. The green line shows us the number of probes that are up and rung so it's not that they have been plugged at in at once, these are actually running probes and apart from the occasional hiccups it's studly growing, in the last couple of weeks it flattened out somehow but that is because we couldn't give out new probes to new people. Also you can see that we have distributed now a bit more than 500 probes and the total number of applicants is around 1,500 or so. We have a backlog of roughly 900 probes which have been applied for but we are now fulfilling the need so you can see clearly there the effects of the RIPE meeting, we have substantial increase in applications and probes as well.

So what we have been working, this is the pass. Obviously we have been working on more probes for you. Originally, we both 500 because that was the initial set?up, we said, we are going to try with that, it seems to be successful so we brought in another thousand and they are being distributed by our customers services department so if you are on the waiting list and have applied for a probe and you are in obscure location you have a good chance you will be contacted in the next couple of weeks. Less obscure you will still be contacted but later on.

Then we have been working on features that you asked for through private or public channels, one of them is that many of you actually asked for some kind of a DNS entry for the probe, some people want to use this to track their own home IP address because the provider changes every now and then so if you go to your page and set appropriate option, then your probe laugh permanent DNS entry that you can always ping and look up to you and give you the current location. Another feature is public probes so if you have a probe and you don't mind sharing the data that is coming out of it, then you can check another tick mark and your probe will appear in the list that is called public probes and every Atlas user will see what your probe sees correctly. We are trying to be careful about the privacy implications of that so we don't show every little piece of data but the basics are there, so you have to make up your mind. The benefit here people who don't have probes can see what they would get out of the system if they had one.

Some people were interested how does it compare, this was out for couple of ?? down for a couple of minutes so we did that. New ideas and changes. This is not really something you have asked for but the RIPE NCC went through a UI designed change that actually affected awful the sites that we do so RIPE Atlas and stat, dub dub dub virtually everything, the RIPE Labs site now has the same look and feel.

And we also did some internal architecture or changes for those of you who remember, you don't need to understand all the details, this was a slide that I flashed at the last RIPE meeting where I gave the technical overview, what you can see here is what we do is hierarchical sytem, that's something we really, really have to do. So what we changed was we just introduced some kind of middle wear there to send messages back and forth because we realised if we used the same channels between the central components, both as control channel and data channel, then it's going to be overloaded soon so we offloaded that into message queuing system. This is internal, no one really notices it. Apart from us.

OK. What we are doing now, we are giving more probes for you so that is also a current activity. But also, we have a new firmware out there which is in testing phase so we have like handful of testers, dozen or so, who are trying this out at the moment and it seems to work and it will enable you to have static configuration on your probe. If you have seen the probes in, as they are in real life, you will see they are very, very tiny, there is not much you can configure on that one so we made it a requirement you have the ACP if you want to use them. We are relaxing that because some people said hey, we want to run this in a Co. low environment and we don't have that there. What we do there is, through the UI you can configure probe that it should use this static configuration the next time it boots up and it just seems to work so that is OK.

As it seems like we have solved the problem of IPv6 installations only information, you can give DNS information to your probe and it will work.

That is actually confirmed by at least one happy Atlas user, that it does.

And more importantly, we started working on the user defined measurements and this is something we promised before. This is will enable you, if you have your own probe and if you are completing your own credits, to define your own measurement using the full network so this is a biggy.

Future steps:

You guessed it, more probes for you. It seems that since our waiting list that prioritised waiting list is 900 long at this moment we expect it will grow beyond a thousand very soon so we have made steps to get the next batch of probes in, which means from October we will be able to distribute 1,000 probes more so we are steadily increasing the size of the network.

Obviously, our biggest chunk of work is user defined measurements. It will allow you to specify your own measurement in this network. Originally, it will let you do RTT measurements and very likely going to be combined with trace route kind of measurements because that makes sense to go hand in hand, as a next step we will very likely do DNS related measurements, Anycast checks thank kind of stuff and what else? You tell us, please. So this is a request for comments here.

Our strategy there is that we are going to enable more and more features as time goes by, so it's very likely that during the summer we will enable the user defined measurements as a feature on website you but your option will be very limited. We will set how it works, how many probes you will use, a couple of things (freeze) and over time we are going to relax those rules so more probes and options and variety of measurements and so on.

OK. We are also going to be working on more visualisations and in the second half of this talk I am going to show you some of the preliminary ones. We are also planning to work together with some external researches because we see that there is a tremendous demand for making good use of this data in a number of ways. And I just try to mention a couple of them, correlation detection is one of them so we really, really want to actually use the power of a big network to figure out that something is happening on the Internet. So we want to be a bit more proactive and not reactive. Researches have very good ideas on how to do this. So, we supply them data and they supply some results back and obviously, with the appropriate privacy concerns addressed.

High on the agenda, you are going to hear talk about RIPE stat, if you haven't heard anything about it before, which I don't think that could happen, but still, we are going to integrate Atlas with RIPE stat so if you, for example, look at a report in RIPE stat about specific puff should be able to say, oh, start measuring it because I am interested in it and then Atlas will do the right thing or other way around. You see weird behaviour coming out from RIPE Atlas website, what is this? And go to RIPE stat and you get more details.

OK. Now, second part: More interesting maps and I am going to he try to do this live and see if it works. Luckly, I pre loaded this so it works. What you see here is a visualization of all the probes that have been active in the last hour, which means that if there is a probe that went down more than hour ago or like yesterday, then it's not on this map. Geolocated so we exclude the ones that are not known in terms of Joe location information, and each one of them are colour coded by the RTT value towards, as you can see it on the top, in this case, labs.ripe.net. Labs is a single server, single physical location somewhere in Amsterdam, so the general expectation is that, well, obviously if you are closer to Amsterdam your RTT is smaller and further, your RTT should be larger. And it seems that this map actually reflects that. So, I hope that, yes, the colours are more or less OK. For example, in Australia, well that is not really the case.

Now if you look at the different example if we go and check out Anycasted, so this is the actual K?root server you can see for Florida becomes green, we have global node. And Japan in Tokyo. There is no probe there. But there is a local node in Brisbane so it kind of makes sense that this is really what I want to see but there are also exceptions; for example, Spain, for some reason generally seems to be a bit behind in terms of RTTs. I said in terms of RTTs.

Now, so I don't want to go into all of the details but just show you one very interesting example and that is M. So M is also Anycasted DNS route server so the expectation would be that if you are closer to an instance that is local to you your RTT towards it should be better. That is not the case. I can tell you if the go to the site and check this out for yourself you will see that it pretty much depends on who your provider is, in Europe M has one location in Paris, so whoever has a good enough peering so they end up in the Paris instance, will have roughly 30 milliseconds towards M everyone else will go to Japan. There is an instance somewhere in San Francisco.

So let's look at some videos. Everyone loves videos. OK. First video, what you will see here is the growth of the network illustrated by a single measurement and it is IPv4 RTT measurements towards K?root so here we should be able to see that the local and the global instances actually play a part. Hopefully, yes, this is the time of it so every frame will be one day and it starts in October, so just before the RIPE meeting. So the first nodes are there, some green and now the RIPE meeting comes. Bang. All the probes suddenly appear in Europe, OK? Please ignore the flickering, that just happens every now and then. I am going to pause that this. For example, here you can see that there is a node at think this probe popping up in Tokyo and it immediately becomes green so the RTT is less than 20 milliseconds or so. That is because global node there. Moving on. More and more probes come up, every now and then they go down, for example the one in Kenya was left out in the window and it just overheated. That happens.

This is an interest moment. We have a local node in Tanzania. If the left side of the room can keep an eye on that one and the right side can do something else instead. For example, these guys are not in Antarctica, we don't know where they are so just at the bottom. Now Tanzania became immediately yellow, it's closer to 100 milliseconds, maybe even more. Our DNS guys tills the reason nor is Tanzania sometimes has power outages and it's more often than here in Europe and their preference is to give power to the hospital instead of their servers, which is understandable, but the by?product of that is that the probe that is more or less active there sometimes just ends up somewhere completely different. This video is available to you so you can check it out in all its details.

I would like to show you a different visualization, we are focusing on a specific network event. Our goal with the network was that we want to have enough probes that we can recognise that oops, something is going on, it's not your problem, it's everyone's problem because it's global to the network. We asked the team, the interim team to look for some events like that and they have found one on the 6th of January. What you see here is a bit different; it's only focusing on Europe and the colouring is a bit different. You have to keep that in mind. The colouring is such that awful the ?? all of the nodes are put wherever they are geo?located, that's fine, and they are greyish if their current RTT is very close to the median of the day. So they are like, yeah, it's normal operations. They become green if it's significantly better than it was during the day as a median in the day and red if it's significantly worse. So what do we see here? The movie is one day long and the event is 3 a.m., so I will just receipt you watch it and I will go back to the interesting part. 1:00, 1:30, 2:00, 2:30, bang and now we are back to normal. There is not much interesting after this. I am going to pause that at the right moment. No. I didn't succeed. So, what we see here, and just admire this for a second, we what we see here is that most of Europe, this is really significant because it's not just one or two having a good time or bad time, most of Europe have significantly worse RTT values towards K?root than they did throughout the day, in general. There is a notable exception of England and France as well, but that is because we don't have enough probes there. But why is this? We actually tried to pinpoint the exact timing and it turns out that there was a 30 minute window where, for reasons ?? reasons don't really matter but for some reason, all of the queries towards K?root inside the European region ended up instead of in the mainland, instead of the Netherlands nodes, they all ended up in links so they all went to the UK. If you think about it, it makes sense that their RTT suddenly jumped. We were able to pinpoint this, we have the DSC graphs and everything as story, they just ignored the local nodes at AMS?IX.

So, this is only things that I wanted to show you. You can go into the details there all on YouTube. With that, I think I am finished. Any questions?

CHAIR: Are there questions for Robert?

AUDIENCE SPEAKER: I am the one who tried the IPv6 only, just a comment on that; the controller actually sees it on?line but all the tests will not work because we don't have NDP over IPv6 so the probe thinks it's 1970 or 1990 and, yeah, the test results will not be accepted..

ROBERT KISTELEKI: Yes, we are working on that so the probe tries to pick up the current time, it's so small it doesn't have a battery that it knows what the time is if it goes off?line, we want to get a time indication from the controller so that will be solved soon.

AUDIENCE SPEAKER: Martin. With regard to the DNS measurements you are willing to add, have you got an idea on the process of getting input, validating it and communicating afterwards to say, hey, these measurements will be implemented and not these because they consume too much memory, CPU or whatever and what are the real criteria, I suppose, the CPU, but maybe there are others, and what will be the process with the community in terms of discussion, validation and communication afterwards?

ROBERT KISTELEKI: OK. Obviously, since the probes are somewhat resource limited and shared between the whole network, we cannot do just everything so if someone says measure this it's going to take all your CPU for hours that is not nice. We will have to find the optimum between what you want to measure and what is possible on the network and I am positive there is an optimum in there. We would really want to hear what you want to do and we can go into discussion of what is possible and feasible.

CHAIR: I think that could be a good topic for measurements BoF, one good reason to have Robert go first you have the rest of the session to come up with more good ideas to discuss during measurements BoF. Let's thank Robert, thank you.

(Applause)

CHAIR: So next up is of course the other Atlas project, our second of the day, Darren Anstee from ARBOR, for those of you who are anti?abuse you saw some of the results from Atlas and there will be a little bit more about those results.

DARREN ANSTEE: Thanks. From ARBOR Networks, I am solutions architect in the ?? this microphone is it? ?? and for the next ten, 15 minutes I am here to talk about ARBOR's Atlas initiative and how it works under the hood. I have presented at the Anti?Abuse Working Group, some of you saw that, and really, first thing I need to say is that the ARBOR Atlas initiative and RIPE Atlas project are very different things. They are both designed to monitor the Internet, to look at what is going on throughout but work if in very different ways and different data sets. From our perspective, the ARBOR Atlas initiative is all about modelling Internet traffic patterns in terms of how much traffic goes from A to B, what kind of traffic is it and it's also about modelling Internet threat evolution in terms of DDoS attack, how many, what are they, what is being targeted, all of those kind of things.

One thing I would like to start with, is introduce ARBOR Networks because if you know what we do it makes a lot more sense as to why we actually spend so much time and effort looking at this stuff. So ARBOR is a provider threat of network detection and reporting solutions and our solution sit out there in service provider networks, flow BGP and SNP, from the routers you have deployed and using that data we build models of network traffic patterns and we provide DDoS detection functions and traffic monitoring and reporting data that you can use for things like peering traffic engineering that kind of thing. So it's important for us as business to understand what is happening out there and understand what is going on and we are lucky we do get a great deal of feedback from our customers in terms of the kind of threats that they are seeing and also in terms of the services that they are rolling out and how they want to monitor, report on and secure those services. We have a team within Arbor, the A cert team whose primary role it is to look at how the Internet is changing, and they do that by collating feedback we get from our customers and by managing the data analysis and collection tools that we have within the Atlas initiative. So what is the at lash initiative?

Well, for us it's really our way of modelling Internet traffic patterns macroscopically and also looking at how Internet threats are evolving, and we use the data that comes out of Atlas in a number of different ways: We use it within our products to provide contextual information to our users on top ASN, protocols, ports, countries, for traffic volumes, and we use it within the Atlas.arpa.net site where you can see a snapshot of all the information we have collated over 24 hours, and also how we look at real world events and how they alter Internet traffic patterns so you may have actually seen this graph and some graphs like it recently being used in the media in relation to the events that occurred in Libya and Egypt, some of those graphs were used with attributions and some weren't, but a lot of that stuff came from us. We use the data in presentations such as the the one I gave to the anti?abuse group and also other previous presentations that have been given to NANOG and MENOG and we share the data with other members of the security community and they obviously share data with us. Because it really is all about getting a better understanding of what is happening on the Internet.

So how does it work, what data do we collect and how do we analyse it? Well obviously we get data from third parties but 3 or 4 primary data sources that we use within the Atlas initiative. The first and probably one of the most important is the Internet trends data feed and that relies on Arbor customers enabling a feature in their products or their deployments of Arbor products that allows those device toss share, anonymised statistics with us on hourly basis. When I looked yesterday, there were 129 ISPs from around the world sharing data with us, we were monitoring about 50 terabits of inter?domain traffic so we do get a good view of what is going on out this and I am going to drill counsel into each of these in subsequent slides.

Secondly, we have the Atlas sensor network which is a network of honey pots that we have do employed around the world, they run our software, most of what they do is automated, they are there to see what ports they get scanned on and exploits people try and feed that data back into our centralised servers for correlation and aggregation. We also have about 30 ISPs who provide us with a full footing feed and we record that and the reason we record it so we can reconstruct the rooting tables from different points in the Internet for different points in time and we can see how the traffic volumes that we are monitoring map on to the underlying changes in routing reachability and how the network ?? how the Internet seems to be connected together. Last but not least, we do do quite a lot of mal ware analysis and I will talk to that in some later slides.

So coming back to the Internet trends side of things. This is the data I talked to in the anti?abuse group a few minutes ago. This relies on deployments of Arbor's P to SP product. Our customers can Saturday check box which allows their deployments on an hourly basis to export an XML file to us, when they enable this they get access to some more contextual data within their user interface, a bit of of pay back and we get the files sent up to us which we can do lots of things with. All of the data within the file is derived from our correlation of flow BGP, that is how the product works, it SIS there, gathering flow BGP, it builds up models of the traffic patterns for interface, and we get an extract of that information in the XML file and I will tubing that in the next slide. We also get an extract of the threat information that is been detected within that customer network as well, and that is for awful the detection mechanisms that the product has. I only talked to misuse in the anti?abuse group to try and make my life easier but there are three detection mechanisms that we include information for: Miss use, which is your traditional flood type DDoS attacks, changes from the norm in terms of total traffic patterns, protocol traffic patterns and also source country traffic patterns and there is something called fingerprint which is there to track traffic, all of that information or an extract from it gets incorporated into the XML file and sent to us hourly.

To give you a bit more detail on that, we actually get whole network data in the XML file which is information about the traffic at the edge of the networks that we are monitoring so how much traffic comes into that network, how much traffic goes out of that network, and we get that data for total volumes but we also get it broken out by protocol, by ASN in terms of where traffic is coming from, where it's going out to, by TCP port, UDP port and also source country, and we get that data at five?minute average granularity every hour for the past hour.

In terms of attack data or threat data, we get all of the high and medium alerts that that deployment has seen, but we actually anonymise the information. One thing about all of the data that comes to us via the Internet trance field is we don't store the IP address that it comes from and there is nothing in the file to identify the customer that sent it. We do ask them to tell us where they are located in terms of geographic location and also we ask them to tell us what their primary business is, whether they are a tier one mobile operator. But there is nothing in there that we store to identify the actual customer.

And when it comes to threats what we do is obfuscate the top two within the customer network and we object view cut the two objecting text of any traffic or attack traffic coming out so you can't just look at the threat data and work out which customer it came from. So we get all of this stuff every hour, correlate it together and use lots of scripts based on systems we have in AC 2 and what we are trying to look for is changes in traffic mix, changes in Internet connectivity, port protocol mix alterations and geoIP country statistics in terms of how much traffic is going to and from different countries and try and look at how DDoS threats are evolving and that is what I talked to in the Anti?Abuse Working Group.

Second data set we have comes out of sensor network, sit out there, they are honey pots, sat in allocated v4 address space so this is address space that is allocated to the ISPs whose networks they are on, there are 20, something sensors out there at the moment spread all around the world. They have about one?and?a?half million v4 addresses pointed at them at the moment, and they are there, they complete the 3 way handshake on various different ports, they log the information about who is scanning them and the information about what exploits are tried a and they export that information to our central serves and what they do with that data is build up rank lists of what kind of ports we are seeing scanned, what exploits we are seeing scammed and what they come from in terms of the source addresses, trying them. And we rank those, that information out into in terms of source countries and source of origin ASNs, all of that, and I will talk to where you can see that data in some upcoming slides.

We also do quite a lot of mal ware analysis which gets pulled into Atlas and there are a couple of reasons behind that. On a daily basis, we actually analyse between 2 and 5,000 mal ware samples. Some of them we collect ourselves and some of them we get from third parties and what we try and do with those is first establish if they are new or if we have seen them before and if they are new we try and establish what they try and do, whether they are there to generate spam or viruses or there as BotNets to do data theft or to generate DDoS traffic. From our perspective we are much more interested in the latter two, that is where our areas of expertise are, other security companies look at other types of mal ware. What we do when we dedetective new BotNets or DDoS pieces of malware is go into much more in?depth analysis, what kind of C and C mechanisms they use and where the serves are and the attack traffic that the Bots might be capable of generating because one of the key things that we are known for is our DDoS detection and mitigation solutions and we need to know if there are new attack out there, new BotNets capable of doing new things to our customers so we need to be able to keep up?to?date with what is happening and that is the primary reason we do so much malware analysis. We also do a lot of stuff in terms of data mining with spam, with phishing sites, where what we are trying to do is rank with a lot of stuff this is, where we can reach it in, work out what countries it's in, all of that kind of stuff. So really, what Atlas is about is pulling together quite a lot of diverse information sets about traffic patterns, about DDoS attacks, about malware analysis, and about the kinds of scans and exploits and attacks we are seeing out there on the Internet and we use this data in lots of different ways so we use it to analyse DDoS attack trends, this is what I talked to the anti?abuse group, and for example, on this slide you can see what the average attack sizes are that they are tracking on a month?by?month basis, this is goes back to January 2009. I won't spend any time on this slide as I talked it to it in the anti?abuse group. We use this information to model what the Internet looks like and we have given various presentations in the past on how the Internet has changed shape, moving from being hierarchical to much flatter and densely connected.

We also use it to look at what is going on in IPv6. But at the moment, this is not one of our strongest suits. It's something we are looking to improve. I am doing some work on it at the moment personally. What this ?? these graphs are showing is the A tunnelled.IPv6 traffic that we are ?? at all the inter?domain borders where we get data. What you can see here on the top graph is the amount of tunnelled traffic that we are seeing is decreasing and that is from August last year to today. If we look at the bottom graph this is the amount of native v6 traffic we are seeing as a proportion of all IPv6 traffic at the edges of the networks we are monitoring and that is actually increasing. Our problem is you can't really correlate these graphs together because the underlying sample sizes are very, very, very different. Top graph we get data from pretty much awful the Atlas initiative deployments so 129 ISPs tell us about how much tunnelled v6 there is. The bottom graph is very much smaller number, somewhere down around ten at the moment. And that is because we don't seem to get a huge amount of information about native v6 traffic within a lot of our deployments, presumably because operators don't have NetFlow v9 enabled on their routers and aren't exporting information about native v6. That is one theory. Maybe there is something wrong in our scripts which is what I am looking at to make sure that is not the case.

We also use a lot of this data within the a Atlas.arpa net portal. It gives you a snapshot of all this information for the last 24 hours so, for example, this is showing you.the top exploits that we are see, ports we are seeing scanned, where we are seeing scams come from, in terms of source AS number. Thereon you can see analysis about some of the malware stuffer doing so where are we seeing.net command and control servers, ranked by country and the ports they are using for communication with their Bots. A blog on there which talks to some of the analysis we do, what kinds of attack traffic they can generate and we actually use some of that information within our products as well if you are an Arbor customer.

That is all I wanted to talk to in terms of Atlas initiative, but part of the point of this talk was to find out from you guys what kind of things you'd like us to do in terms of analysing the data that we have got. We are interested in doing presentations of these kinds of events so if you have got any ideas of things you would be interested in, I am very open to hearing them. Not promising I am going to do them but I am very open to hearing them. Thanks very much.

CHAIR: Are there questions or comments for Darren? OK. I actually have a question. So I was interested to hear you guys are working on v6 and glad to hear you are improving that. How soon do you think you will have some improved data in that department.

DARREN ANSTEE: Our products can do it now and have been able to do it for last couple of releases so they are very capable of releases NetFlow v9 for traffic for IPv6 so you can talk to them over that if you want. But we don't seem to be seeing very much data. I don't fully know why that is, it's because of service providers aren't monitoring it or we have got something wrong somewhere in the scripts that collect this data and process it and I start looking at that yesterday.

CHAIR: Your sensors are very v6 tabled or v4 dark space.

DARREN ANSTEE: The Atlas honey spots are v4 only at the moment.

CHAIR: Okay, any other questions or comments from the room? Right, well, thank you, Darren.

(Applause)

So next up is Renata. She has been doing a lot of work on looking at essential the network from the edge, from out at home networks and what can be observed about axis networks and their properties from that perspective.

RENATA TEIXEIRA: So I am Renata, I am a research at LIP 6 so I am not coming from the same side so I am hoping to get some feedback. I have been doing lots of work as Richard was just saying on trying to measure Internet access networks and also the influence of people's home networks into their performance.

So there has been a lot of press today into the Internet, access performance and people are not getting what they are paid for, EUS, the FCC, trying to get ?? they are trying to get a lot of things around and you know get legislation and regulation for ISPs so they can verify whether people are getting what they are paying for for their homes. So our goal with this research when it started was to try to measure home Internet performance, what people are getting from their homes, and see whether it's true or not, all these things that are going on.

So our first take on this was to use data from the Grenouille project in France. Do people here know Grenouille? Some people know. What it does, since around 2000, these folks are volunteers that have regular day jobs and they started measuring the DSL and cable performance in France, they put a little client in people's homes so whoever wants to measure, they download the client and end host and they have a serve where people are doing pretty much just FTP download and upload and some pings, OK and the user when they install the client in their machine they give some met at that data so they say which ISP they subscribe to, which service and the city where they live. So have some extra annotated data interest from these users and the advantage is coming directly from the home so we can actually see whatever the performance the users are getting. And so they have lots of data, like thousands of users, in most cities in France, most ISPs in France. So we are very excited starting to work with this data. And that is just a to give you an idea. So this will give you an idea of the things of things we have seen.

So this curve is showing you on the X Axis the 95 percentile of the download speed received for user so we were measuring this for a whole month and we are doing the distribution for each user and we are getting the 95 percentile, so this pretty much like the top of the performance that the users are getting for this whole month. And we are dividing it by the advertised service plan, how much the user says that they bought from the ISP. Which plan they said that they have. And what you can kind of see, unfortunately the vertical line became horizontal, what you can see here, if you go from the X Axis, is 0.8 and you go up you can see that is 80% fewer than half of the users achieve 80% of whatever the ISPs are saying that the users should be getting and we were like very puzzled when we first saw this and we wanted to understand little bit more why is this, explain why we have this very bad performance here that some people, like their best performance doesn't correspond to even 20% of what they are supposed to be getting and very puzzled with this. The problem with this data set is the measurements, as I was explaining earlier, they are taken from the end host; they are not taken directly from the gateway. So in home networks today, they are becoming very complex. Before, if you just have a little modem and a computer directly connected to the modem, your computer is measuring the access, what are Internet access is giving you, but today we have  ?? so, I don't know, it's not working ?? but we have lots of things going on in the home today so we have game con sols, TV, people in France, most people have triple play and there are lots of other computers in the home, you have wireless in the home, so home is becoming very, very complex and it's hard to differentiate the performance you are getting from your home to what your access is giving you. So one thing we did at LIP 6, we wanted to understand the ?? how much ?? sort of intuitive that your home network would be impacting whatever you home at home, impact your end performance, by how much and how much could that explain some of the things we were seeing from the data from Grenouille. We had this set up where we had a serve at LIP 6 and we had lines like from France Telecom, with 8 megabits down and one up, and we were connected this to a home, also both of these are in Paris and just trying to emulate different traffic patterns inside this home and see how that would affect our end?to?end RTTs and end?to?end HTP downloads. This is just one result. It's sort of intuitive there would be an impact; we wanted to see how much. Here X Axis is http download rate we are getting from our server. When the network was idol, which is the black line, that is the performance we are getting which was 6 megabits per second which is really close to what was announced, which was eight per second down, OK? When we turned on the phone, because this was a triple play line, so we could turn on the phone and you see the phone didn't impact very much but the TV, as long as they turned the TV, pretty much you get a 3 megabits cut from the http download, so I have never ?? I have been doing research for some time, I have never, ever seen such a strange line in CDF, it means whenever the TV is on the benefits, I am trying to find out what is going on behind, people tell me, explain how these things are working and we also did this these things for cross traffic like upload and download from the home and the impact can be even much worse than what you are seeing here so the bottom line is so we see that the home network can have a very big impact on the performance that users are getting from home so what should we do to distinguish, OK? What you are getting from the home, from what you are seeing in the access.

So we thought about two general approaches: One is you could try measure from the home Gateway itself. If you put the measurements from the gateway, then you can directly see the access, you are not really getting from the home, and that is the approach that some nodes for instance is doing with the deployments of the white boxes that they are doing with FCC and AFCON so they deploy the measurements directly at the access point so you can directly connect to the line and you can sense if there is any cross traffic coming from the home and deside. OK, I am not going to do measurements now so I make sure what I am measuring is really the access performance and not anything the home network is influencing.

The other approach is to try to infer from end host. So if Grenouille have a very large user base and we could use this to maybe improve their client, OK. So the idea is you could try do some extra measurements inside your home or do some sensing with P and P queries or other extra measurements that help you differentiate whether there is some cross traffic from the home or something in the home or the wireless quality or something that is impacting your access or your Internet performance.

The good thing about bag professor is you don't have to choose site, you can do everything, you just need more students. So we are working on both aspects right now, and for the ?? so I am going to just talk a little bit more about the, what can you do from end host, because now, I need your help, so I am going to give my advertisement speech: We are trying to understand what we can do from end host but we need more data on home networks look like today, what kind of protocols do the devices support and what can we do if you are just at end host and so we are developing this tool called home Internet /PAOEUFRD, I send a link to the RIPE ?? the MAT list, I am not sure if people got so I am going to give a little bit more. So what is the design problems that we have there? So we are trying to measure the home network from an end host. OK and we want to get as many users as possible, that is why I told you I need all of your help because we need to get lots of users for our tool, so it has to be portable to running most of the operating systems. We also wanted to be very simple and no installation required so you just sort of click, run it, you ?? we do our measurements to get the data and then it's very simple for the users. And even my mum tried it, I can't say she was the best, but anybody could try this tool. We also want people to have some incentive to participate, so at the end of the mr /AOURPLTS, we give a report to the users where you can see what the measurements we did. Right now the report is not super sophisticated yet but we can ?? so you can tell you about the quality of your wireless, whether there are other access points that are used in the same channel as yours and there is some things about your home network using the tool. So some people express some privacy concerns in running things their computer in their home so I mean, we are doing everything, anonymise everything, there is no access point names or SSID or even UPnP services everything we do we anonymise it. We just identify the user with random ID so there is no way for us to get back to users and we don't collect any information that is sensitive anyway; it's mainly things about your home. Let me put the list of the things we are collecting.

Wave user survey part because it helps us during the measurements we are doing to get some ground truths from the users. All the measurements are optional and ?? if you don't want to do it you can stip it. It's useful if you can do everything because having all the information is helpful. So we collect, the network information we are going to count the devices in the home, we look at the wi?fi quality and also the neighbouring wi?fis and we also use Netalyzer that does a lot of performance measurement and it looks at security so we run the tool to get the measurement side by side. They don't look at the home network; they mostly look at access so it's a way of having them together. We look at the gate way information, UPnP and the services people have at home and we have some information about the configurations that people have in their computer, just to know whether there is some application running that is going to interfere with our measurements and things like that.

So that is sort of what we collect and the status now, the tool is up and running, called home net profiler. The link is there. Run it from home, not from here, please. So just measure the home. Is runses for Mac OS, Linux and Windows, hopefully nobody here has Windows XP. We have been recruiting volunteers starting mid April. We've been sending it to our family, friends. We also have news that the Grenouille site which helped us very much, if you see we are now ?? as of yesterday we will 816 unique agents, so which sort of should be users, and more than half of them were just in France because of the Grenouille use lots of people there that have been downloading this. And we have already measurements for 37 countries hoping to get some more and more people in the countries, so that is my advertisement. I am asking people to help so if you can send this link to people, you know, if you can run it when you are home, it should take five minutes; sometimes it's a little bit slower but it shouldn't take more than ten for sure. And it will really, really help our research. So just to summarise:

We have shown that the home can significantly affect the Internet performance. It's very hard to distinguish today whether the problem is coming from your home or from the access. I think the ideal way of doing this, distinguishing, putting the measurements at the router itself because you ideally place between the home and access and you can measure things correctly and we also think that the home networks are becoming really complex and you need better tools to do diagnosis in the home and we are hoping that the net net profiler tool will evolve into something more sophisticated to be doing diagnosis. So with that, I can take some questions.

CHAIR: Thanks. So are there some questions and comments for Renata.



ROBERT KISTELEKI: Random Atlas user. I am going to run this at home and I am going to compare that to what we see in Atlas. I would be very, very interested in whether there is a correlation or not.

RENATA TEIXEIRA: Yes, that is the part we are trying to get the measurements as well, exactly because of that.

Lorenzo: Can you use this to detect broken IPv6 connectivity in the home? Well, so, in the context of IPv6 day, which is in about a month's time, we know about 300,000 users worldwide will have problems reaching basically a large number of large websites on June 8th. If they could use this or somebody could point them to use this and say, hey, you have this problem, you know, then they would actually be able to access their websites on June 8th and we would all be happier.

RENATA TEIXEIRA: The Netalyzer does lots of IPv6 tests and so this is ?? this tool, everything that is related to the access and going out of the home, will rely on Netalyzer for because there is already such a good job we didn't feel like reimplement everything so our part of the tool is focusing on the home but if you run the tool we are going to have both reports so then you can see some of the problems with v6.

Lorenzo: Because the problem is in the home most of the home. The home gateway is announcing v6 reachability and then it's dropping.

RENATA TEIXEIRA: Netalyzer does ?? some of these questions about DNS and reachability and some of the things that are related to the gateway, they already testing for this.

Lorenzo: Does it run if there is some packets that are coming in that are confusing the stack, so that is ?? it's really something that is happening in the home that is breaking reachability outside the home, which is I thought what you were measuring. But we can take this off?line.

RENATA TEIXEIRA: OK. Let's talk about it.

AUDIENCE SPEAKER: Google. Do you think that the slowness you have seen in the Grenouille network may be related to the dark buffers that ? have been going on about for the last six months.

RENATA TEIXEIRA: Something the buffer load problem is something, I am hoping we will be able to get some interesting results out because the Netalyzer tool does the test of the up load plus the RTT so it can check the buffer size and we have the model of the gate ways with the UPnP so we can correlate which Gateway models actually have these larger buffer and how it rerelates with the up link and down link bandwidth so we are hoping ?? I mean, I am just collecting the data right now so I don't have a perfect answer for your question but I am hoping we will be able to inform much more the community because we have both the UPnP data and the buffer measurements.

AUDIENCE SPEAKER: Thank you.

DANIEL KARRENBERG: RIPE NCC. I think this is very promising field of research and I would want to encourage you to actually give us some intermediate status reports, even in the MAT Working Group even before you start publishing results and things like that, you might get some feedback from this group and I have personally have an interest of seeing some of the results you you have could be applied to RIPE Atlas where with we could see ?? make some inferences from the user traffic in as far as it influences our measurements. We are looking also at some probes that are more like some of those things for the people that trust us enough to see all their traffic, to actually put inside the connection so we can subtract that traffic but for the probes that we have right now, which are very much like the gran /AO*UL, it would be really interesting if there was some results that allow us to know a little bit more about how the actual user traffic influences our results so those are two things. Please keep us informed of this researching it's very interesting and if there are any inferences we can make to make the other results better, that would be really, really nice.

RENATA TEIXEIRA: So that is the goal, that is why we are doing the home net profiler tool because I do think not everybody will be able to put ? like, it's not going to work everywhere, plus, I mean there is still a problem, even the Sonos box we all have triple play and you saw how much the TV impact measurements you are getting and some nodes cannot see the TV traffic.

DANIEL KARRENBERG: I have this little I think that has two /S*EUZs in there and we are evaluating that as an Atlas probe which you could actually, if you could have two ethernet that is before the exit could see that traffic, if people trust us enough. I am not sure whether this will work but we are looking into this stuff.

RENATA TEIXEIRA: I would love to learn now.

CHAIR: Thank you, Renata.

(Applause)

CHAIR: Next up is Job Snijders. Job is going to talk to us about a project he is called NLNOG RING, from the UK ?? collaborative measurement project.

JOB SNIJDERS: Hello, everybody. I am Job Snijders and I would like to share some information on a project we started in December and hopefully after the presentation you are convinced enough to join me.

The ring is a very powerful debugging tool, you can do more with it than with a looking glass. It is flexible. You can script your own programmes to solve riddles in networks and what it actually is, is shell access in autonomous systems, it you can do whatever you want to debug or troubleshoot your network.

How it got started: In December 2010 a friend of mine had awkward problems because from certain ranges in his network, he couldn't access certain IP addresses in somebody else's network. It was very hard to troubleshoot and everybody was providing him with trace routes and pings and they got, haven't you still figured it out and he kept asking for more output from probes that people ran, and it was very manual and intensive process, and in the end, turned out somewhere in Internet exchange on layer 2 fabric there was something with a hash bucket that went wrong. But it took way too much time to solve it. So I figured, why don't we all donate a machine to this, we call it the ring, and if you make a machine available, you get access to all the machines and these are currently the participants. As you can see, we are bringing access and content networks and networks that are in the middle, together. It's pretty cool if you are an access provider that you can look from major content networks how things are.

Before people think that this is a very insecure DDoS network sky net thing that is waiting to happen, it is a closed thing. You can only get access if you participate. If you trust other people to access your machine, they will trust you. And we believe in name and shame. So if there is any abuse, we will get to you.

How it currently works: Everything goes through SSH. That is the interface. You can log on to machines and execute programmes there. We have written some small programmes you can use and I will give some examples after this slide. So, that is the role for the participant, you make a machine available and use resources for SSH and we as ring add minutes, we take care of the rest, you put the box in your network and you don't need to worry about it any more.

This is one of the examples I personally use very often. If somebody tells me, I think this and this is down, it might be hard to confirm whether it's true or not, and on the left you see ring thing in verbose mode and I can just see how other networks can reach it or not. And then on the right, there is the short version, right.net apparently is well connected in Amsterdam, but it's funny that v6 showed a millisecond of difference, but this is just one command; it takes me two seconds to type it in and I get results very fast. This is easier than asking friends can you do this and this command.

Other example: Since we have all these machines, what can you do with it? And smoping was one of the easy thing in the installation, every machine is monitoring every other machine in the room. Smoping won't skill to ?? by then we will have to figure something else out but for these are the cool graphs. .

This is the last example. This one is the coolest. Unfortunately the output is too big. I would ask you to go to the following URL and if your neighbour doesn't have his laptop open, please share with each other.

What happened here in this example is that I run the ring all command which executes whatever the arguments are to the script on every server. One of the most common examples is trace routes, especially when some things are further away from you, you have diversity towards that network that is having some problem far away, and if you do a trace route from all the networks towards it you can easily see, hey, probably this guy's transit is broken somewhere here and you can open a support much easier or convince parties that they actually do have a problem much easier. Then again, this command, it takes four seconds to type in. You wait a minute for the output and you have a pretty good overview of what the target are. These are just examples, since you get shell access, do anything you want. Common application could be checking your DNS, if the ring is spreading out over the world, GUI P set?ups might be easier to troubleshoot and MTU testing is important, you can run I perb between the machines and see what kind of window sizes and MTU you get. Port scanning is easy, I like when I configure a firewall to verify what it looks like from the outside. And troubleshooting Internet Exchanges, that is where it started, layer two load balancing issues can be really hard to find. If you don't like trace routing or pinging you could consider joining because you are attached to Internet Exchange fabric, you want to speed up other people's debugging problems.

So this is what ring currently is and we have some plans for the future. The most important one is we want a legal entity to provide guidance and governance to this project. Currently it's run by me and three other friends as individuals and we have noticed that there are some large access networks that would like to join but cannot do so because there is no paper trail that shifts liability to the proper group of people or they cannot put undocumented box in their network so if they have an nonprofit organisation, that should be easier and another change that will come ?? it's all good faith and common sense, but we want to write down the common sense, we want somebody that is allowed to sign for an organisation, that, on behalf of the organisation, they promise not to abuse the resources, so we can hold that against them if something ever happens.

In that common sense agreement, we, as the nonprofit organisation, promise to keep things up?to?date to audit, to secure, to configure and take away all the maintenance issues. Maybe in the future we will provide a web interface so you can easier give access to your employees, and API, some companies have asked for that. It would be fascinating if you could tell the ring to focus on this IP address for the next 15 minutes and is unreachable in the next 15 minutes from one of locations or more than five locations to send an alert so you could have short bursts of monitoring which is useful because when I am going to reload that core router that 15 minutes are very interesting for me. And of course, if you have ideas, please share them with us. I have heard from researches on university that they want ?? they had some ideas to use the data that could be generated between all those servers to do some fun stuff with. We are very open to feature requests or ideas or collaborative things with students. If you have ideas, please tell them.

So joining the ring is very easy, all you need is one machine. It doesn't need a lot of resources. It is very important that it has one IPv4 and one IPv6 address, especially in upcoming months or years, debugging IPv6 will be very hard, and IPv6 topology on the Internet, I feel that it's more fragile than IPv4 topology and stuff like latency or awkward paths or load balancing tricks that go wrong, we want to know that stuff, so IPv6 you are not allowed to join a ring if you don't have an IPv6 address for the machine. And then we choose you be unit, but who cares.

We are now at the end of my presentation, I hope I could enlighten you a little bit of what we, as Dutch operators, came up with. Are there any questions or concerns or anything?

CHAIR: Questions or comments for Job?

AUDIENCE SPEAKER: Robert Kisteleki, researcher. There is no such thing as one IPv6 address. But that is not the point. And in the future there will be no such thing as IPv4. My point is, I would be really scared if researchers actually had shell access on my network. You really think that you will not introduce these kind of controls of what they can do or what anyone can do, you just showed an example where execute this command. It's really easy to abuse that.

JOB SNIJDERS: If you are an operator you get the shell access. If some researcher comes to me and he is not an operator, he can discuss an idea with me and I will see how we work it out in practice.

ROBERT KISTELEKI: You do give virtually unlimited GLX to someone else on your network.

JOB SNIJDERS: Should be treated the same as any dedicated server or access consumer. You don't put it in your management network but with the other people you provide Internet access to. There should be no difference. So that from that point of view, it could be my mother on a dial up on your network, or me on the ring machine you host. And please, by all means if you feel that firewalling the device to protect certain aspects of your network is necessary, you are allowed to do so.

ROBERT KISTELEKI: OK. Next question: This looks awfully similar to PlanetLab to me or M lab. Have you looked at them to see whether it's going to be similar or different and reasons for that?

JOB SNIJDERS: I am not familiar with those two projects.

ROBERT KISTELEKI: You should be.

CHAIR: May have more diversity, concentrated in certain classes of networks, might be different places.

AUDIENCE SPEAKER: Martin. One comment and one question. You might be on a nice path IPv6 killer ap. And the question is if something on multiple points of presence, is a machine per POP required or you only need one access to one machine?

JOB SNIJDERS: You need at least one machine but if you have interesting POPs that are not currently covered, see Amsterdam, we have so much machines in Amsterdam, we are not really want to do more there but in Singapore or Prague, where we are not currently, please maybe make two machines or three machines available as long as it's interesting enough, but one at least.

AUDIENCE SPEAKER: Fair enough. Thank you.

CHAIR: You might want to consider collecting met at that data from the machines you got.

JOB SNIJDERS: On the website, we have some met at that data, if you click on participants you will see a map and some other information.

DANIEL KARRENBERG: RIPE NCC. Not at this point but nettism. I have a couple of boxes that I pay out of my own pocket in Germany and US, but obviously I am not an operator. Both places actually have a policy against port map scans and stuff like that, since mentioned it, I would like to give you a virtual machine there but can I have some influence on the stuff that is done with it, because if I give you a virtual machine on these boxes, and you do stuff that my provider there, my hosting provider decides are outside their acceptable use policy, my family is not going to be happy because they won't be able to mail each over.

JOB SNIJDERS: We have never had participants outside the land of the free but if this is a valid concern and we would have to discuss.

DANIEL KARRENBERG: This is the German provider who is anal about this. Just to make sure this is not US bashing.

JOB SNIJDERS: We would have to discuss it. It's a valid concern and we haven't encountered it yet so it would be ??

DANIEL KARRENBERG: I would really like to participate but I think you need a mechanism like that,

JOB SNIJDERS: Your company is present in the DFZ with its own AS in?

DANIEL KARRENBERG: You want operators only, then I am not playing.

JOB SNIJDERS: If we notice a problem between ring machines, it's very nice if the communication lines are short and you can get to somebody that has enable access inside that autonomous system so that is where it started.

AUDIENCE SPEAKER: I have a remote question from a Christian, digital security: He says have you considered offering into the full?blown shell to users but specific services, such as ping and MTR, especially as the number of participants grow, trust might become an issue.

JOB SNIJDERS: If we limit to certain commands, I don't want to limit, because the looking glasses, they do ping and trace route but it might not be enough, if you have a really awkward problem and you want to do some creative testing, for instance send packets out and make sure that the source port is different so you can see what happens, it would be annoying if it's limited in that way. If this model doesn't skill, we will have to figure something else out and if it becomes a problem, we might lock down or partition the group into smaller groups, but for now, you only have route access on the machine you made available and you only have regular shell access on all other people's machines.

RANDY BUSH: Remote participant.

JOB SNIJDERS: I didn't hear you? You would like to participate?

RANDY BUSH: Remote participant, I said. How is a server present in the DFZ with its own ASN? Why are you excluding Daniel? How is a server, how is a company on the DFZ? My offices sit on top of a router?

JOB SNIJDERS: What I imagine is you provide a server and it is connected somehow to a router and that is connected to something else and somewhere ??

RANDY BUSH: All you are saying the LAN should be on ?? behind some ??

JOB SNIJDERS: I want a machine to be ??

RANDY BUSH: One hop from a border router?

JOB SNIJDERS: That is not it. We use this to debug, so the machine will be in a network and the company knees needs to run that network. So if you are just a web hoster and you run a correct somewhere else and put a machine in, you don't control the routing in front of that machine and then it's of less value, I think

RANDY BUSH: Why?

JOB SNIJDERS: At least in the Netherlands, I am sure how it is in other countries.

RANDY BUSH: Well, I presume that you are not going to run something here that is going to change the routing?

JOB SNIJDERS: No.

RANDY BUSH: So I am not ?? I am just not understanding what you are trying to do here and you excluded a volunteer based on it and I just don't understand it.

CHAIR: I think maybe we need to take this off?line but thanks for the comment and thanks for the presentation, I think we have got some discussion going here.

JOB SNIJDERS: Thank you for your time.

(Applause)

CHAIR: Next up is Emile Aben from the RIPE NCC with a brief update on v6 measurements they are doing ?? planning to do.

EMILE ABEN: Resident data junkie at RIPE NCC. This someone a quick one about our plans on measurement world IPv6 day, so I guess everybody knows what world IPv6 day, otherwise go to Google. So, we basically have three things: We have an idea for an IPv6 I chart. We have a TTM monitoring of world day participants and a little bonus that is 6 to 4 relative performance on the day. And we want to make all the information that we collect available near?realtime.

So the IPv6 Eye?chart ?? eye?chart. There is lots of people measuring IPv6, there is of course Google and Geoff Houston and us, people that run stuff on server side and see lots of clients and there is also excellent test by Jason Fetcheller called test IPv6 test?IPv6 dot com. But these tests only measure either to multiple clients from a single point or multiple ?? from ?? they are also tested to do single client to multiple points but what we wanted to do here is, measure from multiple clients to multiple points and the idea behind that is that you can have a good IPv6 connectivity from your home network to a specific test site but your connectivity to other sites might be limited. So, or might actually not work due to the dual stack brokenness that has been discussed by many people before.

So the idea here is to check connectivity to people that participate in world IPv6 day and check connectivity from a client to people that are already run dual stack websites. So this is will just be a single web page that people can go to and just see the results from trying to connect to multiple websites so it fetches ?? there is some Java Script under it that displays nice books, you have connectivity to this site or you don't. It measures to multiple real targets not a single target and the goal is to bring down dual stack brokenness, hopefully before world IPv6 day, if not during. That is mock?up of what that will look like. If everything is OK on world IPv6 day, then this is before world IPv6 day, so what these things mean is that there is check for your connectivity to Google which at the moment is IPv4 only if you are not on the white list. You basically see for world IPv6 day participants before the day you will see just green, because that is your normal connectivity, but for the websites that are already dual stacked, so this is RIPE NCC, APNIC, Thor Andersen's stuff in Norway, you will also see everything is OK, so you will test your connectivity to websites, to multiple websites at the same time that are already IPv6 or already dual stacked. So, this is what it looks like if your host is probably attic or if you have problematic IPv6, so before the day your connectivity to the world IPv6 day participants will still work fine because it's usually v4?only, but to the dual stack web size you will have some kind of brokenness. And the message here is please fix this.

If you have a couple of OK check boxes but say there is a single or couple of dual stack websites that don't work, then there is a problem between you and that specific network and that is the type of thing that is hopefully better identifiable this way so we will monitor this a little bit so we can get that data out of that.

So if people don't fix it, this is what it will become on world IPv6 day, that is basically the message, you won't be able to reach these websites and it's the fault of single website there but your problem because you have broken dual stack or you have broken connectivity.

So that is the eye?chart idea.

The other thing we want to do is TTM measurements so I think everybody knows what TTM is. We have 40?plus TTM boxes that are IPv6 enabled and during world IPv6 day, we want to do measurements from these to the participating websites, see if they are AAAA. If they have a AAAA so we want to keep them honest ping and ping 6, we want to fetch contents over v4 and v6 and have a little collection of trace routes to them in case something goes wrong, there is some debug information that people can work with. And this is sort of our bonus measurement, which is a cooperation with University of Applied Sciences in Amsterdam, so we actually have a couple of students from there working on this. And as you all know, 6 to 4 is a concern; we measured that, Geoff gave an excellent presentation on that before and I heard some worries about 6 could 4 relays, that they may not be able to cope with the loads during world IPv6 day. But the message there is don't disable your relays, just put them up, have your clients not do 6 to 4 or any stuff like that. So basic idea is we will have a host or maybe multiple hosts that just does a connection to a single target over native IPv6, will have an RTT for that, we will do measurement from a single target using a 6 to 4 address that maps to an IPv4 address that we have on the same address, so the forward path is the same and reverse path is slightly longer, we will measure the difference and hopefully on world IPv6 day we either see no change, which means towards that particular side there is no problem, or we see some change if they are totally overloading, which is another indication of 6 to 4's reliability.

So that is it, basically. So I hope that world IPv6 day is going to be very, very boring, measurement?wise at least. These are our current plans and we want to put this information up on RIPE Labs so you can comment on it and see what we have and where we have it. So that is it. Any questions?

CHAIR: Any questions for Emile?

AUDIENCE SPEAKER: Do you need any IPv6 dual stack for ages for your measurements are those are not relevant and you need more people who will enable on day D? There are out there many websites which are IPv6 for ages now, and I saw that you mentioned some of them, so is that relevant to get as many as possible for your measurements or it's not relevant and do you need, rather, people who will do that only on day D.

EMILE ABEN: We need both but the v6 providers, there is information there on the sites that will ?? that are going to be enabling their ??

AUDIENCE SPEAKER: So you are full?

EMILE ABEN: No, for the people that are already dual stacked it would be excellent if we could fetch content from you.

AUDIENCE SPEAKER: The more, the merrior.

Lorenzo: I have lots of questions. First of all thank you for doing this. I think it will be great and having the measurements in realtime will be very useful and not only to keep people honest but to, having blow?by?blow account will be very important and we will certainly looking at it. So, I commented, to start with, this is the way I remember it, I wonder if you could fetch something like the fab icon of the website and display that?

EMILE ABEN: I have running code that produced that that and the problem is they are under 1,500 typically, 1,500 bytes typically, so you won't be measuring path NTU problems, that is the big problem otherwise I would be having with having everybody's FAV icon.

Lorenzo: Rewrite it with the FAV icon, you don't know which X is what.

EMILE ABEN: We had a problem with wanting to use logos and that runs into all kinds of lawyery things that I don't want to get into. But we have dedewe could have names under that. This is all very fluid at this point so if you want names under it, by all means we can put names under it.

Lorenzo: For the 6 to 4 return path I would expect to see not latency increase but packet loss.

EMILE ABEN: OK, we will have just a raw data there and still up in the air if we are going to do ping or if we are going to actually do fetch fav icons as well or something.

Lorenzo: Some of them may fall over and I don't think you will see latency changes but may see loss and that is what we see today really, really black out or limiting or things like that. I would love to see, and I don't know if you are measuring this, it's not clear, could you go back a couple of slides, again, so what I'd love to see and what I think the other participants would like to see, since this is about HTP essentially is put yourself in the mode of a user who has a normal operating system and try to do what the operating system, try v6 first and then v4 and then she nice graph. If you see oh, hey, website A is only in two locations world side, so on around about 000 you see all these had a latency spike which was 90 milliseconds and he they went back to zero.

EMILE ABEN: We will be measuring both content over v4 and 6, because wave single OS we do this from, question not emulate awful the brokenness behaviour.

Lorenzo: What I am saying assume the 0 S is doing fine but instead of ?? instead of displaying them ?? measuring v4 and 6 separately and displaying all the time, have a separate graph that does the measurement result of try v6 if available and if not, try v4, because that is the situation that a normal user who has dual stack will find themselves in.

EMILE ABEN: Yes, but you won't know what their OS behaves like. Mac OS ??

Lorenzo: I agree, it'll try v6 if it's there and if not, it will try v4.

CHAIR: One more question from Geoff.

GEOFF HUSTON: It's actually an observation really. And it's an observation that the tools and the things you are looking at at this point are concentrated on the end client. Whereas my understanding at world IPv6 day was actually concentrated on the web consent provider, which is subtly different, and I would like to mention that APNIC we have taken the same tool that you are using and actually twisted it around and allowed a web content provider to add a test into the existing code that if they are using Google analytics and generate the analytics report and say what is going to happen to my existing clients were I to go dual stack and allow folk to understand the numbers and the way in which clients behave before the day, so, if you like to talk to me about it I am happy to talk to anybody. It's the flip side of the coin and look at the world as the content provider is going to see it, as distinct from what clients see.

EMILE ABEN: The problem is the content providers are going to do their utmost best to make things work and they have the resources to make things work. The end users are the problem ?? are sort of the ??

GEOFF HUSTON: Isn't it good to know in advance before you put your entire content up before you do that, what you are likely to see?

CHAIR: I am going to have to cut the mic line. We will have the BoF after this, if there is some related comments, that can be space for them. Thanks again.

(Applause)

We are going to go ahead and let Christian give his talk.



CHRISTIAN TEUSCHEL: I am working for the RIPE NCC at information service department and I take today as a chance to present RIPE stat. I mean, you already have heard about RIPE stat and I promise to keep it really short, just to get the essential information out.

Well, we have some kind of motivation to do RIPE stat and, today we heard a lot about measuring and a lot of tools and all these tools produce a lot of data and in a way the problem is, when you have to find information about Internet resources, IP addresses, AS numbers and all that, you are usually, you have one problem, and the problem is that if you want to have a lot of information, you have to combine different services you have to go to different web pages and use different clients and that is actually the thing many people are complaining about and we gave you the thought and came up with an idea; if we could actually combine a lot of data sets on the one interface and this is basically the idea behind RIPE stat. So we have one interface which is called RIPE stat and from this interface we can query a lot of data sets and the important thing is it will not be only RIPE NCC data; also external data sets. Later on I'm going to show you the black list plug in and another thing about this concept it should be possible to share information, because inherent aspect of information is that it makes more sense if you share it. So we focused on giving you some means to actually share information with other users.

A word on ?? before we jump to the actual screen shots of the application, I just want to drop some thoughts about the development. So actually there is no fixed road map, which means that with your suggestions, you can drive the ongoing development. We started with a basic application which will just be some kind of playground for you to see what could be possible with RIPE stat and what can you do with RIPE stat.

I will just focus on the most important key principles which we adhere to while developing. One of them is that we have actually the data sets, we present in some kind of use in a way you can actually see it, and awful the data sets, if it's possible, should support history, so you can go back in time and also some kind of zooming. Another important thing is the transparent development which one highlight of the transparent development is we are going to have public demos every four weeks where we can show you what we have done in the recent four weeks.

This is actually a screen shot of the RIPE stat, after you queried for one Internet resource then you will be presented with something like that. So in the middle part, we have the information grouped in boxes and these are the views on different data sets, so there can be different views on the same data set.

So if you think that the data or the presentation of the data is not enough for you or you want to further process it, there is a way to actually download the raw data, as well. There will be a link before we said we said we focus on sharing information with other users and this is one of the means you can share the output of this specific plug?in. Another pillar of our development structure is we share all our information, which also means that we have methodology link where you can see the methodology should actually supply you with all the information which data sets we are using, how we process it and all that stuff.

Then I give you a small selection of some plug?ins. For example, the Whois plug?in which shows Whois information. I mean, that is nothing new to you, I guess. But in this case, this is an example that we ride to make a smart selection about what data we are presenting. For example, we are not splashing out all the information we get from Whois because it's information overload.

Just one thing: If you wonder what this P and A ticks mean, that means that we separate the plug?ins, if the plug?in is available for either prefix or AS number so when you see a tick, it is for prefix.

I think I am examining to skip the next, these things I always have problems presenting screen shot because usual the best way is to just play around with it and see what you can do with it.

So, we just jump over to the additional features. On the right side we have popular queries and your latest queries so you can see what is most queried for. And below that, we have some links on the event pages; I mean we call them event pages and in this section we try to cover Internet?related events; for example, the Internet outage in Egypt or earthquake in Japan. Below that you will see links to our recordings of the public demos because we make recordings and we present them here. And another important aspect are the comments, so feedback is very important for us because it will drive the direction of RIPE stat, so if you have suggestions, please drop them here. Afterwards I am going to show you some different ways to participate.

We also provide you with access statistics so we don't keep the data for us, so you can have a look, how many people are actually using it. And also, we have a change log use so you can look up what we have done in the development.

Then just small outlook on possible future features. They are not planned but they could be implemented. For example, we we are thinking about making the result page customisable, so in a way you can change the layout, if you are only interested in black list information, you can skip all the other plug?ins and just get the black list data as a result. And also, we try to get more data sets in there and also more use and also maybe a common line client.

Well, that brings me to the end of the presentation. And just I want to mention, afterwards, I think it's already started, the BoF, where we can talk more or actually ?? I mean, we can also skip the questions and put it to the BoF.

CHAIR: I was going to say the same thing. We will cut questions on this because we are going to have a whole BoF on that. What we are going to do now is take a five?minute break to let people get up and stretch the legs. My watch says 17:45 so back here at 17:50 on the dot. There is incentives in this too, I think the NCC has arranged to have some sort of ipod as award for the best comment.

(Applause)

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE