Multipath Protocol for Delay-Sensitive Traffic Jennifer Rexford Princeton University Joint work with Umar Javed, Martin Suchara, and Jiayue He

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

Strawman: Min Propagation Delay Operator: Sets weights to propagation delay Routers: Link-state routing But links may become congested, causing packet loss and delay…

Our Goal: Adaptive Load Balancing Distributed protocol that automatically minimizes delay  Division of functionality Links: feedback on network conditions Edge routers: balance load over paths

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

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) Delay for link l : p l + f() Summed: ∑ i ∑ j ∑ l z i j R i lj (p l + f()) Weighted: z i j R i lj (p l + f())

Constraints  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

Optimization Decomposition  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

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

Path Rate Updates  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.

Distributed Multipath Protocol Edge node: Update path rates z Split traffic over paths Operator: Select function f Tune step sizes 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 Theoretical Results

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

Multiple Classes of 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

Conclusions  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

Backup Slides

Protocol Dynamics  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