Reviews for PANE

[Rodrigo Fonseca]

Hi,

Please post the reviews to the PANE paper as a group reply to this message.

You will notice that the paper does not have the name PANE (PArticipatory NEtworking), but another name.

This is because the submission to the conference requires that we anonymize the submission.

Thanks,

Rodrigo

[Jeff Rasley]

Title: Participatory Networking: An API for Application Control in SDNs

PANE is an API which provides the ability for applications/users to control and inform the network of its intentions. The system allows for net admins to delegate authority of the network to users/application while still protecting fairness and security. One key component of PANE is the use of Hierarchical Flow Tables (HFTs) in order to support conflict resolution with requests. The authors also note that they have optimized the a previous HFT compiler from exponential to polynomial running time.

The PANE API essentially provides an application with read/write access to the network through the use of an SDN controller. The API exposes requests, queries and hints to applications which allow them to modify/read their network’s state. The authors show that by providing applications the ability to issue bandwidth requests, applications like Zookeeper and Hadoop can see performance improvements. They also show that by providing an application like SSHGuard the ability to deny traffic it can also benefit from their API.

The reproducibility of the paper is straightforward. The authors note that the PANE API and modified applications are available on github. Also, I know that the main author has a pre-built VM that can be easily executed to reproduce the Zookeeper evaluation :)

The authors point out some possible areas for future work. One area is the exploration of privacy protections as they relate to PANE network query messages. Another area is the ability for requests to include constraints, such as a request for bandwidth within a specified window of time.

Comments/Concerns:

I liked the evaluation, the bandwidth reservation examples are compelling. However, I feel like the evaluation is missing the investigation of the impact of hint and query messages. I am not exactly sure how this would be done. Hints could potentially be evaluated in a similar way that D3 does.

It would be neat (however I feel non-trivial) to modify a web-browser (and plug-ins like Flash, Silverlight, etc.) to leverage PANE to make reservations for video streaming applications. I feel that the benefits of PANE for certain applications is clear. However, I do have a minor concern about the amount of work involved in correctly modifying existing applications to take advantage of all that PANE has to offer may be too high for certain existing applications. I feel, ideally, that PANE’s greatest advantages would be seen with its use from the start of an applications design/development, this way it could be fully integrated into the application.

[Zhiyuan "Eric" Zhang]

Paper Title

Participatory Networking: An API for Application Control in SDNs

 

Novel Idea & Main Result

This paper presents an API for applications in software-defined networks, called PANE. This design is based the idea of participatory networks, and it addresses two challenges: decompose network control and visibility and resolve policy conflicts. The main idea is to delegate read and write authority to the applications and end users, so that they can gain controlled visibility into the network. They use Hierarchical Flow Tables to implement policies and resolve policy conflicts. HFTs are compiled to flow table entries for OpenFlow switches.

 

Evaluation

The COPE prototype is evaluated in two aspects: case study of real applications and practicality of implementation. The authors ported four real applications to use the COPE API and evaluated the effects on the networks and the application. They also evaluated COPE in real OpenFlow networks, based on Floodlight controller.

 

Prior Work

 

This paper is based on participatory network framework and the Hierarchical Flow Tables (HFTs).

A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi. Hierarchical Policies for Software Defined Networks. In HotSDN ’12.

A. D. Ferguson, A. Guha, J. Place, R. Fonseca, and S. Krishnamurthi. Participatory Networking. In Hot-ICE ’12.

 

Question

This paper discusses three types of messages that the applications can use to interact with the networks. There is a little confusion about the hints messages. In the papers we have read, Hedera uses flow size, D3 uses flow deadline and MicroTE uses flow predicability. All of these three seem like requests with additional information. Is this how hint is defined? Are there any fundamental difference between requests and hints?

On Monday, April 22, 2013 7:50:57 PM UTC-4, Rodrigo Fonseca wrote:

[Christopher Picardo]

Paper Title: Participatory Networking – An API for Application Control SDNs

Authors: Professor Fonseca, other faculty and his students

Date: 2013

