Context Navigation

Changes between Version 5 and Version 6 of PlasticSlices/FinalReport

Timestamp:: 08/03/11 18:29:35 (13 years ago)
Author:: hdempsey@bbn.com
Comment:: more typos and minor wording changes

Legend:

: Unmodified
: Added
: Removed
: Modified

PlasticSlices/FinalReport

-                      v5
+                      v6
 (Graphs of bytes sent (first graph TX) and bytes received (second graph RX) in each slice during Baseline 5.)
 During the project, all mesoscale campuses were configured to send monitoring data to the GMOC. Some sites initially configured resources that didn't use NTP, but revised the configurations after starting monitoring, because NTP is essential for correlating data between sites. The GMOC offers an interface called SNAPP for browsing the data that they collect, visible at http://gmoc-db.grnoc.iu.edu/api-demo/. In addition, the GMOC offers an API which anyone can use to download raw collected data from GMOC to analyze it, graph it, etc.  The GPO used this API to create useful local monitoring graphs (samples included in this report, and more available through the GENI wiki). The GPO data is of interest to both operators and experimenters, covers various levels of granularity, and presents some per-slice information.  The per-slice information relies on naming conventions to tie together slices and slivers in this implementation.
+During the project, all mesoscale campuses were configured to send monitoring data to the GMOC. Some sites initially configured resources that didn't use NTP, but revised the configurations after starting monitoring, because NTP is essential for correlating data between sites. The GMOC offers an interface called SNAPP for browsing the data that they collect, visible at http://gmoc-db.grnoc.iu.edu/api-demo/ (Despite the name, this is a production GMOC web interface with a number of options for searching and displaying data). In addition, the GMOC offers an API which anyone can use to download raw GMOC-collected data to analyze, graph, etc.  The GPO used this API to create some useful Plastic Slices monitoring graphs (samples included in this report, and more available through the GENI wiki). The GPO data is of interest to both operators and experimenters, covers various levels of granularity, and presents some per-slice information.  The per-slice information relies on naming conventions to tie together slices and slivers in this implementation.
 http://groups.geni.net/geni/wiki/PlasticSlices/MonitoringRecommendations has links to a variety of monitoring sites and information.
 …
 = 9. Experiments =
 We ran five experiments on these slices, to send various kinds of artificial but representative traffic across the network: ping for ICMP, netcat for unencrypted TCP, wget (HTTPS) for encrypted TCP, and iperf for TCP and UDP with some performance statistics. We picked these because they were simple and widely available, but still provided some variety, and are similar to the types of traffic that we expect to be used by real mesoscale GENI experiments. (Note that although ping and iperf both give you performance statistics, we weren't specifically trying to measure network performance, as this wasn't one of the goals of the project.)
 http://groups.geni.net/geni/wiki/PlasticSlices/Experiments has more details about the experiments in general, and the baseline pages (see below) have more details about the exact paramemters used for each experiment in each baseline.
+We ran five experiments on these slices, to send various kinds of artificial but representative traffic across the network: ping for ICMP, netcat for unencrypted TCP, wget (HTTPS) for encrypted TCP, and iperf for TCP and UDP with some performance statistics. We picked these because they were simple and widely available, but still provided some variety, and are similar to the types of traffic that we expect to be used by real meso-scale GENI experiments. (Note that although ping and iperf both give you performance statistics, we weren't specifically trying to measure network performance, as this wasn't one of the goals of the project.)
+http://groups.geni.net/geni/wiki/PlasticSlices/Experiments has more details about the experiments in general, and the baseline pages (see below) have more details about the exact parameters used for each experiment in each baseline.
 = 10. Baselines =
 …
  * A directory of common user configuration files (dotfiles).
 We briefly investigated tools such as Gush or Raven, but at the time the project began, neither seemed sufficiently well-integrated with GENI to be worth the overhead.
+We briefly investigated experimenter tools such as Gush and Raven, but at the time the project began, neither seemed sufficiently well-integrated with GENI to be easily used.  We expect to revisit experimenter tools in later projects.
 http://groups.geni.net/geni/wiki/PlasticSlices/Tools has many more details about the tools we used and how we used them, all the configuration files, etc.
 …
 One of the results that would've been surprising on a regular network is packet loss, e.g. the 8% loss from BBN to Clemson with UDP in a 40-second test. This turns out to be related to our simplistic use of OpenFlow: As the first packet hits each OF switch in the path to the destination, across the entire country, each has to connect back to the slice's OF controller in Boston for instructions. This can take a few seconds to complete, but once the controller has installed rules in the switch's flowtable, subsequent packets flow at line speed, as expeced. Thus, packet loss statistics like this typically reflect "the first 8% of packets failed", not "out of every hundred packets, eight of them failed".
 The logs from the client and server make this clear. On the client, all you see is the overall packet loss:
