RIPE 58

• content to the Chair of the Working Group.
• format to webmaster@ripe.net.

Test Traffic Working Group
RIPE 58, Amsterdam
Friday, 8 May, 09:00-10:30
St. John Room
Scribe: Fergal Cunningham, RIPE NCC
Jabber: Henk Uiterwaal, RIPE NCC

A. Administrative Matters
Co-Chair of the Test Traffic Working Group, Ian Meikle, welcomed attendees and opened the session. Ian said that for recent sessions, the agenda has been a bit light. He said that you do not have to be using TTM to present and the chairs would like to encourage people to present on Internet measurement. He asked for wider scope on the agenda in future.

The minutes from RIPE 57 were approved.

B. TTM Status Update from the RIPE NCC
Ruben van Staveren
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/van_Staveren-TTM_status_update.pdf

Ruben gave a TTM update for the period Q4 2008 – Q2 2009.

Ruben concluded his presentation by asking for users of the TTM platform to collaborate, in the Test Traffic Working Group.

Henk Uiterwaal (RIPE NCC), speaking in a personal capacity, said there were already two mailing lists designed to increase collaboration: the TT Working Group list for those interested in measurements in general and the TT host list for test-box hosts who want to collaborate with each other. He said there has been little traffic on either list.

Ruben said it might be the case that the lists have been forgotten and people don't discuss day-to-day operational issues on the lists, even though they are welcome to do that.

Henk said if you start by making people aware of the lists and that they can use them it would be a good idea. He said if the working group needs different means of collaboration then that can be set up too.

Ian asked if people felt the mailing list was the right means of seeking input. He asked if someone from the RIPE NCC would send a refresher message to the lists to remind people that they exist.

Ruben agreed that it would be a good start to bring the lists to the attention of the users of the service to see if this works.

Ian said that if anyone had ideas on this area or if they felt there should be a more collaborative tool based on the website then they should send their comments to the mailing list.

C. Measuring Bandwidth
Andrei Shukov
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/available-bandwidth.pdf

Andrei intended to give his presentation via audio link but this was not possible due to technical problems. Co-Chair Ian Meikle said he hoped
Andrei would instead be able give his presentation at RIPE 59. The slides are included above.

D. Doubletree
Tony McGregor
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/dt.pdf

Tony, a visiting researcher at the RIPE NCC, gave a brief introduction of Doubletree, an optimisation technique for systems that have multiple
probes probing to multiple destinations. He said the technique (which is not Tony's work) is presented in:
http://www-rp.lip6.fr/site_npa/site_rp/_publications/689-Doubletree-DC.pdf

Tony concluded his presentation and asked for questions.

Ethan Katz-Bassett, University of Washington, said Doubletree starts from the assumption that you can send all the probes in trying to reduce overhead and he wondered how that applies when there are 100,000 probes trying to reach a destination that is at least partly unreachable. He said first you want to probe quickly to determine the problem but if you start sending 100,000 probes you may get complaints or hit rate limiting on ICMP replies. He asked if Doubletree has to scale to 100,000.

Tony said he had thought about this but does not have the answers yet. He said the problem with probing from a lot of destinations is overwhelming the links close to the destination. He said it doesn't matter further back in the network because the probes are coming from a lot of different sources and they are just carried as traffic, but the closer you get to the destination the more probes are going to end up on the same link. He said Doubletree may reduce this because the first traceroute goes all the way but the next one does not have to cover that link, so later probes go less far and you learn information further back in the network. He said another problem is that you have to communicate the information between the probes and this has a cost associated with it.

Ethan said he was curious to see what would happen once Tony moved from simulations to sending probes, and Tony agreed to keep him informed.

E. Diverse Aspect Resource
Tony McGregor
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/dar.pdf

Tony also gave a presentation on Diverse Aspect Resource (DAR), which is a project to investigate the feasibility of building an active measurement system with the ability to support in the order of 100,000 nodes. The probes are expected to be small (cheap) "token" computers.

Tony concluded his presentation and asked for questions.

An attendee said that from the very first slide he had been thinking about botnet architecture, and he asked Tony if this had crossed his mind at all.

Tony said this was something that had crossed his mind, but he said he doesn't hire botnets.

Daniel Karrenberg, RIPE NCC, said he was partly responsible for instigating this work and he thought about it but he didn't think a RIPE NCC botnet would be good. He said it would be a nightmare to build such a thing and then it's taken and owned, and he said this is why they were investigating this type of hardware probe that seem to be limiting because you cannot update them that much, although this limitation in capability is by design. He said they were thinking about hardware probes, not so much because they like developing hardware but if you have 10,000 of them out there it is good not to have them be interesting to be owned.

Ethan Katz-Bassett, University of Washington, asked Tony if he was considering recruiting existing probes with different capabilities.

Tony said the current line of thinking was to try be able to support diversity of probes, and there are a number of reasons for that. He said sometimes there would only be software and sometimes only hardware. He said some of the controllers may be sponsored or owned by organisations, and they might want more powerful probes and be prepared to deploy rack-mounted PCs. So the answer was yes but not in a detailed way, other than the fact that they wanted to support a fairly wide diversity of probes.

Daniel explained that the name DAR came out of a play on the RADAR idea so there would be a RIPE DAR or something like that.

F. Diverse Aspect Resource
KC Klaffy
http://www.caida.org/publications/presentations/2009/aims_ark_update/

kc gave a presentation from CAIDA on its Archipelago (Ark) active measurement infrastructure, which is an evolution of the skitter infrastructure.

kc concluded her presentation and asked if there were any questions.

Daniel Karrenberg, RIPE NCC, said that spoofing is something that is prevented close to the source of the spoofed packets and it's a network hygiene effort on the part of the ISP or organisation that runs these things. He asked what variance the presenter saw in having several destinations close to the source.

kc said early results showed that 80% of the spoofing happens one hop from the filter and certainly within the same AS Number. She said it's something that needs to be measured to test.

Daniel said he was interested in the other 10% or so, and K.C. said more data on this would be available at a later date.

Ethan Katz-Bassett, University of Washington, said he liked the idea of abstracting away the measurement details so people could focus on the experiment they wanted to run. He asked if people use scriptroute and if not then why not.

kc confirmed that this was the instantiation of scriptroute on PlanetLab but said she did not know at this time. She said the problem she saw when trying to have students work with PlanetLab was problems with the node itself. She said it's possible that scriptroute just didn't have a safe platform to grow itself but she couldn't really say this for sure.

Ethan asked if kc had thought about deploying a stripped down version of Ark on the PlanetLab node so people who wanted this abstraction could get more nodes.

kc said she would love to do this but does not have the resources at the moment. She said she hoped to be able to make the code available.

Z. A.O.B.

There was no other business and Ian concluded the session at 10:45.