1 / 56

Adaptive Multimedia Applications: Negotiation, Pricing, and QoS

This resource explores the negotiation, pricing, and quality of service for adaptive multimedia applications in IP networks. It discusses the challenges and opportunities for service providers in meeting diverse user requirements and offers solutions for efficient bandwidth utilization. The resource also introduces a dynamic resource negotiation protocol (RNAP) and a demand-sensitive pricing model.

rengland
Télécharger la présentation

Adaptive Multimedia Applications: Negotiation, Pricing, and QoS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Resource Negotiation, Pricing and QoS for Adaptive Multimedia Applications Xin Wang With Henning Schulzrinne Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang/RNAP.html

  2. Application SLA Application SLA Today’s IP Networks • Growth of new IP services and applications with different bandwidth and quality of service requirements • Presents opportunities and challenges for service providers Service Level Agreements (SLA) are negotiated based on Application Specific Needs bandwidth, loss, delay, jitter, availability, price ISP Networks & Applications IP Network Service User SCOPE

  3. The needs of Next Generation Service Providers • Revenue from the traditional connectivity services (raw bandwidth) is declining • Increase revenue by offering innovative IP services: • Deliver high-margin, differentiated services • VoIP, VPN, Applications Hosting etc • Gain competitive advantage by deploying new services more quickly, placing a premium on time to market and time to scale • Reduce cost and operation complexity • Evolve from static network management to dynamic service provisioning • Reduce costs by automating network and service management

  4. End User LAN POP Regional Provider Regional Provider NAP Backbone Provider Private Peering Backbone Provider Private Peering Private Network Internet Structure

  5. NORDUnet Traffic Analysis

  6. NORDUnet Traffic Analysis • Results: • All access links (interconnect ISP’s or connect private networks to ISP’s), including trans-Atlantic links, can get congested. • Average utilization is low: 20-30% • Peak utilization can be high: up to 100% • Congestion Ratio (peak/average):as high as 5. • Peak duration can be very long: • Chicago NAP congested once in 8/00, lasted 7 hours. • TeleGlobe links congested every workday in 8/00 and 9/00 • Reasons: Frequent re-configuration and upgrading;Load balancing to protect own users.

  7. Solution - Over-provisioning? • Add enough bandwidth for all applications in access network / backbone • Will over-provisioning be sufficient to avoid congestion? • How much bandwidth is enough to meet diverse user requirements? • No intrinsic upper limit on bandwidth use • How much does it cost to add capacity?

  8. Bandwidth Pricing • Reality: leased bandwidth price has not been dropping consistentlyand dramatically. • Facts: • 300 mile T1 price: • 1987: $10,000/month • 1992: $4,000/month • 1998: $6,000/month (thanks to high Internet demand) • 100-mile cabling cost in 1998: $65,000 • Links connecting ISP’s are very expensive

  9. Bandwidth Pricing (cont.) • Facts: • International Frame Relay with 256-kbps: thousands dollars a month. • Transit DS-3 link: $50,000/month between carriers. • Transit OC-3 link: $150,000/month between carriers. • Chicago NAP: • $3,900/month/DS-3, • $4,700/month/OC-3. Bandwidth may be cheap, but not free Higher-speed connection -- higher recurring monthly costs. Option - manage the existing bandwidth better, with a service model which uses bandwidth efficiently.

  10. A More Efficient Service Model • Quality of Service (QoS) • Condition the network to provide predictability to an application even during high user demand • Provide multiple levels of QoS to meet diverse user requirements • How efficiently does a QoS mechanism manage bandwidth? How can a user select one out of a spectrum of services?How much does a user need to pay for QoS? • Application adaptation • Source rate adaptation based on network conditions can avoid congestion and lead to efficient bandwidth utilization • How about also QoS? Why would an application adapt?

  11. A More Efficient Service Model (cont’d) • Service selection and dynamic resource negotiation • An Integrated mechanism by which the user can select one out of a spectrum of services • Network commits resources for short intervals - better response to changes in network conditions and user demand; allows better QoS support for adaptive applications • Usage-,QoS-,demand-sensitive pricing • Allow network to price services based on resources consumed, and allocate resources based on user willingness-to-pay • Give user incentive to select appropriate service based on requirements, adapt demand during network resource scarcity in response to increase in price

  12. What We Add to Enable This Model • A dynamic resource negotiation protocol: RNAP • An abstract Resource Negotiation And Pricing protocol • Enables user and network (or two network domains) to dynamically negotiate multiple services with different QoS characteristics • Enables network to formulate and communicate prices and charges • Lightweight and flexible: embedded in other protocols, e.g., RSVP, or implemented independently • Ensures service predictability: commit service and price for an interval • Supports multi-party negotiation: senders, receivers, or both • Reliable and scalable • A demand-sensitive pricing model • Enables differential charging for supporting multiple levels of services; services priced to reflect the cost and long-term user demand • Allows for congestion pricing to motivate user adaptation

  13. What we add... (cont’d) • Demonstrate a complete resource negotiation framework (RNAP, pricing model, user adaptation) on test-bed network • Simulations show significant advantages relative to static resource allocation and fixed pricing: • Much lower service blocking rate under resource contention • Service assurances under large or bursty offered loads, without highly conservative provisioning • Higher perceived user benefit and higher network revenue

  14. Outline • RNAP: Architecture and Messaging • Pricing models: • Existing model • Usage and congestion-based pricing model • Pricing mechanism • User adaptation • Test-bed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  15. Protocol Architectures: Centralized Host Resource Negotiator RNAP Messages Network Resource Negotiator NRN NRN NRN HRN HRN Access Domain - A Edge Router Access Domain - B Internal Router Intra-domain messages Transit Domain RNAP-C

  16. Protocol Architectures: Distributed RNAP Messages HRN LRN LRN LRN LRN LRN LRN LRN LRN LRN HRN LRN LRN Access Domain - A LRN LRN Edge Router Access Domain - B Internal Router Transit Domain RNAP-D

  17. RNAP Messages Query: Inquires about available services, prices Query Quotation Quotation: Specifies service availability, accumulates service statistics, prices Reserve Commit Reserve: Requests services and resources, Modifies earlier requests Periodic negotiation Quotation Commit: Admits the service request at a specific price or denies it. Reserve Commit Close: Tears down negotiation session Close Release: Releases the resources Release

  18. Message Aggregation (RNAP-D) Turn on router alert Turn off router alert Sink-tree-based aggregation

  19. Message Aggregation (RNAP-C) NRN Sink-tree-based aggregation

  20. RNAP Message Aggregation Summary • Aggregation when senders share the same destination network • Messages merged by source or intermediate domains • Messages de-aggregated at destination border routers (RNAP-D), or NRNs (RNAP-C) • Original messages sent directly to destination/source domains without interception by intermediate RNAP agents; aggregate message reserves and collects price at intermediate nodes/domains • Overhead Reduction • Processing overhead, storage of states

  21. Block Negotiation (network-network) • Aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics Bandwidth time

  22. Outline • RNAP: Architecture and Messaging • Pricing models: • Comparison of model • Usage and congestion-based pricing model • Pricing mechanism • User adaptation • Test-bed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  23. Pricing in Current Internet • Access-rate-dependent flat charge (AC) • Simple, predictable • Difficult to compromise between access speed and cost • No incentive for users to limit usage congestion • Usage-based charge • Volume-dependent charge (V) • Time-base charge (T) • work better for uniform per-time unit resource demands, e.g., telephone • Access charge + Usage-based charge • Per-hour charge after certain period of use, or per-unit charge after some amount of traffic transmitted. • Flat charge for basic service, usage charge for extra bandwidth or premium services

  24. Two Volume-based Pricing Strategies • Fixed-Price (FP): fixed unit volume price • FP-FL: per-byte charge are same for all services • FP-PR: service class dependent • FP-T: time-of-day dependent • FP-PR-T: FP-PR + FP-T • During congestion: higher blocking rate ORhigher dropping rate and delay • Congestion-dependent-Price (CP): FP + congestion-sensitive price component • CP-FL, CP-PR, CP-T, CP-PR-T • During congestion: users maintain service by paying moreORreducing sending rateOR switching tolower service class • Reduced rate of service blocking, packet dropping and delay

  25. Important Time Scales • Technical levels of interaction • Monetary levels of interaction atomic short-term medium-term long-term Retransmission Flow Control Error Handling Reservation Resource Capacity Planning Scheduling Feedback Routing Policing time Congestion Time-of-day Pricing Flat Rates Pricing

  26. Pricing Strategies • Holding price and charge: based oncost of blocking other users by holding bandwidth even without sending data • phj = j (pu j - puj-1) , chij(n) = ph j r ij(n) j • Usage price and charge: optimize the provider’s profit • max [Σl x j (pu1 , pu2 , …, puJ ) puj - f(C)], s.t. r (x (pu2 , pu2 , …, puJ)) R • cuij (n) = pu j v ij (n) • Congestion price and charge: drive demand to supply level (two mechanisms)

  27. Usage Price for Differentiated Service • Usage price based on cost of class bandwidth: • lower target load (higher QoS) -> higher per-unit bandwidth price • Parameters: • pbasicbasic rate for fully used bandwidth •  j : expected load ratio of class j • xij: effective bandwidthconsumption of application i • Aj : constant elasticity demand parameter • Price for class j: puj = pbasic / j • Demand of class j: xj ( puj ) = Aj /puj • Effective bandwidth consumption: xej ( puj ) = Aj / (puj j ) • Network maximizes profit: • max [Σl(Aj /pu j ) pu j - f (C)], puj = pbasic / j , s. t.ΣlAj / (pu j j ) C • Hence: pbasic =ΣlAj / C , puj = ΣlAj /(C j)

  28. Congestion price: first mechanism - Tatonnement • Tatonnement process (CPA-TAT): network applies congestion charge proportional to excess demand relative to target utilization • pcj (n) = min [{pcj (n-1) + j(Dj, Sj) x (Dj-Sj)/Sj,0 }+, pmaxj ] • ccij (n) = pc j v ij (n)

  29. Congestion price: second mechanism - M-bid Second-price Auction • Auction models in literature: • Assume unique bandwidth/price preference, one bid • Service uncertainty: not know about high demand until rejected • Higher setup delay, signaling burst, life-time auction, user response to auction results not considered • M-bid auction model: • User bids (bandwidth, price) for a number of bandwidths, bids obtained by sampling utility function. • Network selects highest bids (one per user); charges highest rejected bid price • During high demand: lower bandwidth (higher price per unit bandwidth) bids get selected; more users served • Inter-auction admission to reduce setup delay • Support auction for a period to help for congestion control

  30. Outline • RNAP: Architecture and Messaging • Pricing models: • Comparison of model • Usage and congestion-based pricing model • Pricing mechanism • User adaptation • Test-bed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  31. Rate Adaptation of Multimedia System • Enable multimedia applications to gain optimal perceptual value based on the network conditions and user profile. • A Host Resource Negotiator (HRN) negotiates services with network on behalf of a multimedia system. • Utility function: users’ preference or willingness to pay Cost U1 U2 Utility/cost/budget U3 Budget Bandwidth

  32. Example Utility Function • User defines utility at discrete bandwidth, QoS levels • Utility is a function of bandwidth at fixed QoS • An example utility function: U (x) = U0 + log (x / xm) • U0 :perceived (opportunity) value at minimum bandwidth •  : sensitivity of the utility to bandwidth • Function of both bandwidth and QoS • U (x) = U0 + log (x / xm) - kd d - kl l , for x  xm • kd : sensitivity to delay • kl : sensitivity to loss

  33. Two Rate Adaptation Models • User adaptation under CPA-TAT (tatonnement-based pricing) • Optimize perceived surplus subject to budget and application requirements: U = ΣiUi (xi(Tspec, Rspec)] • max [ΣlUi (xi ) - Ci (xi) ], s. t. ΣlCi (xi) b , xmini xi xmaxi • With the example utility functions: • max [Σl U0i + ilog (xi / xmi ) - kdi d - klil - pi xi ], s.t. Σlpi xib , x  xm ,d D, l  L • Without budget constraint: x i = i / pi • With budget constraint: x i = bi / pi, withb i = b (i /Σl k ) • User adaptation under CPA-AUC (second-price auction) • Submit M-bid derived by sampling utility function; adapt rate based on allocated bandwidth/QoS • Adaptation of applications in multimedia system • Distribute bid/allocated bandwidth among applications for optimal overall surplus

  34. Stability and Oscillation Reduction • Congestion-sensitive pricing has been shown to be stable, see references. • Oscillation reduction • Users:re-negotiate only if price change exceeds a given threshold • Network: update price only when traffic change exceeds a threshold; negotiate resources in larger blocks between domains

  35. Outline • RNAP: Architecture and Messaging • Pricing models: • Comparison of model • Usage and congestion-based pricing model • Pricing mechanism • User adaptation • Test-bed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  36. Demonstrate functionality and performance improvement: blocking rate, average loss and delay, price stability, perceived media quality Host HRN negotiates resources for a system Host processes (HRN, VIC, RAT) communicate through Mbus Network FreeBSD 3.4 + ALTQ 2.2, CBQ extended for DiffServ NRNs: Process RNAP messages Admission control, monitor service statistics, compute price At edge, dynamically configure the conditioners and form charge Inter-entity signaling: RNAP Test-bed Architecture RAT VIC Mbus HRN RNAP NRN

  37. Functions of Routers • Interior routers: per-class policing, e.g, TBMETER (in/out) for a class • Edge routers: flow conditioning/policing based on SLA

  38. Network Resource Negotiator (NRN) • Monitor statistics and provide price for each service class • Measurement-based admission control • predict future demand, update congestion price based on predictions

  39. Network States • Per-class bandwidth and price variations • Reduction in blocking due to adaptation

  40. Adaptive Wireless Terminal • WAP development over Nokia Toolkit 2.0 • Currently cell phone services: • Flat pricing and best effort: when congestion, all users get worse quality - coarse voice, busy signal, cut off • Using our solution: • Optionally provide real-time pricing information, e.g., every 10 minutes or every call (lower average charge for reward) • Customers choices: • pay a premium to have best quality • pay less by tolerating worse quality • back off to call another time. • Reduce the blocking rate of overall network

  41. Outline • RNAP: Architecture and Messaging • Pricing models: • Comparison of model • Usage and congestion-based pricing model • Pricing mechanism • User adaptation • Test-bed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  42. Simulation Design • Performance comparison: • Network with dynamic services and rate-adaptive users versus network with non-adaptive users • Fixed price policy (FP) (usage price + holding price) versus congestion price based adaptive service (CPA) (usage price + holding price + congestion price) • Four groups of experiments: • (1) Effect of traffic burstiness; (2) Effect of traffic load; (3) Load balance between classes; (4) Effect of admission control • Engineering metrics: bottleneck traffic arrival rate, average packet loss and delay, user request blocking probability • Economic metrics: average and total user benefit, end-to-end price and its standard deviation, network revenue

  43. Simulation Models • Network Simulator (NS-2) • Weighted Round Robin (WRR) scheduler • Three classes: EF, AF, BE • EF: tail dropping, limited to 50 packets; load threshold 40%, delay bound 2 ms, loss bound 10-6 • AF: RED-with-In-Out (RIO), limited to 100 packets; load threshold 60%, delay bound 5 ms, loss bound 10-4 • BE: Random Early Detection (RED), limited to 200 packets; load threshold 90%, delay bound 100 ms, loss bound 10-2 • Sources: mix of on-off and Pareto on-off (shape parameter: 1.5) • Negotiation period: 30s, session length 10 min

  44. Simulation Architecture Topology 1 (60 users) Topology 2 (360 users)

  45. Effect of Traffic Burstiness Average packet loss Average packet delay

  46. Effect of Traffic Burstiness (cont’d) Price average and standard deviation of AF class Average user benefit

  47. Effect of Traffic Load (cont’d) Averagepacket loss Average packet delay

  48. Effect of Traffic Load Price average and standard deviation of AF class Average user benefit

  49. Load Balance between Classes (cont’d) Average packet delay Average packet loss

  50. Load Balance between Classes Variation over time of the price of AF class Ratio of AF class traffic migrating through class re-selection

More Related