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

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 Web Interface Java Applet Data Path PSTN NetMeeting Lucent Elemedia’s H.323 Protocol Stack Primary Rate ISDN Line (23 Simultaneous Calls)

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

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: (510) 642-8919 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. • 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.

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

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?