+The logs from the client and server make this clear. On the server, all you see is the overall packet loss:
 {{{
 …
 }}}
 Packet loss is generally not desirable, but it highlights the fact that OpenFlow allows you to control traffic in GENI in ways that aren't possible in a regular network. Using OpenFlow doesn't require packet loss, of course: For example, we could have used a smarter (experiment-specific) controller that added flowtable rules to the switches before we even began sending traffic. Or, if we didn't want to use a more complicated controller for other reasons, we could have sent some seed traffic to cause the simplistic controller to create the flows, before we began sending the traffic that we actually cared about. OpenFlow in GENI gives you a great deal of flexibilty.
+Packet loss is generally not desirable, but it highlights the fact that OpenFlow allows you to control traffic in GENI in ways that aren't possible in a regular network. Using OpenFlow doesn't require packet loss, of course: For example, we could have used a smarter (experiment-specific) controller that added flowtable rules to the switches before we even began sending traffic. Or, if we didn't want to use a more complicated controller for other reasons, we could have sent some seed traffic to cause the simplistic controller to create the flows, before we began sending the traffic that we actually measured.  OpenFlow in GENI gives you a great deal of flexibility.
 == 12.2. Latency and topology ==
 Another result that would've been surprising on a regular network is low throughput, e.g. between two geographical nearby sites like BBN (in Boston) and Rutgers (in New Jersey). This turns out to be due to a very valuable feature of GENI: The ability to create and use differnet topologies in the core network. Not all GENI network paths are optimized for distance -- deliberately so, since some experiments specifically want long links with high latency. One of the paths available during this project took nearly ten thousand geographical miles to get from BBN to Rutgers, for example.
+Another result that would've been surprising on a regular network is low throughput, e.g. between two geographical nearby sites like BBN (in Boston) and Rutgers (in New Jersey). This turns out to be due to a very valuable feature of GENI: The ability to create and use different topologies in the core network. Not all GENI network paths are optimized for distance -- deliberately so, since some experiments specifically want long links with high latency. One of the paths available during this project took nearly ten thousand geographical miles to get from BBN to Rutgers, for example.
 The RTT results from a ping test between BBN and Rutgers, using each of four different paths, shows this clearly. BBN is a useful test case for this because we connect to both NLR and Internet2, thus giving us four possible paths to each other campus (two VLANs through each of the two providers).
 When you connect via BBN's connection to NLR, on VLAN 3715, the path goes Boston - Chicago - Atlanta - DC - NJ, and the ping RTT is 74.3 ms:
+When you connect via BBN's connection to NLR, on VLAN 3715, the traffic path is Boston - Chicago - Atlanta - DC - NJ, and the ping RTT is 74.3 ms:
 {{{
 …
 }}}
 If instead you use BBN's connection to I2 on VLAN 3715, the path goes Boston - New York - Los Angeles - Houston - Atlanta - DC - NJ, and the ping RTT doubles, to 152 ms:
+If instead you use BBN's connection to I2 on VLAN 3715, the path is Boston - New York - Los Angeles - Houston - Atlanta - DC - NJ, and the ping RTT doubles, to 152 ms:
 {{{
 …
 }}}
 Thus, you can get variations up to a factor of 10 - 12 just by choosing your sites and paths carefully (and potentially even more, by designing an engineering a new toplogy using a different VLAN, rather than simply using one of the existing ones). This topology flexibility is another crucial feature of GENI.
+Thus, you can get variations up to a factor of 10 - 12 just by choosing your sites and paths carefully (and potentially even more, by engineering a new toplogy using a different VLAN, rather than simply using one of the existing ones). This topology flexibility allows GENI to support more varied experiments than an exclusively IP testbed.
 = 13. Future work =
 This report concludes the formal part of the Plastic Slices project, but we plan to continue using the mesoscale infrastructure to run experiments and tests. We'll publish our plans, and our results, on the GENI wiki. We intend to keep data flowing continuously for the next few months, to allow us to continue to develop and test monitoring, operational procedures and practices, etc. We intend to switch to running experiments that are less artificial, and dig deeper into some of the things that we didn't have time to complete.
+This report concludes the formal part of the Plastic Slices project, but we plan to continue using the meso-scale infrastructure to run experiments and tests. We'll publish additional plans and results on the GENI wiki. We intend to keep data flowing continuously for the next few months, to allow us to continue to develop and test monitoring, operational procedures and practices and to integrate new software and hardware.  We intend to involve actual experimenters in future work, and to investigate some of the initial Plastic Slices results in more detail.
 Specific goals include:
 …
 We're also interested in ideas for things that others would like us to investigate and/or try; feel free to contact help@geni.net if you have suggestions.
 Finally, one high-level conclusion is that GENI is ready to expand, so if you represent a campus that isn't yet part of the GENI mesoscale, and would like to be, let us know. (help@geni.net)
+Finally, one high-level conclusion is that GENI is ready to expand, so if you represent a campus that isn't yet part of the GENI meso-scale, and would like to be, let us know. (help@geni.net)
 = 14. Thanks =