managing qos

Managing QoS in a Multiprovider Network

Jean Walrandhttp://www.eecs.berkeley.edu/~wlr

University of CaliforniaBerkeley

Thanks to Jrn Altmann, Linhai He, and Jun Shu for their help.

2Jean Walrand Porquerolles May 03

QoS in a Multiprovider Network Overview Approaches Social Welfare & Packet Marking Market Segmentation Games: Mini-Tutorial Pricing Summary Related Topics References

TOC


Overview Internet Structure Implications Different Views Interactions Peering Agreements

TOC OTOC verview


Internet Structure

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Domains Owned and operated by

independent organizations

Have own set of policies

Relationship between domains Customer and provider Collaborators and

competitors

TOC Overview Structure


Internet Structure Backbone - AT&T

http://www.caida.org/tools/visualization/mapnet/Backbones/



Internet Structure Backbone - Sprint

http://www.caida.org/tools/visualization/mapnet/Backbones/



Internet Structure Autonomous Systems

http://www.caida.org/analysis/topology/as_core_network/pics/ascoreApr2002.gif



Internet Structure

[GH00]

Transit Customer Peering TOC Overview Structure


Network Structure

D EC F

BA

AC {1,2,3}AD {4,5}

D{4,5}DC{1,2,3}

BAC{1,2,3}BAD{4,5}

C{1,2,3}

C{1,2,3}

BGP

1 2 3 4 5

A announces preferred paths: Policies E.g., A prefers C{1,2,3} to DC{1,2,3} because shorter

TOC Overview Structure TOC Overview Structure


Implications

End to End QoS Requires collaboration among all domains Proposed solutions should provide right

economic incentives Scalability

Flow vs aggregate based traffic management

Techniques to eliminate states inside networks

TOC Overview Implications TOC Overview Implications


Different Views End Users

Have utility for services Demand, Willingness to pay

Network as a Public Good Maximize total utility: Social

Welfare Providers as Market Players

Maximize Revenues

TOC Overview Different Views TOC Overview Different Views


Interactions Agents

ISPs, Users Network Leads, Users Follow

Network Set Prices p; Users Respond D(p) Auction

Users Bid, Network Set Prices, Users Respond Many ISPs

Non-cooperative: Each ISP j sets price pj Cooperative: ISPs agree on prices, share revenues

What is the product? Single class or multiple classes of service

TOC Overview Interactions TOC Overview Interactions


Peering AgreementsCaricature

N4 N5N3 N6

N2N1

A B C D

N1, N2 are Tier-1 Networks N3 N6 are Tier-2 Networks A D are clients

TOC Overview Peering


Peering Agreements

N4 N5N3 N6

N2N1

A B C D

N3, N4 pay N1 for traffic: mean, peak, (N3 is a client of N1; N1 is the provider of N3)

N1 N2 may agree to peer



Peering Agreements

N4 N5N3 N6

N2N1 RPeering

Customer

N1 and N2 Peer:Free transport of each others trafficShare cost of R



Peering Agreements

R

N4 N5N3 N6

N2N1 RCustomer

Should N3 and N4 peer?+: Reduce their transit cost through N1-: If |N3| >> |N4|, then N4 free rides N3-: If N3 is faster then N4, then peering might entice

customers of N3 to join cheaper N4 instead. Large ISPs dont like to peer with small ISPs

[BW98][CRT00]



Peering Agreements - BGP

C

A

B DE

E{..}

E{..}

E{..}E{..}

E{..}

F

GE{..}

By not announcing the paths E{..} to D, A limits its transittraffic A favors its paying customers G, at the expenseof the customers F of D



Peering Agreements - BGP

E

E{..}

E{..}

E{..} E{..}E{..}

E{..}

F

G

Selfishly, ISPs may have a benefit in not announcing some routes. However, if they all do this



Peering Agreements Note: BGP is blind to utilization

E F

G

This inefficient routing is not a big problem if utilizationis very low; which is fine when there is vast over provisioning.

However, protection switching also adds to the over provisioning.All this adds up to a big waste .



Approaches What and Where to Control? Best Effort Per Flow Reservation Per Flow End-to-End Admission Edge-to-Edge Pipes Local Pipes Some Lessons

TOC Approaches


What and Where to Control? End-to-end flow, between transport ports Across the network, between edge routers Across each domain Across each individual link Granularity

TOC Approaches What and Where to Control? TOC Approaches What and Where to Control?


Best Effort

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Great Scaling; Poor QoS

Packets competeDropped if congested

TOC Approaches Best Effort TOC Approaches Best Effort


Per Flow Reservation

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Reserve B Mbps?

