Changes between Initial Version and Version 1 of CmuLab-2Q09-status

08/26/09 14:41:38 (12 years ago)
Aaron Falk



  • CmuLab-2Q09-status

    v1 v1  
     1= CMULab Quarterly Status Report =
     3  Period: Q2 2009
     5== I.  Major Accomplishments ==
     7=== A. Milestones Achieved ===
     9This quarter began with the basic node functionality complete for both !HomeNet (broadband/wireless) and Wireless Emulator node booting and management.  The major milestones achieved this quarter were in ProtoGENI control and integration:
     11  * Integrate with ProtoGENI Control Plane
     13    It is now possible to use the ProtoGENI control mechanisms to allocate slices involving CMULab and Emulator resources and to create accounts on the shared !HomeNet nodes.
     15  * Integration of node-CMU and CMU-Utah tunnels
     17    The CMU resources comprise a mix of individually allocated (sliced) resources, such as the CMULab nodes and the Emulator nodes, as well as shared nodes that provide only user-level resource isolation and no allocation mechanisms (the wireless !Homenet nodes).  Most of these nodes are not directly reachable over the Internet or Internet2---they lie behind NATs and firewalls either at Carnegie Mellon or in end-users houses/businesses.  As a result, the integration of the tunnels to these nodes with the conceptually cleaner IP-in-IP tunnels used by ProtoGENI to connect directly-reachable nodes required bridging two encapsulation regimes (IP-in-IP and OpenSSL).
     19    We have created mechanisms to automatically configure these tunnels to the !HomeNet nodes, and have created a mechanism that users can use (at present, manually) to establish these VPN connections to Emulator and CMUlab nodes.  Using this mechanism, it is possible to bridge the data plane from nodes at Emulab to, e.g., wireless Emulator nodes at Carnegie Mellon.  The mechanism is described on the [ HomeNet wiki] and has already been used by one (non-HomeNet-developer) researcher for wireless experimentation.  The researcher's paper describing this is currently under submission; we will provide a bibliographic reference in a subsequent report.
     21  * Merging all CMU-created functionality into ProtoGENI distribution
     23    All milestone-related functionality has been submitted as patches and accepted to the main ProtoGENI distribution.  In addition, we supplied and had accepted several "clean-up" engineering improvements to the base code.
     25  * Student testbed use
     27    The testbeds have received substantial use to date.  This student research use is described in the milestone ticket.
     30=== B. Deliverables made ===
     32As noted above, we continue to keep these changes integrated with the ProtoGENI code, and keep our deployment in sync with the Utah development branch.  Patches for all of the above milestones have been submitted to and accepted into the ProtoGENI codebase and are documented on our or the ProtoGENI Wiki.
     34== II. Description of work performed during the last quarter ==
     36=== A.  Activities and findings ===
     38The milestones listed above represent about half of the effort we put into !HomeNet/ProtoGENI development this quarter, and are somewhat self-explanatory:  establishing tunnels, bridging communication domains to provide federated data plane support through non-transitively connected networks, and ensuring compliance with the evolving ProtoGENI interfaces.
     40A major chunk of time, however, was consumed by a milestone that has not yet been completed:  Integration of the Emulator user interface with the Emulab/ProtoGENI experiment portal interface.
     42The goal behind this integration was to eliminate what is now a two-step, non-integrated configuration process for Emulator users.  With the prior level of ProtoGENI integration, users specified the nodes involved in their experiment to the Emulab interface, which allocated the physical hardware, installed the user's desired operating system, config files, and so on.  After doing so, the users then had to login to a second Emulator-specific control machine that is used to control emulator experiments, but before any experiments can be run, the user must perform two more configuration steps.  The first one involves manually executing a command that grabs the node configuration information from a CMUlab database so the emulator controller knows what nodes the user is using; this same command has to be repeated on swap out. The second step is providing an XML description of the wireless channel -- basically, an Emulator-specific configuration that is used, in turn, to program the digital signal processing inside the Emulator core hardware.
     44While the ProtoGENI/Emulab integration was a huge step forward for managing the nodes, this two-step configuration with two different control interfaces remained an unpleasant and confusing step for users.  The first step is a result of the fact that wireless channels are resources that are not known to CMUlab (emulab). The correct way of handling this is through extensible RSpecs, something we hope to do in year 2.  The second step is frustrating and error prone (forgetting to execute the command on swap out can affect experiments of later users) and the goal of this milestone was to do away with (i.e. automate) this step.
     46The integration hit several technical snags that relate deeply to the model used by Emulab for testbed control:  the emulator controller is a special machine in the sense that it is shared (any user with a valid Emulator experiment should have an account on it), but also privileged (it is able to control the Emulator hardware), and not one of the existing special Emulab nodes such as boss or ops.  We are currently investigating in which direction the model should be extended to account for machines with these properties that are necessary for the control of a subset of nodes.  Second, we encountered a similar limitation in the Emulab event system:  the event system did not provide a facility for running code on _experiment_ swapin/swapout on these special nodes, only on experimental nodes at node swapin/swapout.  For various legacy reasons, the event system is a fairly complex codebase that hasn't been modified lately.  We are in the process of becoming event system experts to provide the necessary modifications.  These details, which fundamentally arose from a difference between the Emulator's control model and the existing model, turned this milestone into a much more substantial technical challenge than we anticipated.  We have updated the GENI wiki with our attack plan for this goal.
     49=== C. Publications (individual and organizational) ===
     51This paper makes heavy use of the Emulator:
     53  Design, Implementation, and Evaluation of an Efficient Opportunistic Retransmission Protocol [ mobicom267-lu.pdf], Mei-Hsuan Lu, Peter Steenkiste, Tsuhan Chen, The Fifteen International Conference on Mobile Computing and Networking (!MobiCom'09), ACM, Beijing, China, September 2009.
     55=== D. Outreach activities ===
     57The Emulator continues to be used in a number of wireless research papers.  In addition, the !HomeNet nodes are now being used as part of both the exploratory research and evaluation of projects in the Intel/CMU collaborative project "Neighborhood Aware Networking."
     59=== E. Collaborations ===
     61As documented in the Utah quarterly report, we have been participating in bi-weekly conference calls with the other members of our cluster.  We continue tight integration with the Emulab team and are keeping our source trees in tight synchronization.
     63=== F. Other Contributions ===