An Integrated Resource Negotiation, Pricing, and QoS Adaptation

An Integrated Resource Negotiation, Pricing, and QoS Adaptation
Framework for Multimedia Applications Xin Wang Internet Real -Time Laboratory Columbia University (Joint work with Henning Schulzrinne)

IRT, Columbia University
Outline Motivation Objectives Resource negotiation through RNAP: architectures, messages, aggregation, reliability Pricing Price and charge formulation Pricing on current Internet Proposed pricing schemes User request adaptation Simulation Conclusions 8/21/00 IRT, Columbia University

Motivation Multimedia requires minimum QoS Current approaches A: resource reservation, admission control, differentiated services Pros: QoS expectation Cons: insufficient knowledge on data traffics, conservative, network dynamics not considered, lacks pricing support for multiple service levels B: multimedia adaptation to network conditions Pros: efficient bandwidth usage Cons: users have no motivation to adapt requests 8/21/00 IRT, Columbia University

Objectives Develop Resource Negotiation and Pricing Framework which: Combines QoS support and user adaptation Allows resource commitment for short intervals Provides differential pricing for differentiated services Allows usage- and congestion-sensitive pricing to motivate user adaptation Allows provider to trade-off blocking connections and raising prices 8/21/00 IRT, Columbia University

Resource Negotiation through RNAP Assumption: Different service types, e.g. diff-serv, int-serv, best-effort. With a pricing structure (may be usage-sensitive) for each. RNAP (Resource Negotiation and Pricing): a protocol through which the user and network (or two network domains) negotiate network delivery services. Network -> User: availability of services, price quotations, accumulated charges, service statistics User -> Network: request/re-negotiate services Underlying Mechanism: Traffic engineering + network pricing 8/21/00 IRT, Columbia University

Resource Negotiation through RNAP (cont’d.) Characteristics Multiple service selection Centralized or distributed architecture Dynamic negotiation, multi-party negotiation Price collation and communication Scalable and reliable Who can use RNAP? Adaptive applications: adapt sending rate, choice of network services Non-adaptive applications: take fixed price, or absorb price change 8/21/00 IRT, Columbia University

Protocol Architectures: Centralized (RNAP-C)
NRN NRN NRN HRN HRN S1 R1 Access Domain - A Access Domain - B Transit Domain Network Resource Negotiator Internal Router NRN We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D) In RNAP-C, user negotiates through a HRN, each network domain has a NRN. When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain. This request is then propagated to next-domain NRN, and so on. In general, each NRN is in charge of admission control, price quotation and charging for its domain. Host Resource Negotiator Edge Router HRN Host Data Flow RNAP Messages Intra-domain messages 8/21/00 IRT, Columbia University

Protocol Architectures: Distributed (RNAP-D)
HRN HRN S1 R1 Access Domain - A Access Domain - B Transit Domain We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D) In RNAP-C, user negotiates through a HRN, each network domain has a NRN. When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain. This request is then propagated to next-domain NRN, and so on. In general, each NRN is in charge of admission control, price quotation and charging for its domain. Internal Router HRN Host Resource Negotiator Edge Router Data Flow Host RNAP Messages 8/21/00 IRT, Columbia University

RNAP Messages Query: Inquires about available services, prices Query Quotation: Specifies service availability, prices Quotation Reserve Commit Reserve: Requests service(s), resources Periodic re-negotiation Quotation Commit: Admits the service request at a specific price or denies it. Reserve Commit Close: Tears down negotiation session Close Release Release: Releases the resources 8/21/00 IRT, Columbia University

RNAP Message Aggregation RNAP-D RNAP-C 8/21/00 IRT, Columbia University

RNAP Message Aggregation (cont’d)
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 8/21/00 IRT, Columbia University

Block Negotiation Block Negotiation Aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics Bandwidth time 8/21/00 IRT, Columbia University

Reliability Soft state for synchronous messages, liveness tracking through data traffic monitoring Retransmission of asynchronous messages Server backup and information retrieval 8/21/00 IRT, Columbia University

Price and Charge Formulation Routers or NRNs maintain state information Resource usage, service prices, service statistics Id, price, accumulated charge for a user e2e price and charge collation Message passes through routers or NRNs, price/charge fields in message incremented Quotation : carry estimated price for each quoted service Commit : carry accumulated charge for preceding negotiation interval, committed price for next interval 8/21/00 IRT, Columbia University

Price Formulation in RNAP-C Some alternative Schemes: NRN does admission control and price computation Pricing based on topology, routing, policies, network load NRN determines data path Accumulates price Sends total price to HRN or neighbors Ingress router does admission control and price computation may determine internal router loads through egress-to-ingress probe messages Routers of the path make admission: through intra-domain signaling protocol, such as RSVP/YESSIR. 8/21/00 IRT, Columbia University