OK!

Poor Scaling and Response Time; Flow QoSTOC Approaches Per Flow Reservation


Per Flow Reservation - IntServBasic Observation [PG93] WFQ at each router + LB per flows

bounded delays Idea: Reserve (,, w) along the path : RSVP

TOC Approaches Per Flow Reservation


Per Flow Reservation - IntServ

Admission Control

C

o

n

t

r

o

l

P

l

a

n

e

D

a

t

a

P

l

a

n

e

Scheduler

Routing RSVP messages

Classifier

RSVP

Route Lookup

Forwarding Table Per Flow QoS Table

Routing Messages

Data InData Out

[Abhay Parekh]

TOC Approaches Per Flow Reservation


End-to-End Per Flow Admission

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Test B Mbps?

OK!

Good Scaling; Unpredictable admission probability

Once admitted, guaranteed

TOC Approaches E2E Per Flow Admission


End-to-End Per Flow Admission A plug for virtual queues!Mark packets when utilization exceeds 90%, using virtual queues:

C

0.9C

With this scheme, we detect congestion before ithappens. The queues never really build up. [CK95, KS01]



End-to-End Per Flow Admission Goal: Admitted calls have guaranteed QoS

(E.g., VoIP, video conference, .)

Scheme:Send test packets, say for 5 seconds. Routers mark test packets if utilization > 90%. (VQ)If no test packet gets marked, the connection is accepted.Otherwise, connection is blocked and goes away.Advantages:+ New calls do not disrupt accepted calls.+ No complex RSVP-like protocol; no state in routers.



Edge-to-Edge Pipe (e.g., MPLS)

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Complex [QoS routing]; Controllable QoS

Reserve big pipesPipes used by flows

TOC Approaches Edge-to-Edge Pipes TOC Approaches Edge-to-Edge Pipes


Local Pipes (SLAs; e.g., DiffServ)

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Simple [local]; Issue: How to provision SLAs?

Reserve local pipesPipes used by flows

TOC Approaches Local Pipes


Local Pipes (SLAs; e.g., DiffServ)DiffServ

IngressEgressEgress

IngressEgressEgress

DS-1 DS-2

Kinds of Service:1. Premium2. Assured3. Best Effort

Kinds of Service:1. Premium2. Assured3. Best Effort

Edge router Core router[Abhay Parekh]



Local Pipes (SLAs; e.g., DiffServ)DiffServ Example - VoIP 80 bytes every 20ms Give high priority to VoIP Assume VoIP utilization of a link is less than 50%

Then, delay of VoIP is less than 10ms per link(assuming preemptive priority add a few ms)

Indeed: Cycles of 20ms with no carry over Worst case: wait for back-to-back VoIP 10ms



Local Pipes (SLAs; e.g., DiffServ) Provisioning SLAs: Worst Case is Bad!

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

1010

1030?



Local Pipes (SLAs; e.g., DiffServ)Provisioning SLAs Can be slow Can have loops: AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley



Local Pipes (SLAs; e.g., DiffServ)Measurement-Based:

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

Measure LoadAdjust SLA preemptively

Good scaling and response time, but .TOC Approaches Local Pipes


Local Pipes (SLAs; e.g., DiffServ) Measurement-Based:

AT&T

Sprint WorldCom

SBC

Level3

BBN

Stanford

UIUC

MIT

Ameritech

Berkeley

SLAs may have to be readjusted sub-optimally

S OK

S no longer OKS



Local Pipes (SLAs; e.g., DiffServ) Measurement-Based: Case StudyNew

Admit if peak(new) < Gap

Capacity

GapMean + 2.4

Multi-domain: Need a broker per domain, with negotiationsof admission quotas among domains .

TOC Approaches Local Pipes TOC Approaches Local Pipes


Some Lessons Comparison Why not much QoS?

TOC Approaches Lessons


Comparison

Per flow steupLong term setupNo setupComplexity

End-to-endDomain End-to-endService scope

Not scalable (each router maintains per flow state)

Scalable(edge routers maintains per aggregate state; core routers per class state)

Highly scalable (nodes maintain only routing state)

Scalability

Per flow isolationPer flow guarantee

Per aggregate isolationPer aggregate guarantee

ConnectivityNo isolationNo guarantees

Service

IntservDiffservBest-Effort

[Abhay Parekh]

TOC Approaches Lessons Comparison


Comparison It is a matter of scale

SF

UCB

Boston

BU

2Mbps

PoP

< 12 Mbps

Total < 8 MbpsUCD

MIT3Mbps