Novel Idea: Development of an API to control Software Defined Networks (SDNs). The prototype named COntroller for Participatory nEtworking (COPE), safely decomposes control and visibility of the network, and resolves conflicts between participants and across requests. In other words, provides a baseline level of fairness and security.

COPE provides a network administrator with the framework to delegate privileges, divide resources, account for their usage, and resolve conflicts between users’ needs.

Main Results:

- COPE allows applications to reserve guaranteed bandwidth. When bandwidth is guaranteed, the high priority job’s completion time observed decreased by 19%.

- An optimized COPE controller must consider the order in which switch operations are made to provide the best experience. Furthermore, it was found that an individual switch can support a minimum of about 200 reservations per second.

- It is not enough for COPE to generate flow tables quickly. It must also propagate switch updates quickly because the time required to update the network affects the effective duration of requests.

- COPE provides conflict resolution and delegation, strict and partial fulfillment (i.e.: bandwidth guarantees), fault tolerance and resilience.

- COPE allows principals to request resources for future intervals for a future planned network state via an indexed sequence of policy trees (VERY INTERESTING).

Criticism: the paper feels like it needs more examples like for example describing complexity in terms of flow table generation, and considering the behavior of fulfillment modes when the centralized controller fails.

Also Figure 3 (i.e.: page 5) is too far away than where it is referenced for the first time (i.e.: page 2).

Question: Is there a way to generate a denial of service attack to the centralized controller of our COPE prototype such that COPE fails to block the attack? If not, then we have a very robust implementation.

Future work: Implementation of a more flexible language for requests to allow the COPE controller more scheduling flexibility. This may result in improved network performance and greater accepted requests.

[Shu Zhang]

1. Paper Title : PANE.

2. Novel Idea

PANE paper makes mainly three contributions: (1) It implements a fully-functioning SDN controller which allows a network’s administrators to safely delegate their authority using PANE API. (2) It analyzes a previously proposed algorithm for consolidating hierarchical policies, and propose a new algorithm that reduces the complexity. (3) It tests the COPE system on a real OpenFlow testbed using microbenchmarks and four real applications enhanced with PANE API.

3. Main Results

The paper posted four real applications to use the COPE API. In Ekiga, users could use Reserve message to request guaranteed bandwidth. The QoS is guaranteed, and is proved feasible in practice. The nearest feasible time is calculated if the current resource is not enough for the request. But detailed stats is not shown for this test.  In SSHGuard test,it proves that COPE could be used to defend network attacks and could be used as firewalls. In ZooKeeper test, using COPE could let Zookeeper flows survive in large amount of traffic. And in the Hadoop test, the overall system performance is improved by using PANE API to reserve bandwidth. And at last, the overhead of COPE is measure, and results suggest that an individual switch could support 200 reservations per second.

4. Impact

The real-world tests show that COPE could enhance the overall performance by making reservation or other requests. Also, COPE provides a way for the network to solicit and react to the application performance needs automatically, dynamically and at a finer time scale. And it overcomes the two challenges of decomposing network control, and resolving conflicts between users’ needs.

5. Evidence

There are some core data structures and an algorithm inside COPE. Shared Tree is used to constrain the policies that can be realized in the network. The policy tree is composed with policy atoms. The conflict-resolution algorithm with conflict-resolution operators are used in the hierarchical structure (HFT) to resolve conflicts.And NIB is a lower-level component which translates higher-level requests to actual network element configurations. NIB could also be used to query the feasible configurations since it records all information about the network. And the COPE controller should deal with faults. It deals with link failures by recompiling the policy tree. To deal with the failure of the controller, the redo log is kept in the consistency layer. In the front-end, the representation of COPE is inspired by the declarative languages.

6. Prior / Related Work

SDN, Hedera (large flow recognition), darwin (like COPE but does not support over-subscription), RSVP/NSIS (single administration domains), Oktopus/CloudNaaS, other networking and Declarative languages.

[Place, Jordan]

Participatory Network (PANE)

Various authors we know well...

