Engineer versus Complexity Russ White/rule11.us Networks are - - PowerPoint PPT Presentation

Engineer versus Complexity

Russ White/rule11.us

Networks are complex…

• And ge'ng more complex

all the 2me

• But what is complexity,

really?

• Can we put a network on a

scale that measures complexity?

You can’t “solve” complexity

• Why not just

make things simple?

• Because

complexity is required to solve real world problems

In our view, however, complexity is most succinctly discussed in terms of functionality and its

• robustness. Specifically, we argue that complexity

in highly organized systems arises primarily from design strategies intended to create robustness to uncertainty in their environments and component parts.

Solu2on Effec2veness Robustness Complexity

Alderson, D. and J. Doyle, “Contras:ng Views of Complexity and Their Implica:ons For Network---Centric Infrastructures”, IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 40, NO. 4, JULY 2010

You can’t “solve” complexity

• If you can’t “solve”

complexity…

• Then—abandon all hope ye

who enter here?

• No!
• Instead, we need to learn to

manage complexity

Why?

• Acts as an abstractor
• Only look at the stuff you need to understand the

system

• Closes off rabbit trails
• “Why does IS-IS elect a DIS?”
• “That’s a good ques2on, but it’s not related to fixing

these slow DNS queries…”

• Connects the technical to the business
• Unless you can explain why this problem is important

to solve…

• It’s probably not!

What?

What?

• What rou2ng protocol …?
• What features… ?
• What topology… ?
• These are all good ques2ons…
• But they don’t get at complexity
• What is complex about this system?
• What tradeoffs were made in system design?
• We need to understand complexity beUer…

10

• “Department of Defense” (DoD) model
• Origin of TCP/IP
• Recursive Internet Architecture (RINA) model
• hYp://csr.bu.edu/rina/
• IP Fast Reroute

DoD Model

• How can state be divided up to

produce clean interfaces between different so]ware components?

• What informa2on must be

moved from component to component to transmit informa2on from applica2on to applica2on?

• Lateral across the network
• Ver2cally among components

Link Internet Transport Applica2on Link Internet Transport Applica2on

DoD Model

• What state is contained here?
• How much?
• How fast does it change?
• What state is shared here?
• How much does the internal

state mix between these two components?

• What am I op2mizing by

spli'ng this state up?

• What is the goal of breaking

this up into mul2ple subsystems?

Link Internet Transport Applica2on Link Internet Transport Applica2on

DoD Model

• What state is contained here?
• How much?
• How fast does it change?
• What state is shared here?
• How much does the internal

state mix between these two components?

• What am I op2mizing by

spli'ng this state up?

• What is the goal of breaking

this up into mul2ple subsystems?

Link Internet Transport Applica2on Link Internet Transport Applica2on

Network Device

RINA Model

• Recursive Internet

Architecture

• What processing

needs to take place to transmit informa2on from applica2on to applica2on?

• Iden2fies four

processes: Transport, Mul2plex, Error handling, Flow control

• Grouped into two

complimentary pairs

• Who needs to do it?
• Interface, host,

applica2on

• Network device

App to App

TR/MULT ERROR/FLOW

Host to Host

TR/MULT ERR/FLOW

Interface to Interface

TR/MULT ERROR/FLOW TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW

Network Device

RINA Model

App to App

TR/MULT ERROR/FLOW

Host to Host

TR/MULT ERR/FLOW

Interface to Interface

TR/MULT ERROR/FLOW TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW

• What state is required here?
• How much?
• How fast does it change?
• What state is shared here?
• How much does the internal

state mix between these two components?

• What am I op2mizing by

spli'ng this state up?

Network Device

RINA Model

App to App

TR/MULT ERROR/FLOW

Host to Host

TR/MULT ERR/FLOW

Interface to Interface

TR/MULT ERROR/FLOW TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TR/MULT TR/MULT ERR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW TRANSPORT/MULTIPLEX ERROR/FLOW

• What state is shared here?
• How much does the internal

state mix between these two components?

• What am I op2mizing by

spli'ng this state up?

• What state is required here?
• How much?
• How fast does it change?

Control Plane Example

• A uses the path through B as to

2001:db8:0:1::/64

• Path through C is blocked by the

control plane

• We would like to be able to use

C as an alternate path in the case of a link failure along A->B- >E

2001:db8:0:1::/64 A B C D E

Control Plane Example

• Loop Free Alternates (LFAs)
• A can compute the cost from C to

determine if traffic forwarded to 2001:db8:0:1::/64 will be looped back to A

• If not, then A can install the path

through C as a backup path

2001:db8:0:1::/64 A B C D E

Control Plane Example

2001:db8:0:1::/64 A B C D E

• Do other routers in the

network need to react to new state in the control plane?

• How much faster will the

network converge with LFAs?

• How much state is added to the

control plane to calculate the LFA?

• How o]en does this state change?

Control Plane Example

2001:db8:0:1::/64 A B C D E

• Do other routers in the

network need to react to new state in the control plane?

• How much faster will the

network converge with LFAs?

• How much state is added to the

control plane to calculate the LFA?

• How o]en does this state change?

Examples of State, Optimization, and Surface

