The test traffic session commenced as follows:

CHAIR: Good morning everybody. Welcome to the test traffic Working Group. My name is Ian, I am co‑chair with /H*EPB of the RIPE NCC of this group. We have got the agenda this morning, so an update from Ruben, we have got Andrei Shukov participating remotely and we have got Tony Mcgreg /O giving a couple of talks. We have got somebody from CAIDA who is due to give a presentation, I am not sure if she is in the room yet? OK, well hopefully that presentation will arrive soon.

OK. Just to remember, the session is being recorded and broadcasted so could you use any of the microphones and state your name and affiliation when asking any questions.

Just before we get started, there is a slight feeling amongst the chairs that the agenda has been a bit light for the last couple of meetings. Lack I said, we have got somebody from CAIDA who is going to presentation on the measurements they are doing. We will a little aware that the charter may suggest that you have to be using the RIPE TCM system to be able to give presentations here. We would like to encourage presentations that are more about Internet measurement, whether through a change of the charts isn't clear, we are thinking about widening the scope of the group a little bit later and would welcome any input.

One thing I forgot to do, with the minutes of the last meeting in Dubai accepted, were there any issues with them? OK. (Were) we will start straightaway with Ruben.

RUBEN VAN STAVEREN: Good morning, thank you for making it along this early hour. My name is Ruben starch at RIPE NCC, I work at the information services department and I am the service manager for test traffic and managements and this is my updates.

The status of the grid as I would like to call it, we have like 106 boxes enlisted and of which is like 78 active, which is 74 percent. The number of installations we did since the last update, that is 2 complete kits, which means antenna and computer server, and 6 antenna kits where the house ‑‑ provider own computer server. So there is increasing popularity in the kits and get your own hardware, which is good, which is encourages rollout.

The new boxes are internal one for RIPE NCC for SLA measurements and two for the Chinese university in Hong Kong, which is in Hong Kong, which kind of enlarged our presence in the Far East.

Replacements: We had none since last updates.

And decommissioned boxes, luckily, also non‑since the last updates, so that is stable.

The current running projects we have is TT N Brazil. (TTM?)this week I checked out with them and there is still one to go. They are planning this to the deploy a large carrier in Brazil, probably get back to them in about a month time to see what the state is about on that.

TTM in the APNIC area. Last year, we shipped a bunch of clock /KA*RTS to Brisbane, they provision the cables and antennas themselves and send it off to locations in their service area. And that is active, that is currently rolling out.

Also some new efforts in that area, we are planning to do the same thing in the RIP N area, the former Soviet union and new effort in the LACNIC area which is a bit different from the current efforts running in Brazil as this will be for the whole LACNIC area instead of just Brazil.

Both of those are just currently under discussion.

Pending new installs: That is really a large list. First of all, really, really different locations where we previously used to be like Europe and United States, and now see that we start to pop newspaper locations in Africa, like Nairobi and Pretoria. There is a pending insulation by LACNIC in you are guy, as part of the APNIC roll out we see deployments in Pakistan and also in Hong Kong. Boxes for which I don't have a number because it's like the, first come first served, one new boxes for DE‑CIX, another additional one for SLA measurements at their exchange and one that is going to be placed at N IX /TPHEUFPLT Dehli in India.

The graphs, show some graphs. As you see, it's quite stable. At the end of January we had kind of a dip in the service delivery of it. T M. We brushed this away by (TTM) mid‑/HRA*FRPB, so to say. You also see there is a slight increase in the historic boxes but those were already confirmed to be out of service last year, so those are no new additions to that.

What else has been cooking since then: At RIPE NCC we have a process called IT SC M M, which stands for the IT service capability maturing model, all about service delivery, change and management, it has five levels, currently we deploy up 'til level 2 within RIPE NCC which various bits and parts of the other service level I believe. TTM is part of this since Q 12009. We make monthly reports that go to senior management and we ‑‑ we list the key and specific performance indicators, the key performance indicators are like what was the availability of the services the number of open and closed troubleshooting tickets, and for the specific ones which is like specific for the servers, it's the availability of the greatest number I have showed you in the first slide, so you can ‑‑ reported on a monthly basis and also the speed of data delivery, we aim for a delivery within the one day.

Something else: What we see with roll out of it. T M in getting in more and more places (TTM) and also being used for other sever like DNSMON. We often see users of the service have questions like, why is this bar red and why is this showing lots of loss or lots of delay, and they ask us "can you figure out at the other side what is going on?" And yes, it's please don't shoot the messenger, and the thing is do we actually need additional troubleshooting tools or do we even need some sort of a collaboration platform where you can bring the users of these servers together so they can directly or indirectly ask questions to the end owners, but this all needs discussions with, I hope, can be done in test traffic Working Group, because it needs your input. And that brings me to the questions slides. Are there any?

AUDIENCE SPEAKER: Henk RIPE NCC but speaking as myself this time. We go back to the previous slide, get in touch with each other, the original plan was that this Working Group would be the place to get in touch with each other and we also have two mailing lists, one for everybody ‑‑ the TTD Working Group list for everybody who is interested in measurements in general and the TT host list which is ‑‑ was intended as a list for text‑box hosts coming together amongst each other, all these things still there but admitted very little traffic on it.

SPEAKER: It's /T* might be it's kind of forgotten and people think it's only about discussion about the servers in some sort of Meath at that fashion and not like the day‑to‑day operational aspects of that. OK, to discuss these items on those two lists ‑‑

AUDIENCE SPEAKER: I think if you start with posting it and make people aware that this exists and they can use it. We have already take ten a step forward and if we need something else, we can set it up.

CHAIR: Is somebody from the RIPE NCC going to send a kind of refresh message to the list reminding people that they exist? And encouraging collaboration.

SPEAKER: Can go that way unless of course there is input from the text‑box owners or from test traffic Working Group that another platform is being desired in there, but, yes, this is a good start and we will bring this on the attention of the owners and the users of the service ‑‑ servers and see if this works.

CHAIR: Does anybody have any feelings on that? Is is a mailing list the right form for doing this or do we need something more a collaborative tool based on the website? OK. If anybody has any comments the mailing lists do exist so we can discuss it on that.

RUBEN VAN STAVEREN: Yes.

(Applause)

CHAIR: Next, we have got Andrei Shukov.

RUBEN VAN STAVEREN: One moment, please.

CHAIR: Andrei, we can hear you.

RUBEN VAN STAVEREN: Can you hear us?

CHAIR: You are breaking up a little. Are you still there, Andrei?

RUBEN VAN STAVEREN: Can you hear us?

ANDREI VAN SHUKOV: Yes.

RUBEN VAN STAVEREN: I think we are ready to go, then.

ANDREI VAN SHUKOV: Yes.

RUBEN VAN STAVEREN: If you indicate when to switch slides, I can flip them over here.

ANDREI VAN SHUKOV: Yes. Slides.

RUBEN VAN STAVEREN: I switched the slides.

