Tim Roughgarden Stanford CS

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

description

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 - PowerPoint PPT Presentation

Transcript of Tim Roughgarden Stanford CS

Page 1: Tim Roughgarden Stanford CS

1

Quantifying Trade-Offs via Competitive Analysis

(Clean Slate Seminar)

Tim RoughgardenStanford CS

Page 2: Tim Roughgarden Stanford CS

2

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.

Page 3: Tim Roughgarden Stanford CS

3

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

Page 4: Tim Roughgarden Stanford CS

4

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

Page 5: Tim Roughgarden Stanford CS

5

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 [secs]

Rate R

s t

c(x) = xd

c(x) = 1

Page 6: Tim Roughgarden Stanford CS

6

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 [secs]

Rate R

s t

c(x) = xd

c(x) = 10

1

Page 7: Tim Roughgarden Stanford CS

7

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 [secs]

Rate R

s t

c(x) = xd

c(x) = 10

1 1-Є

Є

Page 8: Tim Roughgarden Stanford CS

8

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]

Page 9: Tim Roughgarden Stanford CS

9

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”

Page 10: Tim Roughgarden Stanford CS

10

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 s t

c(x) = xd

c(x) = 1

Page 11: Tim Roughgarden Stanford CS

11

Qualitative Insights

Insight #1:• advocates overprovisioning but...

Page 12: Tim Roughgarden Stanford CS

12

Qualitative Insights

Insight #1:• advocates overprovisioning but...• even (say) 20% works wonders

– both Nick and Bernd are right!

Page 13: Tim Roughgarden Stanford CS

13

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

Page 14: Tim Roughgarden Stanford CS

14

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

Page 15: Tim Roughgarden Stanford CS

15

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

Page 16: Tim Roughgarden Stanford CS

16

Bigger Picture

• had one or more constraints– 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

Page 17: Tim Roughgarden Stanford CS

17

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

rk

uk

Equal-slope “Pareto condition”

Page 18: Tim Roughgarden Stanford CS

18

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

Page 19: Tim Roughgarden Stanford CS

19

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.

Page 20: Tim Roughgarden Stanford CS

20

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"

sserver

n potential clients with valuations

edge cost = 1

Page 21: Tim Roughgarden Stanford CS

21

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

sserver

n potential clients with valuations

edge cost = 1

Page 22: Tim Roughgarden Stanford CS

22

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.

sserver

n potential clients with valuations

edge cost = 1

Page 23: Tim Roughgarden Stanford CS

23

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

Page 24: Tim Roughgarden Stanford CS

24

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?

Page 25: Tim Roughgarden Stanford CS

25

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)

Page 26: Tim Roughgarden Stanford CS

26

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...