Using Prices to Allocate Resources at Access Points

1
Using Prices to Allocate Resources at Access
Points

• Jimmy Shih, Randy Katz, Anthony Joseph

Access Point A
Network Resources
One Administrative Domain
Access Point B
User A
User B
2
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.

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

4
Todays 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?

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

H.323 Gateway
PSTN
Internet
6
What Do We Want To Do?

• 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

Web Clients
H.323 Computer Telephony Service
Phones
Web Interface
Java Applet
Web Server
Motorola Vanguard H.323 Gateway
NetMeeting
Control
Database
Data Path
Web Interface
Java Applet
PSTN
NetMeeting
Primary Rate ISDN Line (23 Simultaneous Calls)
Lucent Elemedias H.323 Protocol Stack
7
Problem Proposed Solutions

• Congestion is a serious problem because users
  dont 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.

8
Proposed Solutions (cont.)

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

Internet
H.323 Gateway
PSTN
9
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.

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

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

12
Possible User Web Interface
Current Price for Using Your Computer 10
Tokens/min
Next Minute Price for Using Your Computer 20
Tokens/min
Current Price for Using Your Telephone 35
Tokens/min
Next Minute Price for Using Your Telephone 35
Tokens/min
Packet Loss Rate When Using Your Computer 3
Handoff the Current Call to Your Telephone
[phone] Yes?
Handoff the Current Call to Your Computer
annie.cs.berkeley.edu Yes?
13
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.

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

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

Users in a Local Area Network
Access Router
Internet
16
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.

17
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.
• Dont provide rebate if users dont use all their
  reserved resources.
• Allow users to change their reservations at any
  time.
• Dont charge users fees for changing their
  reservations.

18
Possible User Web Interface
Current Price Per Mbyte Per Sec 10 Tokens
Tokens Left for Today 200 Tokens
Current Usage 4 Mbyte Per Sec
How Much Bandwidth to Purchase 3 Mbyte Per
Sec
Most Willing to Pay Per Mbyte Per Sec 30 Tokens
19
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.

20
Deployment Experiments

• In the Fall, replace our research groups 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.

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

22
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?