ANDREI VAN SHUKOV: Can I begin?

CHAIR: Please do, Andrei.

RUBEN VAN STAVEREN: Do it again.

ANDREI VAN SHUKOV: Yes.

CHAIR: Andrei, we have having some problems with the audio. Andrei, can you hear us? Andrei, can you hear us? We are having some problems with the audio. We are having some problems with the audio, Andrei. Could you try switching the the video off at your side, please. I am sorry, we are having ‑‑ as you can see we are having some problems with the audio on this. Would it be a good idea to move on to Tony's presentations and then come back to this? Sorry, Tony, would you be able to step in. Apologies for the problems with the remote participation. We will move on to the next presenter, which is Tony McGregor who is a visiting researcher at the RIPE NCC and he is going to give two talks, first one or doubletree.

TONY McGREGOR: Thank you. I am, as you just heard, visiting the RIPE NCC for five months and the main project I am working on is the locking out the design and what the requirements would be for a large scale active measurement system perhaps in the order of 100,000 probes, at least in the design, and as part of that, the notion of using double tree for optimising traceroute has come up and it was suggested that you might find it interesting to learn a little bit about double tree. It's an area that was presented in a paper a couple of years ago, got nothing do with /TPHE terms of the development of it; I just happen to be looking into it, so I am going to present the idea to you.

I am going to start by teaching you to suck eggs. I just want to start by talking a bit about traceroute and I realise almost all of you probably know about traceroute, but it just gives a starting point to work from and I personally find it frustrating when I go to talks and I don't understand anything, so you will probably understand all of this talk.

So traceroute as, you know, works by sending out packets with limited TTL, usually starting with one and then the packet times out and the node sends back a ICMP TTL expired message and you increment the TTL and you work out effectively what the path is.

Of course it's a little bit more complicated than that, it doesn't really tell you about the nodes, it tells but interfaces, and so, you get back a message saying what interface, usually incoming interface, to the router. Of course it's a bit more complicated, still. In fact, traceroute normally sends modable packets to each hop, 3 is the common case and even that is not really true because you have different paths in each direction and, of course, traceroute finds the forward path it, can't find the backward path, which is obviously important. It's also true that from, the intermediate hops, perhaps from this one here, the path back that the TTL expired packet takes, might have nothing to do with this or the forward or reverse path, so the path back from here to there won't go through F, it doesn't necessarily go through B it, could go somewhere else entirely and this is sometimes in a traceroute you see sometimes that don't make sense. And Ethan I think on his presentation gave a classic example of that, the first few hops, were 75, 80, 95, then 200‑odd milliseconds and back to 90 and so forth and one of the reasons why that happens is because of this reverse path problem. Actually, there is a whole lot more issues with traceroute of course, sometimes you get RFC 1918 addresses because that is what the router interface was configured with. Lots of times you don't get back at all, people might have been disabled somewhere or with a filter for ICMP, you can get false routes that don't exist at all. During ‑‑ just a to mention this, this is two forward baths a load balancer in the middle here and you might start going this way and then the next hop might go in a different direction and you, it appears there is a length from C to G which doesn't exist in reality.

Have you to deal with this issue that you are getting interfaces, not routers, and if that matters to you you have got to figure out with interfaces are all on one router and that is quite tricky to do. Sometimes hops exist that don't ‑ TTL at all and tunnels of different varieties and you may or may not discover things in there.

So, one of these problems ‑‑ one of the problems with traceroute; if you are tracerouting from some sources, more than one, to a large number of destinations, which is what a number of projects do, including TTM, of course, you waste a lot of effort, and this is what double tree is designed to deal with. It's designed to reduce the amount of effort that you waste in probing, so I am going to go through a couple of quick examples. We have two different sources here, I am going to focus on the first one, and two different destinations, obviously a trivial case but you can imagine the case where there is thousands of these things and traceroute, this ‑‑ if you are tracing just from S to these two things, you go out a hop at a time and find that one and go out a hop at a time and find the other one, and the ‑‑ the first hops in this path are probed twice in two different sets of traceroute, one when tracerouting out to D and the other to D 2, and what Doubletree says is well that is a bit of a waste of effort, let's see if we can reduce that and Doubletree keeps, for this part of the redundancy, it keeps a stop set, a local step set so the monitor when its probing it remembers what hops it's seen, so if we are halfway through we have probed out to D so we have already seen, of course, the source at A, B and C and D so put all of those in a stop set. When we start probing, instead of probing from the beginning we pick some point in the middle of the network, perhaps in theory it might be better to sort of start from the absolute destination but you don't know how far away there is, there is another optimisation that traceroute does that would be less effective if you started from the very end, even if you could. And so, you pick a number, somewhere in the middle, and there is some discussion in the paper of how you go about picking that number and you do your first TTL probe out to there, it's gone through these links, but it discover E and you add E to the stop set and then you probe again with one less of the TTL, so now we have probed out to D and you nought into the local stop set and you get to B (put that into) and B was already in the stop set and so you don't need to probe any more because you know what the path is from S 1 to B.

There is also ‑‑ you have got to finish the process, of course, so you start probing upwards from where you started until you get to the destination.

So, in the paper, they do some analysis of how much redundancy is going on and they produce these graphs, these are like box and /KPEUS Kerr type graphs, slightly differently drawn so this is the minimum, the median the ‑‑ the upper /KWAUR tile and maximum up here. And really important thing to notice, that is logarithmic scale and this is how many hops away you are from the source monitor and on this one we are looking at the redundancy, how much there is. In terms of an absolute number, and this experiment they took a topology from CAIDA's, /SK*EUD da this time, and they took 50,000 destinations out of it to reduce the amount of work in simulating and they found there was in the order of 150,000 redundant probes at the beginning of the path, basically /PRET each everything you are doing is redundant and the further away from the beginning of path you go, the larger the median goes which kind of is logical, in fact everything about Doubletree is logical and makes sense and it's obviously just a good idea.

With Doubletree that is reduced dramatically, in the order of 150 redundant probes per hop at the beginning of the network and then dropping off rapidly, as well.

You might wonder why there are any redundant hops at the beginning, probes with Doubletree at the beginning, but of course, you have got to take account of the concurrent nature of this kind of probing, so you don't instantly ‑‑ you don't do one trace and that gets into your stop set and then you do the next one, there is concurrent probes going on and sometimes ‑ /TKURB still end up with some redundant probing but not as much. (You)

So the other half, I have just really told you about half of Doubletree, the other half deals with the fact that you are probing from different sources to the same destinations. And so the same kind of redundancy happens just routed at the other end. So, imagine that we have traced out from source 1 to destination 1 or destination 2 using Doubletree, probably, and now we are going from source 2 out to the destination 2 and of course, there is a common couple of hops and here and we don't really need to keep on retracing those, either. So we build a global stop accept, one that is shared between the monitors and if we were at our initial stage here, in the global stop set, well, we have ‑‑ we are saying that we have seen destination 1 and we have seen A, B and C in that path and destination 2 we have seen A, B, D and E and we start probing again from, if we are going to start from S 1 here, and in this case if we are probing forwards from S 1, as soon as we get to D, in fact, we discover we don't need to go any further because we have traced all that, we have seen and know D on the D 2 so now global stop set and so we stop.