VoIP traffic UCB PoP to 2Mbps: MPLS pipe, etcTotal VoIP traffic at PoP: 8 Mbps: DiffServ, etc.Given access constraints, some regularity in bboneand some regularity in S/D pairs of VoIP .

TOC Approaches Lessons Comparison


Why not much QoS? Answer 1: Complexity, Scalability, .

Answer 2: Need agreements QoS must be end to end, i.e., across multiple providers. If ISP2 does not do it, why should ISP1 do it, and vice versa .

Answer 3: What are the economic incentives?Need pricingChargingRevenue Distribution

TOC Approaches Lessons No QoS


Social Welfare and Packet Marking We consider a congested link Key idea: Packet marking can provide a signal that decouples a social welfare optimization problem. We then see how a version of TCP can solve the decoupled problem Social Welfare Problem (Primal) Decoupled Problem (Dual) Example TCP ImplementationWhy does it work? Extension Virtual Queues

TOC Social TOC Social


Primal Consider the following problem:

TOC Social Primal

x Max U1(x) + U2(y)

Subject to x + y C

Max U1(x) + U2(y)

Subject to x + y CC

ySolution:The solution (x*, y*) is such that x* + y* = C.Also, U1(x* + ) + U2(y* - ) U1(x*) + U2(y*), for all .Hence,

U1(x*) + U2(y*) + {U1(x*) U2(y*)} U1(x*) + U2(y*).Since is arbitrary, this implies

U1(x*) = U2(y*) =: p


Dual Consider the following problem:

x Max U1(x) + U2(y)

Subject to x + y C

Max U1(x) + U2(y)

Subject to x + y CC

ySolution (continued):U1(x*) = U2(y*) =: p is equivalent to

User 1 maximizes U1(x) pxUser 2 maximizes U2(y) py

In this decoupled problem p is the price per unit bandwidth.Price p is a congestion price that reflects the impact of anadditional unit of bandwidth on the utility of the other user.[p is a.k.a. shadow price Internalizing the externalities.]TOC Social Dual


Example

x Max U1(x) + U2(y)

Subject to x + y C

Max U1(x) + U2(y)

Subject to x + y CC

yU1(x) = log(x), U2(y) = 2log(y).

User 1: Max log(x) px x = 1/pUser 2: Max 2log(y) py y = 2/p

Thus, x* = 1/p and y* = 2/p where 3/p = C.

Hence, x* = C/3, y* = 2C/3.

TOC Social Example


Example

x Max U1(x) + U2(y)

Subject to x + y C

Max U1(x) + U2(y)

Subject to x + y CC

yU1(x) = log(x), U2(y) = 2log(y).The network does not know U1 and U2. How does it choose p?Choose a price that goes up fast as x + y approaches C:

C

p(z)

z = x + y - C

TOC Social Example


TCP Implementationx* = C/3, y* = 2C/3.

Let dx(t) = a.dt bx(t)p(x(t) + y(t) C)dt [1]dy(t) = 2a.dt by(t)p(x(t) + y(t) C)dt. [2]

wherep(u) > 0 if u > 0 and p(u) = 0 if u < 0.

Then

x

y

21

[1]

[2]

C

(x*, y*)

x

yC

(x*, y*)

Dynamics:

TOC Social TCP


Why Does It Work?

11

Distance ||(x,y) (x*,y*)||decreases at each step oneach side of the boundary.

y/2C

(x*, y*)

x

Key properties: [CJ89]Push (x, y) in right directionDistributed: x does not need to know y, and vice versa

TOC SocialWhy?


ExtensionMax U1(x1) + U2(x2) + + Un(xn)

Uk(x) = wklog(x)

Subject to Ax C

Max U1(x1) + U2(x2) + + Un(xn)

Uk(x) = wklog(x)

Subject to Ax CSolution:dxk(t) = wka.dt bxk(t)pj(yj(t) Cj)dt [KMT98]

wherey(t) = Ax(t).

Thus,AIMD, with appropriate packet marking, works!

It maximizes the social welfare subject to capacity constraints!

TOC Social Extension


Virtual Queues

Imagine the constraint is utilization on link j is less than 90%

Then we can use the same packet marking scheme, butthe marking is done with virtual queues:

C

0.9C

With this scheme, we detect congestion before ithappens. The queues never really build up. [CK95, KS01]

TOC Social Virtual


Market Segmentation Basic Observation Paris Metro

TOC Segmentation


Basic Observation Why is there a first class in a plane?E.g., 20% are filled with 40% of revenues(20% of plane = 10% of seats, but 4x price ) How much space should there be in first class?

Demand d(p)

Price p

Demand

One classd(p)

Price p

Economy

