1 st PlanetLab Asia Workshop September 17 th -18 th 2004 Yonsei University, Seoul, Korea Friday September 17 th, 1.30 – 2.30 pm –Welcome Greetings, Young-Yong Kim (Yonsei Univ.) –Opening Remarks, Timothy Roscoe (Intel Research Berkeley) –“PlanetLab Expansion in China,” Rob Knauerhase (Intel Labs, PlanetLab SRP) –“CERNet Research and PlanetLab,” Tao He (Tsinghua Univ.) –“PlanetLab v.3,” Steve Muir (PlanetLab) Friday September 17 th, 3:00 – 4:30 pm –“PHI: An information plane for the Internet,” Timothy Roscoe (Intel Research Berkeley) –“Volunteer-based Monitoring System,” Min Gyung Kang (KAIST) –“Happy Packets to You!” Jun Li (U. of Oregon) Friday September 17 th, 5:30pm –Workshop Dinner (within walking distance, to be announced) Saturday 18 th, 9:00 – 10:30 am –“Overview of Co  projects,” Kyoung Soo Park (Princeton Univ.) –“Planetary-Scale Event Propagation and Routing,” Rob Knauerhase (Intel Labs, PlanetLab SRP) Saturday 18 th, 11:00 – 12:30 am –Panel Session / Questions and Answers –Closing Remarks, Sue Moon (KAIST)

In the Q&A session, we’ll ask everyone to answer the following questions: If you are new to PlanetLab: –What do you think is the value of PlanetLab? –What do you think it is useful for? –What’s your biggest question about PlanetLab? If you have used PlanetLab: –What is the best thing about PlanetLab? –What is the worst thing?

Answers… Best thing: being able to access lots of widely distributed nodes Worst thing: no warning of outages / shutdowns (particularly right at project deadlines!) Why did we shut PlanetLab down when it was compromised? [at least half the nodes were port scanning other sites, network admins would have removed PlanetLab]. What class projects are students doing on PlanetLab? Good platform for class projects: students like a real environment (vs. e.g. Emulab) for protocol studies. Not need to create emulated topologies. PlanetLab has realistic (but not repeatable) environment. Exciting to run all over the world Planning student projects about overlay networks. It’s a good thing that nodes just disappear – local test beds don’t do this, PlanetLab teaches students that real world problems occur. Worst thing: floppy disk seem to cause lots of problems on reboot (often disk gets corrupted). Installation procedure is too long – too many files to download, ~5hours install is way too log. OS is only going to get bigger (currently ~4-500MB or something) In the past, overlays have shown bad performance, but trials of overlays nowadays is good because bandwidth is more available. Operators complain that machines receive lots of small packets => DDOS attack. Like to evaluate algorithms in addition to simulation results. PlanetLab is like an overlay – everyone can see every node (different from physical Internet). If we develop new technology on an overlay, not clear that we can translate this to a physical network. How can we bridge this gap? Overlays overlook physical structures in the network. Research should look at both at once. PlanetLab seems to be integration between P2P and Grid (e.g. use of DHTs, CPU sharing, etc.) Is this the case? [You can do P2P and/or Grid work on PlanetLab – PlanetLab is more a building block] How does PlanetLab deal with Firewalls? Does it automatically open holes in Firewalls? [no – expectation that PlanetLab is outside the firewalls] Think a lot of companies use firewalls/IDS – this could be an obstacle to expansion of PlanetLab. Best thing: it’s the only way to experiment at global scale for some researchers/students Worst thing: sudden outages, it is hard to write fault-tolerant applications Currently used for experimenting academically, mainly. What’s the future target for more commercial work on PlanetLab? Is there a way to force sites to keep nodes running? How can we get sites to manage nodes well? Aim to know: what can I do by using PlanetLab? Is PlanetLab aiming at a more supported infrastructure service (production quality)? Best thing: the community (projects building on other projects, encouraging collaboration, reuse of techniques, code, know-how, support. Worst thing: Overall the state of resource management: too coarse, how do we add more CPU/bandwidth, not very flexible Another bad thing: slice creation is very confusing when it fails (e.g. I asked for 50 nodes, got 30). Asynchronous nature is good technically but very confusing. Gives impression of lower reliability. Don’t let people get discouraged when not all nodes appear.