SIGCOMM '13

     This paper looks to move beyond the traditional SDN controllers we have read about earlier in this class. These controllers attempt to monitor network traffic and guess what network configuration will provide optimal throughput to flows. However, this problem is difficult as network traffic is normally unpredictable and the latency involved in reacting to real time traffic is often too great. The authors of this paper propose that instead of attempting to guess what traffic will look like, we allow network applications to participate in shaping the network configuration optimally.

      To allow this application-to-network communication, the authors propose an API for applications to talk to an SDN controller running OpenFlow. Through this API applications may request guaranteed minimum bandwidth, the installation of access control rules or particular routing rules. Applications may also query network state and negotiate policy changes with the SDN. The authors focus on the implementation of the controller which facilitates these requests as it is not trivial to facilitate the fulfillment of these requests and mitigate conflicts.

    The authors present their implementation and many application augmented to use the network API on github. Tests using these implementations show significant performance improvements. The authors discuss security and scalability concerns briefly, though the paper is meant to just introduce the idea of a network API and leaves these concepts open to further development.

      It is unlikely that heavily-used consumer applications will update to support a network API anytime soon (though I am sure this is the future!) so I am curious to see how PANE enhances a datacenter or a university's back-end services. Is the time it takes to alert PANE of pending Hadoop traffic actually worth the performance gains amortized over all Hadoop jobs ? How can data be collected to simulate something like this?

--
You received this message because you are subscribed to the Google Groups "CSCI2950-u Spring 13 - Brown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to csci2950u-sp13-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shao, Tuo]

Paper Title

Participatory Networking: An API for Application Control in SDNs

Novel Idea

This paper presents a design of decomposing controls over different users or groups and exposing network states and rescources to them. It also provides a way of resolving conflicts among policies.

Main Results

First, the paper decribes the data structure of share tree and policy tree to resolve its primary challenges. Based on that, it implements a fully-functioning SDN controller and provides API to upper-layer applications. Second, it proposes a new algorithm to reduce the complexity from expontional to polynomial. Third, the functionalities of the controller are tested along with four applications.

Impact

The controller provides a bunch of features to expose resource allocation, priviledges and predictablitity of network state durations. Thus it enables applications to reason about the current and future network states and make better decisions.

Evidence

First, the paper gives us a overview of COPE, including the model of interations and the types of messages used in the interation between controller and applications. Second, It decribes a data structure-share tree-to delegate different principles which represents different visiblities of the network control. Third, it describe how it resolve conflicts between policies. It also proposes a new algorithm to reduce the complexity of both time and space. In addition, it raises other considerations of controller design. At last, it tests how it affects applications' performance by testing ported application with COPE's API supported and it also tests switch's operation times on real switches.

Prior Work

[16] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi. Hierarchical Policies for Software Defined

Networks. In HotSDN ’12.

[17] A. D. Ferguson, A. Guha, J. Place, R. Fonseca, and S. Krishnamurthi.

Participatory Networking. In Hot-ICE ’12.

Reproducibility

The source code of the controller are already provided, so reproducing the results in the paper is achievable.

On Mon, Apr 22, 2013 at 7:50 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Papagiannopoulou, Dimitra]

Title: Participatory Networking: An API for Application Control in SDNs

Novel Idea: This paper presents the design and implementation of an API serving as the next layer on the current SDN stack, that can be used by applications to control SDNs and is implemented by an OpenFlow controller. The authors build a prototype Controller for Participatory Networking (COPE), which is logically centralized but has a global view of the  network, and delegates read and write authority from the network's administrators to the end users or applications.

Main Result: The main result of the paper, is the design and implementation of COPE which addresses two key challenges of participatory networks. First, how to provide a flexible mechanism that decomposes network control and visibility, giving multiple principals control over a portion of the network resources. Second, how to resolve conflicts between participants and across requests while maintaining fairness and security. Through an OpenFlow testbed using microbenchmarks and experimentation with four real applications, the authors evaluate COPE's performance and demonstrate its feasibility and usefulness.

 