So that is why it's called Doubletree because it looks at the trees for both ends.

The inter monitor redundancy is in the examples that they looked at in the paper, which is for a relatively small number of sources to a large number of destinations, which matches most topology discovery systems today, there is a lot less gain from the inter monitor redundancy, it's not logarithmic this time on the scale and we are only looking in the order of 25 redundant probes at a peak. It doesn't peak at a large number and that is just because some of the paths of course finish, so this might be the end of a certain number of paths at hop whatever that is, 15 or so. So close to the source there is not much redundancy it goes up and drops off as the number of paths and in the order of 25 peaking there, whereas for the median, at least, with Doubletree it peaks at much lower level, around about five.

So that is basically Doubletree. Does anyone ‑‑ has anyone been keeping track of the time?

CHAIR: Given our problems with the previous speaker, I think we have still got plenty of time.

TONY McGREGOR: I don't want to take more of your time than this really warrants. But, let me talk briefly about the limitations of Doubletree and the application that we are going to use for it and then I will got another traceroute technology to talk about, so perhaps I will do that, if there is no worry about the time.

So Doubletree finds fewer nodes, there is some limitations to Doubletree. T finds fewer nodes than repeated trace routes, so what they did in the paper was they just added up how many interfaces were reported by Doubletree and how many interfaces were reported by traceroute and Doubletree finds less because it's not repeatedly probing, and of course the network isn't static; the topology might change during the time of the probing and so you might discover some new probes with traceroute that you wouldn't find with Doubletree there could be load balancing, I am going to talk a bit about that in a moment, and so it's kind of a mixed message as to whether this is a bad thing or not because finding new nodes may actually just confuse the situation rather ‑‑ because something has changed it might be better to get a more static picture of the network, it depends what your motivation for measurement S and the other big issue is in a the global stop set requires communication. It monitors need to tell one another what they have already found and of course, that reduces, to some extent, its effectiveness; how much it reduces it depends on how many monitors you have got and how much redundancy they discover.

So the other project I am going to tell you about, a thing I am working on here as I mentioned at the beginning, is this large scale active measurement system which is called diverse aspect resource, and one of the issues that comes up in there we might have many sources and we might want to investigate just a few destinations because we have found out that there is something about those destinations we want to know, perhaps they are not reachable from everywhere in the Internet and so, in this case, we sort of turning around the current work that is being done with most Internet topology measurement systems and we are going from a large number of sources to a small number of destinations, and it seems that double /TWRAOE could be very effective for reducing (tree) the amount of work that happenings. , you know, you can't just ‑‑ say you had 100,000 probes in the network and you discovered that some people couldn't get to your network and you want to see exactly who, you can't send 100,000 trace routes that that one box you have got in your network obviously because it's going to overwhelm the source box but Doubletree might well be able to reduce that very significantly in its inter monitor ‑‑ interprobe type working.

But on the other side, is this issue of sharing the stop set, which could ‑‑ which could reduce the usefulness of it and so, what I am doing at the moment with Doubletree is I have bit a simulator to just ‑‑ I have just finished this /T* this week ‑ /TKORB study this issue. Basically, I want to find out how effective it is with a large number of sources and small number of destinations and what is the cost of the stop set is and how you can perhaps optimise that.

So the other sort of general traceroute technology that I thought I would just mention just briefly is Paris traceroute, again not my work and the references are there, it's looking at the issue of discovering load balanceers. They cited another study that was done in 2006 that had just 5,000 destination addresses, but out of that 5,000 had reasonably good coverage of the sort of core of the Internet, they said 7 out of 9 one ISPs and figures out of the paper. The important thing is they reckon there were 80 percent of destinations had a load balancer somewhere in their path and this is from their one monitor so it's hardly an exhaustive study that you'd put a great deal of confidence on the number, but it's probably in the ballpark. So load balanceers can be a bit of a problem for tracerouteers. I mentioned before. So imagine wave load balancer at A, somehow dividing traffic between C and B, we go and do traceroute and get to there and here and then, for some reason, and I will come back to what the reasons might be, the load balancer decides to send our next packet out through this other path, so we then, you know, continue perhaps with the same thing and we have discovered this topology that doesn't even exist. We haven't discovered there is a load balancer and we have discovered something which it doesn't exist, what is the point if, we can't discover even a valid path, traceroute falls down.

There are other ways this might work out, in this case we have gone to A and then to C and then to E and then the ‑‑ our path has changed and we have taken this longer one so we get E twice and it looks like we have got a loop in path and we are also get diamonds or ‑‑ a diamond what we would actually want to see here because of the load balancer.

So, it turns out there are really three ways that load balanceers work. They can be random, just any old packet they decide to send on one link or the other. Not many do that because it's going to introduce jitter and perhaps reordering into a stream of packets. So they don't do that /SREP often. Some load balance remembers destination‑based, they look at destination field in the IP packet and all of one destination they will send in one direction and all of another they may send in a different direction.

