Using Prices to Allocate Resources at Access Points

Jimmy Shih, Randy Katz, Anthony Joseph

One Administrative

Domain

AccessPoint A

AccessPoint B

Network Resources

User A

User B

Problem & Proposed Solutions Access points are congested. E.g modem

pools, access routers. Can add capacity, perform admission

control, balance loads between the access points, allow advance reservation, or constrain usage.

For admission control, use prices to allocate the access points to those who value them the most.

For load balancing, use prices to encourage users to use the less capable access points.

State-of-the-Art on Congestion Pricing Lots of theoretical & simulation work on

congestion pricing. Explored issues like benefits, stability, fairness, & robustness.

Lots of work on auctions. But prices are very unpredictable.

Lots of systems deployed using usage-based pricing.

No discussion of exactly how to implement systems that use congestion pricing.

No system deployed using congestion pricing.

Today’s Goal & Outline Goal:

Discuss our hypotheses about congestion pricing, and how we can verify them through simulations and deployments.

Outline: Use the following two examples:

Using a H.323 gateway to make & receive telephone calls on the Internet.

Using an access router to send & receive IP packets. How to design systems that use congestion pricing? How effective can congestion pricing affect users’

behaviors?

What is a H.323 Gateway?

Connect the Internet to the Public Switched Telephone Network (PSTN).

Allow users to make & receive computers-to-PSTN, computer-to-computer, and PSTN-to-PSTN calls.

The bottleneck resource is the number of PSTN phone lines connected to the gateway.

The bottleneck resource is connection oriented. Each call uses the same amount of the bottleneck resource.

Internet PSTNH.323 Gateway

Provide students in the UC Berkeley dorms with a H.323 computer telephony service that allows them to use a web interface to make & receive telephone calls.

System Architecture:

What Do We Want To Do?

Web Interface

Java AppletNetMeeting Motorola

Vanguard H.323 Gateway

Web Clients H.323 Computer Telephony Service

PSTN

Phones

Web ServerControl

Data PathDatabase

Web Interface

Java AppletNetMeeting

Primary Rate ISDN Line (23 Simultaneous Calls)

Lucent Elemedia’s H.323 Protocol Stack

Problem & Proposed Solutions Congestion is a serious problem because users

don’t have dedicated lines or an over-provisioned network.

Use congestion pricing for admission control to: Encourage users not to call when the system is

congested. Encourage users to make their calls shorter when

the system is congested.

Use congestion pricing for load balancing to: Encourage users to use their computers instead of

telephones to minimize using the bottleneck resource.

Give each user a certain number of tokens per week for making & receiving phone calls.

Only need to perform accounting at the gateway. Only need to provide users with a web interface

containing the current prices.

Proposed Solutions (cont.)

Internet

PSTN

H.323 Gateway

Hypotheses Congestion pricing can:

Reduce bursts on demand at the gateway. Minimize the number of long duration calls.

Given enough incentives: Users would choose congestion pricing over flat

rate pricing. Users would use their computers instead of

telephones. Through proper policies, we can ensure that

the system is stable when using congestion pricing.

Policies for Admission Control

Let the gateway decides the price it wants to charge.

Set the price equals to a function on the load.

Inform users the current price and the next minute price. The current price will not change while the next minute price will change depending on the congestion.

Have the gateway gradually inform users of new prices.

Policies for Load Balancing Charge users a flat minute rate for

using their telephones, and congestion prices for using their computers.

Inform users the current connection qualities if they use their computers.

When users use their telephone to make & receive calls, inform them how much cheaper it would be if they switch to their computers.

Possible User Web Interface

Current Price for Using Your Computer: 10 Tokens/min

Current Price for Using Your Telephone: 35 Tokens/min

Next Minute Price for Using Your Computer: 20 Tokens/min

Next Minute Price for Using Your Telephone: 35 Tokens/min

Handoff the Current Call to Your Computer: annie.cs.berkeley.edu Yes?

Handoff the Current Call to Your Telephone: (510) 642-8919 Yes?

Packet Loss Rate When Using Your Computer: 3%

Simulations What if users’ demands are not

sensitive to changing prices? What if users take a long time to

react to changing prices? Use calling patterns from our

previous deployments of a H.323 computer telephony service to perform these simulations.

Deployment Experiments In August, provide the service to 200 students in

the UC Berkeley dorms. Alternate between congestion pricing, time of day

pricing, and flat rate pricing on a weekly basis. Offer users the option at the beginning of each

week of paying congestion prices, a flat minute rate per call, or a flat minute rate for the whole week.

Charge users congestion prices for using their computers and a flat minute rate for using their telephones.

Congestion Pricing at an Access Router

Lots of people in a local area network trying to send and receive IP packets through a bottleneck link router. E.g. 500 students in a dorm sharing an access router.

The bottleneck resource is connectionless. Users can adjust their bandwidth and duration usage. Only need to modify the access router and provide

users with a web interface containing the current prices.

InternetAccess Router

Users in a Local Area Network

Hypotheses Congestion pricing can

Be used to decide whose incoming and outgoing packets to drop during congestion.

Quickly free up large amount of bandwidth. Reduce bursts on demand at the router. Encourage users to reduce their bandwidth

and duration usage during congestion.

Policies for Admission Control

Inform users the amount of bandwidth they are using. Allow users to reserve the amount of incoming and

outgoing bandwidth they need, and the most they are willing to pay for them.

Have each Mbyte of bandwidth cost the same. Don’t provide rebate if users don’t use all their

reserved resources. Allow users to change their reservations at any time. Don’t charge users fees for changing their

reservations.

Possible User Web Interface

Current Price Per Mbyte Per Sec: 10 Tokens

How Much Bandwidth to Purchase: 3 Mbyte Per Sec

Tokens Left for Today: 200 Tokens

Most Willing to Pay Per Mbyte Per Sec: 30 Tokens

Current Usage: 4 Mbyte Per Sec

Simulations What if users can only adjust their

bandwidth usage? What if they can only adjust their duration usage? Etc.

What if users take a long time to react to changing prices?

Use IP traces from the Internet Traffic Archive to perform these simulaitons.

Deployment Experiments In the Fall, replace our research group’s

subnet router with a Nortel Java Programmable router that uses congestion pricing to decide whose packets to drop.

Measure how quickly a user can obtain large amount of bandwidth if he is willing to pay for them.

Measure users’ willingness to pay at any given time.

Measure a user’ willingness to pay throughout a day.

Summary Lots of hypotheses about congestion pricing. Determine the right policies for using

congestion pricing. E.g. How to ensure price & system stability, minimize

starvation, prevent denial of service attacks, etc. Determine how well congestion pricing can

affect users behaviors. E.g. Amount of incentives required for users to

choose congestion pricing over flat rate pricing, to adjust their behaviors during congestion, to use the less capable access points, etc.

Discussion Is it a good idea to use congestion

pricing to allocate resources at access points?

What are our hypotheses about congestion pricing?

How can we verify them through simulations and deployments?