Impact: The work done in this paper can have a great impact on applications such as video conferencing or Map-Reduce style  applications that, through the assignment of control over a portion of the network resources, can achieve certain bandwidth guarantees and benefit in terms of performance. It could also benefit applications such as an intrusion detection script running on a user machine, that needs to filter traffic or an RPC service that needs to protect latency-sensitive flows.

 

Evidence: The authors begin with an overview of COPE, presenting its model of interaction, its message types (requests, queries and hints) and providing useful definitions of key terms such as flowgroups, shares, share trees, policy atoms and policy trees.  Then, they proceed to a more detailed description of key concepts such as Access Control through Allow and Deny requests, Minimum Bandwidth Guarantees through the Reserve privilege, Path Control and Rate-limits, and describe COPE's notion of Principals, Flows and Privileges. They discuss how COPE uses operators to resolve conflicts and how the compiler addresses requests. They provide a complexity analysis of the compilation algorithm, which shows that when the number of policy atoms is larger than 2^h,  (where h are the header fields of OpenFlow patterns) then the algorithm runs in O(n²) time and produces a flow table of size O(n²). This is an improvement over a direct implementation of the HFT algorithm which produces flow tables of size O(2ⁿ). So the new proposed algorithm, reduces complexity from exponential to polynomial. The COPE prototype is evaluated using the Mininet platform for emulating SDNs, as well as on real networks. Four real applications were ported to use the COPE API (Ekiga, SSGGuard, ZooKeeper and Hadoop). These four case studies showed how COPE can improve user experience. The results on Ekiga demonstrated the feasibility of making reservations for VoIP applications that use COPE. COPE's behavior in SSHGuard showed its ability to off-load work from the end host's network stack and to block DoS attacks. ZooKeeper's and Hadoop's performance improved when they used COPE for bandwidth reservations. Finally, through the evaluation of COPE on current OpenFlow networks, the authors obtained the resulting latency distribution and found that the overhead of establishing reservations outweighed the performance benefit for smaller flows.

 

Prior Work: The paper is based on participatory networks which were discussed in [17]. The concept of 'shares' was also discussed in [17]. It uses Hierarchical Flow Tables (HTFs) introduced in [16], that provide flexible conflict resolution operators and a compiler. COPE uses these operators to resolve conflicts and the compiler to fulfill requests. The implementation of the Network Information Base (NIB) is inspired by Onix [29]. COPE builds upon control-plane abstractions proposed by Onix for OpenFlow and 4D [23] networks. Finally, COPE relies on reservations and prioritized queue management [28,43].

 

Related/Competitive Work: Previous research on Active Networking [44] also shared the idea of allowing users to make decisions on network operations. Other works such as Hedera [1], Ident++[34], Darwin [9] and [46] described how information from end-users or applications can help network configuration and enhance flexibility and performance. RSVP [8] and NSIS [32] protocols, showed how applications could reserve network resources, but COPE is designed for single administrative domains and gives applications control over the choice of network paths, while RSVP and NSIS don't. Oktopus [3] and CloudNaaS [4] are complementary to COPE. Some of COPE's design aspects are inspired by projects such as the Margrave tool [36], RCC [15] and FML [25].

 

Reproducibility: The results of the paper are reproducible if the same set of experiments is carried out.

 

Criticism: Overall, this is a great work. The paper is very well written and comprehensive. COPE's parameters and terms are clearly defined and presented throughout the paper. The authors cover many aspects of their design, describing not only how it compares to related work but also how it could benefit from existing work (Hedera, Mahout, MicroTE,D3) and discuss specific ideas for future work. The proposed API can be very beneficial for certain applications. Using COPE, applications can issue queries to improve the user's experience. It provides a novel conflict-resolution algorithm, minimum bandwidth guarantees and control over the flow paths. It includes a compilation algorithm with reduced complexity. The authors use a real OpenFlow testbed to demonstrate COPE's practicality and usefulness as well as four real applications. The evaluation process clearly demonstrates how the applications can benefit from it. The paper includes a discussion on fault tolerance and resilience, which are both very important. Some of COPE's weaknesses are that, while its principles are authenticated, the prototype is not protected against principals that could issue excessive requests. Regarding the implementation practicality, COPE imposes some limitations when the application includes a considerable amount of smaller flows. Addressing these two aspects of COPE could further improve it in the future.  

 Overall, this work includes great ideas, it incorporates important features to the proposed prototype and offers a very strong approach.

 

