1. User Experiments of Using Congestion Pricing to Allocate Access Link Bandwidth Jimmy Shih, Randy Katz, Anthony Joseph

2. Problem Statement Apply congestion pricing, varying prices according to load, at access links. Some users can conserve & save. Others can pay more & receive good quality. How to apply congestion pricing? Effective.  Users can understand & react to price changes.  Reacting to price changes would be useful. Acceptable.  Not burdensome to users. Internet Local Area Network Computer Access Link Computer $

3. State-of-the-Art Advantages & disadvantages. Economic efficiency. User involvement. Simulation studies. Compare congestion pricing with flat-rate. Explore a particular design space.  Depend on user model. Limited user studies involving pricing. Our work. Real implementation & user trial. Varying prices in the middle of usage.

4. Methodology Difficult to conduct user study with large number of users. Small-scale experiments.  Feasibility & acceptance. Large-scale simulations.  Effectiveness. Iterative of prototype, evaluation, analysis. Prototype & evaluate.  Using small-scale experiments. Analyze.  Using large-scale simulations. Prototype Evaluate Analyze

5. Testbed Packeteer PacketShaper. Monitor & shape all incoming & outgoing flows.  2000+ flows on 100Mbps Ethernet. Proxy for the PacketShaper. Monitoring, price setting, allocating, & accounting.  Monitor usage once every 3 seconds.  Provide web interface (web server & Java applet) for current usage & purchase request.  Allocate different bandwidth to each IP address.  Protect control traffic using the PacketShaper. 1 2 3

6. First Prototype 3 bandwidth sizes, SMALL, MEDIUM, LARGE. 150k, 5M, 10M. 1000 tokens a day. SMALL always free. Occasionally request MEDIUM or LARGE. Charge certain number of tokens/min for MEDIUM & LARGE.

7. Evaluation 12 users for two weeks. Usages dominated by short bursts when active. Web traffic. 10 seconds. Problems with charging per minute. Need frequent interaction. Constant worry about prices & tokens left. Hard to accurately specify purchase.  Low correlation between usage & purchase. Burst ends before a purchase. Purchase but did not use.  Lower correlation between usage & correct purchase. Ask for tools to automat purchases.

8. Second Prototype 3 QoS: RESPONSIVE MEDIUM SLOW-GOING 15 minutes per purchase. 24 tokens a day. SLOW-GOING Always free. MEDIUM 1 token/15min (6 hours). RESPONSIVE 2-6 tokens/15min (3-1 hour).

9. Evaluation 8 users for 1 weeks. RESPONSIVE price: 50% 2 tokens (GREEN). 25% 4 tokens (YELLOW). 25% 6 tokens (RED). Can easily entice users to select different QoS by changing prices. Price of RESPONSIVE Number of Samples % Select RESPONSIVE 2 Tokens/15min11855.1% 4 Tokens/15min4723.4% 6 Tokens/15min6513.8%

10. Conclusion Proof of concept. Fix QoS & vary prices to affect user behavior during congestion. 3 QoS based on smoothing because short bursts. If short bursts & long bursts, use smoothing + rate limiting. Through simulations, if can entice half of the users to select lower QoS during congestion, then would be effective in reducing burstiness at access links. Limit each user to certain number of tokens a day and charge certain token rate per 15 minutes of usage. User experiments. Varying prices can easily entice users to select different QoS. Charging once every 15 mins seems acceptable.