# The Future of Networking, and the Past of Protocols
### SDN
* Is SDN the right solution?
* Talk is not about what SDN is, but why SDN is
### Key to Internet success: layers
* Multiple layers of networking
* The importance of layerings
* Decomposed delivery to fundamental components
* It enables independent but compatible innovation at each layer
* SDN <--> Internet
* An amazing success but an academic failure
* Build an artifact, not a discipline
* Other fields in "systems": OS, DB, etc.
* Teach basic principles
* Are easily managed
* Continue to evolve
* Networking
* Teach big bags of protocols
* No principles to teach lol !
* Notoriously difficult to manage
* Evolves very slowly
#### Why does networking lag behind?
* Networks used to be simple
* IP is incredibly simple protocol, ethernet...
* New **control** requirements led to great complexity
* Fortunately, the infrastructure still works...
* Only because of your great ability to master complexity
* Lowest level (how much you have to keep in your head)
* The ability to master complexity is both a blessing and a curse
#### A simple story about complexity
* \~1985: Don Norman
* Talks about user interfaces and stick shifts
* Stick shift! None of you should manage the interface!
* The ability to **master complexity** is not the same as the ability to **extract simplicity**
* When first getting systems to work: focus on mastering complexity
* When making system easy to use and understand: focus on extracting simplicity
#### What is the point
* Networking has never made the distinction
* And therefore has never made the transition
* Still focused on mastering complexity
* Little emphasis on extracting simplicity from control plane
* Intellectual foundations
* Necessary for creating a discipline
* Other example: programming
* Machine language
* OS and other abstraction
* Modern langauges: object orietnation, garbage collection
#### The power of abstraction
* "Modularity based on abstraction is the way things get done" - Barbara Liskov
* Abstractions --> Interfaces --> Modularity
* What can we do in Networking
* Layering: only deal with the data plane
* We have no powerful control plane abstractions
* How do we find those abstractions
* Define our problem, and then decompose it
* **The network control problem**
* Compute the configuration of each physical device (e.g. forwarding tables, ACLs)
* Operate without communication guarantees (e.g. fields in packet headers, losses)
* Operate within given network-level protocol
* Only people who love complexity would find this a reasonable request
* Programming analogy
* What if programmers had to: specify where each bit was stored; explicitly deal with all internal communication errors; within a programming language with limited expressibility
* Programmers would redefine problem: higher level abstraction for memory, build on reliable communication abstractions, use a more general language
* **Abstractions** divide problem into tractable pieces: make task of control program easier
#### From requirements to abstractions
1. Operate without communication guarantees
1. Need an abstraction for **distributed states**
1. Shield mechanisms from vagaries of distributed state
1. While allowing access to this state
2. Natural abstraction: global network view
1. Annotated network graph provided through an API
3. Control mechanism is now program using API
1. No longer a distributed protocol, now just a graph algorithm
2. E.g. Use Dijkstra rather than Bellman-Ford
3. "logically centralized"
2. Compute the configuration of each physical device
1. Need an abstraction that **simplifies configuration**
1. Network virtualization
2. E.g. "access control"
1. A can or cannot happen to B: don't care about switches
3. Operate within given network-level protocol
1. Need an abstraction for general **forwarding model**
1. Abstraction should not constrain control program
2. But it should hide details of underlying hardware
1. Crucial for evolving beyond vendor-specific things
### One sentence
* SDN is defined precisely by these three abstractions: distribution, forwarding, configuration
* SDN can be derived from decomposing network control
* Fundamental validity and general applicability
### Realizing these abstractions
* Core challenge
* **Make distributed control problem a logically centralized one**
* Design a common distribution layer
* Gathers information from network elements (topology)
* Disseminates control commands to network elements
* This is done by network operating system
* Traditional control mechanisms
* 
* SDN
* 
* Major change in paradigm
* No longer designing distributed control protocols
* Now just defining a centralized control function: configuration = function(view)
* This spells the end for distributed protocols
* Easier to write, reason about, and maintain
* Beginning of "software era" of networking
* Rate of change, nature of standards, different culture, etc.
* Other challenges
* Requires a shared control layer
* Map abstract configuration to physical configuration
* 
* Add network virtualization layer
* Forwarding abstraction
* Switches have two brians: management cpu (smart but slow), forwarding asic (fast but dumb)
* Need a forwarding abstraction for both
* CPU abstraction can be almost anything
* ASIC abstraction is much more subtle: OpenFlow
* All this assumes switches are unit of abstraction
* Why not fast, cheap fabrics? (in datacenters)
### Keep in mind
* OpenFlow: of is a detail in the overall SDN architecture
* Crucial for industry; but minor piece architecturally
* Don't let the tail wag the dog
* Dog: clean separation of concerns
* Control program: specify behavior on abstract model
* Driven by operator requirements
* Network virtualization: map abstract model to global view
* Driven by specification abstraction
* NOS: map global view to physical switches
* API: driven by distributed state abstraction
* Switch / fabric interface: driven by forwarding abstractions
* SDN: value proposition
* build ecosystem that we can have progress going on in all pieces
* maintain an overall coherent system
### Final words
* Future of networking lies in finding right abstractions
* The era of "a new protocol per problem" is over
* Takes years to internalize and evaluate abstractions
* Even longer to adjust to software-oriented culture
* Early stages of an intellectual voyage
* We should keep our minds open while charting our course