1. Xin Wang Internet Real -Time Laboratory Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang http://www.cs.columbia.edu/~xinwang

2. 8/21/00IRT, Columbia University2 Outline Outline MotivationMotivation ObjectivesObjectives Resource negotiation & RNAP: architectures, messages, aggregation, reliabilityResource negotiation & RNAP: architectures, messages, aggregation, reliability PricingPricing –Price and charge formulation –Pricing on current Internet –Proposed pricing schemes User request adaptationUser request adaptation SimulationSimulation ConclusionsConclusions

3. 8/21/00IRT, Columbia University3Motivation Multimedia requires minimum QoSMultimedia requires minimum QoS Current approachesCurrent approaches –A: 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 –B: 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

4. 8/21/00IRT, Columbia University4Objectives Develop Resource Negotiation and Pricing Framework which: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

5. 8/21/00IRT, Columbia University5 Resource Negotiation through RNAP Assumption: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.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:Underlying Mechanism: –Traffic engineering + network pricing

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

7. 8/21/00IRT, Columbia University7 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

8. 8/21/00IRT, Columbia University8 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

9. 8/21/00IRT, Columbia University9 RNAP Messages Query Quotation Reserve Commit Quotation Reserve Commit Close Release Query : Inquires about available services, prices Quotation : Specifies service availability, 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

10. 8/21/00IRT, Columbia University10 RNAP Message Aggregation RNAP-D RNAP-C

11. 8/21/00IRT, Columbia University11 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 by HRNs at destination border routers (RNAP-D), or NRNs (RNAP-C)Messages de-aggregated by HRNs 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

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

13. 8/21/00IRT, Columbia University13 Reliability Reliability Soft state for synchronous messages, liveness tracking throughSoft state for synchronous messages, liveness tracking through Retransmission of asynchronous messagesRetransmission of asynchronous messages Server backup and information retrievalServer backup and information retrieval

14. 8/21/00IRT, Columbia University14 Price and Charge Formulation Routers or NRNs maintain state informationRouters or NRNs maintain state information –Resource usage, service prices, service statistics –Id, price, accumulated charge for a user e2e price and charge collatione2e 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

15. 8/21/00IRT, Columbia University15 Price Formulation in RNAP-C Alternative Schemes :Alternative Schemes : –NRN does admission control and price computation Pricing based on topology, routing, policies, network loadPricing based on topology, routing, policies, network load NRN determines data pathNRN determines data path Accumulates priceAccumulates price Sends total price to HRN or neighborsSends total price to HRN or neighbors –Ingress router does admission control and price computation may determine internal router loads through egress-to- ingress probe messagesmay 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.

16. 8/21/00IRT, Columbia University16 Pricing on Current Internet Access rate dependent flat chargeAccess rate dependent flat charge Usage-based chargeUsage-based charge –Volume-based charge –Time-base charge Access charge + Usage-based chargeAccess charge + Usage-based charge

17. 8/21/00IRT, Columbia University17 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

18. 8/21/00IRT, Columbia University18 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)

19. 8/21/00IRT, Columbia University19 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 QoSUsage price for a service class based on cost of class bandwidth; lower target load -> higher per unit bandwidth price, higher QoS 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

20. 8/21/00IRT, Columbia University20 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 j ( p u j ) = p u j  –x 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 )

21. 8/21/00IRT, Columbia University21 User adaptation based on utility Users adapt service selection + data rate based on utility associated with QoS + data rate; utility expressed in terms of perceived value, e.g.,15 cents /minUsers adapt service selection + data rate based on utility associated with QoS + data rate; utility expressed in terms of perceived value, e.g.,15 cents /min Multi-application task (eg., video-conference) - maximize total utility of task subject to budget -> dynamic resource allocation among component applicationsMulti-application task (eg., video-conference) - maximize total utility of task subject to budget -> dynamic resource allocation among component applications User utility optimization:User utility optimization: –U = Σ i xi (Tspec, Rspec)] –U = Σ i U i (xi (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

22. 8/21/00IRT, Columbia University22 User adaptation based on utility: example User defines utility at discrete bandwidth, QoS levelsUser defines utility at discrete bandwidth, QoS levels Function of bandwidth at fixed QoSFunction 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 bandwidthfind argo.ctr 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 (w i / Σ l  k )

23. 8/21/00IRT, Columbia University23 Stability and Oscillation Reduction Congestion-sensitive pricing (tatonnement process) has been shown to be stable ( ….)Congestion-sensitive pricing (tatonnement process) has been shown to be stable ( ….) Oscillation reductionOscillation 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

24. 8/21/00IRT, Columbia University24 Simulation Model Topology 1 Topology 2

25. 8/21/00IRT, Columbia University25 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%expected load threshold 40% –AF: RED-with-In-Out (RIO), limited to 100 packetsRED-with-In-Out (RIO), limited to 100 packets expected load threshold 60%expected load threshold 60% –BE: Random Early Detection (RED), limited to 200 packets Random Early Detection (RED), limited to 200 packets expected load threshold 90%expected load threshold 90%

26. 8/21/00IRT, Columbia University26 Simulation Model (cont’d) Parameter Set-upParameter Set-up –topology1: 48 users; topology 2: 360 users –user requests: 60 kb/s -- 160 kb/s –targeted reservation rate: 90% –price adjustment factor: σ = 0.06 –update threshold: θ = 0.05 –negotiation period: 30 seconds –usage 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 / min –average session length 10 minutes, exponential distributed.

27. 8/21/00IRT, Columbia University27 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

28. 8/21/00IRT, Columbia University28 Design of Experiments Performance comparison: Fixed price policy (FP: usage price + holding price) and CPAPerformance comparison: Fixed price policy (FP: usage price + holding price) and CPA 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 (…...):Other experiments (…...): –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

29. 8/21/00IRT, Columbia University29 Variation over time of the price of AF class Price average and stand deviation of AF class Effect of Traffic Burstiness

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

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

32. 8/21/00IRT, Columbia University32 Effect of Traffic Load Variation over time of the price of AF class Price average and stand deviation of AF class

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

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

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

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

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

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

39. 8/21/00IRT, Columbia University39Conclusions RNAPRNAP –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

40. 8/21/00IRT, Columbia University40 Conclusions (cont’d) PricingPricing –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 adaptationApplication adaptation –Bandwidth shared among competing users proportional to user’s willingness to pay

41. 8/21/00IRT, Columbia University41 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 –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, experiments over Internet2