1 / 67

Xin Wang Work under Professor Henning Schulzrinne Internet Real -Time Laboratory

Scalable Network Architecture & Measurements. for Multicast and Adaptive QoS. Xin Wang Work under Professor Henning Schulzrinne Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang. Scope of this Talk. Main work

coraleon
Télécharger la présentation

Xin Wang Work under Professor Henning Schulzrinne Internet Real -Time Laboratory

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. Scalable Network Architecture & Measurements for Multicast and Adaptive QoS Xin Wang Work under Professor Henning Schulzrinne Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang

  2. Scope of this Talk • Main work • Resource Negotiation, Pricing, and QoS for Adaptive Multimedia Applications • Other work • Measurements and Analysis of LDAP Performance • IP Multicast Fault Recovery in PIM over OSPF

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

  4. Application SLA Application SLA Today’s IP Networks Service Level Agreements (SLA) are negotiated based on Application Specific Needs bandwidth, loss, delay, jitter, availability, price ISP Networks & Applications IP Network Service User 1. Growth of new IP services and applications with different bandwidth and quality of service requirements 2. Revenue from the traditional connectivity services is declining 3. New services presents opportunities and challenges for service providers

  5. The Needs of Next Generation Service Providers • Increase revenue by offering innovative services • VoIP, VPN, Applications Hosting etc • Deliver high-margin, differentiated services • Gain competitive advantage - rapidly deploy and scale new services • Meet service expectations of diverse services: • Over-provision - add enough raw bandwidth to backbone and access networks AND/OR • Provision and manage network more efficiently (greater automation, dynamic provisioning)

  6. NORDUnet Traffic Analysis

  7. NORDUnet Traffic Analysis • Results: • All access links (interconnect ISP’s or connect private networks to ISP’s, 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.

  8. Bandwidth Pricing • Reality: leased bandwidth price has not been dropping consistentlyand dramatically. • 300 mile T1 price: • 1987: $10,000/month • 1992: $4,000/month • 1998: $6,000/month (thanks to high Internet demand) • Links connecting ISP’s are very expensive • Transit DS-3 link: $50,000/month between carriers. • Transit OC-3 link: $150,000/month between carriers. • Cost of fiber optics is declining. But network management costs - switches and routers, state of the art POP, data centers - are high. Bandwidth may be cheap, but not free Higher-speed connection -- higher recurring monthly costs.

  9. Is Simply Over-Provisioning Enough? • Even though average bandwidth utilization is low, congestion can happen; Access links get congested frequently • Wireless bandwidth is even more scarce • Bandwidth prices not dropping rapidly • How much bandwidth is enough? • No intrinsic upper limit on bandwidth use 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 services • Efficient bandwidth management? Can a user select one out of a spectrum of services?How much does a user need to pay? • Application adaptation • Source rate adaptation based on network conditions - congestion control and efficient bandwidth utilization • Adaptation of service (QoS level)? • Why would an application adapt?

  11. A More Efficient Service Model (cont’d) • Requirements of QoS/adaptive model: • mechanism to select and negotiate services • adaptive applications • short-term resource configuration for better response to user demand and network conditions, for more efficient resource usage Allow dynamic resource negotiation during ongoing service • price network services based on QoS (resources consumed), allocate resources based on user willingness-to-pay • provide signal / incentive for user adaptation through pricing • A dynamic service selection and resource negotiation mechanism • Usage-,QoS-,demand-sensitive pricing

  12. What We Add to Enable This Model • A dynamic resource negotiation protocol:RNAP • An abstractResource Negotiation And Pricingprotocol • Enables user and network (or two network domains) to dynamically negotiate multiple services • Enables network to formulate and communicate prices and charges • Service predictability: commit service and price for an interval • Multi-party negotiation: senders, receivers, or both • Reliable and scalable • Lightweight and flexible: embedded in other protocols, e.g., RSVP, or implemented independently • 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 • Background • RNAP: architecture and messaging • Pricing models: • Existing model • Proposed pricing model • User adaptation • Testbed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  15. Protocol Architectures: Centralized(RNAP-C) 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

  16. Protocol Architectures: Distributed(RNAP-D) 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

  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. Turn off router alert Message Aggregation (RNAP-D) Turn on router alert Sink-tree-based aggregation

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

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

  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 • Background • RNAP: architecture and messaging • Pricing models: • Comparison of model • Proposed pricing model • User adaptation • Testbed 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 • Simple, price predictable • Difficult to compromise between access speed and cost • No incentive for users to limit usage congestion • Usage-based charge • Volume-dependent charge • Time-base charge • 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 • Flat pricing (FP-FL): per-byte charge are same for all services • Priority pricing (FP-PR): service class dependent • Time-dependent pricing (FP-T): time-of-day dependent • Time-dependent priority pricing (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 have options to maintain service by paying moreORreducing sending rateOR switching tolower service class • Overall 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: maximize the provider’s profit, constrained by resource availability • 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): • 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: user does not know about high demand until rejected • Other issues: setup delay, signaling burst, one-time auction, user response to auction results • M-bid auction Model • User bids (bandwidth, price) for a number of bandwidths, bids obtained by sampling utility function. • Network selects highest bids, charges highest rejected bid price • Periodic auctions - support congestion control • During high demand: lower bandwidth (higher price per unit bandwidth) bids get selected; more users served • Inter-auction admission to reduce setup delay

  30. Example of M-bid Auction • Total capacity 70, congestion price is 2 Bid Bandwidth Bid Selection Bid Price Bidder 1 10 5 2 10 4 1 15 4 3 20 3.5 2 25 3 Cutoff 2 30 3 Congestion Price

  31. Outline • Background • RNAP: architecture and messaging • Pricing models: • Comparison of model • Proposed pricing model • User adaptation • Testbed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  32. Rate Adaptation of Multimedia System • 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

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

  34. Two Rate Adaptation Models • User adaptation under CPA-TAT (tatonnement-based pricing) • Optimize perceived surplus subject to budget and application requirements • With the example utility functions: • 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

  35. Stability and Oscillation Reduction • Congestion-sensitive pricing has been shown to be stable • 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

  36. Outline • Background • RNAP: architecture and messaging • Pricing models: • Comparison of model • Proposed pricing model • User adaptation • Testbed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

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

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

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

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

  41. Adaptive Wireless Terminal • WAP development over Nokia Toolkit 2.0 • Current cell phone services: • Flat pricing and best effort: during congestion, all users get worse quality - distorted voice, busy signal, cut off • Adaptive Wireless Terminal: • Provide real-time pricing information, periodically (e.g., every 10 minutes) or per-call based • Lower basic charge, e.g. 20 c/min instead of 30 c/min • During congestion, price raised subject to upper limit • Customer choices under congestion: pay a premium to maintain high quality; pay less and tolerate worse quality; back off to call later. • Reduce overall network blocking rate

  42. Outline • Background • RNAP: architecture and messaging • Pricing models: • Comparison of model • Proposed pricing model • User adaptation • Testbed demonstration of Resource Negotiation Framework • Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework

  43. Simulation Design • Performance comparison: • Network with dynamic service negotiation and rate-adaptive users vs. 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 load; (2) Effect of admission control ; (3) Effect of traffic burstiness; (4) Load balance between classes; • 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

  44. Simulation Models • Network Simulator (NS-2) • Weighted Round Robin (WRR) scheduler • Three classes: EF, AF, BE • EF: tail dropping, load threshold 40%, delay bound 2 ms, loss bound 10-6 • AF: RED-with-In-Out (RIO), load threshold 60%, delay bound 5 ms, loss bound 10-4 • BE: Random Early Detection (RED), 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

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

  46. Effect of Traffic Load Averagepacket loss Average packet delay

  47. Effect of Admission Control Average packet delay Average packet loss

  48. Effect of Admission Control (cont’d) Average price and standard deviation Blocking rate

  49. Effect of Admission Control (cont’d) Network revenue Average user benefit

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

More Related