Changes between Initial Version and Version 1 of MeasSys-JulyQSR


Ignore:
Timestamp:
08/05/10 14:14:12 (14 years ago)
Author:
Vic Thomas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MeasSys-JulyQSR

    v1 v1  
     1= Measurement System =
     2
     3Period:  September 2009 through July 2010
     4
     5This status report includes all activities related to the GENI Instrumentation and Measurement project that have been conducted over the 10 month period from September '09 through July '10.  As such, this status report covers what is effectively three quarters worth of development activities.  The primary reason for the delay in reporting has our intense focus on development activities toward the stated Spiral 2 milestones.  Achieving the target operational capability targeted for Spiral 2 has turned out to be quite challenging, but we believe that the system we have developed meets our own high standards and will provide significant capability to GENI users.
     6
     7== 1. Major Accomplishments ==
     8
     9=== a. Milestones Achieved ===
     10Over the period covered by this report, our team has achieved its most critical Spiral 2 development milestones.  Namely, a functional and deployable network measurement system that can be used in an operational setting, and that is accessible and managed through the ProtoGENI control framework.  These activities have led to the development of additional features and functions that were not specifically identified in the Spiral 2 goals, but that emerged as requirements as we worked toward the envisioned and originally specified GIMSv2.0 capability.
     11
     12A list of the unmet milestones as they appear on the current GENI wiki page for our project are listed below (note there are slight discrepancies between the milestone descriptions used in the Wiki and those that appear below).  In each case, we indicate whether or not the milestone has been met, and for those that have been met, an approximate completion date has been given.  Our focus on system building, test and deployment has caused us to delay and modify some of the stated Spiral 2 milestones as noted below.  In each case, we have noted how we plan to address the milestone objective in the remaining 6 weeks of Spiral 2.
     13
     14  1) Spiral 1, S1.e:  Prototype with basic measurement functionality.
     15
     16  This milestone was completed in December 22, 2009.  The basic functionality included a ProtoGENI front end, a GIMS aggregate manager and the packet capture measurement system.
     17
     18  2) Spiral 1, S1.f:  Basic functionality prototype available.
     19
     20  This milestone is no longer applicable due to the availability of the v2.0 system (milestone S2.e) which is completed and available for deployment.  The prototype components were actually not made publicly available (ie. posted on the GENI wiki or elsewhere) when they were completed in December 22, 2009.  The reason is that our team was collaborating with the ProtoGENI team at Utah to make the GIMS prototype available on a live network (our NLR link to Kansas City which joins a set of ProtoGENI sites that are now operational), which we felt would be more useful for users interested in running actual experiments in a live environment.  We trivially had (and have) the ability to create a prototype installation at any time in WAIL.  We felt that deployment in WAIL would be of limited utility to users and that our efforts were better spent on a live deployment.
     21
     22  3) Spiral 2, S2.a:  Improve test suite for tests needed for NLR deployment.
     23
     24  This milestone has been completed in conjunction with completion of the prototype basic measurement functionality (ie. December 22, 2009).
     25
     26  4) Spiral 2, S2.b:  Specify and develop a library of packet transformations that might be useful to early experiments on GENI.
     27
     28  This milestone has been completed as of July 15, 2010.  Three types of transformations are implemented: packet and byte counter aggregation, flow aggregator and packet anonymization.  To implement the flow aggregation is based on the open source FIXBUF implementation of IPFIX, a new flow aggregation standard created by the IETF.  The anonymization at present is a prefix-preserving IP address anonymization, which requires a private key.
     29
     30  5) Spiral 2, S2.c:  Implement GENI Spiral 2 identity management mechanisms.
     31
     32  This milestone has been completed as of July 15, 2010.  The authorization and identity management functionality in the current version of GIMS is limited and will be expanded in future versions of the system - see details in activities and findings listed below.
     33
     34  6) Spiral 2, S2.d:  Develop Improved functionality for measurement prototype.
     35
     36  This milestone was completed as of July 15, 2010.  Significant updates (see details under activities and findings below) were made to each of the three major components of the system:  the ProtoGENI compatiable GUI, the GIMS Aggregate Manager and the GIMS Packet Capture System.
     37
     38  An originally envisioned aspect of this milestone that has not yet been fully implemented is a publish/subscribe capability for GIMS packet capture components.  The currently available version of the GIMS Aggregate Manager has device administrative capability that can accommodate publish/subscribe.  But, the currently available version of the Packet Capture System does not associate with the AG via pub/sub.  It is simply not necessary at this point in the development process when the number of packet capture devices is extremely small.  We plan to implement pub/sub registration in Spiral 3 where the focus will shift to broader deployment and further enhancement of the system.
     39
     40  7) Spiral 2, S2.e:  Develop and test GIMSv2.0 prototype and make this available to users.
     41
     42  This milestone was completed on July 15, 2010.  The tarballs for the three key components:  the ProtoGENI compatiable GUI, the GIMS Aggregate Manager and the GIMS Packet Capture System have all been posted on the GIMS (now referred to as !MeasurementSystem) wiki.
     43
     44  A further element of this milestone is the deployment of a GIMS measurement node on our NLR link to Kansas City, which will enable the system to be accessed by authorized ProtoGENI users.  To that end, systems are available in WAIL (the termination point for this link and the location of the systems on which ProtoGENI users will gain access) and network paths have been established to our border. Unfortunately, creating the entire path requires significant coordination with the University of Wisconsin campus networking groups, the ProtoGENI group and others.  There have been consistent set backs and delays that are outside of our capability to control.  We hope to have these resolved by the 8/31/10 completion of Spiral 2.
     45
     46=== b. Deliverables Made ===
     47
     48Code tarballs for the 2.0 versions of each of the three key GIMS components have been published on the GIMS wiki.  This is the most important aspect of our Spiral 2 activities.
     49
     50
     51== 2. Description of Work Performed During Last Quarter ==
     52
     53* As noted above, this report covers a 10 month period, thus there are an extensive set of activities reported below.
     54
     55=== a. Activities and Findings ===
     56
     57'''Aggregate Manager:'''
     58The GIMS Aggregate Manager (AM) is one of the three key components of the GIMS infrastructure and key deliverable for our Spiral 2 activities.  The AM coordinates activities between the GUI, the AJAX server, the GIMS database, and the distributed measurement nodes.  The implementation, improvement, and expansion of this component was a major focus of the UW Maidson team's activities over the period covered by this report.  Improved logic for device communication was added, which will enable scalability of the envisioned GIMS infraststructure.  Integration of the XML/RPC utility library and GIMS database utility library was also completed.  The development effort also focused on key functionality for efficient and scalable operation of the GIMS infrastructure.  The functions that have been designed, implemented and tested include logging, error-checking, error-handling, and improving user feedback at each step of the experiment life-cycle.
     59
     60'''The GIMS Database:''' A MySQL database has been designed and implemented to keep track of experiment and device information as well as experiment/device pairings.  This database replaces the flat-files used to store information in the prototype delivered in December '09.
     61
     62'''GIMS Database Utility Library:''' An initial version of a utility library has been designed and implemented to provide insert/edit/retrieve/delete functionality for database information.  These capabilities are required for operation and management of the MySQL database that is part of the GIMS AM.
     63
     64'''The GIMS Database Admin Tool:'''  The GIMS Admin tool is a web-based GUI that enables authorized GIMS administrators to manage the GIMS database and is specifically focused on measurement system device management.  The tool simplifies and streamlines measurement device management, sanity-checks input values and also handles packaging device capabilities as XML/RPC for the database.  This functionality is a necessary precursor to the publish/subscribe functionality, which will enable authorized measurement devices to register themselves in the GIMS database.  The current version of the Admin Tool implements the following functionality:
     65 * Add Device: Add a new device to the GIMS database.  Admin can specify a device location, device name, device type, hostname, port, and description.  Admin can also specify which device capabilities are supported by the device in question.  Location name pull-down is pre-populated with a list of existing locations, but user can also specify a new location.  Admin-entered info is sanity-checked via Javascript and errors are pointed out before form submission making it less likely for bogus values to make it into the database.  Upon entry, device capability settings are converted into XML/RPC code for database submission.
     66 * Edit Device: Edit an existing device in the GIMS database.  Admin can change any of the afore-mentioned parameters.  All fields are pre-populated with existing device state information, including device capabilities.  As with the "Add Device" functionality, Admin-entered data is sanity-checked via Javascript and errors are pointed out before form submission.
     67 * Delete Device: Delete an existing device from the GIMS database.  Admin is prompted to pick from a list of existing devices and once a device is selected the full device listing is displayed in a verification step before device is deleted from the database.  After deletion, a listing is given of the device data that was deleted in case it needs to be recreated later.
     68
     69'''XML/RPC Utility Library:'''  An extensive utility library was created to centralize creation and decoding of XML/RPC data structures for use by the various GIMS components.
     70
     71'''Definition and Implementation of the GIMS Command Structure:'''  The GIMS command structure, implemented as XML/RPC calls, was expanded to include Control and Utility commands as follows:
     72 * Control Commands.  A experiment control command language has been designed and its associated functionality has been implemented in the three key GIMS components.  These control commands include:
     73     * !CreateExperiment: Instantiate a new experiment in the GIMS database.  Associate a specific capture device with the experiment.  Assign a unique ExperimentID to the experiment.
     74     * !ConfigureExperiment: Presents the user with a setup UI that is tailored to the capabilities of the device.  Allows the user to choose which capture parameters they want to enable and configure.  Creates the libpcap string that will be used by the capture device to specify packets of interest to the experiment.  Allows the setup of either local or remote data storage, as well as anonymization and/or data aggregation techniques to be applied.
     75     * !StartExperiment: Begin data collection using pre-established collection criteria and data storage options.
     76     * !PauseExperiment: Stop data collection temporarily without ending the experiment.
     77     * !StopExperiment: Stop data collection and end the experiment.
     78 * Utility Commands: Similar to the experiment control commands, an initial set of utility commands have been designed and implemented in the three key GIMS components.
     79     * !GetDeviceCapabilities: Retrieves the capture capabilities for the device in question from the database.   Allows the GUI to present the user with an experiment setup dialog that makes sense.
     80     * !GetExperimentSettings: Return the settings used to create the experiment.  This can allow the user to double-check settings or potentially re-create a previous experiment.
     81     * !GetExperimentStatus: Get the current state of the experiment (e.g. total pkts captured, elapsed experiment time, errors, CPU usage, number of other running experiments, storage capacity used/remaining, etc.
     82     * !GetExperimentResults: Post-experiment analyses and statistics presented to the user
     83
     84'''AJAX incorporation:'''
     85Wherever possible we've begun to integrate AJAX functionality into the GIMS GUI.  This technology allows changes to be made to the GUI in response to user input (using data from the GIMS AM) without requiring a form submission/refresh cycle.  This gives the GUI more of an application feel even when running in a browser.  This activity is a departure from our originally envisioned GUI development activities but we felt it was necessary in order to create a measurement system capability that would be more attractive to users. Further AJAX integration is planned.
     86
     87'''Graphics:'''
     88Significant enhancements to the graphics were added in the 2.0 version of the GUI.  The goal is an intuitive and pleasant user experience.  Graphics enhancement will be an on-going acivity.
     89
     90'''Experiment Life-cycle Workflow Support:'''
     91We defined and implemented work flow logic to govern experiment life-cycle.   This is another addition to our original specification for GIMS, but one which we determined to be important to making the process of defining and using measurement capabilities in GENI. Transitions that are currently defined include the following state-changes in response to commands:
     92 * !CreateNewExperiment: Instantiated
     93 * !ConfigureExperiment: Instantiated->Configured
     94 * !StartExperiment: Configured->Running | Paused->Running
     95 * !PauseExperiment: Running->Paused
     96 * !StopExperiment: Running->Done | Paused->Done
     97Sanity-checking logic was implemented at each step of the experiment life-cycle to catch actions that don't make sense given the experiment state.
     98Better feedback is now provided to user at each step, both for progress and for error conditions.  Added improved logging for troubleshooting and verification.
     99
     100We plan to continue to expand and enhance work flow support in future versions of the system toward the goal of making measurement as streamlined as possible in GENI experiments.
     101
     102
     103'''Authorization and Identity Management:'''
     104Implementation of authorization capability has been a significant challenge in our development efforts.  This is because two forms of authorization are actually required.  The first is authorization in the control framework.  The second is authorization of users on individual packet capture measurement systems that are deployed in GENI. 
     105
     106Conceptually, a user is issued a certificate at their local ProtoGENI site, which they then manually load into their browser or use in scripts to contact various ProtoGENI web services.   Authenticating a user is then a simple process of verifying the certificate is valid which is done by Apache and then services that are implemented check variables that are passed to it.  That information is used to establish a valid ProtoGENI user.
     107
     108To facilitate user authorization, we have implemented an initial version of a GENIAuth module.  Users can go to the main control GUI page: http://www.schooner.wail.wisc.edu/gims/GIMSControl.cgi.  It will tell you at the top of the page if it could get your GENI credentials or not.  At present, we have it configured as an informational feature but can trivially change the configuration to reject unauthorized users.
     109
     110The tricky part is authorization of user access to a packet capture measurement node that is deployed on the physical substrate.  We are in the process of defining this capability within the context of the greater ProtoGENI X.509 infrastructure.  We plan to have an initial capability for link access authorization by 8/31/10.
     111
     112'''Packet Capture System:'''
     113Over the period covered by this report, capabilities of the packet capture
     114measurement component of GIMS have been extended and improved.  Two undergraduate students at Colgate University have been primarily responsible for this effort.  Co-PI Sommers obtained internal funding from Colgate University to support these students during the school term.  The GENI subcontract has funding to support one summer student, and Co-PI Sommers obtained internal Colgate funding to support one additional summer student to carry on this work.
     115
     116The main improvements to the packet capture subsystem, which have culminated in the v2.0 release, have been to implement measurement aggregation and anonymization, two outstanding items on our list of milestones.  At present, two forms of aggregation are implemented: a simple packet and byte counter aggregator, and a flow aggregator.  To implement the flow aggregation, we have leveraged code from the open source project YAF ("yet another flow collector"), which in turn uses the open source FIXBUF implementation of IPFIX, a new flow aggregation standard created by the IETF.  The anonymization at present is a simple prefix-preserving IP address anonymization, which requires a private key.  By using the same key for a set of packet capture devices, an experimenter will be able to have a consistent view of IP addresses (i.e., the anonymization will be consistent across capture devices).
     117
     118Over this summer, undergraduate students will be testing these newly
     119implemented components with the goal of supporting a demo at GEC8 in San
     120Diego.  Co-PI Sommers has obtained internal Colgate funding to augment
     121existing GENI subcontract funding to support student travel to present a
     122demonstration of the packet capture subsystem.  Leading up to GEC8,
     123students will be focussed on testing and refining the aggregation and
     124anonymization functionalities, as well as augmenting the capabilities of
     125the XML/RPC interface to the GUI front-end being developed by Charles
     126Thomas at U. Wisconsin. 
     127
     128
     129=== b. Project Participants ===
     130
     131UW-Madison:  Paul Barford (PI), Mike Blodgett, Charles Thomas
     132
     133Boston University:  Mark Crovella (PI)
     134
     135Colgate:  Joel Sommers (PI), Tiantong Yu, John Raffensperger, Ananya Das
     136
     137=== c. Publications ===
     138
     139None.
     140
     141=== d. Outreach Activities ===
     142
     143None.
     144
     145=== e. Collaborations ===
     146
     147While no significant collaborations beyond the GIMS team have emerged, there are on-going conversations with participants in the Instrumentation and Measurement Working Group.  We expect that these will lead to future collaborations toward the goal of coordinated and efficient instrumentation and measurement capability throughout GENI.
     148
     149=== f. Other Contributions ===
     150
     151PI-Barford is a co-chair of the GENI Instrumentation and Measurement Working Group.