1st Class

TOC Segmentation Basic


Basic Observation Of course, service should be better in first class. Service can be better because Better seats and food Less congested

TOC Segmentation Basic


Paris Metro [O98] Say that the Paris metro has two classes with identical cars. First class is more expensive than second class. As a result, first class is less congested and justifies a higher price.

Similar Examples: Palo Alto Country Club Harvard Business School

TOC Segmentation Metro


Paris Metro [O98] DiffServ:Say class k costs p(k) and has a corresponding arrival rate (k) and service rate , k = 1, 2. Average delay of class k = 1/( (k))

(1)(2)

T()

TOC Segmentation Metro


Game Theory Mini Tutorial Prisoners Dilemma: Nash Equilibrium Cournot: Nash, Stackleberg, Cooperation Mechanisms: Vickrey, VCG

TOC - Games


Prisoners Dilemma: C = Cooperate; D - Defect

One shot: Nash Equilibrium = (D, D) Repeated N times: Time N = (D, D) (D, D)N

TOC Games Prisoners


Prisoners Dilemma: Repeat forever:

Alice: I play C until you play D, then I play D forever Then (C, C) forever is a Nash equilibrium

(sub-game perfect) Note: Folk Theorem:

Play C % of the time, elseTOC Games Prisoners


CournotAlice and Bob are two firms (say Intel and AMD) that manufacture quantities x and y (resp.) of a product.

The unit price of the product is F x y.The unit production cost is H for Alice and Bob.

The profits of Alice and Bob are, respectively,

A(x, y) = (F x y)x Hx = (C x y)xB(x, y) = (F x y)y Hy = (C x y)y

TOC Games Cournot


Nash Assume Bob chooses y

Then Alice should choose x* = (C y)/2

A(x, y) = (C x y)xB(x, y) = (C x y)y

C

C

C/2

C/2x

y

y*

x*Best response functions

Equilibrium:(C/3, C/3)

Nash: (x, y) = (C/3, C/3); Rewards are (C2/9, C2/9).TOC Games Cournot


Stackelberg Assume Alice moves first and chooses x

Then Bob should choose y* = (C x)/2Consequently, Alices reward is (C x)x/2Accordingly, Alice should choose x* = C/2

A(x, y) = (C x y)xB(x, y) = (C x y)y

Stackelberg, with Alice = Leader:

(x, y) = (C/2, C/4); Rewards are (C2/8, C2/16).

TOC Games Cournot


Cooperation A(x, y) = (C x y)xB(x, y) = (C x y)y

Assume Alice and Bob agree to optimize x and yto maximize the total revenues that they then split.

In that case, A(x, y) + B(x, y) = (C z)z, z = x + yThe optimal value of z is C/2.

Cooperation

(x, y) = (C/4, C/4); Rewards are (C2/8, C2/8).

TOC Games Cournot


Summary A(x, y) = (C x y)xB(x, y) = (C x y)y

C2/8, C2/8C2/8, C2/16C2/9, C2/9A*, B*

C/4, C/4C/2, C/4C/3, C/3x*, y*

CooperationStackelbergNash

TOC Games Cournot


Mechanism Model Vickrey Auction Bidding for place in queue Bidding for CoS

TOC Games Mechanisms


Model N users bid b1 > b2 > > bN The utility of user n in position j is un = ajvn User n in position j has to pay a price pj(b1bN)

Question: How can we choose the prices so that each user n has an incentive to bid bn = vn?

(Incentive-compatible mechanism)

TOC Games Mechanisms Model


ModelDoes Bob have an incentive to bid more than Alice whenever v > bj+1? His utility increases by (aj aj+1)v. This is desirable if pj pj+1 < (aj aj+1)v whenever bj+1 < v.Thus, pj pj+1 = (aj aj+1)bj+1 is incentive-compatible.

pj = (aj aj+1)bj+1 + (aj+1 aj+2)bj+2 + VCG

= decrease in utility because Bob is in position j.

Bob: v, bid x ajvAlice: bid bj+1

a1 a2 a3 aj aj+1 aN

TOC Games Mechanisms Model


Vickrey AuctionAuction: One item is auctionedMechanism: Item sold to highest bidder who pays the second highest bid.

Here, a1 = 1, a2 = a3 = = 0.

Hence, p2 = p3 = = 0; p1 = b2.

pj = (aj aj+1)bj+1 + (aj+1 aj+2)bj+2 +

TOC Games Mechanisms Vickrey


Place in QueueAuction: Position j delay = j = - aj.

Utility of user n in position j is - vnj(i.e, v is the loss in utility per unit waiting time).

