Quantifying Trade-Offs via Competitive Analysis (Clean Slate Seminar) Tim Roughgarden Stanford CS

Clean Slate Trade-Offs Clean Slate design fraught with trade-offs between competing objectives "There is not likely to be a unique answer for the list of requirements, and every requirement has some cost. The cost of a particular requirement may become apparent only after exploration of the architectural consequences of meeting that objective in conjunction with others...it there requires an iterative process..." NewArch Intro paper, 2000.

Clean Slate Trade-Offs E.g., overprovisioning: good or bad? Nick: inefficient, motivates Valiant load-balancing in backbone network Bernd: good, QoS becomes easy Theme in my research: rigorously quantify trade-offs between competing objectives e.g., excess capacity vs. performance

Plan for Talk Goals: illustrate this idea with several examples: routing, protocol design, pricing, capacity installation models vary in direct relevance to clean slate emphasize commonalities + flexibility of analysis approach, qualitative insights via quantitative analysis illustrate my own interests/expertise

Example #1: Routing Motivating example: low capacity, prop delay vs. high capacity, prop delay d  how close arrival rate is to “knee” of delay curve Conges-tion D [secs] c(x) = xd s t c(x) = 1 Rate R

Example #1: Routing Motivating example: low capacity, prop delay vs. high capacity, prop delay d  how close arrival rate is to “knee” of delay curve dumb routing (source, delay-based, etc) = all on top Conges-tion D [secs] c(x) = xd 1 s t c(x) = 1 Rate R

Example #1: Routing Motivating example: low capacity, prop delay vs. high capacity, prop delay d  how close arrival rate is to “knee” of delay curve dumb routing (source, delay-based, etc) = all on top smart routing = offload some to bottom Conges-tion D [secs] c(x) = xd 1 1-Є s t c(x) = 1 Є Rate R

Trade-offs in Routing Summary: constraint: can’t/don’t want to implement smart routing trade-off: excess capacity vs. performance (avg delay relative to optimal routing) Next: two related approaches for quantifying this trade-off. [Roughgarden/Tardos 00], [Roughgarden 02]

Quantifying the Trade-Off Approach #1 (the ratio): as a function of the excess capacity, what is the ratio: avg delay of delay-based routing vs. avg delay of optimal routing at least 1, the closer to 1 the better “competitive ratio”, “price of anarchy”

Quantifying the Trade-Off Approach #1 (the ratio): as a function of the excess capacity, what is the ratio: avg delay of delay-based routing vs. avg delay of optimal routing at least 1, the closer to 1 the better “competitive ratio”, “price of anarchy” Answer: grows as  d/ln d small as long as there’s some overprovisioning c(x) = xd s t c(x) = 1

Qualitative Insights Insight #1: advocates overprovisioning but...

Qualitative Insights Insight #1: advocates overprovisioning but... even (say) 20% works wonders both Nick and Bernd are right!

Qualitative Insights Insight #1: advocates overprovisioning but... even (say) 20% works wonders both Nick and Bernd are right! Insight #2: worst-case = trivial topology worst-case ratio does not degrade with more complex topologies, traffic matrices

Quantifying the Trade-Off Approach #2 (match the old optimum): how much overprovisioning need before delay-based routing as good as optimal? with overprovisioning without overprovisioning

Quantifying the Trade-Off Approach #2 (match the old optimum): how much overprovisioning need before delay-based routing as good as optimal? Answer: 100% (double the capacity) cf., “switch speedup results” by Ashish, Nick, Balaji with overprovisioning without overprovisioning

Bigger Picture had one or more constraints two competing objectives not feasible to route traffic optimally two competing objectives minimize both overprovisioning + average delay two ways to quantify trade-off competitive ratio, min capacity to simulate opt precise answers, qualitative insights small amount of overprovisioning helps trivial worst-case topologies

Ex #2: Protocols for Bandwidth Allocation Setup: [Johari/Tsitsiklis 04] + [Johari 04] goal is to partition bandwidth (e.g. 1 link) to maximize sum of heterogeneous utilities uk Equal-slope “Pareto condition” rk

Trade-Offs for a Bandwidth Allocation Protocol Constraint: can’t directly implement optimum (e.g., don’t know utility functions); want decentralized protocol to do this [Kelly] simple such protocol exists if no user “large” (has non-negligible “market power”) [JT04] quantify trade-off between protocol performance, max market power of a player at most 25% efficiency loss

Kelly mechanism still optimal Qual Insight #1: market power not a big deal. Idea: use efficiency loss as novel metric to compare different protocols. Theorem: [J04] Kelly mechanism the best one! all protocols in a certain class have > 25% eff loss Qual Insight #2: Kelly mechanism designed for no market-power setting, but still optimal (in above sense) more generally.

Ex #3: Pricing a Service Motivating question: how do we price a service (e.g. a movie broadcast) so that it is (at least somewhat) economically viable? Constraint: "fairness" = every customer's cost can only go down as more customers served economies of scale connected to "collusion-resistance" n potential clients with valuations server edge cost = 1 s

Ex #3: Trade-offs Trade-off: want to charge enough to cover costs, but also want "good solution" easy to cover costs of the empty set! max "surplus" = benefit to served customers - cost of serving them n potential clients with valuations server edge cost = 1 s

Ex #3: Trade-offs Trade-off: want to charge enough to cover costs, but also want "good solution" easy to cover costs of the empty set! max "surplus" = benefit to served customers - cost of serving them Old result: can't have both [Moulin/Shenker]. New result (w/Sundararajan): quantify trade-off curve between them. n potential clients with valuations server edge cost = 1 s

Ex #3: Insights Qualitative insight #1: can have approximate versions of both goals. approximate cost recovery + nearly maximum-possible surplus #2: trivial examples exhibit worst-case behavior (like in routing, complex topology doesn't make things worse) Open issue: trade-offs when economic viability a constraint, "fairness" an objective

Example #4: Valiant Load-Balancing Constraint: [Zhang-Shen/Mckeown 04,05]: allocate edge capacity w/out knowing traffic matrix Assume: know amount of traffic out of each node in backbone network (say R each) linear # of parameters instead of quadratic want sufficient capacity to route any traffic matrix respecting these node constraints Intuitively: lack of knowledge  need more capacity. But how much more?

Example #4: VLB Theorem: [ZM 04,05]: only a factor 2! know matrix just do one-hop routing  need at most nR capacity (n = # nodes) VLB: two-hop routing suffices, at most 2R/n capacity on each of n2 links extensions (node-varying R, failures,...) future: avg prop delay vs. capacity trade-offs (w.r.t. underyling physical network)

Summary much of the clean slate work will be struggling with different trade-offs quantitative analysis flexible, often tractable, often offers new qualitative insights always looking for new problems to tackle... future: evaluate the e2e principle? has suggestive "smart" vs. "dumb" flavor...