Beehive: Towards a Simple Abstraction for Scalable Software-Defined Networking

Presenter: Yashar Ganjali

Authors: Soheil Hassas Yeganeh, Yashar Ganjali (University of Toronto)

Paper: http://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final17.pdf

Although SDN argues for a centralized controller, centralization is not always an option for several reasons: networks demand scalability and performance.  Unfortunately, existing solutions to scalability are point solutions that only further complicate the interface for writing SDN applications.  More concretely, SDN programmers still need to write distributed programs and deal with issues such as concurrency. 

The goal of beehive is to provide an API or abstraction that allows SDN developers to create centralized applications while the underlying platform scales by automatically distributing the SDN applications.

The key insight underlying Beehive is to demarcate application state and tightly control interactions between event-handlers and the application state.  By providing a fine API between the event-handler and the application state, Beehive is able determine to map state usage to network events.  In BeeHive, all application state is stored in dictionary (key-values stores).  Each event-handler must specify the dictionary and the set of keys required to handle a message.  Building on this, Beehive is able to distribute and parallelize applications by collocating state used by the same event to the same server.   By ensuring that all state used to handle an event is collocated, BeeHive ensures consistency across all servers — no two servers will ever operate on the same state.

Beehive allows for a variety of use-cases: Migration, Fault-tolerance, Analytics, runtime analysis of resource utilization.

Q& A: 

--------

Keith: How about storing all state in a distributed database?

Yashar: The distributed database no control over placement of networking state. some overhead communication to that subsystem.

Panel Discussion:

---------------

keith Winstein (Stanford): What is the next step to take the system to the real world?

Yashar Ganjali: The system is already built, now we need to add new application.

Nikola Gvozdiev: We have a preliminary prototype —  we need to optimize to get better response to network events.  Furthermore, it would be nice to explore a variety of network policies.

Junchen Jiang: stance to have a framework that proves a systematic way for this

Anees Shaikh (Google): the I2A interface may be problematic. have you thought about the range of information that can cross the boundaries.

Junchen Jiang: I2A may be too idealized too much info. info is already being shared. so you want a narrow interface. already happening in an adhoc way.

Minlan Yu (USC): many prior work work on one direction, a feature of yours is to have bi-directional. can you give some intuition as to why bi-directional is better that two unidirectional.

Junchen Jiang: it is valuable to include ISP in the loop. in the past ISP was in the passive mode — it is valuable to include them. There are things that can only be done when both directions are involved in the loop.

Minlan Yu (USC): will there be a feedback between the two?

Junchen Jiang: there may be some bad interaction but that is better than no interaction.

Ando Wang (UIUC): what are the objectives? are they general enough to characterize user experience. will many applications have conflicting user requirements?

Junchen Jiang: UE depends on Applications  — need to be careful when designing objective functions.  collaboration between the two should be aware of these distinctions. 

Nicola Gvozdiev: Raw per-metrics aren’t sufficient. how the metrics will be expose is very app specific.

David Orjan (Cisco): How Beehive’s API  work when you have to compose multiple applications? Do you assume they don’t interact in funny ways?

Yashar Ganjali: Application developers need to be careful to allow it to be scalable. Can have a series of smaller functions that are used to aggregate information between app.

Andrew Ferguson (Google): How rich are the set of messages being captured?

Yashar Ganjali: BeeHive only captures the dependencies between the current events and state. However it can’t capture dependencies between state and past events.

Ando Wang (UIUC): An ISP's infrastructure is optimized for a specific use-case and thus the set of knobs exposed are for that specific use-case. How will the ISPs implement the new knobs?

Junchen Jiang:  We only expose existing knobs thus there is little need to change the infrastructure.  A better question to ask is this: 'what new knobs can EONA expose? and when they are added how should they be exposed.'

Li: It is not profitable to improve QoE beyond a certain point as it will result in diminishing results.

Junchen Jiang:  We have yet to reach the point of diminishing returns.

Anja Feldmann (TU Berlin): how much complexity does FUBAR and Beehive add? at what granularity should info be shared and when?

Fubar: timescales of a minute. collect per aggregate measurements and do calculation.

Yashar Ganjali: if compare Beehive to Pox/Nox, there is some complexity but the hope is that the new complexity will reduce complexity required by app developers. 

Junchen Jiang: time granularity in EONA is a control channel between control planes.

Anja Feldmann (TU Berlin): What is the granularity for EONA?

Junchen Jiang: EONA doesn’t have to operate at the per-flow. The granularity you operate on depends on the problems you are troubleshoot.