State Op(miza(on Surface Number of routes carried in a rou2ng protocol Convergence speed Configura2on (human to machine interface) How fast reachability/topology informa2on changes in the network Shortest path versus path taken (stretch) Two control planes interac2ng on a single network (e.g. BGP + IS-IS) Des2na2on host Applying filters as close to the source as possible API between the configura2on system and network devices (machine to machine interface) Des2na2on service (on a host) Amount of configura2on required to implement Two routers exchanging rou2ng informa2on Hello transmit interval Distance between informa2on source and control point Two data planes interac2ng on the same physical topology

21

What?

• Three

subques2ons—

• State
• Op2miza2on
• Surface
• Three way choices

are common in the real world

• Network

complexity is another form of this sort of three way choice

Quick Cheap High Quality State Surface Op2miza2on

The plane of the possible

• Another way of looking at

this…

• There is a “plane of the

possible”

• You can’t reach the dragon,

no maUer how hard you try

Realm of the Impossible Plane of the Possible S t a t e Op2miza2on

Complexity in design

• Complexity is a

tradeoff

• Decreasing

complexity in

• ne part of the

system will (almost) always increase complexity elsewhere

State Surface Op2miza2on

It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. … It is always possible to add another level of indirec2on. RFC1925

How?

How is Complexity Managed?

• What I’m managing is a tradeoff
• State, Op2miza2on, Surface
• How am I managing it?
• Have I seen these ideas before?
• What are the “natural tradeoffs” for these technique/

technologies?

Tools to Manage Complexity in Design

• Aggrega2on
• Summariza2on
• Hierarchy
• Overlays/virtualiza2on
• Automa2on
• Autoconfigura2on
• Increase skills

Hiding Information

Aggrega2on

• Hiding longer prefixes in shorter ones
• 2001:db8:0:1::/64 + 2001:db8:0:2::/64 ==

2001:db8::/61 Summariza2on

• Hiding detailed topology informa2on
• Flooding domain to single LSA/LSP at boundary

Hierarchy

• A family of network design paUerns
• Aggrega2on + summariza2on + modulariza2on

Virtualiza2on

• Overlay topology on top of physical topology
• Hide detailed topology/reachability informa2on

between topologies

28

Hiding Information

• No aggrega2on—
• A knows all routes and all

topology changes

• A routes op2mally to

2001:db8:0:2::/64

2001:db8:0:1::/64 2001:db8:0:2::/64 A B D C E

1 1 1 2 2

Hiding Information

• B & C aggregate—
• A only knows about

2001:db8::/61

• A doesn’t know about

topology changes, etc.

• A routes subop2mally to

2001:db8:0:2::/64

• Increased stretch

2001:db8:0:1::/64 2001:db8:0:2::/64 A B D C E

1 1 1 2 2

Hiding Information

No Aggrega2on Op2mal rou2ng

• More control

plane state

• Changes less
• ]en
• No configura2on

Aggrega2on Subop2mal rou2ng

• Less control

plane state

• Changes less
• ]en
• Configured

aggrega2on 2001:db8:0:1::/64 2001:db8:0:2::/64 A B D C E

1 1 1 2 2

Hiding Information

No Aggrega2on Op2mal rou2ng

• More control

plane state

• Changes less
• ]en
• No configura2on

Aggrega2on Subop2mal rou2ng

• Less control

plane state

• Changes less
• ]en
• Configured

aggrega2on 2001:db8:0:1::/64 2001:db8:0:2::/64 A B D C E

1 1 1 2 2

State Surface Op2miza2on

Hiding Information

• Aggrega2on “hides”

2001:db8:0:1::/64 and 2001:db8:0:2::/64 in 2001:db8::/61

• Another way of saying this—

aggrega2on creates an abstract representa2on of two longer prefixes in the form of a single shorter prefix

• Aggrega2on == abstrac2on
• Hiding informa2on ==

abstrac2on

2001:db8:0:1::/64 2001:db8:0:2::/64 2001:db8:0:1::/64 2001:db8:0:2::/64 2001:db8:0:2::/64

Hiding Information

• Aggrega2on
• If the A->B link fails, the cost
• f the aggregate changes
• TCP retransmissions
• Embedded IP addresses
• Abstrac2ons Leak

10 2001:db8:0:1::/64 2001:db8:0:2::/64 20 A B C D 2001:db8::/61 aggregate metric set to metric of the lowest component

Have I seen this solution before?

Common Problem Common Solu2on Common Problems with the Solu2on Find the shortest path SPF Path Vector Bellman-Ford DUAL Microloops, state too fast Slow convergence, inconsistent state Slow convergence, feedback loops Drops during convergence, feedback loops Distribute Data Flood Mul2cast Unicast Possibly too dense, CAP, transmission errors Complex control plane, CAP, transmission errors Complex control plane, CAP, transmission errors Reliable Data Transmission Forward Correc2on Detect/Retransmit Carry unneeded state in many cases Slows down transmission

What is this like?

• This is an opportunity, rather than a problem
• The more you understand about the past, the more you will understand

the future

• Be a collector of…
• Models, protocols, theories, algorithms, ideas, etc.

Every old idea will be proposed again with a different name and a different presenta:on, regardless of whether it works.

• RFC1925, rule 11

Conclusion

Corralling the Questions

• Why?
• What is the

porpoise?

• What?
• State
• Op2miza2on
• Surfaces
• How?
• Have I seen this

before?

Why?

What problem am I solving? Narrows my view – don’t boil the

• cean

What? How?

How was the problem solved? How was it solved before? What are the problems with this solu2on?

Solu2on Effec2veness Robustness Complexity

Seek out the point where complexity is lowest, robustness is highest, and the solu:on isn’t really improving any longer…

41

Why? What?

State? Surface? Op2miza2on?

How? to find poten2al solu2ons and “know

where to look”