And destination base is kind of a special case of flow /*EUD based load balancing and flow ID load balancers try to make a decision about or try to keep all packets from one flow together. The definition of a flow for load balancers varies; some of them use the classic five tupple, source and destination port and IP protocol. Others include some TOS data in there. In the case of ICMP packets they often include the code and checksum out of the ICMP packet and that seems a bit odd but I will back in a moment to why that is.

Of course traceroute deliberately varies some of this information. Classic trace /WROUT UDP, the port number increases with each packet that you send out. And it's done so you can ‑‑ it's an easy way of matching a TTL expired packet that comes back because you get the first bites of the packet that expired, you get them back in the TTL expired message. And you can look at the port number that, say that is that one. But of course by varying the port number we are varying the thing that the load balancers is likely to be working on and so traceroute is particularly likely to suffer from getting its packets sent in different directions by the load balancer.

What Paris traceroute tries to do is try to discover why /WR* there is load balancers in the path. It doesn't try to deal with ‑‑ to deal with random load balancers, it just deals with that statisticically it, says tell me what percentage of probability you want to know whether you have found that or not and I will just send enough packets to figure that out. It doesn't deal with destination‑based load balancers in the ‑‑ in the paper they waiver that away, it's just a just a special case of flow based, which it is of course, but in reality it's not actually a technique that can discover destination‑based load balancing but it does deal with flow ID‑load balancing.

So, the /THRAEUBG they do is they create headers so the flow ID remains the same over a whole traceroute, and they can do that for UDP based traceroute for TCP based traceroute. In UDP based traceroute, they vary the checksum so that the whole ‑‑ the whole header stays the same in total, so the ‑‑ so the flow ID at the end of it stays the same because they varied both the chequesum and they have manipulated the payload to make the checks unmatched. For ICMP the check sum remains constant that is included in the packet, in the flow based stuff. I am not explaining this very clearly. The problem they need to solve is how do they ‑‑ if they keep the whole flow ID the same, how do they ‑‑ distinguish the replies for different packets they sent? So for UDP they do that by deliberately segment the check sum to some value which they can recognise when the packets comes back and they need to modify the payload to make it match the ‑‑ otherwise it would be dropped, for ICMP vary the sequence number and the identifier but they must make sure that the checksum remains the same because the checksum is often included in these load balancers. The reason why it's included, it's a little hard to see here, is probably just laziness. If you want top include the source and destination port from a UDP or TCP packet they are just exactly the same path in the packet. If it's an ICMP one that actually has a type and code and checksum in it and that is why they end up including the checksum. The type doesn't change in any packets they send so they don't really sort of say that is included although, logically, it is.

And for TCM P, they have varied the sequence number and that is not included and use half open technique. For their set of 5,000 destinations from the university, they found that 5.3 percent of traceroute paths had loops in them, so they look like this and ‑‑ appeared to look like that as far as traceroute presented them. And 87 percent, a huge majority of them, were caused by per flow load balancing. They found cycles in some, much less common but where they did find, mostly always caused by per flow load balancing and diamonds they found again a lot of those and most of them were caused by per flow load balancing, but not all.

So that is the end of those ‑‑ this particular talk. Do you want to take questions ‑‑ I can have a stab at answering your questions but I am not sure.

CHAIR: Are there any questions that people want to ask about this?

AUDIENCE SPEAKER: Ethan at University of Washington. You might have mentioned something about this the other day, so I think Doubletree sort of starts from this assumption that you can send all the probes in your mostly trying to reduce overhead and I was curious how if you thought at all how that applies in your setting when you have 100,000 probes and you might be trying to /POEB like in the example you gave was a destination that is having some problems at partly reachable, first of all you want to probe fairly quickly because you want to discover the problem and forget what is going on in realtime but then if you start sending 100,000 probes you'll hit ‑‑ either cause complaints or hit rate limiting on ICMP replies so I am wondering if you have thought at all, is there some proprocession step where you get to the Doubletree part where you decide ‑‑ where you decide which probeers you are going to use into the Doubletreeal algorithm and how does that ‑‑ does Doubletree not have to scale to 100,000. I am wondering?

TONY McGREGOR: I have thought about it and I don't know the answers yet. I would really like to have had answers today but didn't get that far. The key problem with probing from a lot of destination toss a few sources, is overwhelming the links close to the destination, right. It doesn't matter quite as much further back in the network that you are sending lots of probes because they are all coming from different places and they just traffic that gets carried. But the closer you get to the destination the more of those probes are going to end up on the same link as you say this thing we have at the end here might be just a small machine on somebody's DSL connection so we obviously can't do that. At one level, at least, it appears that Doubletree could be extremely effective in reducing that, because the first traceroute goes all the way and finds this, but the next one that comes along doesn't have to go over that last link and the more you see and the further back in the network you learn information and so later probes go less and less distance. The other side of this problem is that somehow you have got to communicate this information between the probes and that has a cost associated with it. In terms of pre filtering, well probably you are not going to ask ‑‑ you are probably unlikely to initially, anyway, ask every probe to test to one destination; you might, for example, say take one per autonomous system, to go further than that it seems a bit tricky, actually, as to how you would actually filter it out to smaller number other than perhaps randomly. Does that answer your question?

Ethan: Yes. I am curious to see once you move from simulations into starting to send more probes.

TONY McGREGOR: Keep you informed. Thanks for question.

CHAIR: Thank you. Tony, you have got another presentation. We are going to take Tony's second presentation and try and get Andrei to speak again, and we have got a final presentation from CAIDA.

TONY McGREGOR: So I want to tell awe bit more about (you a) about this design, this thought experiment at this stage that we are carrying on to think about could blue something, with, say, in the order of 100,000 probes, why would you want to do it, what might it do for you, those kinds of things, and as I mentioned at the beginning, I am not really part of RIPE, but in this context I am not really part of the university either so I kind of get to disclaim anybody. It's a bit like being at Guantanamo, don't come under any jurisdiction.

So there are a whole bunch of challenges ‑‑ I want to start by trying to motivate why you want to do this, why is this an important problem and I will start by talking quite broadly about problems in active measure. /TKA* would solve all of these but does address some. I want to start with topology measurement and move on to some other examples.

If you are doing topology measurement you can do it from a small number, say a few hundreds of sources and you can mech our out if you want to to large number of destinations and you don't have to always have control of the destinations that you measure to and this is what /SKAFRPer does and from PlanetLab people have done experiments including Ethan with Hubble.

There is some problems with this. Firstly, the limited perspective is the obvious thing. You don't see from everywhere. The probes that you can probe from usually aren't typical machines in the Internet, either. Many of them are academic sites which are often connected by research and education networks. They generally have fairly large networks and they generally well connected, even if they are not ‑‑ if your probe isn't hosted at a university, it might well be hosted by an ISP and again, well connected.

You ‑‑ when you are probing, you need to probe to some destination but you don't have control of that destination so you don't actually know what is happening there. So if you can't reach it at the moment, it may be because there is never been a machine there because the machine at the moment is down or because part of the network path to it is missing. The network is asymmetric and but you are only likely to discover the directions from your probes out to the destination, so if you wanted to, like I am, for Doubletree, you wanted to sort of build a map of the network so you can then poke your packets in and see how they perform, you only get half of the topology, the outgoing stuff and you have got to assume coming back is likely to be the same even though it's not symmetric. For some experiments it probably doesn't matter; others it will. Because of the small number of probes cycle time is high and typically you can't get behind NATS because the machines won't accept just incoming traffic from nowhere.

Another example is the sort of area that Ethan has been working in with discovering routing failures, and you can see ‑‑ you can discover the failures that are seen by the perspectives that you have but that doesn't necessarily mean you discover them all; you probably won't, and the little picture down here, OK, we have got a source ‑‑ in this case just going to two destinations and, it can measure out to H and to the other H here, but the two Hs talk to one another through a different path and you never saw this one and so if it's broken you have got no way of knowing. If you have a failure close to one of the monitors you can't see anything beyond that and so you potentially miss a lot of failures that way. And the accurate diagnosis of precisely where the failure happens is challenging, the direction of failure is difficult, as again, as Ethan has talked about a couple of days /ARBGS you can get quite a long way by using spoofing but that has quite a lot of limitations to it, it doesn't discover everything and in many cases you can't spoof and likely it will become less and less effective as people build stronger filters.

It's difficult to discover the extent of the failure and as I mentioned, you can't see path asymmetries.

So the big kind of issues here I think are limited perspectives. I mean, at the moment you might get.001 percent of end hosts as sources. That is just a tiny fraction of the network. You get a bit better if you are just interested in autonomous systems but these numbers are very ‑‑ done ballpark, trying to give an idea of the scale that we are looking at. You might get.2 percent of autonomous systems as sources so you miss a lot of things.

You can probe to third party destinations but you don't know about the responsiveness, what workload is going on in that machine or on the last links so that introduces a lot of unknowns into your measurement and of course you can't get behind NATS.

So, what is the DAR thing? (D A R) it's really a question, as I said before, a thought experiment. Could we design and build, maintain and make good use of active measurement system that in the order of 100,000 probes? If we could, what might it look like and what are the key challenges in doing that?

So just to focus a wee bit more on the problem. I have got an example application and again it's the Hubble‑like application, it's what we want is is a notification service that would tell you about reachability events that happen preemptively. So it's going to find this out and automatically send you some information that you have got some reachability problems. The large scale example is things like the YouTube hijack but it could be much lower scale, just your network is failing and in some way and that failure is specific to people in other, it's not a total failure, you only only some people cannot reach your destinations.

So, we can find out quite a lot about this by, from current data, like the RIS data that clicks, BGP tables. But it's mostly useful after the event, partly because of the way it's able to be collected, but more so because you don't know what to look for until the event has happened. The YouTube event, it's very clear and you can see it in the BGP play type movies and so forth; but it's not obvious that you could have picked that up beforehand from routing information, because changes in the network are quite common, even quite large scale changes sometimes. So, the goal is to produce something Hubble‑like with a wide range of vantage sites a lot more leave nodes and a larger number of destinations.

There is lots of other things you might do with this kind of system, as well, including by directional topology and so forth. So I am running out of time so I need to speed up a little.

So, what are the probes going to look ‑‑ what is the thing it will look like? Well, it's obviously going hierarchical, if we have hundreds of thousands of probes you are not ‑‑ well 100,000 probes, you are not going to connect them up to one management system and have it look after them all. So, probes are likely to be ‑‑ so this hierarchy is a starting point, it's a stick in the sand, line in the sand, saying, what is is it likely to be like? It's likely to be hierarchical, likely to be clustered together into controllers and controllers look after their probes, they know something about the resource that the probe has, etc.. and then the controllers are managed by brains ‑‑ of which there is probably relatively small number, and possibly a super brain that oversees the whole thing. As you go sort of down the model, the number of components increases, information flows upwards, the probes are doing the measurement, they go up to the control and the controller may aggregate some of that information and then pass it up to the brain and so forth, up to the super brain.

So, the probes themselves, well they are likely to be either hardware or software. If they are hardware, because we are going ‑‑ want to deploy a lot of these, going to have to be cheap, and fortunately there are a lot of systems out there which are relatively capable and keep. They can be the sort of single board computer type systems, it's a bit hard to see the scale of this, this is sort of slightly larger than significant /REUT packet‑type machine. (Cigarette). Some of them exist in ethernet port type thing. So you probably want something with a few 100 /PHEUG /TKPWEUTS of processor, some flash and RAM and ethernet port on T we also think there should be the possibility of software only probes that are deployed on existing machine. They are likely to change more often than the hardware probes and they are likely to have different performance characteristics.

So, how might this look as over all architect /TAOUFRPLT I need to emphasise, this is very fluid, but at the moment, my thinking is along this sort of line, that the hierarchy that we described is here with one super brain, a relatively small number of brains, less than 16 and then some controllers that are controlling individual probes, so say, less than 100 controllers per brain and 1,000 probes per controller. When a probe comes to life it needs to have some way of figuring out what controller it should talk to, and where to find that controller, and that is managed by a registration server, so the probe goes to a well‑known address of some sort and asks that address or set of addresses, you know, I am a probe, who should talk to for my controller and the registration server can give one or more controllers for it to talk to and the probe can pick between the possibilities. And a similar process happens when controllers and brains come to life, as well. The data itself will need to be stored somewhere and presented to users through perhaps a web or some other kind of service and that happens on presentation server which can also be responsible for getting new requests for measurements which then get fed into the super brain or the brains.

So I have kind of talked about the probes already, they can be tokens of software, perform the low level measurements, things like ping trace routes, send a packet. On a boot request they find a controller through the registration server. The software obviously needs to be remotely upgradeable and the resources is probably the most important point, will be limited. That maybe because of the hardware, or it may be because the user who has deployed the probe only wants to give you a certain amount of resource.

In terms of stability, the probes aren't expected to be highly stable. They will be coming and going, and in fact, it's expected that the set of probes that is a/HR* available will be always be in flux with that large number of probes.

The controller manages a set of probes that keep tracks of what probes it has available and it can answer questions about what resources each probe has, things like where is the probe located? What IP does it have? Perhaps what autonomous system it's in? How much bandwidth does it ahave available at the moment, how much memory has it got for storing results and the controller can accept work requests from the brain and aggregate, perhaps, the results. So with a Hubble‑type system for example, you might not be terribly interested in positive reachability events and aggregate those up to a statistic but non‑reachability events you may pass up all of those and the controller can take account of that.

It's got medium reliability, it shouldn't go down, but if it does, then the operation of all the other controllers in the rest of the system should just continue on without a problem.

The brain manage asset of controllers and in some sense it implements a measurement application, and so, one measurement application may involve lots of low level tests and the brain is keeping control of this. It knows or:discover what resources each of its controllers have and then allocate work to the controllers. The brain has to be pretty reliable. If it fails, then the particular measurement that it's looking after will fail.

If there is a super brain, it has sort of overall supervision of the brains and can be involved in allocating work between the brains to keep an even load between them and also discovering resources where only some brains may have them. If you want particular autonomous system for example to be part of your measurement, that may only be available through one controller, through one brain, and so the super brain can find that out for you and help to you allocate the measurement to an appropriate set of brains.

There is only ever going to be one of these and it should be hardened against failure, although if it fails, that shouldn't stop the rest of the system, so the brains themselves can continue on and the existing measurements that are happening will all continue on, you just might not be able to start perhaps a new one.

Presentation server as I said it, interfaces with users and presents data and there might be ‑‑ to void /PRO* /SRAOEUD enough resource and add stability.

Registration servers, very simple, the main I think that it has is it knows where the example resource are and wean new resource like a new probe comes along, it just sends a message to the registration server and it replies with where to find the next level in the hierarchy.

So, a major challenge that we face is this one, in fact, that we mentioned in the last talk, it's not obvious how you design measurements that have a very large number of probes. You can't, for example, do full mesh probing, probably. If you have got 100,000 probes all ping to go another 100,000, all the other set of the 100,000 probes, it's going to be too much capacity for the kinds of ‑‑ many of the kinds of links that users, some users anyway, are going to be prepared to give you.

So we are looking at optimised techniques and one of them is to use traceroute as I mentioned, and that is the focus of the work that we are doing at the moment.

I think I will leave it there since I am at the end of my time.

CHAIR: Thank you very much, Tony.

(Applause)

CHAIR: I see we have one person at the mike already. Mosen: I have a very strange question: Since the very first slide on the architecture I have been thinking of Botnets. I don't know why. But were you invited at least for part of it from the Botnet architecture?

SPEAKER: It's not such a strange question and it is one that we have actually not seriously thought of but played with in our thinking in the lab, and, you know, I guess it's not the idea of taking over a Botnet and doing something who will some with it is not a new idea, it's probably not somewhere you really want to go. You had a you had a that was my provocative suggestion: Why don't hire Botnet?

SPEAKER: That is because we are good guys, that is why.

AUDIENCE SPEAKER: /TPOEPBL it's cheaper. (Only if.)

Daniel: Slightly responsible for instigateing this kind of work. Obviously with played with this, we had a good laugh but I don't think a RIPE NCC Botnet would just cut it. But more seriously, actually, the next worst nightmare is that actually you build such a thing and it's taken, right, it's owned, and that is why we are really investigating these kind of hardware probes which at the first instance seem to be limiting because you cannot update them that much, they are very, you know, limited in capability but that is actually by design. I would be very much ‑‑ sleep much better if we /HOEPBL those in the network because they are not so interesting in terms of being owned, because they can't do that much, and that is one of the reasons why we are thinking about hardware probes, not so much because we like developing hardware but it's really the thing is like if you have a couple of 10,000 of them out there and you are probably for them in some way, it's very nice to have them not be interesting to be owned.

AUDIENCE SPEAKER: Just one quick answer, come on Daniel: Are you meaning that if you have hardware probes that means can you not update them? There are too many /KHA*PTer box out there. If you half top password you can upload the firm ‑‑ Daniel: If are seesier targets I sleep well.

Ethan: You have mentioned having Heather genius probes with different capabilities. I was curious if you were thinking of trying to recruit existing probes like dimes or I plain or anything like that?

TONY McGREGOR: At the moment, our thinking is along the lines of we need to be able to /SPAOR diversity of probes and there is a whole bunch of reasons why that is the case. (Support a). Sometimes, there will only be software and sometimes hardware. Some of the controllers, we imagine, might be sponsored or owned by a particular organisation, perhaps an ISP, and they may want more powerful probes perhaps, prepared to deploy rack mounted PCs, so and get some extra measurement capabilities because of that. The answer to your question is sort of, yes, sort of, but not really in a detailed way, other than the fact that we do need to support a reasonably wide diversity of probes. I think Daniel wants to add to the answer.

Daniel: No, I don't want to add to the answer. I just wanted to point out what the idea behind the DAR title which seems to be somewhat contrived but we were thinking actually to have more of these things and as a work play on the radar idea so we might have a RIPE DAR, K DAR, whatsoever DAR, that is why we came up with diverse aspect resource.

CHAIR: Thank you. We are going to give Andrei a try now. Thanks very much, Tony. Unfortunately, the Internet seems to have defeated us so we are going to try and do it by phone and then we are going to have Kasy to finish with.

(Via phone:

ANDREI VAN SHUKOV: I am Andrei /SHUBG ‑‑ I would like to make a presentation the available bandwidth ‑‑ Mick he will ‑‑ ‑‑ measurement today it will be (inaudible)

CHAIR: Sorry about that, it looks like we are going to have to ‑‑ sorry about that, it looks like we are going to have to postpone Andre's talk possibly to the next meeting. I think to ‑‑ we do have a further presentation in the Working Group coming from Kasy from CAIDA, so if I could invite her up. We are going to start before the slides.

Kasy: I am examining to talk for a few minutes because I happen to be in town, I was here Tuesday for real, sorry if you were trying to find me. Kate da has been doing in active measurement how many people have heard of /A*RBG project? Skidder? Only about twice as many. Skidder was our ten year running more or less traceroute project kind of a smarter ‑‑ but not much more through about 30 machines or notly around the world and probing over a million different IP addresses. In the first version which we call skidder overloading to mean a lot of different things just not project, infrastructure, software, hardware, data, the maps, in the first version of the project we were trying to limit ourselves to IP address that is would not theoretically be in a position to object to a probe, because we were worried about setting off pagers and upsetting people and this was actually back in the early 90s, mid‑, so there wasn't a whole lot of attention to this yet. But we as such we limited our addressing list, destination list to web servers /ORS DNS server we found another way were on the Internet supposedly providing services. And therefore, shouldn't to be a ping packet or ICMP packet or two. In this version of this active measurement we have changed quite a few things and that is one of the big things we change is the way we picked destination probes so instead of trying to go out of our way to make sure we have a live active current list of responding destinations, which is impossible to keep current, and we try to keep it current for a couple of years and we let the list go, we didn't add anything to do it or take away except when IP addresses stopped responding, I think it was 10 percent, I can't remember if it was a month or a year but just a systemic destination of any given destination IP list you have you are trying to probe on the Internet, as things disappear behind firewalls, start responding, go off the net, what have you, so the current version which we are calling the Platform Arc, Archipelago, ARC for short. We are choosing a different approach through gathering destinations, so this is a long slide set that will give you a thorough detail on update of this project and I won't go all of it, I will go through it quickly. And then each of these slides may point to different aspects of the project you may want to investigate more carefully or I can answer questions on it at the end, to give you some high level motivation of what we are trying to do and where we have gotten so far.

So next generation active measurement infrastructure after skidder we call it full production as of September 12th 2007 although we are still adding between one and two boxes per month. This is being funded by US government agencies, two of them National Science Foundation and Department of Homeland and Security. What is the focus? What are we trying to do in ARC that we didn't do in skidder. Skid youer did one thing, did traceroute and it did it fairly stupidly, it didn't use Doubletree, Paris, it just sent out ‑‑ it didn't try figure out it had already probe stuff and not probe it again. It didn't divide work up into multiple teams. Every box sent the same traceroute to every destination.

So, what we are trying do with ARC is enable a lot of different types of measurements besides just topology measurements. Although, even topology measurement there is a whole host of things you can do there that isn't just about getting the path per se but an nations about the path including bandwidth and latency and customer semantics. What we are trying to do enable not only topology measurements but all different types and build a platform, we think of is kind of operating system for measurement itself so that if a research comes along or scientist and wants to do an experiment on the global Internet or at least a big serious chunk of the macroscopic Internet they are bring that to ARC and not have to worry about building an actual platform to do it with which in our experience takes up most of the time and you don't end up having much time to do re/SEFRPBLT lower the barrier for other researchers including ourselves, to participate in measurement broad scale measurement and in the process of doing this. Our approach is to raise the level of abtraction for people whon't don't want to learn about the low level details of infrastructure measurement.

If it wasn't obvious, we look who the of inspiration from other projects that have tried to do pieces of this and we are trying to put them together into a global system.

So what is the architectural glue that allows this to happen? One, we have instead of each node essentially acting on its own we have on each ARC node part of this coordinated facility and you can take advantage of distributed measurements nodes in ways you couldn't with skidder. You can set up teams to focus on a certain measurement assignment you want them to do and another team work on something else, or you can divide the destination list into subsets and divide and conquer, as it were, and you can see Doubletree as well.

Build on the work of others. Composed of measurement nodes located in various networks worldwide, thank you very much in you are hosting an ARC box, almost half in Europe and many of these were hosting skidder boxes or some ‑‑ very few about a couple of old LANNer boxes. Please contact if you want to host an ARC box. We use Tupple space, which is architectural concept, took from other folks which allows distributed shared memory combined with easy to use API to request a measurement from the system. It's written in /RAO*UBy young is the designer and implementer of this and he is tolly in love with Ruby, if a Ruby fan definitely contact him.

So here is monitors are out there, essentially servers located at CAIDA which brings data back but the monitors can act independently. We provide some centralisation for bringing data back to analyse it.

Where are the monitors? We have about 33 that might ablittle bit hire us because these are 3 months old, I don't think it is, might be 35 across 22 countries. Google map, you can go to the website and found out where the nodes are now. We try to keep it up to date. The kinds of measurements we are doing today, six different big headings here, the top one we call IPv4 router /24 topology, this is essentially the original type of trace route we were doing with skidder, the reason we call it this now is that whereas skidder I mentioned earlier we tried to make sure we have a IP list that is pre vetted to be responding. When we are doing this topology measurement with ARC don't do that. We pick one IPv address in entire IPv routed /SPAEUFPLTS we take route vice or RIPE ‑‑ chunk that /TPHAOUP every announced prefix and one IP from every 24 and it's dynamic so every knew polling cycle we pick a new randomly selected IP within each routed 24 and then the data set we end up making aavailable is the results of this probing from one of many ARC monitors to each /24.

I will go through the rest of these as we ‑‑ I have a slide on each of these, at least one, but the second one is convert the IP addresses into ASs, using BGP routing tables, it shouldn't be new, so convert to AS links ‑‑ IP links to AS links. Number 3 IPv6 topology we never did this before because we didn't have capable monitors and we still don't have many, we have about 6 out of 33.

But we did do a map this year and I have copies of this somewhere that I can bring you on the IPv6 topology as we are able to observe it. You might be thinking how are you picking your destination list because you can't possibly use the same approach that you used in IPv4. That is true. So we do something more, we go download from the registries where they have allocated IPv6 addresses and pick one randomly. /TPHOZ as thorough or as bulletproof a methodology. And DNS, two DNS data certificate, one is we ‑‑ for every IP address we probe in the course of this traceroute like probeing that we do, we resolve it to a DNS name and then we store any DNS names that resolve, not just the ultimate probed destination but every intermediate hop we find along the way. We make that list available to people. And the fifth one DNS query/response, in the process of get that /RES loose, when we do reverse look up, we find name servers and we store the entire trance ah for from one DNS server to the other until we get the authoritative resolution for this IP address and if folks are interested they can get that data too and large thing is spoofer project. I will spend the whole lied on that.

An example of IPv4 routed /24 topology. I mentioned earlier what it was. I should make a big shout out to ‑‑ Tony McGregor was the advisor for Matthew lucky that wrote the code which is the fundamental probing code for the topology project. Now we are trying to separate, I should have said this at the beginning the infrastructure that is doing ‑‑ that is supporting different types of measurements including topology but not limited to topology measurements, could even conceivably be doing passive measurements, we haven't but it's not out of the question. We are trying to separate the infrastructure, the platform, the operating system for doing the measurements with ‑‑ separate it from the measurements itself, so the platform is ARC and the nodes in ARC are ARC nodes and they can be divide up into seems or whatever is needed for specific type of measurements and the application that sits on top of ARC can be many and this is one, the IPv4 topology probing so in this case the application that is doing the probing is called scamper, that is the follow on to skidder, if you think that have as just the probing software which few people did but we did. Because we overloaded the term. So Matthew wrote this code called scamper and it's using ICMP Paris traceroute. That is a result of us doing a thorough experiment on which have the different probing methods, ICMP, Paris, UDP, Paris, TCP were going to capture the most information possible. We spitted that as IMC paper last year and I think that might have also been part of Matthew's thesis, and so then the result ‑‑ answer was ICMP Paris and that is what we are now using operationally. As I mentioned earlier we do group the monitors into teams, divide up the measurement among various teams, we have 3 teams active right now. This from September '07 to March 09 of how much traceroute data we got and, so there is 2 .5 billion trace routes represented there, the ARC monitors on the right, and I don't know what the number ‑‑ the vertical bars where you see gaps in the data is software failure, the horizontal bars are hardware failure. There is one horizontal bar where you saw a gap and little green meaning real data again is is a power supply died and we put one back finally and it died immediately so it wasn't really the power supply.

And as I mentioned earlier, the next data set maps these, we also compare to other toll on data is south there, the dimes ‑‑ route views BGP data, we only compare this to dimes, I don't think we did I plain, Ethan may be able to comment on that. We gave you some basic statistics of the data set. So these statistics are going to matter later, like average neighbour degree and clustering, as we try to decide, here is is a big one, what is the appropriate window to use when you are trying to build a match the Internet, do you want two weeks of topology data, six weeks, and the reason this matter is a very unfortunate thing happens, even the best scientist out there, at least they are not talking about this, there seems to be accumulation of links that you get if you just probe, even the same or variety or changing list of IP addresses, you seem to have a continual accumulation of links between ASs, in the back of your head thinks that makes sense, one link one day and other another day. That is true and that may completely explain it, but this seems to be happening no matter how you look at the data and over what interval of time you ‑‑ it never levels off. And so, one of the things we ‑‑ as we are trying figure out, what is the right level of, the window at /TWOEU stop and say OK I have two weeks of data this is my map of the Internet I am going to use today and these three statistics on the right are how we compare different intervals to figure out at what point does mean clustering change and you have kind of a knee and the curve based on the window you are observing this. This is way into topology research and trying to figure out how to get the best map. This is accumulating all 3 different, top two dimes and ARC means traceroute data convert to go AS using BGP data and bottom one is BGP data straight and one month accumulation in both cases, CCDF of no degree, cumulative function of no degree. And the next one is average neighbour degree so this means if the node degree of a given node in the observed data set is on X aches for nodes that have degree on the X, what is the average degree of the node's neighbours on the Y? This turns tout matter in terms of the correlation of degrees with their neighbours which is a big way of modelling and reproducing data sets with similar characteristics to another. So if you want to do a simulation of something that is Internet‑like, the degree co‑relations between node and neighbours matters a lot. You want to reproduce that. This is clustering, the last metric in the table: You don't see a lot of convergence here, there is a lot of mystery unresolved on why a lot of clustering values here.

And this is what I mentioned earlier, there seems to be a linear accumulation of AS links no matter how you look at it, even with fixed traceroute sources and destination list and you can see some ‑‑ the average degree of the graph which we will call denseification seems to increase no matter how long you look at it.

I want to get to the spoofer thing, so I will skip that. This is how do you determine a natural time period, I have mentioned that before. I don't know what the punch line is here.

Has anybody got Spam on how to increase the size of your AS graph? /KWR*UPBG got this Spam. This is just showing again the fact the links seem to accumulate, nodes give some indication of levelling /AUFPLT

I want to spend a time on, if you are interested in this mystery, come talk to me off line I can give you a PhD thesis to do, not to read, to do.

The 6 topology here 3 v6 nodes in US and 3 in Europe. I think that is probably still true. I think we didn't even get our seventh one in the last three months and we are doing Paris traceroute to every prefix that we can find. So we are ‑‑ it sounds to me because of the router in here we are using ‑‑ in addition to the registry assignments. And this is some stats we get on v6 topology from December of last year to February of this year, right before the workshop that we had, and again, this is comparing v6 to 4. I don't think there is much to see in here scientifically because I don't think there is enough V 206 make it statistically significant, if that were a lot of data, you would be that is fundamentally different graph. It's not so you can't make these claims.

DNS names I mentioned, using in‑house look up service so you can do millions of addresses per day, we had 2 million ‑‑ I am going to skip that.

Alias resolution how do you figure out if you have a million IP addresses which got by tracerouter, figuring out which are the same action is tricky in a different way so it doesn't even help if you figured out which ones are the same so we are working on an IMC paper which will be finished Monday I hope and I am not going to talk about it now but at the next meeting on how we are collapsing ‑‑ single routers and the punch line is we are using a lot of different techniques and trying to integrate them similar to the ARK project itself to get the (K)

Spoofer is my favourite thing that ARK is doing. Has anyone heard of the spoofer ‑‑ as many people as heard of ARK, probably the same people. Spoofer is using ARK. Sewer is is a project try to figure out how much spoofing is aloud on the Internet. That is a tough question to answer, if you have going too far node on each AS or prefix depending on what type of granularity you are testing it, he tried it anyway without a node on each AS in Internet but using/dot instead, a client software that would probe MIT with various types of addressing including /SPAOFD address and if it got he checked your off as your network is able to spoof and he put it on a slash dot, let a few people download the software and posted pie charts of what percentage of AS and he ex trapped from what percentage of ASs he got numbers from at all to what it would be if he assumed that was the same level of spoofing in the whole Internet. The problem is there are many, one of them is you are only testing one path to /PHEUFPLT I Fr. A given AS. You have got a slash dot buy /ARBGS people who download your tool are going to bias your results to whatever that pop /HRAEUFPLGTS we are trying to some address some of that. I know RIPE thinks about TTM stuff in general and we don't have a group per se, maybe CAIDA is the closest thing to it, that is great application for an increasingly relevant and interesting to governments application for active measurement and broad scale is network hygiene. So, ARK enables spoofer to do instead of Rob asking these client software to spoof to MIT we are allowing him the ARK nodes by permission, you got a letter if this was OK to do with your ARK node, although the ARK nodes themselves are not engaging in spoofing, the ARK nodes in in this he can permit are receiving the spoofed packets that myth used to receive, to all of the ARK nodes and that is only 33 right now but we are prototyping the idea that could you scale this up so could you probe a lot more topology and get a lot more information about filtering that is happening on the network, both good and bad, the recent questions I have got from ARIN is this /TKPWO*E gone filtering issue, if you hand out new IPv4 address or old, it would be nice to figure out what is filtering that and it's not going to be as you useful. So this issue of filtering and understanding network hygiene I think is a /PWRAEULiant application of active measurement and underutilised. Again that work is in process, IMC paper this week. One of the reasons I haven't been here. There will be good technical results to show you by next week. Next time I will be doing it is is a couple of months from now.

And that is all I have got. Last thing, TTM probably knows this, in order to, both for our own he hadification and in order to innocent folks to deploy these nodes, I think TTM has similar frontal web page, you get these nice views of your ‑‑ RTT CCDF have path link etc.. if you go to this web side, you will see examples of these from every ARK node and we are still in the process of aggregate statistics as seen from all of the arc nodes.

Daniel: You made me really curious. To my simple mind, the whole spoofing thing is actually something that is prevented usually very close to the source of the spoofed packets

SPEAKER: Indeed.

Daniel: And it's mainly a network hygiene effort of the local ISP or organisation that actually runs these things, so I am really curious on what, having several destinations, what variance you see by having several destinations you are close to the source anyway or anyway

SPEAKER: I would lien you are right, even on our early results on this paper 80 percent of the spoofing happens one hop from the filter and certainly within the same AS, 85, 90 percent happens with the /A*FPLTS you might be right. It may be not necessary but it's something we need to measure to test.

Daniel: Fine. I was curious about the other ten percent because that is ‑‑

SPEAKER: Yes, we will give you more data next week on that.

Daniel: The suspense.

CHAIR: We have quite a bit into the coffee break.

Ethan: So I really like this idea of abstracting or away the measurement details so people can just focus on the experiment they actually want to run and /SOEUD two questions about that: If you have any idea if people use script route and if not, why not?

SPEAKER: You mean ‑‑

AUDIENCE SPEAKER: Does have a lot of people using that.

SPEAKER: When you say you mean initiation offer Scripto on PlanetLab?

AUDIENCE SPEAKER: Yes.

SPEAKER: I have no no idea. Scripto has a lot of great stuff in it, he was at university pre him, when he wrote script route to, do a peeves this, to do abtraction to enable people to write simple /SKREUPLTS as use PlanetLab as platform to deploy them and the problems that we heard whenever we tried to have students work with PlanetLab was problem with node itself, getting access to time stamp or issue of shared facilities so it ‑‑ didn't have a safe platform to grow itself, you know, and I think Neil probably had a bunch of other things to do. I can't say one way or the other what happened.

AUDIENCE SPEAKER: My next question was whether you thought at all about deploying maybe a stripped down of ARK on the planet so people who want this can get more nodes.

SPEAKER: I would love it if somebody did that, we don't have the bodies for it. We are funded under a contract, US funding has shifted a little, may change back, we are funded to do some very specific stuff, to get ‑‑ situational awareness, information protection type stuff which means I don't have as many resource to spend on PlanetLab. One of the things we are go going to try and make this code available. It may be the case that there is things you find are useful out of of that you want to deploy into a different type of architect /TAOUFRPLT /TPHAOEPT, the Tupple space itself for doing the coordination between nodes should be available this year by iBGP so hopefully you will build one.

CHAIR: I think that is all we have got time for, actually. Thanks very much, we have one more agenda item, any other business. Is there anything anybody wants to raise? OK. Only remains for me to thank all our speakers, Kasy, Tony, Ruben.

(Applause)

Thank Fergal for taking the minutes, the stenographer and our audio engineers and we will see you all in Lisbon, hopefully. Thank you.