Xin Wang Internet Real Time Laboratory Columbia University

Xin Wang Internet Real -Time Laboratory Columbia University http: //www. cs. columbia. edu/~ xinwang 8/21/00 IRT, Columbia University

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 8/21/00 IRT, Columbia University 2

Motivation • Multimedia requires minimum Qo. S • Current approaches – A: resource reservation, admission control, differentiated services • Pros: with Qo. S 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 8/21/00 IRT, Columbia University 3

Objectives • • Combine Qo. S 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 8/21/00 IRT, Columbia University 4

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 8/21/00 IRT, Columbia University 5

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 8/21/00 IRT, Columbia University 6

Protocol Architectures: Centralized (RNAP-C) NRN NRN HRN S 1 R 1 Access Domain - A Internal Router Edge Router Host RNAP Messages 8/21/00 Access Domain - B Transit Domain NRN Network Resource Negotiator HRN Host Resource Negotiator Data Flow Intra-domain messages IRT, Columbia University 7

Protocol Architectures: Distributed (RNAP-D) HRN S 1 R 1 Access Domain - A Access Domain - B Transit Domain Internal Router HRN Edge Router Host Resource Negotiator Data Flow Host RNAP Messages 8/21/00 IRT, Columbia University 8

RNAP Messages Periodic re-negotiation Query Quotation Reserve Commit Close Release 8/21/00 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. Close: Tears down negotiation session Release: Releases the resources IRT, Columbia University 9

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

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 8/21/00 IRT, Columbia University 11

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

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

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

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-toingress probe messages – Routers of the path make admission: through intradomain signaling protocol, such as RSVP/YESSIR. 8/21/00 IRT, Columbia University 15

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 16

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

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 (pu 1 , pu 2 , …, pu. J ) puj - f(C)], s. t. r (x (pu 2 , …, pu. J )) 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 18

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 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 19

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 , t. Σl Aj / ( pu j j ) C s. • Hence: – pbasic = Σl Aj / C , puj = Σl Aj /(C j) 8/21/00 IRT, Columbia University 20

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 = Σi Ui (xi (Tspec, Rspec)] – max [Σl Ui (xi ) - Ci (xi) ], t. Σl Ci (xi) b , xmini xmaxi – Determine optimal Tspec and Rspec 8/21/00 IRT, Columbia University s. 21

User Adaptation • Measure utility: at discrete bandwidth, Qo. S levels • Function of bandwidth at fixed Qo. S – – – An example utility function: U (x) = U 0 + log (x / xm) U 0 : perceived (opportunity) value at minimum bandwidth : sensitivity of the utility to bandwidthfind argo. ctr • Function of both bandwidth and Qo. S – – – U (x) = U 0 + log (x / xm) - kd d - kl l , for x xm kd : sensitivity to delay kl : sensitivity to loss 8/21/00 IRT, Columbia University 22

User Adaptation (cont’d. ) • Optimization: – max [Σl U 0 i + 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: constraint b i = b (wi / Σl k ) 8/21/00 IRT, Columbia University 23

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 8/21/00 IRT, Columbia University 24

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

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% 8/21/00 IRT, Columbia University 26

Simulation Model (cont’d) • Parameter Set-up – – – – topology 1: 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, 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. 8/21/00 IRT, Columbia University 27

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 28

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 8/21/00 IRT, Columbia University 29

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

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

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

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

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

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

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

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

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

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

Conclusions • RNAP – Enables dynamic service negotiation – Supports centralized and distributed network 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 8/21/00 IRT, Columbia University 40

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

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 Internet 2 8/21/00 IRT, Columbia University 42