Version 2 (modified by, 9 years ago) (diff)


GEC15 Programmable Networks and GENI Session

The goal of the session is to discuss what GENI provides to experimenters (a layer-2 stitched custom stitched topology) and what experimenters would like to do on such a topology in terms of programmable networking and how GENI can help (what kind of tools, intrinsic capabilities, architectural support etc) to support such programmable networking experiments.

Current slate of speakers:

  • Deniz Gurkan (Houston)
  • Kiran Nagaraja (Winlab Rutgers)
  • Prasad Calyam (OSU)
  • Ashish Vullmiri (Illinois)

Session Summary

The "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.

Marshall Brinn

Marshall 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?

Deniz Gurkan

Deniz 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.

Kiran Nagaraja

Kiran 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:

  • Wireless edge integration with the GENI core (he notes this is underway)
  • VLAN translations and bridging
  • Support for header re-writes on OpenFlow switches

Prasad Calyam

Prasad Calyam discussed three GENI/SDN projects he's been working in VMLab at OSU, specifically:

  • 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.
  • 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.
  • 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.

For 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.

Ashish Vulimiri

Ashish 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).

The 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.

Attachments (5)