2. Xin Wang and Henning Schulzrinne Xin Wang and Henning Schulzrinne Internet Real -Time Laboratory Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang/RNAP.html http://www.cs.columbia.edu/~xinwang/RNAP.html

3. 8/21/00IRT, Columbia University2 Outline Outline MotivationMotivation ObjectivesObjectives Dynamic resource negotiation: architectures, messages, aggregationDynamic resource negotiation: architectures, messages, aggregation Pricing schemesPricing schemes User request adaptationUser request adaptation SimulationSimulation ConclusionsConclusions

4. 8/21/00IRT, Columbia University3Motivation Current approaches for quality supportCurrent approaches for quality support –Resource reservation, admission control, differentiated services Pros: QoS expectationPros: QoS expectation Cons: insufficient knowledge on data traffics, conservative, network dynamics not considered, lacks pricing support for multiple service levelsCons: insufficient knowledge on data traffics, conservative, network dynamics not considered, lacks pricing support for multiple service levels –Multimedia adaptation to network conditions Pros: efficient bandwidth usagePros: efficient bandwidth usage Cons: users have no motivation to adapt requestsCons: users have no motivation to adapt requests

5. 8/21/00IRT, Columbia University4Objectives Develop a resource negotiation and pricing framework whichDevelop a resource negotiation and pricing framework which –Combines QoS support and user adaptation –Allows resource commitment for short intervals –Provides differential pricing for differentiated services, and usage- and congestion-sensitive pricing to motivate user adaptation –Allows provider to trade-off blocking connections and raising prices RNAP: a Resource Negotiation And Pricing protocol through which the user and network (or two network domains) negotiate network delivery services.RNAP: a Resource Negotiation And Pricing protocol through which the user and network (or two network domains) negotiate network delivery services.

6. 8/21/00IRT, Columbia University5 Protocol Architectures: Centralized (RNAP-C) S1 R1 Access Domain - BAccess Domain - A Transit Domain Internal Router Edge Router Host RNAP Messages NRN HRN Network Resource Negotiator Host Resource Negotiator Intra-domain messages Data Flow NRN HRN

7. 8/21/00IRT, Columbia University6 S1 R1 Access Domain - B Access Domain - A Transit Domain Protocol Architectures: Distributed (RNAP-D) Internal Router Edge Router Host HRN Host Resource Negotiator Data Flow HRN RNAP Messages

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

9. 8/21/00IRT, Columbia University8 RNAP Message Aggregation RNAP-D RNAP-C

10. 8/21/00IRT, Columbia University9 RNAP Message Aggregation (cont’d) Aggregation when senders share the same destination networkAggregation when senders share the same destination network Messages merged by source or intermediate domainsMessages merged by source or intermediate domains Messages de-aggregated at destination border routers (RNAP-D), or NRNs (RNAP-C)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/domainsOriginal messages sent directly to destination/source domains without interception by intermediate RNAP agents; aggregate message reserves and collects price at intermediate nodes/domains

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

12. 8/21/00IRT, Columbia University11 Two Volume-based Pricing Policies Fixed-Price (FP)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)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

13. 8/21/00IRT, Columbia University12 Proposed Pricing Strategies Holding price and charge :Holding price and charge : –p h j =  j (p u j - p u j-1 ) –c h ij (n) = p h j r ij (n)  j Usage price and charge :Usage price and charge : –max [Σ l x j (p u 1, p u 2, …, p u J ) p u j - f(C)], s.t. r (x (p u 2, p u 2, …, p u J ))  R, j  J –c u ij (n) = p u j v ij (n) Congestion price and charge :Congestion price and charge : –p c j (n) = min [{p c j (n-1) +  j (D j, S j ) x (D j -S j )/S j,0 } +, p max j ] –c c ij (n) = p c j v ij (n)

14. 8/21/00IRT, Columbia University13 Usage Price for Differentiated Services Usage price for a service class based on cost of class bandwidth: lower target load -> higher QoS, but higher per unit bandwidth costUsage price for a service class based on cost of class bandwidth: lower target load -> higher QoS, but higher per unit bandwidth cost Parameters:Parameters: –p basic basic rate for fully used bandwidth –  : expected load ratio of class j –  j : expected load ratio of class j –x ij : effective bandwidth –x ij : effective bandwidth consumption of application i : constant elasticity demand parameter –A j : constant elasticity demand parameter

