Xin Wang Internet Real -Time Laboratory Columbia University

1. An Integrated Resource Negotiation, Pricing, and QoS Adaptation Framework for Multimedia Applications Xin Wang Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang

2. Outline • Motivation • Objectives • Resource negotiation & RNAP: architectures, messages, aggregation, reliability • Pricing • Price and charge formulation • Pricing on current Internet • Proposed pricing schemes • User request adaptation • Simulation • Conclusions IRT, Columbia University

3. Motivation • Multimedia requires minimum QoS • Current approaches • A: resource reservation, admission control, differentiated services • Pros: with QoS expectation • Cons: no enough knowledge on data traffics, conservative, no consideration of network dynamics, no pricing to support multiple service levels • B: multimedia adaptation on network conditions • Pros: efficient bandwidth usage • Cons: users have no motivation to adapt requests IRT, Columbia University

4. Objectives • Combine QoS and multimedia adaptive service • Allow resource commitment for short interval • Provide differential pricing for differentiated services • Allow usage- and congestion-sensitive pricing for motivation of users request adaptation • Provide trade-offs between blocking and raising prices in network IRT, Columbia University

5. Resource Negotiation & 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 IRT, Columbia University

6. Resource Negotiation & 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 IRT, Columbia University

7. 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 Host Resource Negotiator Edge Router HRN Host Data Flow RNAP Messages Intra-domain messages IRT, Columbia University

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

9. RNAP Messages Query:Inquires about available services, prices Query Quotation: Specifies service availability, prices Quotation Reserve Reserve: Requests service(s), resources Commit 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 IRT, Columbia University

10. RNAP Message Aggregation RNAP-D RNAP-C IRT, Columbia University

11. RNAP Message Aggregation (cont’d) • Aggregation for senders sharing the same destination network • merged by source domains • split for HRNs at destination border routers (RNAP-D) , or NRNs (RNAP-C) • Two messages: • aggregated message reserves and collects price in the middle of network • original messages sent directly to destination/source domains without visiting agents in between IRT, Columbia University

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

13. Reliability • Soft state for synchronous messages, liveness tracking through • Retransmission of asynchronous messages • Server backup and information retrieval IRT, Columbia University

14. 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 passing through routers or NRNs, increasing price/charge fields • Quotation: carry estimated price for each quoted service • Commit : carry accumulated charge for preceding negotiation interval, committed price for next interval IRT, Columbia University

15. Price Formulation in RNAP-C • Alternative Schemes: • NRN does admission control and price computation • Based on topology, routing, policies, and network load • Determine the path • Accumulate price • Send 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. IRT, Columbia University

16. Pricing on Current Internet • Access rate dependent flat charge • Usage-based charge • Volume-based charge • Time-base charge • Access charge + Usage-based charge IRT, Columbia University

17. 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 • When congestion: a) higher blocking rate; b) higher dropping rate and delay • Congestion-Price-based Adaptation (CPA) • FP + congestion-sensitive price • CP-FL, CP-PR, CP-T, CP-PR-T • When congestion: a) maintain service by paying more; b) reduce sending rate or lower service class IRT, Columbia University

18. Proposed Pricing Strategies • Holding price and charge: • phj = j (pu j - puj-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: • pcj (n) = min [{pcj (n-1) + j(Dj, Sj) x (Dj-Sj)/Sj,0 }+, pmaxj ] • ccij (n) = pc j v ij (n) IRT, Columbia University

19. Pricing for Differentiated Services • Lower load leads to lower average delay; charging proportionally to the expected load of class is one way of considering the cost • Parameters: • pbasic basic rate for fully used bandwidth • j: expected load ratio of class j • xij: effective bandwidthconsumption of application i • Aj : constant elasticity demand parameter IRT, Columbia University

20. Pricing for Differentiated Services (cont’d) • Price for class j: puj = pbasic /j • Demand of class j: xj ( puj ) = Aj /puj • Effective bandwidth consumption: • xj ( puj ) = Aj / (pujj ) • Network maximize 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) IRT, Columbia University

21. Pricing for Differentiated Services (cont’d) • Based on perceived value, e.g.,15 cents /min • Maximize total utility of a task, dynamic resource allocation of the resources among applications of the task • User benefit optimization: • U = ΣiUi (xi (Tspec, Rspec)] • max [ΣlUi (xi ) - Ci (xi) ], s. t. ΣlCi (xi) b , xmini xi xmaxi • Determine optimal Tspec and Rspec IRT, Columbia University

22. User Adaptation • Measure utility: at discrete bandwidth, QoS levels • 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 bandwidthfind argo.ctr • 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 IRT, Columbia University

23. User Adaptation (cont’d.) • Optimization: • max [ΣlU0i + 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: b i = b (wi /Σl k ) IRT, Columbia University

24. Stability and Oscillation Reduction • Proof see references • Oscillation reduction • Users: re-negotiate only if price change exceeds a given range • Network: a) update price only when traffic change exceeds a threshold; b) block negotiation IRT, Columbia University

25. Simulation Model Topology 1 Topology 2 IRT, Columbia University

26. 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% • AF: • RED-with-In-Out (RIO), limited to 100 packets • expected load threshold 60% • BE: • Random Early Detection (RED), limited to 200 packets • expected load threshold 90% IRT, Columbia University

27. Simulation Model (cont’d) • Parameter 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: 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 • average session length 10 minutes, exponentialdistributed. IRT, Columbia University

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

29. Design of the Experiments • Performance comparison: FP and CPA • Four groups of experiment: • Effect of traffic burstiness • Effect of traffic load • Load balance between classes • Effect of admission control • Other experiments (see reference): • 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 IRT, Columbia University

30. Effect of Traffic Burstiness Price average and stand deviation of AF class Variation over time of the price of AF class IRT, Columbia University

31. Effect of Traffic Burstiness (cont’d) Average packet delay Average packet loss IRT, Columbia University

32. Effect of Traffic Burstiness (cont’d) Average traffic arrival rate Average user benefit IRT, Columbia University

33. Effect of Traffic Load Price average and stand deviation of AF class Variation over time of the price of AF class IRT, Columbia University

34. Effect of Traffic Load (cont’d) Average packet delay Average packet loss IRT, Columbia University

35. Effect of Traffic Load (cont’d) Average traffic arrival rate Average user benefit IRT, Columbia University

36. Load Balance between Classes Variation over time of the price of AF class Ratio of AF class traffic migrating through class re-selection IRT, Columbia University

37. Load Balance between Classes (cont’d) Average packet delay Average packet loss IRT, Columbia University

38. Effect of Admission Control Average and stand deviation of AF class price User request blocking rate IRT, Columbia University

39. Effect of Admission Control (cont’d) Average packet delay Average packet loss IRT, Columbia University

40. Conclusions • RNAP • Enables dynamic service negotiation • Supports centralized and distributednetwork architectures • 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 IRT, Columbia University

41. Conclusions (cont’d) • Pricing • Differential pricing for multiple classes of services • Consider both long-term user demand and short-term traffic fluctuation • Application adaptation • Bandwidth sharing is proportional to user’s willingness to pay IRT, Columbia University

42. Conclusions (cont’d) • Simulation results: • Different levels of service gained by different load • Without admission control, CPA coupled with user adaptation allows congestion control, and service assurances • With admission control, performance bound can be assured even with FP policy, but CPA reduces the request blocking rate greatly and helps to stabilize price • Allowing service class migration helps for further price stabilization • Future work • Refine the RNAP protocol, experimental over Internet2 IRT, Columbia University