Mechanism: Ranked in order of bids.

pj = bj+1 + bj+2 + + bN= cost of additional delay imposed on others

pj = (aj aj+1)bj+1 + (aj+1 aj+2)bj+2 +

TOC Games Mechanisms Queue


Bidding for CoS [SV03]Auction: Class j utility vrj. Cj spots in class j, j = 1, , K 1, CK = .E.g., rj is the fraction of the traffic that goes through in class j.Mechanism: Fill classes in order of bids.

pj = (rj rj+1)dj+1 + (rj+1 rj+2)dj+2 + + (rK-1 rK)dK

where dk = bid of first user forced into class k.

Indeed: Here, aj = rk if position j is in class k.pj = (aj aj+1)bj+1 + (aj+1 aj+2)bj+2 +

TOC Games Mechanisms CoS


Bidding for QoS [SV03]

p4 = p3 + (0.9 0.7)b11Max. # users in class

Goodput of that class25 users bid for 4 classes of serviceUser bids: b1 > > b25

0.9, 101-1011-2021-25 0.4, 10

0.7, 10p2 = p1 + (0.4 0.2)0p3 = p2 + (0.7 0.4)b21

p1 = 00.2, Network ranksusers in decreasingbid order and fillsthe classes

Price of classes

If user n gets into class 2, hervaluation is 0.7vn and her price is p2

If user n gets into class 2, hervaluation is 0.7vn and her price is p2

Users should bid their true valuationUsers should bid their true valuation

TOC Games Mechanisms CoS


PricingOverview SLAs Packets

TOC - Pricing


Overview

UsersUsers ISP1

ISP2

ISP3

ISP4

ISPnTrafficRevenues

PricesQoS

Objectives

ISPs should have incentive to provide good services

Better services yield more revenuesSuitable redistribution of revenues among ISPs

TOC Pricing Overview


Overview

UsersUsers ISP1

ISP2

ISP3

ISP4

ISPnTrafficRevenues

PricesQoS

VERSION 1: SLAs Pricing SLAs Between ISPs Each provider chooses its prices to max. revenues

Leader-Follower or Nash; Bandwidth or QoS

VERSION 1: SLAs Pricing SLAs Between ISPs Each provider chooses its prices to max. revenues

Leader-Follower or Nash; Bandwidth or QoS

VERSION 2: PACKETS Pricing packets across ISPsEach provider chooses its prices to max. revenues

Leader-Follower, Nash, or Cooperation

VERSION 2: PACKETS Pricing packets across ISPsEach provider chooses its prices to max. revenues

Leader-Follower, Nash, or Cooperation

TOC Pricing Overview


SLAs Model Formulation Game-Theoretic Formulations Preliminary Results Conclusions

TOC Pricing SLA


ModelSource domains

Objective: maximize net utility R(x)-pS

s networkSx

Source Domain p

Vector of fixed demand (Poisson rates)

for various destinations Total rate of Accepted calls

SLA Unit SLA price(fixed for now)

TOC Pricing SLA Model


Provider Domains Objective: maximize profit

i pi Si - j pj Sj

Model

Downstream

piSiSells

pjSjBuys

Upstream Neighbors Neighbors



Destination domainsSink trafficCharge fixed unit price p for

incoming SLAs

Model



ModelAdditional Assumptions Type of domains:

Source, Provider, or Destination Routing: Fixed Traffic model: Loss networkErlang Fixed Point

Infinite internal capacity

TOC Pricing SLA Model TOC Pricing SLA Model


Games Formulation A: Domains Individually Optimize

Bandwidth

S T Dp1S1 S2 p2

S maximizes [over S1]: R(x) p1S1where x = q1q2

q1 = 1 E(q2, S1)q2 = 1 E(q1, S2)E(a, C) = Erlang loss for rate a, capacity C

T maximizes [over S2]: p1S1 p2S2TOC Pricing SLA Games


Games

S T Dp1S1 S2 p2

Formulation A1: Nash Game Degenerate Nash Equilibrium

(NEP)T maximizes [over S2]: p1S1 p2S2 S2 = 0

Reason:Fails to capture the incentive to provide good QoS

TOC Pricing SLA Games


GamesFormulation A2: Stackelberg Game

Leader-follower

SS1 S2 S3p1 p2 p3 T1 T2 D

T2 leads by choosing S3 T1 then follows by choosing S2 S then follows by choosing S1 S1(S2, S3) is best choice by S Knowing this, S2(S3) is best choice by T1 Knowing this, S3 is best choice by T2Example: If p1 > p2 > p3, then S1 = S2 = S3 = S1*



