Reviews for Foster11Frenetic
Rodrigo Fonseca
Zhiyuan "Eric" Zhang
Paper Title
Frenetic: A Network Programming Language
Authors
Nate Foster, Rob Harrison, Michael J. Freedman, Christopher Monsanto, Jennifer Rexford, Alec Story and David Walker
Date
ICFP 11'
Novel Idea
This paper present Frenetic, a high-level network language for programming OpenFlow switches. It has two components: a declarative network query language and a network policy management library. The network query language is allows programs to access the state of network in a high-level and declarative way. The network policy management library uses functional reactive programming combinators to govern packets and manage policies.
Evidence
The authors provide the language design and a series of sample application to support their points. They also discuss their experiment of comparing Frenetic programs with equivalent NOX programs. They are evaluated on three metrics: lines of code, traffic to controller and total traffic.
Prior Work
The Frenetic language is implemented on the NOX controller[20]. The library design and event functions are inspired by Yampa[12] and other functional reactive languages.
Competitive work
Several other high-level network languages have been proposed, such as FML[23] and Nettle[39]. Nettle is a network language that also uses FRP combinators for OpenFlow switch programming. The main difference between these two is that Nettle is a substitute of NOX while Frenetic is running on higher-level where on top of Nox.
Reproducibility
Their implementation is open sourced on github. It should be easy to reproduce their experiment on Mininet.
Question
What is the advantage of having a runtime system between applications and the network? I can see that it brings more flexibility. Is there more? I'm also thinking about the delay of the runtime system. Is there any performance/scalability issue here?
Comments
I think this paper is a really good combination of programming languages and network research. It contains formal syntax of the language, and gives tons of sample code as well. From the network and system aspect, it discusses the implementation, architecture and performance evaluation. Although there might be some details not covered, I think it is totally reasonable due to the length of the paper.
Christopher Picardo
Paper Title:
Frenetic – A network Programming Language
Authors:
Nate Foster, Rob Harrison, Michael J. Freeman, Christopher Monsanto, Jennifer Rexford, Alec Story, David Walker
Date:
September 19 – 21, 2011
Novel Idea:
Frenetic is a functional reactive programming language operating at a packet level of abstraction.
More precisely, it is a high level language for programming distributed collections of network switches. Provides high –level abstractions that free programmers from having to reason about a host of low level details involving the underlying switch hardware.
Of note, Frenetic has a novel runtime system, which manages all of the details to installing, uninstalling, and querying low-level packet processing rules on physical switches.
- The paper analyses the state of the art in languages for programming networks and identify the key limitations.
- Frenetic addresses these limitations.
- Frenetic implementation is described, and its performance evaluated on several benchmarks.
Main results:
Frenetic ’s Network Query language:
1. Queries compose seamlessly with one another.
2. The Frenetic run-time system suppresses superfluous packets that occur due to race conditions in the underlying network, giving queries a simple race-free semantics.
3. Queries have a simple clear cost model that depends primarily on the number of inhabited microflows, not the number of packets within a microflow.
Frenetic ‘s Implementation:
1. Complete working prototype implemented as an Embedded combinatory library in Python. Consists of the Frenetic language itself, the run-time system, and NOX controller.
2. The runtime translates the high level forwarding policy into switch-level rules reacting to flows of network traffic as they occur.
3. The run-time system’s use of exact-match rule follows the approach used in Ethane and many OpenFlow-based applications and is well-suited or dynamic settings.
Experiment Results:
- Frenetic compares comparable to NOX hand-written NOX programs.
- Frenetic provides substantial code savings to the network programmer. For example, Frenetic ’s compositional semantics permit to easily compose monitoring modules with each of the forwarding policies unlike the NOX programs, which had to be manually refactored to correctly implement each version of the micro benchmark.
-Programmers, aided by Frenetic ’s LFLSW which dynamically discovers a network topology, can write sophisticated network programs that actually consume less network capacity than hand-written NOX programs.
- Frenetic ’s runtime system does not perform well when the optimal implementation of the forwarding policy uses wildcards. Authors suggest extending the run-time system to support wildcard rules. Right now the NOX application significantly outperforms the reactive microflow based approach used in Frenetic.
- Scalability experiments show Frenetic performance scales better than NOX in many cases. Frenetic, does not use timeouts.
Impact:
Frenetic addresses some serious problems with the OpenFlow/NOX programming model by introducing a collection of high level and compositional operators for querying and transforming streams of network traffic.
A runtime system handles all of the details related to installing and uninstalling low-level rules automatically as opposed to possibly less optimal manual installations.
Evidence:
Experimental evaluation demonstrates that the performance of Frenetic’s run-time system is competitive with hand-written Openflow/NOX programs.
Prior work:
Work inspired by Openflow/NOX.
Question:
Frenetic is trying to solve the problem of not having a universal tool for programming a network. Therefore as a nascent language (at time of publication) it seems to lack the ability to support security applications that among other tasks, perform network authentication and access control. What kind of difficulties could Frenetic encounter when attempting to interact with secure networks that do not play well with the Frenetic programing language?
Shu Zhang
“There's no problem in Computer Science that can't be solved by adding another level of indirection to it”. - David Wheeler
The Frenetic paper is a proof of the quote above. The general idea of the paper is that, “Wow, NOX cannot perform well in so many aspects ! So let’s add a layer over it and it will work!” So then, a run-time system layer is built, and upon which a new version of network programming language module is built, and the authors claim, “Hey, you see, the problems solved by adding extra layers of abstraction!”
The paper has mainly three parts, first it analyzes the key limitations of the network programming languages (by default they are used in SDNs such as Openflow and using controllers such as NOX) before Frenetic was introduced. Then it proposes Frenetic and its usage and components/interfaces opening to programmers. At last implementations and evaluations are mentioned.
The Openflow/NOX framework has limitations. First, the interaction between concurrent modules might be poor, which means the degree of coupling of different functions might be is not loose, so it is not easy to write a program which has two functions to cooperate with each other because we have to manually set the composition on switches such as ordering the priorities. Second deficiency is similar to the first one because the low-level programming interfaces bring bad programming practice, programmers sometimes have to set overlapping rules on the switch and use priorities to disambiguate between them. The third is that the system architecture is two-tiered, so programmers have to think about switch and controller simultaneously. The last is the occurrence of race condition and it will bring inconsistency for rule establishment and forwarding.
The paper said Frenetic could cope with these problems. First it shows the basic usage of the language. In high level, the language is divided into two modules, one is the network query language, another is the network policy management library. The basic building block of the mechanism is the “event”. The event might be anything, it might be a packet, it might be a stat, so the “event” is quite different from people’s intuitive thought. The network query language is one-level so it gives the programmer an experience that it could “see” all packets in the network. The network policy management library language has the same target as other policy making language like POL-ETH or FML. But as we can see, the language syntax is not like the <Pattern : Action> mode, the language should follow some syntax like functional programming. Although I have no experience in functional programming , but a big impression it leaves on me is the chain-like programming style which makes programming a lot easier and neater. the example in the balance function is a good example, it used “>>” operator to link different parts and the operator acts like a pipe. It is pretty cool if programmer could write language in such as natural way.
The network query language is using a syntax quite like SQL. So the code will be very easy to understand. The Limit() is a good function because by imposing limit() we can get rid of the situation that all packets should be forwarded to the controller. To query composition is easy in this form by simply using Merge() to combine two different queries. The query language copes the race problem by using Limit(). Along with the query language is the query cost model. The cost of queries is relevant to the number of microflows and how often / how many packets the program want to deal with flows. Using Limit() could greatly decrease the cost.
The network policy management library is to impose rules on patterns. The basic idea is to control the installation of policies in a network over time by generating policy events. The events are built upon the NOX messages, as we can see later. Using functional programming and operator overload, the programs could be written in a neat way, the load balancer code is a good example.
What makes frenetic magic is its implementation, which is a middle layer lies below the frenetic language and above the nox. The idea of translating the policy and queries to switch flow table entries is pretty straightforward: If there is query programs which want to see each packet, we don’t add flow table rules in switch, otherwise we add flow table rules so as to lower the cost. Also, by utilizing the counters in the openflow switches could alleviate the workload of querying the aggregate stats. So actually, Frenetic does not solve the problem of NOX/Openflow described in section 2, indeed these problems could not be solved as long as we are building our systems on top of them. Instead, Frenetic builds additional layers so as to HIDE these inconveniences to programmers.
In the evaluation part, the diagrams show that Frenetic beats naive NOX programs in lines of code as well as traffic consumption.
Question ( confusion ):
Why Frenetic wants to use functional programming style? I admit it is cool, but for programmers like me who is not familiar with it, it might be an obstacle impeding me to use it. How about using OOP idea?
For example, there are two interfaces, one is for policy language, another if for query language. The user can create its own Frenetic class and do whatever he wants to do by implementing these two interfaces.
Jeff Rasley
Context: ICFP 2011 (functional programming conference)
One major aspect of this paper that I find interesting is the collaboration of networks/systems and programming languages researchers. In addition to this contribution the paper outlines 4 major contributions.
1) An analysis of current OpenFlow/NOX difficulties
2) A design and overview for the Frenetic language
3) A Frenetic implementation
4) Evaluation of a few applications written with Frenetic
In terms of analysing current systems, they state that systems like NOX, Onix, Beacon and Nettle suffer from 4 similar issues:
1) Lack of component composition.
2) Languages are too low-level, which leads to cumbersome and error-prone code.
3) Required to program to controller and switches, which leads to two-tiered architecture.
4) Race conditions related to time to install rules and when packets enter system.
Frenetic aims to alleviate these outlined issues. It appears the reproducibility of their evaluation should be obtainable since it appears some of their source is on github.
On Monday, March 11, 2013 9:27:48 PM UTC-4, Rodrigo Fonseca wrote:
DTrejo
On Monday, March 11, 2013 9:27:48 PM UTC-4, Rodrigo Fonseca wrote:
Place, Jordan
Jennifer Rexford, Alec Story, David Walker
ICFP '11
Today, there are a wide variety of SDN programming languages
available to network administrators. This paper analyzes one of these
languages, offered by NOX, asserting that it does not offer enough
modularity or high-level abstractions to ensure that network
management programs are transferable and free of human error. As a
better solution, the authors propose a new layer of abstraction, built
on top of NOX, called Frenetic which allows network adminstrators to
create modules for managing switch logic. These modules can then be
merged and combined easily and without error.
The authors offer details about the performance, implementation
and deployment of Frenetic, all of which imply it is as good if not
better than NOX itself. They also cite many competing SDN languages
and discuss how Frenetic may be used to replace them or work on top of
them.
Frenetic is definitely a step in the right direction for SDN
programming. The ability to layer and modularize network policies
without having to think about the lower-layer details is powerful and
sure to improve network setup speeds and reduce policy-writing errors.
I'm curious as to whether there may be a better way to indicate to
program writers how "expensive" their programs are; as Frenetic
stands, it seems there is now a whole other class of human error
available where programs generate either an unexpected amount of rules
or cause unexpected and hard-to-debug performance issues.
> 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.
>
>
Zhou, Rui
Rodrigo
kmdent
By N. Foster, R. Harrison, M.J Freedman, C.Monasnto, J. Rexford, A. Story, D. Walker
Novel Idea: Fernetic is a network programming language aimed at fixing some of the weak spots of other languages, mainly NOX. They aimed to introduce modularity and high level reasoning about networks, which it’s predecessors were lacking. Whenever possible they tried to create a framework that considered how the programmer would reason about something as opposed to how the low level implementation did.
Evidence: They ran tests comparing NOX and Fernetic on a mininet visualization. It was run on a 2.43GHz processor with 4GB of ram. The tests the two using all to all communication, gathering statistics from a server, and collecting statistics on a per host basis with multiple policies. In general, Nox slightly outperformed Frenetic.
Main Results: Fernetic allows the programmer to reuse a substantial amount of code while sacraficing minimal network performance in most cases, and in some cases, the abstraction over nox allowed the programmer to more efficiently use the network. They mention the Wildcard case, in which NOX significantly outperforms Fernetic.
Prior Work: Openflow, NOX, ONIX, Beacon, Nettle
Competitive Work: FML
Ideas for further work: Quality of service guarantees for any Network programming language, as it would be extremely useful.
Papagiannopoulou, Dimitra
Paper Title: Frenetic: A Network Programming Language
Authors: Nate Foster, Rob Harrison, Michael J. Freedman, Christopher Monsanto, Jennifer Rexford, Alec Story, David Walker
ICFP'11
Novel Idea: In this paper, the authors propose Frenetic, a new, high-level, domain-specific language for programming OpenFlow networks, in an effort to address some serious issues with the OpenFlow/NOX programming model. Frenetic is embedded in Python and includes a high-level declarative network query language, and a reactive network policy management library.
Main Results: The main result of this paper is the design and implementation of Frenetic, a new programming language for OpenFlow networks, that offers a number of features to make programming easier such us strong composition properties, a clear cost model and simple race-free semantics. Through an experimental evaluation of Frenetic's run-time system, using several benchmarks, the authors show that its performance is competitive with OpenFlow/NOX programs.
Impact: The impact of this work is significant, as it proposes an efficient language that is capable of solving many of the issues and limitations of the OpenFlow/NOX programming model and makes programming more convenient.
Evidence: The process the authors follow to present their ideas is as following: They begin by analyzing the OpenFlow/NOX weaknesses. Then, they talk about how Frenetic's design addresses those limitations, using various examples. Finally, they describe the implementation architecture of the language and its run-time system and perform a set of experiments using microbenchmarks to evaluate its performance. They compare Frenetic with NOX, in terms of lines of code, controller traffic and aggregate traffic for several numbers of hosts, and find that Frenetic programs are more comprehensive while achieving similar performance levels.
Prior Work: This paper is an extension upon preliminary work [19] that was done by the same team, but did not describe a run-time system, query language and applications or provide performance evaluation. Frenetic is a new programming language intended to address the challenges and difficulties that OpenFlow [31] programmers often face. OpenFlow uses a programmable controller, NOX [20]. Frenetic's implementation, also uses the NOX controller, which provides Python and C++ APIs for handling raw events and communication with switches, although several other OpenFlow controllers exist such as Beacon[1], Maestro [8], Onix [25] or SNAC [4]. Many of Frenetic's primitives are borrowed from languages such as Yampa [12] a language for programming robots, and part of its implementation is also based on FrTime [11]. The design of the network policy management library was inspired by Yampa and its implementation strategy is similar to FlapJax [32], a library for web programming. Finally some parts of the run-time system follow approaches previously used by Ethane [9] and other OpenFlow-based applications [18, 21].
Competitive Work: Some competitive work includes Click modular router [24], that is also intended to make network devices more easily programmable, and aims in modularity, but in contrast to Frenetic, Click targets only software switches. Other systems such as RouteBricks [15], Bro [35], Snortran [16], Shangri-La [10] and FPL-3E [14] have been proposed, but they are limited to a single device and as a result they don't provide a solution to programming a set of switches. Nettle [39] is a language that also uses FRP combinators to program OpenFlow switches, but it has significant differences from Frenetic, such that it operates at a lower level of abstraction. NDLog [27,28], an extension of Datalog, also has important differences compared to Frenetic even though they both use high-level languages to program networks.
Criticism:
This is a very good paper, that proposes an alternative new language as a solution to the existing problems of the OpenFlow/NOX programming model. Existing network programming languages that are defined at the low abstraction level, fail to provide support for modular programming, resulting in complicated network programs that are vulnerable to errors and difficult to maintain. By creating Frenetic that is a high-level language organized around two levels of abstraction, a set of source-level operators and a run-time system for installing/uninstalling low-level rules on switches, that allows to raise the level of abstraction without sacrificing performance, the authors give a solution to the limitations imposed by existing languages. They show that it is easier to write simple, modular, reuseable programs in Frenetic than it is in NOX. Furthermore, they include a performance evaluation in which they compare Frenetic against NOX using many microbenchmarks, and reporte results on important parameters that represent its efficiency (such as lines of code, that indicates the complexity of each program, the controller traffic, that indicates the overhead of managing switch-level rules using the run-time system and the aggregate traffic that measures the total load on every link in the network). Moreover, the authors include clear examples as well as pseudo-code to describe the language design and implementation and talk about their future plans on extending it further. Overall it is a very good work that offers significant results.
Reproducibility: The results are reproducible.
Question/Class Discussion: While the lines of code seems a reasonable metric to measure the language's effectiveness, the authors could also use more sophisticated metrics motivated by the programming language community (such as how much effort someone needs to interpret the code, how easily bugs can be created, or how difficult it would be for the programmer to detect those bugs in the program and recover from errors). Furthermore, a very useful evaluation metric would be how fast their applications run using this language, apart from how many lines of codes are required. So, while the number of lines of code is a useful evaluation metric it is not necessarily enough to determine the effectiveness of the language. What other metrics would you suggest for this case?
Rodrigo