Pricing on Current Internet Access rate dependent flat charge Usage-based charge Volume-based charge Time-base charge Access charge + Usage-based charge 8/21/00 IRT, Columbia University

Two Volume-based Pricing Policies Fixed-Price (FP) FP-FL: 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 OR higher dropping rate and delay Congestion-Price-based Adaptation (CPA) FP + congestion-sensitive price CP-FL, CP-PR, CP-T, CP-PR-T During congestion: users maintain service by paying more OR reduce sending rate or lower service class 8/21/00 IRT, Columbia University

Proposed Pricing Strategies Holding price and charge: phj =  j (pu j - pu j-1) chij (n) = ph j r ij (n) j Usage price and charge: max [Σl x j (pu1 , pu2 , …, puJ ) puj - f(C)], s.t. r (x (pu2 , pu2 , …, puJ ))  R, j  J cuij (n) = pu j v ij (n) Congestion price and charge: pc j (n) = min [{pcj (n-1) +  j (Dj, Sj) x (Dj-Sj)/Sj,0 }+, pmaxj ] ccij (n) = pc j v ij (n) 8/21/00 IRT, Columbia University

Usage Price for Differentiated Services Usage price for a service class based on cost of class bandwidth: lower target load -> higher per unit bandwidth price, higher QoS Parameters: pbasic basic rate for fully used bandwidth  j : expected load ratio of class j xij : effective bandwidth consumption of application i Aj : constant elasticity demand parameter 8/21/00 IRT, Columbia University

Usage Price for Differentiated Services (cont’d) Price for class j: puj = pbasic /  j Demand of class j: xj ( puj ) = Aj / puj Effective bandwidth consumption: xe j ( puj ) = Aj / ( puj  j ) Network maximizes profit max [Σl (Aj / pu j ) pu j - f (C)], puj = pbasic /  j , s. t. Σl Aj / ( pu j  j )  C Hence: pbasic = Σl Aj / C , puj = Σl Aj /(C j) 8/21/00 IRT, Columbia University

User Adaptation based on Utility Users adapt service selection and data rate based on utility which is associated with QoS Utility expressed in terms of perceived value, e.g.,15 cents /min Multi-application task (e.g., video-conference) - maximize total utility of task subject to budget -> dynamic resource allocation among component applications User utility optimization: U = Σi Ui (xi (Tspec, Rspec)] max [Σl Ui (xi ) - Ci (xi) ], s. t. Σl Ci (xi)  b , xmini  xi  xmaxi Determine optimal Tspec and Rspec 8/21/00 IRT, Columbia University

User adaptation based on utility: example 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 Optimization: max [Σl U0i + i log (xi / xmi ) - kdi d - kl i l - pi xi ], s. t. Σl pi xi  b , x  xm , d  D, l  L Without budget constraint: x i = i / pi With budget constraint: b i = b ( i / Σl  k ) 8/21/00 IRT, Columbia University

Stability and Oscillation Reduction Congestion-sensitive pricing (tatonnement process) has been shown to be stable (see web page for proof) Oscillation reduction Users: re-negotiate only if price change exceeds a given threshold Network: a) update price only when traffic change exceeds a threshold; b) negotiate resources in larger blocks between domains 8/21/00 IRT, Columbia University

Simulation Model Topology 1 Topology 2 8/21/00 IRT, Columbia University

Simulation Model Network Simulator (NS-2) Weighted Round Robin (WRR) scheduler Three classes: EF, AF, BE EF: tail dropping, limited to 50 packets expected load threshold 40%, delay bound 2 ms, loss bound 10-6 AF: RED-with-In-Out (RIO), limited to 100 packets expected load threshold 60%, delay bound 5 ms, loss bound 10-4 BE: Random Early Detection (RED), limited to 200 packets expected load threshold 90%, delay bound 100 ms, loss bound 10-2 8/21/00 IRT, Columbia University

Simulation Model (cont’d) Parameter Set-up topology1: 60 users; topology 2: 360 users sources: on-off or Pareto on-off (shape parameter: 1.5) price adjustment factor: σ = 0.06; update threshold: θ = 0.05 negotiation period: 30 seconds price (for a 64 kb/s transmission): usage price pbasic = $0.08 / min, pEF = $0.20 / min, pAF = $0.13 / min, pBE = $0.09 / min holding price: pEF = $0.067 / min, pAF = $0.044 / min : 64 kb/s as reference, randomly set based on service type EF: $0.13 / min - $0.20 / min; AF: $0.09/ min - $0.26 / min ; BE: $0.06 / min - $0.18 / min. average session length 10 minutes,exponentially distributed. 8/21/00 IRT, Columbia University