GamesFormulation A2: Stackelberg Game

Shortcoming:

Not always a simple leader/follower structure

S1 D1P1

P3

1s

P2 D2

D3

S22s

Sa

Sb

Sc

P3 leadsP2 leads P1, butP1 and P2 are

also peers



Games Formulation A3: Repeated Game

S S1 S2 S3p1 p2 p3

T1 T2 D

Strategy S: choose S1 as usual T1: S2 follows S1 T2: play S3 = S2 if S2 = S1*;

otherwise, if S2 < S1*, punish by playing S3 = 0



Games Formulation A3: Repeated Game

S S1 S2 S3p1 p2 p3

T1 T2 D

Shortcomings: All players need to know S1*

If decreases, S1 decreases. Then S2 decreases following S1. This causes S3= 0 (punishing) Not desirable! Formulation does not reflect available information.



GamesFormulation B. QoS as strategy Control QoS instead of bandwidth

Each provider chooses to guarantee a target level of QoS q

Amount of bandwidth it buys depends on this qand its traffic load

Concatenation of these local QoS guarantees forms the end-to-end QoS for source domains

Source domains buy bandwidth based on perceived end-to-end QoS level



GamesFormulation B. QoS as strategy Control QoS instead of bandwidth An example

qi=1-E(ji qj, Si)S S1 S2 S3p1 p2 p3

T1 T2 D

S: maxq1 R(q1q2q3) - p1 S1(q2q3, q1)T1: maxq2 p1 S1(q2q3, q1) p2 S2(q1q3, q2)T2: maxq3 p2 S2(q1q3, q2) p3 S3(q1q2, q3)

TOC Pricing SLA Games TOC Pricing SLA Games


Preliminary ResultsSolution to the gameNumerical ExamplesProperties of the solution:

Effect of Prices

TOC Pricing SLA Results


Solution to the Game Modeled as a static game with complete

information Certain properties of the model:

Each players strategy set is q [0,1] SLA S(L,q) is a concave function of load, L and a convex function of QoS level, q n-player concave game; NEP exists (Rosen,

1965) However, it is not diagonally strict concave

TOC Pricing SLA Results Solution


Solution to the GameQuestions of interest Is the NEP unique? Can the NEP be reached by

decentralized algorithms? Is the NEP Pareto optimal? How is the end-to-end QoS at NEP

divided among domains? How do parameters, such as price,

affect the NEP?

TOC Pricing SLA Results Solution


Solution to the Game NEP in Tandem Networks NEP is unique, non-zero when prices are set

appropriately (e.g., pIN > pOUT is sufficient) Asynchronous, distributed algorithm for reaching

NEP Each domain: gradient algorithm using only

local information Each domain updates in a random order but

infinitely often No need to use traffic model; just estimate

the gradient by perturbation Can be shown to converge to the unique NEP

TOC Pricing SLA Results Solution TOC Pricing SLA Results Solution


Example 1QoS Levels

q3

q2 q1

At NEP

q*=(0.920, 0.920, 0.942)S*=(45.90, 45.90, 46.97)

S DT1 T2S1 S2 S3q1 q2 q3

p1 p2 p3

q3Best reply from T2

Trajectory ofAdaptation

NEP

Best reply from T1

q2TOC Pricing SLA Results Examples

= 50, R(x)=10xp1 = 5 , p2 = 2.5 , p3 = 1


Example 21214

1

2 3

4 5

6

7 8

9

13

15 12

7.5

88

7.57.5

64

443

34

1

11

2.5

11

10201555s

52025104s

20515103s

10155202s

101010 101s

5d4d3d2d1d

Shortest-path routing basedon hop-count

demands

TOC Pricing SLA Results Examples


Example 2

access links last-hop links

backbone links

access links

0.8410.8510.8770.8440.9240.873

q6q5q4q3 q2q1

backbone links

0.8790.9410.9150.8830.9140.826

q12q11q10q9 q8q7

last-hop links

0.9630.9730.9110.9500.9280.924

q18q17q16q15 q14q13

TOC Pricing SLA Results Examples


Effect of Prices on NEP On local and end-to-end QoSHigher ingress/egress price ratio better

local QoSUneven price ratios poor end-to-end QoS


25 5 1Best QoS

25 2 1Poor QoS (T2)

25 20 1Poor QoS (T1)

TOC Pricing SLA Results Prices


Effect of Prices on NEP Price as Strategy:


NEP of individual selection of prices is degenerate: For q2, p1 fixed, T2 has incentive to set p2 to infinity

Could formulate as Stackelberg or repeated game Same difficulties as Formulation A

