Experiment Design on PlanetLab

Document Sample
Experiment Design on PlanetLab Powered By Docstoc
					Experiment Design on PlanetLab
    Or, Why Running on PlanetLab
     Shows (and Requires) Skill

              Neil Spring
• Limited resources and high demand
  discourage waste.
• Diverse resources and varying demand
  make performance less predictable.
• PlanetLab is part of the real world.
• Seek guidance, best practices.

              Neil Spring; BCnet 2007    2
                  PlanetLab Panel
   Three Experiment Types
1. The Service
  – Allow others to contact PlanetLab
2. The Overlay
  – Forward packets among PlanetLab nodes
3. The Internet Measurement
  – Send probe packets to other machines

                 Neil Spring; BCnet 2007   3
                     PlanetLab Panel
       Resources are Limited
•   Disk
•   Processing
•   Memory
•   Network bandwidth
•   Disk bandwidth
•   Uptime
•   Sysadmin time

                Neil Spring; BCnet 2007   4
                    PlanetLab Panel
              Using Little Disk
• Minimal packages installed by default
      – No compilers, no Ruby, no Java, no strace,
          no debugger.
• Slices that aren’t renewed                   expire.
      – Slices are deleted completely.
• I     nstall what you need yourself.
      – Use yum, stork, rsync, scp, tar.

                     Neil Spring; BCnet 2007             5
                         PlanetLab Panel
      Using Less Processing
• Don’t compile.
   – Build an RPM on your own FC4 box, or on your
     local Pla netLab machine.
• Don’t analyze.
   – Ship raw data to your repository, process it there.
• Don’t poll.
   – To get the most responsiveness out of a unix CPU
     scheduler, sleep as often as possible.

                     Neil Spring; BCnet 2007               6
                         PlanetLab Panel
       Using Less Memory
• Make Java GC in a smaller footprint.
  – java -Xmx8 M Foo
• Be careful with in-memory caches.
  – e.g., tcpdump’s memory “leak”
• Be careful with cron and fork.
  – Processes may hang deterministically;
    cron can create many hung processes.

                Neil Spring; BCnet 2007     7
                    PlanetLab Panel
       Limited Bandwidth
• DSL-attached nodes add diversity for
  measurement and overlays, but may be
  unsuitable for your app.
• Bandwidth is expensive in India and
• Each site can limit outbound rate.

              Neil Spring; BCnet 2007    8
                  PlanetLab Panel
  Using Less Disk Bandwidth
• read() and write() sometimes slow
  – The I/O scheduler may be no good.
• Paging doesn’t help.
• Write less, less often.
  – Limit logging, collection.

                  Neil Spring; BCnet 2007   9
                      PlanetLab Panel
  Adapting to Limited Uptime
• Treat Disks as Cache
• Upgrades, failures, power outages,
  abuse-related shutdowns, etc.
• Expect the machines you use one day
  to be unavailable the next.

              Neil Spring; BCnet 2007   10
                  PlanetLab Panel
  Consuming less Sysadmin
• PlanetLab’s quid pro quo:
  – I’ll support your researchers if you’ll
    support mine
• But research may:
  – send dodgy packets, send lots of traffic,
    risk infringing content, launder attacks,
    appear as a compromised machine, etc.
• Don’t do anything you wouldn’t do
  (haven’t done) from your workstation.

                  Neil Spring; BCnet 2007       11
                      PlanetLab Panel
Implications: Measurement (1/2)
• Avoid gettimeofday(), use libpcap.
  – to send a packet: may be rate-limited.
  – to receive: other processes may run first.

                 Neil Spring; BCnet 2007         12
                     PlanetLab Panel
Implications: Measurement (2/2)
• Choose data to collect, move data
  quickly to reliable (your) storage.
• Consider:
  – Destination-side firewalls
  – Hosting-side firewalls
• Randomize, start slow, start local, use a
  blacklist, describe your experiment.
• Don’t use published tools blindly.
                 Neil Spring; BCnet 2007   13
                     PlanetLab Panel
          Implications: Overlays (1/2)
      • Performance diversity affects peer selection

Graph from Rhea et al., Worlds 2005.
    Implications: Overlays (2/2)
• The network between PlanetLab nodes is not
  “representative” of the Internet.
  – Abiliene (Internet2), CAnet, Geant research
  – High bandwidth, low latency, few failures, etc.
• Understand how this affects your results.
  – Bandwidth limits and connections off-PlanetLab
    mitigate the trouble.

                    Neil Spring; BCnet 2007           15
                        PlanetLab Panel
      Implications: Services
• Services are abused, PlanetLab is a
  – Services like CoDeeN log all accesses,
    prevent dangerous ones.
• IP address based authentication used
  by electronic journals
  – We can’t tell journal publishers to use
    better authentication, must blacklist.

                 Neil Spring; BCnet 2007      16
                     PlanetLab Panel
            Lasting Challenges
• Should you build on the work of others?
  – Creates a dependency, and the services
    you use might be supported by students
    (who tend to graduate).

• How can researchers share negative
  experiences, mea culpas, and lessons?
  – The learning curve can be steep, but many have
    made it.

                            Neil Spring; BCnet 2007                            17
                                PlanetLab Panel
      Acknowledgements and
         Further Reading
• Apologies to those whose tools I neglected to feature.
• Pai et al., “The dark side of the web: An open proxy’s
  view”, HotNets 2003
• Rhea et al., “Fixing the Embarassing Slowness of
  OpenDHT on PlanetLab”, Worlds 2005
• Spring et al., “Using PlanetLab for Network
  Research: Myths, Realities, and Best Practices” OSR
• Users mailing list.

                    Neil Spring; BCnet 2007           18
                        PlanetLab Panel