Simulation Model (cont’d.) Performance measures Engineering metrics Bottleneck traffic arrival rate Average packet loss and delay User request blocking probability Economic metrics Average user benefit End to end price, and it standard deviation 8/21/00 IRT, Columbia University

Design of Experiments Performance comparison: FP (usage price + holding price) and CPA (usage price + holding price + congestion price) Four groups of experiments: Effect of traffic burstiness Effect of traffic load Load balance between classes Effect of admission control Other experiments (see web page for references ): Effect of system control parameters: target reservation rate, price adjustment step, price adjustment threshold Effect of user demand elasticity, session multiplexing Effect when part of users adapt, session adaptation and adaptive reservation - Offered load: total user resource requirement at the bottleneck over the bottleneck capacity - Bottleneck bandwidth utilization: averaging the reserved bandwidth (ratio of the link capacity) over all negotiation periods - User request blocking probability: percentage of user requests being denied - Average and total user benefit: utility. Not benefit for a blocked call. - Network revenue: total charge paid to the network for all the admitted requests during a simulation -System price: Different along different paths. -User charge: based on bandwidth and price quoted. 8/21/00 IRT, Columbia University

Effect of Traffic Burstiness Price average and standard deviation of AF class Variation over time of the price of AF class 8/21/00 IRT, Columbia University

Effect of Traffic Burstiness (cont’d) Average packet delay Average packet loss 8/21/00 IRT, Columbia University

Effect of Traffic Burstiness (cont’d) Average traffic arrival rate Average user benefit 8/21/00 IRT, Columbia University

Effect of Traffic Load Price average and standard deviation of AF class Variation over time of the price of AF class 8/21/00 IRT, Columbia University

Effect of Traffic Load (cont’d) Average packet delay Average packet loss 8/21/00 IRT, Columbia University

Effect of Traffic Load (cont’d) Average traffic arrival rate Average user benefit 8/21/00 IRT, Columbia University

Load Balance between Classes Variation over time of the price of AF class Ratio of AF class traffic migrating through class re-selection 8/21/00 IRT, Columbia University

Load Balance between Classes (cont’d) Average packet delay Average packet loss 8/21/00 IRT, Columbia University

Effect of Admission Control Average and standard deviation of AF class price User request blocking rate 8/21/00 IRT, Columbia University

Effect of Admission Control (cont’d) Average packet delay Average packet loss 8/21/00 IRT, Columbia University

Prototype: Embed RNAP in RSVP Framework FreeBSD with routed, CBQ (in ALTQ package) , and RNAP R1 S1 Ra Rb S2 R2 10 Mb S3 R3 Embed negotiation and pricing information in RSVP Policy Data; Receiver negotiation, in RNAP-D format. RNAP RSVP Quotation Path Reserve Resv Commit ResvErr 8/21/00 IRT, Columbia University

Conclusions RNAP Enables dynamic service negotiation Supports centralized and distributed network architectures Has mechanisms for price and charge formulation, collation, communication Flexibility of service selection Multi-party negotiation: senders, receivers, both Stand alone, or embedded inside other protocols Reliable and scalable 8/21/00 IRT, Columbia University

Conclusions (cont’d) Pricing Differential pricing for multiple classes of services Consider both long-term user demand and short-term traffic fluctuation; use congestion-sensitive component to drive adaptation in congested network Application adaptation Bandwidth shared among competing users proportional to user’s willingness to pay 8/21/00 IRT, Columbia University

Conclusions (cont’d) Simulation results: Differentiated service requires different target loads in each class Without admission control, CPA coupled with user adaptation allows congestion control, and service assurances by restricting the load to the targeted level With admission control, performance bounds can be assured even with FP policy, but CPA reduces the request blocking rate greatly and helps to stabilize price Allowing service class migration further stabilizes price Future work Refine the RNAP protocol, stand alone RNAP implementation in progress, experiments over Internet2 8/21/00 IRT, Columbia University

An Integrated Resource Negotiation, Pricing, and QoS Adaptation

Similar presentations

Presentation on theme: "An Integrated Resource Negotiation, Pricing, and QoS Adaptation"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

An Integrated Resource Negotiation, Pricing, and QoS Adaptation

Similar presentations

Presentation on theme: "An Integrated Resource Negotiation, Pricing, and QoS Adaptation"— Presentation transcript:

Similar presentations

About project

Feedback