Better formulation: Selection of profit margins:m1 = p1/p2 and m2 = p2/p3

TOC Pricing SLA Results Prices


Effect of Prices on NEP Profit Margin as Strategy:


NEP exists: equal profit margins m and equal QoS q Both m and q decrease with number of providers Numerically: These prices seems to yield best QoS Note: This result requires no internal capacity constraints

TOC Pricing SLA Results Prices TOC Pricing SLA Results Prices


Conclusions Tandem networks with profit

margin and QoS as strategy, equilibrium prices lead to stable equilibrium for QoS (need QoS faster than prices)

General Topology: Still open problemExamples show that if profit

margins are not excessive, then QoS tends to converge

TOC Pricing SLA Conclusions TOC Pricing SLA Conclusions


Packets Model Tandem Network General Topology Conclusions

TOC Pricing Packets


Model

Pricing per packet Packet contains fields [x|y] that we discuss later Ack either follows reverse path or there is a pricing

message (to convey information about the other providers)

+ p1+ p2

p1+ p2

monitor marks and process

inter-network billing info

TOC Pricing Packets Model


Tandem Network

ISPj gets revenues pjd(p) Leader-Follower:ISP1, then ISP2, Nash: ISPj maximizes pjd(p) s.t. d(p) Cj Cooperative: Subsets of ISPs charge the

same price and play Nash against the others

d(p1 + + pN)

C1p1

C2p2

C3 CNp3 pN

TOC Pricing Packets Tandem


Tandem Network: N = 2



Tandem Network: N

For N 3, cooperationyields more revenuesfor all the ISPs

For N 3, cooperationyields more revenuesfor all the ISPs



Tandem Network

Protocol for cooperation (nave): Using TTL, last ISP (here, N) figures out that

new connection ID X corresponds to N Last ISP informs ISP1 that X == N ISP1 selects price for X to maximize pd(p) and

marks the packets of connection ID X with the price p/N.

d(p1 + + pN)

C1p1

C2p2

C3 CNp3 pN



General Topology

12

3

4

56

Route b

Route r

p(1, r)

p(3, b)p(1, b)

p(2, r)

p(5, r)

p(4, b)

p(6, r)

Nash: ISPj sets p(j, r) and p(j, b) to maximize its revenues subject to its capacity constraint

Cooperative: Maximize sum of revenues subject to all the capacity constraints; Redistribute the revenues in proportion to traffic

TOC Pricing Packets General


General Topology Case A. no constraint is active

Under cooperation prices are smaller and profits larger Case B. cooperation and Nash have the same set of

active constraints Total price for users is same under cooperation and Nash Under Nash, bottleneck providers get larger share than

under cooperation However, congestion price at bottlenecks is larger under

cooperation than under Nash, thus providing more incentive to upgrade (and drive the system to case A)

Case C. cooperation and Nash have different set of active constraints Still open

Fairness issue in the case of capacity constraintTOC Pricing Packets General TOC Pricing Packets General


Conclusions Packet pricing looks promising Bottleneck ISPs have incentive to play Nash,

others to cooperate Bottleneck has incentive to upgrade Eventually, demand is constraint and revenues

are split evenly In some networks, routing may prevent

bottleneck ISPs from overcharging Need more work on routing & protocols.

TOC Pricing Packets Conclusions TOC Pricing Packets Conclusions


Summary We believe the lack of economic incentives

explains the state of QoS To modify the incentives, one needs new

mechanisms for charging and redistributing revenues

Market segmentation is key to improved revenues

Pricing has two effects: Signal for efficient sharing of bottlenecks

(valuable traffic displaces less valuable) Extract revenues from users willingness to pay

TOC Summary


End-users / Enterprises

Content Service

Providers

Resource Service

Providers

Network Planning and Management

Technology

Economics

DataCollection

ResourcePricing

Business Relationship

DataCollection

DataCollection

Service Provider Ecosystem

Stakeholder

EconomicallyEfficientResourceAllocation

Summary Different application

requirements Enable new applications higher revenues

Different user utilities Enable market segmentation higher revenues

More flexible economic arrangements 800-service, third party

billing, Various players get fair share

of revenues Incentive for improved

services Flexible peering agreements

Revenues

Service Quality

increases improve

TOC Summary


SummaryDesirable Features of Mechanisms Everybody is a player

Not simply social maximization Designed for multi-provider and multi-business

environment Heterogeneous

Incentive-compatible Dont assume altruism

Scalable 12,000+ ASes

Flexible: Support different service types Dependable service, variable price Dependable price, variable service

Catalyst for ecology Network; Storage; Distribution; Contents;

TOC Summary


