Presenter: Sean Donovan
Authors: Sean Donovan, Nick Feamster (Georgia Institute of Technology)
Paper: http://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final102.pdf
Sean starts by describing the story of catching a spy acting in a company, only knowing that he/she uses some VoIP technology. Out of a network log, the obvious first thing to do is to isolate VoIP flows. The problem though is that it is likely that there will be a lot of concurrent VoIP traffic and often, a lot more will be mixed in. How can someone filter out everything that does not relate to the spy? You could filter based on the IP address, but the spy can move, e.g. change access point, or start using a different VoIP services (Google Hangout today, Skype tomorrow). Sean believes that "SDN is a good hammer to nail this problem".
In this paper, the authors introduce Intentional Network Monitoring (INM) which can be seen as an extension of the Intentional Naming System concept (see http://nms.csail.mit.edu/projects/ins/). With INM, one can express monitoring requirements at a high-level, one that maps operator's understanding of what is going on in the network. For instance, INM enables to express requirements such as "Capture all traffic from Sean". Other examples of INM usage include billing based on traffic type or redirecting traffic based on source networks.
To realize INM in practice, Sean implemented NetAssay (check out his code: https://github.com/sdonovan1985/netassay/). NetAssay is a SDN-based system built on top of Pyretic (http://www.frenetic-lang.org/pyretic/). NetAssay policies are declarative. You say what you want, and the system figures out (compiles) the low-level rules that need to be spit out to the SDN devices. At a high-level, NetAssay can therefore be seen as a mapping engine that can harness whatever existing mapping systems out there such as BGP, DNS, ARP, LDAP, etc. Right now, they have two mapping engines in place: DNS and BGP.
The biggest challenge faced in compiling NetAssay policies is the number of forwarding rules they currently require. It is indeed possible to completely exhaust switches' forwarding resources with a single NetAssay policy. The authors are currently looking at optimizations mechanisms to speed up: the compilation time; as well as the size of the produced forwarding policies.
- Q&A
Q: What is the difference between NetAssay and functional programming?
A: Different objectives. NetAssay is working at a higher level, and is only concerned by the match() part of a SDN forwarding rule, not the action part.
Q (Vyas Sekar): How do you deal with name changes?
A: Interesting question. We haven't considered that case yet.
There are some similarities to functional programming. Procera (HotSDN 2012) also performs actions based on similar types of sets (e.g., the set of all authenticated hosts). NetAssay requires similar functional abstractions, and it might even be possible to express the NetAssay functions in a language like Procera.
ReplyDeleteThe Procera runtime, however, cannot cannot rapidly re-evaluate the types of functions that we aim to express with NetAssay (e.g., when BGP routes change continuously, the runtime would need to continually re-map AS numbers to corresponding flow-table rules, which requires new optimizations).
The contribution of NetAssay is thus primarily the runtime that scalably supports these abstractions, not the programming abstractions (which would be similar to something like a functional language such as Procera).
Ace4sure is the website that deals in preparation material for the exam for many years. According to my exposure and research, this is the right platform where you can get exact 1z0-1075 exam dumps.
ReplyDelete