Jennifer Rexford
Princeton University
Joint work with Umar Javed, Martin Suchara, and Jiayue He http://www.cs.princeton.edu/~jrex/papers/comsnets09.pdf

Clean-Slate Network Architecture
 Network architecture
 More than designing a single protocol
 Definition and placement of function
 Clean-slate design
 Without the constraints of today’s artifacts
 To have a stronger intellectual foundation
 And move beyond the incremental fixes
 But, how do we do clean-slate design?

Protocols as Distributed Optimizers
 Example: TCP congestion control
 Additive increase, multiplicative decrease
 Implicitly maximizes aggregate utility
 TCP variants have different utility functions
 Optimization for “forward” engineering
 Start with a central optimization problem
 Decompose to divide the computation
 … among the sources and the links
Research by Frank Kelly, Steven Low, Mung Chiang, and others

Our Focus: Delay-Sensitive Traffic
 Interactive applications
 Voice over IP (VoIP)
 Online gaming
 IP television
 Path-selection goals
 Paths with low propagation delay
 … as long as paths are not overloaded
For now, assume the network carries only delay-sensitive traffic

Operator:
Sets weights to propagation delay
3
2
3
4
1
2
2 2 Routers:
Link-state routing
But links may become congested, causing packet loss and delay…

 Division of functionality
 Links: feedback on network conditions
 Edge routers: balance load over paths
Distributed protocol that automatically minimizes delay

Multiple Paths With Flexible Splitting
 Multiple paths between edge nodes
 Paths with low propagation delay
 Flexible traffic-splitting ratio
 Traffic rate x i z
1
1
 Traffic rate z i j for src-dest pair i over path j x
1
= z 1
1
+ z 1
2
+ z 1
3 z
2
1 z
3
1

Objective: Minimize Average Delay
 Minimize average delay
 End-to-end delay on each path
 Weighted by the traffic on the path
 Delay for link l
 Propagation delay p l
 Congestion penalty f(load on link l)
∑ i
∑ i j j
∑ l i
l: lj z p i j l
(p R i (p l
+ f())

 Carry the offered load for each source
 ∑ j z i j
= x i
 Avoid overloading each link
 ∑ i
∑ j z i j
R i lj
≤ c l
 Carry non-negative traffic on each path
 0 ≤ z i j

 Deriving source and link algorithms
 Prices: penalties for violating a constraint
 Path rates: updates driven by prices
 Example: TCP congestion control
 Link prices: packet loss or delay
 Source rates: AIMD based on prices
 Our problem is more complicated
 More complex objective, multiple paths

Example Decomposition: Link Capacity
 Capacity constraint
l
 Subgradient feedback price update: l l
(t+1) = [ l l
(t) + stepsize*(link load – c l
)] +
 Stepsize controls the granularity of reaction
 Link computes price l as feedback to sources
Source does similar update for “carry all offered load” constraint.

 Each source i does a local optimization
 To update the path rates z i j
 Based on
 The “prices” of violating constraints
 … and the objective function
 Closed-form expression
 With piecewise-linear queuing function f()
 See the paper for the exact equation
Derived by taking the Lagrangian and applying KKT conditions.

Operator: Select function f
Tune step sizes
Edge node:
Update path rates z
Split traffic over paths
Routers:
Set up multiple paths
Measure link load
Update link prices

 Optimality and stability
 Provably optimal
 Provably converges for diminishing step sizes
 Practical limitations
 Must have well-chosen step sizes
 … to achieve fast convergence
 Matlab experiments to sweep parameters
 Good heuristics for setting (constant) step sizes

Converting to Packet-Level Protocol
 Packets rather than fluid
 Links compute load over a time interval
 Counting the sizes of the packets
 Feedback delay of round-trip time
 Multiple paths have different RTTs
 Path rate updates once per max of RTTs
 Implemented in ns-2 simulator
 For more realistic evaluation

Comparison With Shortest-Path Routing
 Shortest-path routing
 Link weights equal propagation delay
 Under low load
 The two protocols behave the same way
 Under higher load
 Our protocol gradually shifts traffic
 … to longer paths to avoid overload
 … while keeping end-to-end delay small

Convergence Under Dynamic Traffic

 Satisfying multiple traffic classes
 Delay-sensitive: VoIP and gaming
 Throughput-sensitive: file transfers
 Running separate virtual networks
 Customized protocol for each traffic class
 Dynamic update to bandwidth shares
 Provably maximizes aggregate performance
 Derived using optimization theory http://www.cs.princeton.edu/~jrex/papers/davinci.pdf

 Delay-sensitive applications
 VoIP, online gaming, IPTV…
 Customized routing protocol
 Load balancing over multiple paths
 Minimizing end-to-end delay
 Optimization decomposition
 Rigorous way to design new protocols
 With provable optimality and stability
 Ongoing work: network virtualization

 Good heuristics for setting step size
 Converges quickly under range of settings
 Relatively fast convergence
 Small tens of seconds in worst case
 Better under more realistic settings
 Quick response to changes in load
 Fast adaptation to new traffic demands