Network Protocols Designed for Optimizability Jennifer Rexford Princeton

Network Protocols Designed for Optimizability Jennifer Rexford Princeton University http: //www. cs. princeton. edu/~jrex

Measure, Model, and Control Network Management Models, tools, scripts, databases Dials Offered Topology/ traffic Configuration measure Knobs Changes to the network control Operational network 2

Knobs and Dials • Knobs: configurable parameters – Buffering: Random Early Detection parameters – Link scheduling: weighted fair queuing weights – Path selection: link weights and routing policies • Dials: measurement data – Traffic: link utilization, Netflow records, … – Performance: ping, download times, … – Routing: routing-protocol messages, tables, … Network management: read the dials and tune the knobs 3

Two Directions We Could Go • Algorithms for setting knobs based on dials – E. g. , setting RED parameters based on link load – E. g. , setting link weights based on traffic matrix – E. g. , setting access-control lists to block attacks • Designing better knobs and dials – Maybe we can’t add all that much meaningful abstraction on top of what we’ve got underneath – Maybe we should design new protocols and mechanisms with optimization in mind – “Doing well in a class is much easier when you get to write the exam. ” – Mung Chiang 4

Problem #1: No Algorithm For Setting the Knobs • Random Early Detection (RED) Probability – Several tunable parameters – Min and max thresholds on queue length, max probability, queue weight Average Queue Length 5

Problem #1: RED Example Continued • Settings have a big influence on performance – Good settings can improve the network “goodput” – Bad settings may offer no improvement, or (in some cases), worse performance • No algorithm for optimizing the parameters – Settings based on general guidelines – Makes it difficult for operators to enable RED We need mechanisms that have algorithms for setting knobs. 6

Problem #2: Poor Dials to Guide Knob Settings • Example: Random Early Detection – Appropriate parameters depend on many factors • Number of active flows, flow durations, flow RTTs, … Probability – Not easily measurable today on high-speed links Average Queue Length We need measurements that support network management. 7

Problem #2: Poor Dials to Guide Knob Settings • Example: Traffic engineering – Depends on knowing the traffic matrix Mij – Challenging to measure • Resorting to inference of the traffic matrix • Aggregating and joining lots of fine-grain data i j We need measurements that support network management. 8

Problem #3: Intractable Optimization Problems • Example: Traffic engineering – Tuning link weights to the prevailing traffic 2 3 2 1 1 1 3 5 4 3 – Leads to an NP-hard optimization problem – … forcing the use of local-search techniques We need protocols designed with knob optimization in mind. 9

Problem #4: Non-Linearities in the System • Example: Hot-potato routing – Small change causes a big effect • Failure, planned maintenance, or traffic engineering • Routes to thousands of destinations shift at once • … causing large shifts in traffic and many BGP updates dst NYC SFO ISP network 10 9 11 Dallas We need protocols that make small reactions to small changes. 10

Design for Optimizability • Creating protocols and mechanisms where – We know the algorithms for tuning the knobs – We have the measurements the algorithms need – The resulting optimization problems are tractable – The system does not have non-linearities • Example approaches – Randomization – Increasing the degrees of freedom – Logically centralized control 11

Randomization • Example: traffic engineering – Forward traffic in inverse proportion to path costs – … rather than using only the shortest paths – Leads to polynomial-time optimization problems 2 3 2 1 1 1 3 5 4 3 12

Increasing Degrees of Freedom • Example: egress selection – Forward traffic to lowest ranked egress point – … as weighted sum of constant and path cost – E. g. , keep using SFO even when cost goes to 11 – Enables integer programming solutions for tuning dst NYC SFO ISP network 10 9 11 Dallas 13

Logically Centralized Control • Example: Routing Control Platform (RCP) – Separate topology discovery from path selection – Collect topology and traffic data at servers – Apply optimization techniques for selecting routes – … and tell routers what forwarding tables to use RCP 14

Conclusions • Protocols induce optimization problems – Read the dials and tune the knobs – Controls how the system performs • Yet, optimization problems are often hard – Lack of predictive models – Missing measurement data – Computational intractability – Non-linearities in the system • Design protocols with optimization in mind – Randomize, add degrees of freedom, decompose 15