SummaryResearch Issues Necessity of economics-networking synergy

Upgrades of networks require incentives Incentives necessitate economic mechanisms Economic mechanisms require protocols

Design of protocols that are flexible Support different economic models

Suitable mechanisms Impact on industry structure

Implementation considerations Are overlays desirable? Security

TOC SummaryTOC Summary


Related Topics Pricing for Wi-Fi Access [MW03] ISP Competition [LMPRT01] Combinatorial Auctions [S90] Bidding for Nodes On Shortest Path [FPSS02]

TOC Related


References[BW98] Pio Baake, Thorsten Wichmann - On the Economics of Internet Peering -

January 1998.[CJ89] Chiu D-M and Jain R (1989). Analysis of the increase and decrease

algorithms for congestion avoidance in computer networks. Comp Networks and ISDN Sys 17: 114.

[CK95] Courcoubetis, C., G. Kesidis, A. Ridder, J. Walrand, and R. R. Weber (1995). Admission control and routing in ATM networks using inferences from measured buffer occupancy. IEEE Trans. On Communications 43, 1778 - 1784.

[CRT00] Cremer, J., P. Rey & J. Tirole ,"Connectivity in the Commercial Internet" Journal of Industrial Economics, December 2000, vol 48, n4, pp. 433-472

[CW03] Courcoubetis, C and R.R. Weber (2003). Pricing Network Services, Springer Verlag.

[FPSS02] Feigenbaum, C. H. Papadimitriou, R. Sami, S. Shenker (2002) A BGP-based Mechanism for Lowest-cost Routing,"in Proceedings of the 21st Symposium on Principles of Distributed Computing, ACM Press, New York, 2002, pp 173-182.

[FT91] Fudenberg, D. and J. Tirole (1991). Game Theory. MIT Press.[GK99] Gibbens, Kelly. Distributed connection acceptance control for a

connectionless network. [GH00] Geoff Huston Interconnection and Peering, November 2000. [JK02] Y. Jin and G. Kesidis, Feasible pricing of differentiated services for the

emerging Internet, in Proc. 40th Allerton Conference on Communications, Control and Computing, Oct. 2002.

TOC References


References[KMT98] F. P. Kelly, A.K. Maulloo D.K.H. Tan Rate control for communication

networks:shadow prices, proportional fairness and stability (1998) Journal of the Operational Research Society.

[KS01] Srisankar Kunniyur, R. Srikant Analysis and Design of an Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Management Srisankar Kunniyur R. Srikant, Proceedings of SIGCOMM 2001.

[LMPRT01] J.-J. Laffont, S. Marcus, P. Rey, and J. Tirole, Internet interconnection and the off-net-cost pricing principle, 2001.

[MW03] Musacchio, J. and J. Walrand. Game-theoretic analysis of Wi-Fi Access Pricing, in preparation.

[O98] Andrew Odlyzko, Paris Metro Pricing for the Internet (1998), ACM Conference on Electronic Commerce

[PG93] Abhay K. Parekh, Robert G. Gallager: A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case. INFOCOM 1993: 521-530.

[S90] Vernon Smith et al., Auction Design for Composite Goods, Journal of Economic Behavior and Organization, 14 (1990) 127-129.

[SV03] Jun Shu and Pravin Varaiya, Pricing Network Services. Infocom 2003.[V61] Vickrey, W., 1961, Counterspeculation, Auctions, and Competitive Sealed

Tenders, Journal of Finance, XVI, 8-37.

TOC References

Managing QoS in a Multiprovider NetworkQoS in a Multiprovider NetworkOverviewInternet StructureInternet StructureInternet StructureInternet StructureInternet StructureNetwork StructureImplicationsDifferent ViewsInteractionsPeering AgreementsPeering AgreementsPeering AgreementsPeering AgreementsPeering Agreements - BGPPeering Agreements - BGPPeering Agreements Note: BGP is blind to utilizationApproachesWhat and Where to Control?Best EffortPer Flow ReservationPer Flow Reservation - IntServPer Flow Reservation - IntServEnd-to-End Per Flow AdmissionEnd-to-End Per Flow AdmissionEnd-to-End Per Flow AdmissionEdge-to-Edge Pipe (e.g., MPLS)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Local Pipes (SLAs; e.g., DiffServ)Some LessonsComparisonComparisonWhy not much QoS?Social Welfare and Packet MarkingPrimalDualExampleExampleTCP ImplementationWhy Does It Work?ExtensionVirtual Queues

managing qos

Documents

peer toc overview peering

multiprovider network

clients toc overview

users network leads

different views end

network set prices p

client of n1 n1

implications end