Xin Wang

1
An Integrated Resource
Negotiation, Pricing, and
QoS Adaptation
Framework for
Multimedia Applications

• Xin Wang
• Internet Real -Time Laboratory
• Columbia
  University
• (Joint work with
  Henning Schulzrinne)
• 
  http//www.cs.columbia.edu/xinwang

2
Outline

• Motivation
• Objectives
• Resource negotiation through RNAP architectures,
  messages, aggregation, reliability
• Pricing
• Price and charge formulation
• Pricing on current Internet
• Proposed pricing schemes
• User request adaptation
• Simulation
• Conclusions

3
Motivation

• Multimedia requires minimum QoS
• Current approaches
• A resource reservation, admission control,
  differentiated services
• Pros QoS expectation
• Cons 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 usage
• Cons users have no motivation to adapt requests

4
Objectives

• 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
Resource Negotiation through 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 -gt User availability of services, price
  quotations, accumulated charges, service
  statistics
• User -gt Network request/re-negotiate services
• Underlying Mechanism
• Traffic engineering network pricing

6
Resource Negotiation through RNAP (contd.)

• 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

7
Protocol Architectures Centralized (RNAP-C)
NRN
NRN
NRN
HRN
HRN
S1
R1
Access Domain - B
Access Domain - A
Transit Domain
Network Resource Negotiator
Internal Router
NRN
Host Resource Negotiator
Edge Router
HRN
Host
Data Flow
RNAP Messages
Intra-domain messages
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
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
10
RNAP Message Aggregation
RNAP-D
RNAP-C
11
RNAP Message Aggregation (contd)

• Aggregation when senders share the same
  destination network
• Messages merged by source or intermediate domains
• 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/domains

12
Block Negotiation

• Block Negotiation
• Aggregated resources are added/removed in large
  blocks to minimize negotiation overhead and
  reduce network dynamics

Bandwidth
time
13
Reliability

• Soft state for synchronous messages, liveness
  tracking through data traffic monitoring
• Retransmission of asynchronous messages
• Server backup and information retrieval

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 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
Price Formulation in RNAP-C

• Some alternative Schemes
• NRN does admission control and price computation
• Pricing based on topology, routing, policies,
  network load
• NRN determines data path
• Accumulates price
• Sends 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.

16
Pricing on Current Internet

• Access rate dependent flat charge
• Usage-based charge
• Volume-based charge
• Time-base charge
• Access charge Usage-based charge

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
• During congestion higher blocking rate OR higher
  dropping rate and delay
• 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
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 Sl 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
  
• pc j (n) min pcj (n-1) ? j (Dj, Sj) x
  (Dj-Sj)/Sj,0 , pmaxj
  
• ccij (n) pc j v ij (n)

19
Usage Price for Differentiated Services

• Usage price for a service class based on cost of
  class bandwidth lower target load -gt higher per
  unit bandwidth price, higher QoS
• Parameters
  
• pbasic basic rate for fully used bandwidth
  
• ? j expected load ratio of class j
• xij effective bandwidth consumption of
  application i
• Aj constant elasticity demand parameter

20
Usage Price for Differentiated Services (contd)

• Price for class j puj pbasic / ? j
• Demand of class j xj ( puj ) Aj / puj
• Effective bandwidth consumption
• xe j ( puj ) Aj / ( puj ? j )
• Network maximizes profit
• max Sl (Aj / pu j ) pu j - f (C), puj
  pbasic / ? j ,
  s. t. Sl Aj / ( pu j ? j ) ? C
• Hence
• pbasic Sl Aj / C , puj Sl Aj /(C? j)

21
User Adaptation based on Utility

• Users 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 /min
• Multi-application task (e.g., video-conference) -
  maximize total utility of task subject to budget
  -gt dynamic resource allocation among component
  applications
• User utility optimization
• U Si Ui (xi (Tspec, Rspec)
• max Sl Ui (xi ) - Ci (xi) , s. t. Sl Ci (xi)
  ? b , xmini ? xi ? xmaxi
• Determine optimal Tspec and Rspec

22
User adaptation based on utility example

• User defines utility at discrete bandwidth, QoS
  levels
• Utility is a 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 bandwidth
• 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
• Optimization
• max Sl U0i ?i log (xi / xmi ) - kdi d - kl
  i l - pi xi ,
  s. t. Sl pi xi ? b , x ? xm , d
  ? D, l ? L
• Without budget constraint x i ?i / pi
• With budget constraint b i b (? i / Sl ? k )

23
Stability and Oscillation Reduction

• Congestion-sensitive pricing (tatonnement
  process) has been shown to be stable (see web
  page for proof)
• Oscillation 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 between domains

24
Simulation Model
Topology 1
Topology 2
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, delay bound 2 ms,
  loss bound 10-6
• AF
• RED-with-In-Out (RIO), limited to 100 packets
• expected load threshold 60, delay bound 5 ms,
  loss bound 10-4
• BE
• Random Early Detection (RED), limited to 200
  packets
• expected load threshold 90, delay bound 100 ms,
  loss bound 10-2

26
Simulation Model (contd)

• Parameter Set-up
• topology1 60 users topology 2 360 users
• sources on-off or Pareto on-off (shape
  parameter 1.5)
• price adjustment factor s 0.06 update
  threshold ? 0.05
• negotiation period 30 seconds
• price (for a 64 kb/s transmission)
• 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
• ? 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.
• average session length 10 minutes,exponentially
  distributed.

27
Simulation Model (contd.)

• 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

28
Design of Experiments

• Performance comparison FP (usage price holding
  price) and CPA (usage price holding price
  congestion price)
• 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 )
• 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
Effect of Traffic Burstiness
Variation over time of the price of AF class
Price average and standard deviation of AF class
30
Effect of Traffic Burstiness (contd)
Average packet delay
Average packet loss
31
Effect of Traffic Burstiness (contd)
Average traffic arrival rate
Average user benefit
32
Effect of Traffic Load
Variation over time of the price of AF class
Price average and standard deviation of AF class
33
Effect of Traffic Load (contd)
Average packet delay
Average packet loss
34
Effect of Traffic Load (contd)
Average traffic arrival rate
Average user benefit
35
Load Balance between Classes
Variation over time of the price of AF class
Ratio of AF class traffic migrating through class
re-selection
36
Load Balance between Classes (contd)
Average packet delay
Average packet loss
37
Effect of Admission Control
User request blocking rate
Average and standard deviation of AF class price
38
Effect of Admission Control (contd)
Average packet delay
Average packet loss
39
Prototype Embed RNAP in RSVP Framework
FreeBSD with routed, CBQ (in ALTQ package) , and
RNAP
R1
S1
Rb
Ra
R2
S2
10 Mb
R3
S3
Embed negotiation and pricing information in RSVP
Policy Data Receiver negotiation, in RNAP-D
format.
RSVP
RNAP
Quotation
Path
Reserve
Resv
Commit
ResvErr
40
Conclusions

• RNAP
• 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

41
Conclusions (contd)

• Pricing
• 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 adaptation
• Bandwidth shared among competing users
  proportional to users willingness to pay

42
Conclusions (contd)

• 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 work
• Refine the RNAP protocol, stand alone RNAP
  implementation in progress, experiments over
  Internet2