15. 8/21/00IRT, Columbia University14 Usage Price for Differentiated Services (cont’d) Price for class j : p u j = p basic / Price for class j : p u j = p basic /  j Demand of class j : x j ( p u j ) = p u jDemand of class j : x j ( p u j ) = A j / p u j Effective bandwidth consumption :Effective bandwidth consumption : –x e j ( p u j ) = p u j  –x e j ( p u j ) = A j / ( p u j  j ) Network maximizes profitNetwork maximizes profit –max [Σ l (p u j ) p u j - f (C)], p u j = p basic /  Σ l p u j   C –max [Σ l (A j / p u j ) p u j - f (C)], p u j = p basic /  j, s. t. Σ l A j / ( p u j  j )  C Hence :Hence : –p basic = Σ l, p u j = Σ l  –p basic = Σ l A j / C, p u j = Σ l A j /(C  j )

16. 8/21/00IRT, Columbia University15 User Adaptation based on Utility Users adapt service selection and data rate based on utility which is associated with QoSUsers 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 /minUtility 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 applicationsMulti-application task (e.g., video-conference) - maximize total utility of task subject to budget -> dynamic resource allocation among component applications User utility optimization:User utility optimization: –U = Σ i x i (Tspec, Rspec)] –U = Σ i U i (x i (Tspec, Rspec)] –max [Σ l x i ) - C i (x i ) ], Σ l C i (x i )  b, x min i  x i  x max i –max [Σ l U i (x i ) - C i (x i ) ], s. t. Σ l C i (x i )  b, x min i  x i  x max i –Determine optimal Tspec and Rspec Not need to reveal utility to the networkNot need to reveal utility to the network

17. 8/21/00IRT, Columbia University16 User adaptation based on utility: example User defines utility at discrete bandwidth, QoS levelsUser defines utility at discrete bandwidth, QoS levels Utility is a function of bandwidth at fixed QoSUtility is a function of bandwidth at fixed QoS –An example utility function: U (x) = U 0 +  log (x / x m ) –U 0 : –U 0 : perceived (opportunity) value at minimum bandwidth –  : sensitivity of the utility to bandwidth Function of both bandwidth and QoSFunction of both bandwidth and QoS –U (x) = U 0 +  log (x / x m ) - k d d - k l l, for x  x m –k d : sensitivity to delay –k l : sensitivity to loss Optimization:Optimization: –max [Σ l U 0 i +  i log (x i / x m i ) - k d i d - k l i l - ], Σ l  b, x  x m, d  D, l  L –max [Σ l U 0 i +  i log (x i / x m i ) - k d i d - k l i l - p i x i ], s. t. Σ l p i x i  b, x  x m, d  D, l  L –Without budget constraint: x i =  i / –Without budget constraint: x i =  i / p i  Σ l  k –With budget constraint: b i = b (  i / Σ l  k )

18. 8/21/00IRT, Columbia University17 Simulation Model Topology 1 Topology 2

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

20. 8/21/00IRT, Columbia University19 Simulation Model (cont’d) Parameter Set-upParameter 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 p basic = $0.08 / min, p EF = $0.20 / min, p AF = $0.13 / min, p BE = $0.09 / minusage price p basic = $0.08 / min, p EF = $0.20 / min, p AF = $0.13 / min, p BE = $0.09 / min holding price: p EF = $0.067 / min, p AF = $0.044 / minholding price: p EF = $0.067 / min, p AF = $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.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.

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

22. 8/21/00IRT, Columbia University21 Design of Experiments Performance comparison: FP (usage price + holding price) and CPA (usage price + holding price + congestion price)Performance comparison: FP (usage price + holding price) and CPA (usage price + holding price + congestion price) Four groups of experiments :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 ):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

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

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

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

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

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

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

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

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

31. 8/21/00IRT, Columbia University30 Average packet loss Average packet delay Effect of Admission Control

32. 8/21/00IRT, Columbia University31 User request blocking rate Average and standard deviation of AF class price Effect of Admission Control (cont’d.)

33. 8/21/00IRT, Columbia University32Conclusions RNAPRNAP –Supports dynamic service negotiation, mechanisms for price and charge collation –Allows for both centralized and distributed architectures –Multi-party negotiation: senders, receivers, both –Can be stand alone, or embedded inside other protocols –Reliable and scalable PricingPricing –Consider both long-term user demand and short-term traffic fluctuation; use congestion-sensitive component to drive adaptation in congested network Application adaptationApplication adaptation –Bandwidth proportional to user’s willingness to pay

34. 8/21/00IRT, Columbia University33 Conclusions (cont’d) Simulation results :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 workFuture work –Refine the RNAP protocol, stand alone RNAP implementation in progress, experiments over Internet2