Xin WangXin Wang
Internet Real -Time LaboratoryInternet Real -Time Laboratory
Columbia University
http://www.cs.columbia.edu/~xinwanghttp://www.cs.columbia.edu/~xinwang
8/21/00 IRT, Columbia University 2
OutlineOutline
• MotivationMotivation• ObjectivesObjectives• Resource negotiation & RNAP: architectures, Resource negotiation & RNAP: architectures,
messages, aggregation, reliabilitymessages, aggregation, reliability• PricingPricing
– Price and charge formulationPrice and charge formulation– Pricing on current InternetPricing on current Internet– Proposed pricing schemesProposed pricing schemes
• User request adaptationUser request adaptation• SimulationSimulation• ConclusionsConclusions
8/21/00 IRT, Columbia University 3
MotivationMotivation
• Multimedia requires minimum QoSMultimedia requires minimum QoS
• Current approachesCurrent approaches– A: resource reservation, admission control, A: resource reservation, admission control,
differentiated servicesdifferentiated services• Pros: with QoS expectationPros: with QoS expectation
• Cons: no enough knowledge on data traffics, Cons: no enough knowledge on data traffics, conservative, no consideration of network dynamics, no conservative, no consideration of network dynamics, no
pricing to support multiple service levelspricing to support multiple service levels – B: multimedia adaptation on network conditions B: multimedia adaptation on network conditions
• Pros: efficient bandwidth usagePros: efficient bandwidth usage• Cons: users have no motivation to adapt requestsCons: users have no motivation to adapt requests
8/21/00 IRT, Columbia University 4
ObjectivesObjectives
• Combine QoS and multimedia adaptive serviceCombine QoS and multimedia adaptive service• Allow resource commitment for short interval Allow resource commitment for short interval • Provide differential pricing for differentiated servicesProvide differential pricing for differentiated services• Allow usage- and congestion-sensitive pricing for Allow usage- and congestion-sensitive pricing for
motivation of users request adaptationmotivation of users request adaptation• Provide trade-offs between blocking and raising prices Provide trade-offs between blocking and raising prices
in networkin network
8/21/00 IRT, Columbia University 5
Resource Negotiation & RNAPResource Negotiation & RNAP
• AssumptionAssumption::– Different service types, e.g. diff-serv, int-serv, best-effort.Different service types, e.g. diff-serv, int-serv, best-effort.– With a pricing structure (may be usage-sensitive) for each.With a pricing structure (may be usage-sensitive) for each.
• RNAP (Resource Negotiation and Pricing):RNAP (Resource Negotiation and Pricing): a protocol a protocol through which the user and network (or two network through which the user and network (or two network domains) negotiate network delivery services.domains) negotiate network delivery services.– Network -> UserNetwork -> User:: availability of services, price quotations, availability of services, price quotations,
accumulated charges, service statisticsaccumulated charges, service statistics– User -> NetworkUser -> Network: request/re-negotiate services: request/re-negotiate services
• Underlying MechanismUnderlying Mechanism: : – Traffic engineering + network pricing Traffic engineering + network pricing
8/21/00 IRT, Columbia University 6
Resource Negotiation & RNAP (cont’d.)Resource Negotiation & RNAP (cont’d.)
• CharacteristicsCharacteristics– Multiple service selectionMultiple service selection– Centralized or distributed architectureCentralized or distributed architecture– Dynamic negotiation, multi-party negotiationDynamic negotiation, multi-party negotiation– Price collation and communicationPrice collation and communication– Scalable and reliableScalable and reliable
• Who can use RNAP?Who can use RNAP?– Adaptive applications: adapt sending rate, choice of network Adaptive applications: adapt sending rate, choice of network
servicesservices
– Non-adaptive applications: take fixed price, or absorb price Non-adaptive applications: take fixed price, or absorb price
changechange
8/21/00 IRT, Columbia University 7
Protocol Architectures: Centralized (RNAP-C)Protocol Architectures: Centralized (RNAP-C)
S1
R1
Access Domain - BAccess Domain - A
Transit Domain
Internal Router
Edge RouterHost
RNAP Messages
NRN
HRN
Network Resource Negotiator
Host Resource Negotiator
Intra-domain messages
Data Flow
NRN NRNNRNHRNHRN
8/21/00 IRT, Columbia University 8
S1
R1
Access Domain - BAccess Domain - A
Transit Domain
Protocol Architectures: Distributed (RNAP-D)Protocol Architectures: Distributed (RNAP-D)
Internal Router
Edge Router
Host
HRN Host Resource Negotiator
Data Flow
HRNHRN
RNAP Messages
8/21/00 IRT, Columbia University 9
RNAP MessagesRNAP Messages
Query
QuotationReserve
Commit
QuotationReserve
Commit
Close
Release
Query: Inquires about available services, pricesQuotation: Specifies service availability, prices
Reserve: Requests service(s), resourcesCommit: Admits the service request at a specific price or denies it.
Per
iodi
c re
-neg
otia
tion
Close: Tears down negotiation session
Release: Releases the resources
8/21/00 IRT, Columbia University 10
RNAP Message AggregationRNAP Message Aggregation
RNAP-DRNAP-D
RNAP-CRNAP-C
8/21/00 IRT, Columbia University 11
RNAP Message Aggregation (cont’d)RNAP Message Aggregation (cont’d)
• Aggregation for senders sharing the same Aggregation for senders sharing the same destination networkdestination network– merged by source domainsmerged by source domains
– split for HRNs at destination border routers (RNAP-D) , split for HRNs at destination border routers (RNAP-D) ,
or NRNs (RNAP-C) or NRNs (RNAP-C)
• Two messagesTwo messages::– aggregated message reserves and collects price in the aggregated message reserves and collects price in the
middle of networkmiddle of network
– original messages sent directly to destination/source original messages sent directly to destination/source
domains without visiting agents in betweendomains without visiting agents in between
8/21/00 IRT, Columbia University 12
Block Negotiation Block Negotiation
• Block NegotiationBlock Negotiation– Aggregated resources are added/removed in large Aggregated resources are added/removed in large
blocks to minimize negotiation overhead and reduce blocks to minimize negotiation overhead and reduce network dynamicsnetwork dynamics
time
Ban
dwid
th
8/21/00 IRT, Columbia University 13
ReliabilityReliability
• Soft state for synchronous messages, liveness Soft state for synchronous messages, liveness tracking through tracking through
• Retransmission of asynchronous messagesRetransmission of asynchronous messages• Server backup and information retrievalServer backup and information retrieval
8/21/00 IRT, Columbia University 14
Price and Charge Formulation Price and Charge Formulation
• Routers or NRNs maintain state informationRouters or NRNs maintain state information– Resource usage, service prices, service statisticsResource usage, service prices, service statistics– Id, price, accumulated charge for a userId, price, accumulated charge for a user
• e2e price and charge collatione2e price and charge collation– Message passing through routers or NRNs, Message passing through routers or NRNs, increasing increasing
price/charge fields price/charge fields – QuotationQuotation : carry estimated price for each quoted service: carry estimated price for each quoted service– CommitCommit : carry accumulated charge for preceding : carry accumulated charge for preceding
negotiation interval, committed price for next intervalnegotiation interval, committed price for next interval
8/21/00 IRT, Columbia University 15
Price Formulation in RNAP-C Price Formulation in RNAP-C
• Alternative SchemesAlternative Schemes::
– NRN does admission control and price computation NRN does admission control and price computation • Based on topology, routing, policies, and network loadBased on topology, routing, policies, and network load• Determine the pathDetermine the path• Accumulate priceAccumulate price• Send total price to HRN or neighborsSend total price to HRN or neighbors
– Ingress router does admission control and price Ingress router does admission control and price computation computation • may determine internal router loads through egress-to-may determine internal router loads through egress-to-
ingress probe messagesingress probe messages
– Routers of the path make admission: through intra-Routers of the path make admission: through intra-domain signaling protocol, such as RSVP/YESSIR.domain signaling protocol, such as RSVP/YESSIR.
8/21/00 IRT, Columbia University 16
Pricing on Current Internet Pricing on Current Internet
• Access rate dependent flat chargeAccess rate dependent flat charge
• Usage-based chargeUsage-based charge– Volume-based chargeVolume-based charge
– Time-base chargeTime-base charge
• Access charge + Usage-based chargeAccess charge + Usage-based charge
8/21/00 IRT, Columbia University 17
Two Volume-based Pricing Policies Two Volume-based Pricing Policies
• Fixed-Price (FP)Fixed-Price (FP)– FP-FL: same for all servicesFP-FL: same for all services– FP-PR: service class dependentFP-PR: service class dependent– FP-T: time-of-day dependentFP-T: time-of-day dependent– FP-PR-T: FP-PR + FP-T FP-PR-T: FP-PR + FP-T – When congestion: a) higher blocking rate; b) higher dropping When congestion: a) higher blocking rate; b) higher dropping
rate and delayrate and delay
• Congestion-Price-based Adaptation (CPA) Congestion-Price-based Adaptation (CPA) – FP + congestion-sensitive priceFP + congestion-sensitive price– CP-FL, CP-PR, CP-T, CP-PR-T CP-FL, CP-PR, CP-T, CP-PR-T
– When congestion: a) maintain service by paying more; b) When congestion: a) maintain service by paying more; b)
reduce sending rate or lower service classreduce sending rate or lower service class
8/21/00 IRT, Columbia University 18
Proposed Pricing Strategies Proposed Pricing Strategies
• Holding price and chargeHolding price and charge: : – pphh
j j = = j j ((ppu u jj - p - puu j-1j-1) )
– cchhijij ((nn)) = p = ph h
j j r r ijij ((nn)) jj
• Usage price and chargeUsage price and charge: : – max max [Σ[Σll x x j j ((ppuu
11 , p , puu22 , , ……, p, puu
J J )) p puujj - f(C) - f(C)]], , s.t.s.t. r r ((xx ((ppuu
22 , ,
ppuu22 , …, p , …, puu
JJ )) )) RR, , j j J J
– ccuuij ij ((nn) = ) = ppu u
j j v v ijij (n) (n)
• Congestion price and chargeCongestion price and charge: : – ppcc jj (n) (n) = min [{ = min [{ppcc
jj (n-1) (n-1) + + jj (D(Djj, S, Sjj) x (D) x (Djj-S-Sjj)/S)/Sjj,0 ,0 }}++, p, pmaxmaxj j ]]
– ccccij ij ((nn) = ) = ppc c
j j v v ijij (n) (n)
8/21/00 IRT, Columbia University 19
Pricing for Differentiated Services Pricing for Differentiated Services
• Lower load leads to lower average delay; Lower load leads to lower average delay; charging charging proportionally to the expected load of class is one way proportionally to the expected load of class is one way of considering the cost of considering the cost
• Parameters:Parameters: – ppbasic basic basic rate for fully used bandwidth basic rate for fully used bandwidth
j : expected load ratio of class j: expected load ratio of class j– xxijij : effective bandwidth: effective bandwidth consumption of application i– Aj : constant elasticity demand parameter: constant elasticity demand parameter
8/21/00 IRT, Columbia University 20
Pricing for Differentiated Services (cont’d)Pricing for Differentiated Services (cont’d)
• Price for class jPrice for class j: : ppuujj = = ppbasic basic // j
• Demand of class jDemand of class j: : xxj j ( ( ppuuj j ) = ) = Aj / ppuu
jj
• Effective bandwidth consumptionEffective bandwidth consumption: : – xxj j ( ( ppuu
j j ) = ) = Aj / ( ppuujj j )
• Network maximize profitNetwork maximize profit– max max [Σ[Σll ((A
j / ppu u jj ) ) ppu u
j j - f - f ((CC)])], p, puujj = = ppbasic basic // j , s. t.
ΣΣll Aj / ( ppu u
jj j ) CC
• HenceHence: : – ppbasic basic == ΣΣll A
j / C , p, puujj = Σ = Σll A
j /(C j)
8/21/00 IRT, Columbia University 21
Pricing for Differentiated Services (cont’d) Pricing for Differentiated Services (cont’d)
• Based on perceived value, e.g.,15 cents /minBased on perceived value, e.g.,15 cents /min• Maximize total utility of a task, dynamic resource Maximize total utility of a task, dynamic resource
allocation of the resources among applications of the allocation of the resources among applications of the tasktask
• User benefit optimizationUser benefit optimization::– U = U = ΣΣii U
i (xi xi ((Tspec, RspecTspec, Rspec)])]
– max max [Σ[Σll Ui (xxi i ) - ) - CCi i ((xxii) ]) ], , s. t.
ΣΣll CCi i ((xxii) ) b , xb , xminmin
ii xxii xxmaxmaxii
– Determine optimal Tspec and RspecDetermine optimal Tspec and Rspec
8/21/00 IRT, Columbia University 22
User AdaptationUser Adaptation
• Measure utility: at discrete bandwidth, QoS levelsMeasure utility: at discrete bandwidth, QoS levels• Function of bandwidth at fixed QoSFunction of bandwidth at fixed QoS
– An example utility function: An example utility function: U U ((xx) = ) = UU00 + + log log ((x / xx / xmm))
– UU0 0 :: perceived (opportunity) value at minimum bandwidth
: sensitivity of the utility to bandwidthfind argo.ctr: sensitivity of the utility to bandwidthfind argo.ctr
• Function of both bandwidth and QoSFunction of both bandwidth and QoS– U U ((xx) = ) = UU00 + + log log ((x / xx / xmm) - ) - kkdd d - k d - kll l , for x l , for x x xmm
– kkdd : sensitivity to delay : sensitivity to delay
– kkll : : sensitivity to losssensitivity to loss
8/21/00 IRT, Columbia University 23
User Adaptation (cont’d.)User Adaptation (cont’d.)
• Optimization:Optimization:– max max [Σ[Σll UU00
ii + + ii log log ((xxii / x / xmmii ) - ) - kkdd
ii d - k d - kll ii ll - - pi xi ]], ,
s. t. ΣΣll pi xi b , b , x x x xm m ,, dd DD, , l l LL
– Without budget constraintWithout budget constraint: : x x ii = = ii / / pi
– With budget constraint: b i = b (wi / ΣΣll k k )
8/21/00 IRT, Columbia University 24
Stability and Oscillation ReductionStability and Oscillation Reduction
• Proof see referencesProof see references• Oscillation reductionOscillation reduction
– Users: re-negotiate only if price change exceeds a given Users: re-negotiate only if price change exceeds a given range range
– Network: a) update price only when traffic change Network: a) update price only when traffic change exceeds a threshold; b) block negotiationexceeds a threshold; b) block negotiation
8/21/00 IRT, Columbia University 25
Simulation ModelSimulation Model
Topology 1Topology 1 Topology 2Topology 2
8/21/00 IRT, Columbia University 26
Simulation ModelSimulation 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: EF: • tail dropping, limited to 50 packets tail dropping, limited to 50 packets • expected load threshold 40%expected load threshold 40%
– AF: 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:BE:• Random Early Detection (RED), limited to 200 packetsRandom Early Detection (RED), limited to 200 packets• expected load threshold 90%expected load threshold 90%
8/21/00 IRT, Columbia University 27
Simulation Model (cont’d)Simulation Model (cont’d)
• Parameter Set-upParameter Set-up– topology1: topology1: 4848 users; topology 2: users; topology 2: 360360 users users– user requests: user requests: 6060 kb/s -- kb/s -- 160 160 kb/skb/s– targeted reservation rate: targeted reservation rate: 90%90%– price adjustment factor: price adjustment factor: σσ = = 0.060.06– update threshold: update threshold: θθ = = 0.050.05– negotiation period: negotiation period: 30 30 secondsseconds
– usage price: usage price: ppbasic basic = $= $0.08 / 0.08 / min, min, ppEF EF = $= $0.20 / 0.20 / min, min, ppAF AF
= $= $0.13 / 0.13 / min, min, ppBE BE = $= $0.09 / 0.09 / minmin
– holding price: holding price: ppEF EF = $= $0.067 / 0.067 / min, min, ppAF AF = $= $0.044 / 0.044 / minmin
– average session length average session length 10 10 minutes, exponentialminutes, exponential distributed.distributed.
8/21/00 IRT, Columbia University 28
Simulation Model (cont’d.)Simulation Model (cont’d.)
• Performance measuresPerformance measures– Engineering metricsEngineering metrics
• Bottleneck traffic arrival rateBottleneck traffic arrival rate• average packet loss and delayaverage packet loss and delay• User request blocking probabilityUser request blocking probability
– EconomicEconomic metricsmetrics• Average user benefitAverage user benefit• End to end price, and it standard deviationEnd to end price, and it standard deviation
8/21/00 IRT, Columbia University 29
Design of the ExperimentsDesign of the Experiments
• Performance comparison: FP and CPA Performance comparison: FP and CPA
• Four groups of experimentFour groups of experiment::– Effect of traffic burstinessEffect of traffic burstiness– Effect of traffic loadEffect of traffic load– Load balance between classesLoad balance between classes– Effect of admission controlEffect of admission control
• Other experiments (see reference):Other experiments (see reference):– Effect of system control parameters: target reservation Effect of system control parameters: target reservation
rate, price adjustment step, price adjustment thresholdrate, price adjustment step, price adjustment threshold– Effect of user demand elasticity, session multiplexingEffect of user demand elasticity, session multiplexing– Effect when part of users adapt, session adaptation and Effect when part of users adapt, session adaptation and
adaptive reservationadaptive reservation
8/21/00 IRT, Columbia University 30
Variation over time of the Variation over time of the price of AF classprice of AF class
Price average and stand deviation Price average and stand deviation of AF classof AF class
Effect of Traffic BurstinessEffect of Traffic Burstiness
8/21/00 IRT, Columbia University 31
Average packet lossAverage packet lossAverage packet delayAverage packet delay
Effect of Traffic Burstiness (cont’d)Effect of Traffic Burstiness (cont’d)
8/21/00 IRT, Columbia University 32
Average user benefitAverage user benefitAverage traffic arrival rateAverage traffic arrival rate
Effect of Traffic Burstiness (cont’d)Effect of Traffic Burstiness (cont’d)
8/21/00 IRT, Columbia University 33
Effect of Traffic Load Effect of Traffic Load
Variation over time of the Variation over time of the price of AF classprice of AF class
Price average and stand deviation Price average and stand deviation of AF classof AF class
8/21/00 IRT, Columbia University 34
Average packet lossAverage packet lossAverage packet delayAverage packet delay
Effect of Traffic Load (cont’d)Effect of Traffic Load (cont’d)
8/21/00 IRT, Columbia University 35
Average user benefitAverage user benefitAverage traffic arrival rateAverage traffic arrival rate
Effect of Traffic Load (cont’d)Effect of Traffic Load (cont’d)
8/21/00 IRT, Columbia University 36
Load Balance between Classes Load Balance between Classes
Variation over time of the Variation over time of the price of AF classprice of AF class
Ratio of AF class traffic Ratio of AF class traffic migrating through class re-migrating through class re-selectionselection
8/21/00 IRT, Columbia University 37
Load Balance between Classes (cont’d) Load Balance between Classes (cont’d)
Average packet delayAverage packet delay Average packet lossAverage packet loss
8/21/00 IRT, Columbia University 38
User request blocking rateUser request blocking rateAverage and stand Average and stand deviation of AF class pricedeviation of AF class price
Effect of Admission ControlEffect of Admission Control
8/21/00 IRT, Columbia University 39
Average packet lossAverage packet lossAverage packet delayAverage packet delay
Effect of Admission Control (cont’d)Effect of Admission Control (cont’d)
8/21/00 IRT, Columbia University 40
ConclusionsConclusions
• RNAPRNAP– Enables dynamic service negotiationEnables dynamic service negotiation– Supports Supports centralized centralized and and distributeddistributed network network
architecturesarchitectures– Price and charge formulation, collation, Price and charge formulation, collation,
communicationcommunication– FlexibilityFlexibility of service selection of service selection– Multi-party negotiation: senders, receivers, bothMulti-party negotiation: senders, receivers, both– Stand alone, or embedded inside other protocolsStand alone, or embedded inside other protocols– Reliable and scalableReliable and scalable
8/21/00 IRT, Columbia University 41
Conclusions (cont’d)Conclusions (cont’d)
• PricingPricing– Differential pricing for multiple classes of servicesDifferential pricing for multiple classes of services– Consider both long-term user demand and short-Consider both long-term user demand and short-
term traffic fluctuationterm traffic fluctuation
• Application adaptationApplication adaptation– Bandwidth sharing is proportional to user’s Bandwidth sharing is proportional to user’s
willingness to paywillingness to pay
8/21/00 IRT, Columbia University 42
Conclusions (cont’d)Conclusions (cont’d)
• Simulation resultsSimulation results::– Different levels of service gained by different loadDifferent levels of service gained by different load– Without admission control, CPA coupled with user Without admission control, CPA coupled with user
adaptation allows congestion control, and service adaptation allows congestion control, and service assurancesassurances
– With admission control, performance bound can be assured With admission control, performance bound can be assured even with FP policy, but CPA reduces the request blocking even with FP policy, but CPA reduces the request blocking rate greatly and helps to stabilize price rate greatly and helps to stabilize price
– Allowing service class migration helps for further price Allowing service class migration helps for further price stabilization stabilization
• Future workFuture work– Refine the RNAP protocol, experimental over Internet2Refine the RNAP protocol, experimental over Internet2