Question: Something that was not very clear to me is how COPE addresses cases of flows with certain deadline limitations, in the example of Figure 2. 

On Mon, Apr 22, 2013 at 7:50 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[kmdent]

Participatory Networking

Novel Idea: An API to interact with software defined networks built with on openflow. They deal with how to provide control and visibility of the network as well as how to resolve conflicts while preserving security and fairness across the network. The basic idea is that the more a programmer knows and can program the network, the more efficient and predictable it can become. COPE implements the network admins restrictions by changing the configuration of the devices.

Main Result: COPE uses a share tree to ensure flows have appropriate privileges and a policy tree to represent the global policy state of the network and is backed by a HFT. The share tree helps to aid in conflict resolution, i.e. the outcome is that of the child, not the parent. The policy tree is then used to install appropriate rules in the switches to achieve this state. When a request is sent to COPE, it first checks to see if it’s permissions match that of it’s flow group, it then checks to see if it is compatible with the state of the network, and then if these two tests pass, it is incorporated into the tree, and installed on the network. COPE allows for partial vs strict fulfilment policy, i.e. whether or not a request is partially overlapping with another rule. COPE also provides functionality of requesting a reservation for resources in the future. With a log of previously accepted requests, COPE is fairly fault tolerant.

Evidence: They ported Ekiga, SSHGuard, ZooKeeper, and Hadoop to analyze the additional latency brought on by COPE. The applications they implemented were a pretty representative bisection of applications.They also take into account the ease of using this system with existing applications.

Prior work: IntServ, RSVP, NSIS

Impact: I think this will have a big impact in the future. It is moving towards a more easily customizable and efficient network. It is fairly new, and still features not yet implemented such as distributed rate-limiting.

Crit: It seems odd that the default installation time is permanent. Defaulting to permanent seems like it would introduce more bugs when programming. If it was partial, the programmer would have to directly confront the time period.

-- 

kmdent

[Rodrigo Fonseca]

On behalf of David Trejo:

On Monday, April 22, 2013 7:50:57 PM UTC-4, Rodrigo Fonseca wrote:

[Charles Zhang]

Paper Title: Participatory networking: an API for Application Control in SDNs

Date: to be submitted to sigcomm 13

Novel Idea:

This network control API delegates the read and write authority from the network’s authority to end users, or applications and devices acting on their behalf. The design of the API addresses two key challenges: how to safely decompose control and visibility of the network, and how to resolve conflicts between untrusted users and across requests, while maintaining baseline levels of fairness and security.

Main Results:

Implemented a fully functioning SDN controller which allows a networks administrators to safely delegate their authority using the API, analyzed a previously proposed algorithm for consolidating hierarchical policies, and proposed a new algorithm that reduces the complexity from exponential to polynomial, and demonstrated the system’s usefulness and practicality on a real openflow testbed using microbenchmarks and four real applications using this API.

The key data structures for this system are two trees: share tree to determine the previleges that principals have to read and write, policy tree to hold policy atoms that can affect the network.

Some of the control powers exposed by this API include access control for allowing or denying flows, minimum bandwidth allocation between two end points, path control for specifying which waypoints to avoid, and rate limits. The API also has mechanism for querying the network states. The system and also give hints based on previous knowledge of the network.

Usage and evaluation:

This system is ported on four real applications. Ekiga, a video conferencing application that asks the user the desired duration of the call, SSHGuard, Zookeeper, and Hadoop. They also evaluated the practicality of implementing the COPE API in current open flow enabled networks

Prior work: Hierarchical flow table is used to resolve conflicts in a hierarchy of policies. Active networking allows participants to take part in the decision making process. A lot of previous work use application layer information to aid the lower layers. COPE also relies heavily on existing mechanisms such as reservation and prioritized queue management. And COPE is inspired by works done for network and firewall configuration and analysis.