Changes between Version 1 and Version 2 of GEC15Agenda/ProgrammableNetworksAndGENI

10/31/12 10:06:10 (12 years ago)



  • GEC15Agenda/ProgrammableNetworksAndGENI

    v1 v2  
    1212== Session Summary ==
    14 [wiki:GEC15Agenda/ProgrammableNetworksAndGENISummary Programmable Networks And GENI Summary]
     14The "Programmable Networks and GENI" session was held at GEC15 10/25/2012 8:30-10:00 AM ET. Marshall Brinn was the moderator and the presenters were Deniz Gurkan of University of  Houston, Kiran Nagaraja of Winlab/Rutgers, Prasad Calyam of Ohio State, and Ashish Vulimiri of University of Illinois.
     16=== Marshall Brinn ===
     17Marshall opened by framing the discussion. GENI presents to experiments a 'deeply programmable' layer 2 data plane. The question is: what is the nature of that deep programmability? How can we help experimenters to take advantage of this capability in terms of programming the network, and monitoring or orchestrating experiments? He discussed several dimensions in which the network could be programmed: we can program individual routes, set up !OpenFlow data_flow rules, or handle frame-by-frame processing within an !OpenFlow controller. We have both hardware !OpenFlow switches and software switches within the GENI topology. Software switches, themselves, are modular and allow for writing new software modules for managing routing decisions, re-writing headers or in-the-loop analysis. Passing the podium to the speakers, Marshall asked them to speak to the topic of network programming from their experience as experimenters: what has been hard and easy? What tools or services could GENI provide to make the experience more efficient?
     19=== Deniz Gurkan ===
     20Deniz Gurkan spoke about her experiences teaching and leading research in programmable networking on a variety of hardware and software platforms. In the GENI context she has been working with ExoGENI/ORCA platforms with the goal of establishing inter-rack slicing using !OpenFlow. She talked about the desire to configure or provision a network based on application or service requirements (congestion, security, mobility, VM migration) relative to available resources.  She suggested two domains for experiments for which programmable networking would be well suited, namely Emergency Management and Programmable Network Nodes (i.e. applications that would run on actual network nodes). Finally, Deniz advocated for the ability to add custom networking hardware (an experimental switch, e.g.) to an existing GENI slice.
     22=== Kiran Nagaraja ===
     23Kiran Nagaraja spoke about programmable networking from his perspective of the !MobilityFirst effort. !MobilityFirst mixes wireless and wired configurations and their respective data layers and protocols dynamically. He has built and advocated for more tool support for Edge-Core-Edge topology experiments (e.g. experiments between wireless labs at edges connected by wired backbones). By appropriate forward deploying of data caches on such a hybrid topology, we can support efficient robust content delivery to multi-homed mobile devices. Kiran discussed how !MobilityFirst protocols merged with !OpenFlow to route GUID-based routing of packets between wireless edge components connected by !OpenFlow switches on the backbone. Kiran listed some elements that would be helpful in pursuing this vision:
     24 * Wireless edge integration with the GENI core (he notes this is underway)
     25 * VLAN translations and bridging
     26 * Support for header re-writes on !OpenFlow switches
     28=== Prasad Calyam ===
     29Prasad Calyam discussed three GENI/SDN projects he's been working in VMLab at OSU, specifically:
     30 * VDCloud Experiments. Using VDCloud, the goal here is comparing performances across Internet and !OpenFlow-based routed paths in terms of performance (latency and bandwidth). He advocated for redundancy and diversity in the GENI topology to allow for different paths and enhanced robustness. He talked about the desirability of proactive (pre-population of flow-tables) versus reactive (controller driven flow-table management) in different contexts. He raised concerns about the robustness of !OpenFlow controllers in the context of extremely high traffic throughput.
     31 * VDC-Sim Lab Exercises. VDC-Sim is a simulator for classroom exercises in which students are asked to "maximize net-utility score" across multiple dimensions. The focus here is intelligent adaptation on the server, client or network side of simulated application environments. He advocated for making it easier to set up slices and controllers for student groups, particularly support for !OpenFlow controllers on shared resources.
     32 * OSU-MU Science DMZs. This project sets up a DMZ between OSU and U of Missouri Science with joint users/roles, single-sign-on and !AuthZ policies, using E2E programmable !PerfSonar I&M and VLAN-based Internet2 topologies. The goal is to set up GENI slices to dynamically change user load patterns from remote campuses, supporting the scalability of remote user access and response time analysis. Prasad advocated for performance isolation between slices/topologies to allow for experiment instrumentation and analytics.
     34For all these projects, he advocated for easier management and debugging tools for programmable flows. Access to MAC address tables and other network state internals for debugging was also cited as a desirable feature. Finally, good documentation and examples were listed as important features to help support programmable networking experiments.
     36=== Ashish Vulimiri ===
     37Ashish Vulimiri spoke about "Adaptation and Replication", the research he's done with Brighten Godfrey at UIUC and Oliver Michel at U. Vienna. The goal is to use replication and adaptive techniques to reduce overall latency (and the associated reduction in production costs). He notes that replication has proven benefits for reducing latency, and is not hard to do (just duplicate packets: can be done at end hosts). However this approach may be less than optimal (lots of wasted bandwidth due to indiscriminate duplication). Adaptation is an attempt to adaptively pick the best path to reduce latency. For these experiments he wanted both efficient multi-path source routing and realistic background traffic. Under !PlanetLab he had realistic background traffic but not efficient multi-path source routing. Using !OpenFlow, he was able to find efficient multi-path source routing but not realistic background traffic. He presents relatively unique requirements among network experimenters in that he wants realistic background traffic even while he controls the routing (most efforts want network isolation). Ashish advocated for enhanced tooling to help support simulated traffic. He also advocated for upgrading to !OpenFlow 1.1+ to take advantage of full features of the spec (including IpV6) as well as full implementations of !OpenFlow 1.0 (many switches only implement parts of the spec).
     39The session ran a little over the budgeted time so we didn't have time for an open discussion among the guest speakers and the audience. We agreed this was a topic that was worth continued discussion and may try to have a follow-on session at the next GEC.