The Future of Networking, and the Past of Protocols

https://www.youtube.com/watch?v=YHeyuD89n1Y

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