Xin Wang

1
Resource Negotiation, Pricing and QoS
for Adaptive Multimedia Applications

• Xin Wang
• With Henning Schulzrinne
• Internet Real -Time Laboratory
• Columbia University
• http//www.cs.columbia
  .edu/xinwang/RNAP.html

2
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Existing model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
3
Todays IP Networks
Service Level Agreements (SLA) are negotiated
based on Application Specific Needs bandwidth,
loss, delay, jitter, availability, price
ISP Networks
Applications
IP Network
Service
User
SCOPE
Growth of new IP services and applications with
different bandwidth and quality of service
requirements Presents opportunities and
challenges for service providers
4
The needs of Next Generation Service
Providers

• Revenue from the traditional connectivity
  services (raw bandwidth) is declining
• Increase revenue by offering innovative IP
  services
• VoIP, VPN, Applications Hosting etc
• Deliver high-margin, differentiated services
• Gain competitive advantage by deploying new
  services more quickly, placing a premium on time
  to market and time to scale
• Reduce cost and operation complexity
• Evolve from static network management to dynamic
  service provisioning
• Reduce costs by automating network and service
  management

5
Internet Structure
6
NORDUnet Traffic Analysis
7
NORDUnet Traffic Analysis

• Results
• All access links (interconnect ISPs or connect
  private networks to ISPs, trans-Atlantic links)
  can get congested.
• Average utilization is low 20-30
• Peak utilization can be high up to 100
• Congestion Ratio (peak/average) as high as 5.
• Peak duration can be very long
• Chicago NAP congested once in 8/00, lasted 7
  hours.
• TeleGlobe links congested every workday in 8/00
  and 9/00
• Reasons Frequent re-configuration and upgrading
  Load balancing to protect own users.

8
Solution - Over-provisioning?

• Add enough bandwidth for all applications in
  access network / backbone
• Will over-provisioning be sufficient to avoid
  congestion?
• How much bandwidth is enough?
• No intrinsic upper limit on bandwidth use
• How much does it cost to add capacity?

9
Bandwidth Pricing

• Reality leased bandwidth price has not been
  dropping consistently and dramatically.
• 300 mile T1 price
• 1987 10,000/month
• 1992 4,000/month
• 1998 6,000/month (thanks to high Internet
  demand)
• Links connecting ISPs are very expensive
• Transit DS-3 link 50,000/month between
  carriers.
• Transit OC-3 link 150,000/month between
  carriers.

Bandwidth may be cheap, but not free Higher-speed
connection -- higher recurring monthly
costs. Option - manage the existing bandwidth
better, with a service model which uses bandwidth
efficiently.
10
A More Efficient Service Model

• Quality of Service (QoS)
• Condition the network to provide predictability
  to an application even during high user demand
• Provide multiple levels of services
• Efficient bandwidth management? Can a user select
  one out of a spectrum of services? How much a
  user needs to pay?
• Application adaptation
• Source rate adaptation based on network
  conditions - congestion control and efficient
  bandwidth utilization
• How about also QoS? Why would an application
  adapt?

11
A More Efficient Service Model (contd)

• Service selection and dynamic resource
  negotiation
• An integrated mechanism for a user to select a
  service
• Network commits resources for short intervals
• better response to changes in network conditions
  and user demand
• better QoS support for adaptive applications
• Usage-,QoS-,demand-sensitive pricing
• Network price services based on resources
  consumed, allocate resources based on user
  willingness-to-pay
• Users select appropriate service based on
  requirements, adapt demand during network
  resource contention

12
What We Add to Enable This Model

• A dynamic resource negotiation protocol RNAP
• An abstract Resource Negotiation And Pricing
  protocol
• Enables user and network (or two network domains)
  to dynamically negotiate multiple services
• Enables network to formulate and communicate
  prices and charges
• Service predictability commit service and price
  for an interval
• Multi-party negotiation senders, receivers, or
  both
• Reliable and scalable
• Lightweight and flexible embedded in other
  protocols, e.g., RSVP, or implemented
  independently
• A demand-sensitive pricing model
• Enables differential charging for supporting
  multiple levels of services services priced to
  reflect the cost and long-term user demand
• Allows for congestion pricing to motivate user
  adaptation

13
What we add... (contd)

• Demonstrate a complete resource negotiation
  framework (RNAP, pricing model, user adaptation)
  on test-bed network
• Simulations show significant advantages relative
  to static resource allocation and fixed pricing
• Much lower service blocking rate under resource
  contention
• Service assurances under large or bursty offered
  loads, without highly conservative provisioning
• Higher perceived user benefit and higher network
  revenue

14
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Existing model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
15
Protocol Architectures Centralized(RNAP-C)
Host Resource Negotiator
RNAP Messages
Network Resource Negotiator
NRN
NRN
NRN
HRN
HRN
Access Domain - A
Edge Router
Access Domain - B
Internal Router
Intra-domain messages
Transit Domain
16
Protocol Architectures Distributed (RNAP-D)
RNAP Messages
HRN
LRN
LRN
LRN
LRN
LRN
LRN
LRN
LRN
HRN
LRN
LRN
LRN
Access Domain - A
LRN
LRN
Edge Router
Access Domain - B
Internal Router
Transit Domain
17
RNAP Messages
Query Inquires about available services, prices
Query
Quotation
Quotation Specifies service availability,
accumulates service statistics,
prices
Reserve
Commit
Reserve Requests services and resources,
Modifies earlier requests
Periodic negotiation
Quotation
Commit Admits the service request at a specific
price or denies it.
Reserve
Commit
Close Tears down negotiation session
Close
Release Releases the resources
Release
18
Message Aggregation (RNAP-D)
Turn on router alert
Sink-tree-based aggregation
19
Message Aggregation (RNAP-D)
Turn off router alert
Sink-tree-based aggregation
20
Message Aggregation (RNAP-C)
NRN
Sink-tree-based aggregation
21
Block Negotiation (network-network)

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

Bandwidth
time
22
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Comparison of model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
23
Pricing in Current Internet

• Access-rate-dependent flat charge
• Simple, price predictable
• Difficult to compromise between access speed and
  cost
• No incentive for users to limit usage
  congestion
• Usage-based charge
• Volume-dependent charge
• Time-base charge
• work better for uniform per-time unit resource
  demands, e.g., telephone
• Access charge Usage-based charge
• Per-hour charge after certain period of use, or
  per-unit charge after some amount of traffic
  transmitted.
• Flat charge for basic service, usage charge for
  extra bandwidth or premium services

24
Two Volume-based Pricing Strategies

• Fixed-Price (FP) fixed unit volume price
• Flat pricing (FP-FL) per-byte charge are same
  for all services
• Priority pricing (FP-PR) service class dependent
• Time-dependent pricing (FP-T) time-of-day
  dependent
• Time-dependent priority pricing (FP-PR-T) FP-PR
  FP-T
• During congestion higher blocking rate OR higher
  dropping rate and delay
• Congestion-dependent-Price (CP) FP
  congestion-sensitive price component
• CP-FL, CP-PR, CP-T, CP-PR-T
• During congestion users have options to maintain
  service by paying more OR reducing sending rate
  OR switching to lower service class
• Overall reduced rate of service blocking, packet
  dropping and delay

25
Important Time Scales

• Technical levels of interaction
• Monetary levels of interaction

atomic
short-term
medium-term
long-term
Retransmission
Flow Control
Error Handling
Reservation
Resource
Capacity
Planning
Scheduling
Feedback
Policing
Routing
time
Congestion
Time-of-day
Pricing
Flat Rates
Pricing
26
Pricing Strategies

• Holding price and charge based on cost of
  blocking other users by holding bandwidth even
  without sending data
• phj ? j (pu j - pu j-1) , chij (n) ph j r
  ij (n)? j
• Usage price and charge optimize the providers
  profit
  
• max Sl x j (pu1 , pu2 , , puJ ) puj - f(C),
  s.t. r (x (pu2 , pu2 , , puJ )) ? R
  
  
• cuij (n) pu j v ij (n)
• Congestion price and charge drive demand to
  supply level (two mechanisms)
  

27
Usage Price for Differentiated Service

• Usage price based on cost of class bandwidth
• lower target load (higher QoS) -gt higher per-unit
  bandwidth price
• 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
• 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)

28
Congestion price first mechanism - Tatonnement

• Tatonnement process (CPA-TAT)
• Congestion charge proportional to excess demand
  relative to target utilization
• pc j (n) min pcj (n-1) ? j (Dj, Sj) x
  (Dj-Sj)/Sj,0 , pmaxj
  
• ccij (n) pc j v ij (n)

29
Congestion price second mechanism - M-bid
Second-price Auction

• Auction models in literature
• Assume unique bandwidth/price preference, one bid
  
• Service uncertainty not know about high demand
  until rejected
• Higher setup delay, signaling burst, life-time
  auction, user response to auction results not
  considered
• M-bid auction Model
• User bids (bandwidth, price) for a number of
  bandwidths, bids obtained by sampling utility
  function.
• Network selects highest bids, charges highest
  rejected bid price
• During high demand lower bandwidth (higher price
  per unit bandwidth) bids get selected more users
  served
• Inter-auction admission to reduce setup delay
• Support auction for a period to help for
  congestion control

30
Example of M-bid Auction

• Total capacity 70, congestion price is 2

Bid Bandwidth
Bid Selection
Bid Price
Bidder
1
10
5
2
10
4
1
15
4
3
20
3.5
2
25
3
Cutoff
2
30
3
Congestion Price
31
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Comparison of model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
32
Rate Adaptation of Multimedia System

• Gain optimal perceptual value based on the
  network conditions and user profile
• A Host Resource Negotiator (HRN) negotiates
  services with network on behalf of a multimedia
  system.
• Utility function users preference or
  willingness to pay

Cost
U1
U2
Utility/cost/budget
U3
Budget
Bandwidth
33
Example Utility Function

• 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

34
Two Rate Adaptation Models

• User adaptation under CPA-TAT (tatonnement-based
  pricing)
• Optimize perceived surplus subject to budget and
  application requirements
• With the example utility functions
• Without budget constraint x i ?i / pi
• With budget constraint x i bi / pi, with b
  i b (? i / Sl ? k )
• User adaptation under CPA-AUC (second-price
  auction)
• Submit M-bid derived by sampling utility
  function adapt rate based on allocated
  bandwidth/QoS
• Adaptation of applications in multimedia system
• Distribute bid/allocated bandwidth among
  applications for optimal overall surplus

35
Stability and Oscillation Reduction

• Congestion-sensitive pricing has been shown to be
  stable, see references.
• Oscillation reduction
• Users re-negotiate only if price change exceeds
  a given threshold
• Network update price only when traffic change
  exceeds a threshold negotiate resources in
  larger blocks between domains

36
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Comparison of model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
37
Testbed Architecture

• Demonstrate functionality and performance
  improvement
• blocking rate, average loss and delay, price
  stability, perceived media quality
• Host
• HRN negotiates resources for a system
• Host processes (HRN, VIC, RAT) communicate
  through Mbus
• Network
• FreeBSD 3.4 ALTQ 2.2, CBQ extended for DiffServ
• NRNs
• Process RNAP messages
• Admission control, monitor service statistics,
  compute price
• At edge, dynamically configure the conditioners
  and form charge
• Inter-entity signaling RNAP

VIC
RAT
Mbus
HRN
RNAP
NRN
38
Functions of Routers

• Interior routers per-class policing, e.g,
  TBMETER (in/out) for a class
• Edge routers flow conditioning/policing based on
  SLA

39
Network Resource Negotiator (NRN)

• Monitor statistics and provide price for each
  service class
• Measurement-based admission control
• predict future demand, update congestion price
  based on predictions

40
Network States

• Per-class bandwidth and price variations
• Reduction in blocking due to adaptation

41
Adaptive Wireless Terminal

• WAP development over Nokia Toolkit 2.0
• Currently cell phone services
• Flat pricing and best effort when congestion,
  all users get worse quality - coarse voice, busy
  signal, cut off
• New Service Option to users
• Provide real-time pricing information,
  periodically (e.g., every 10 minutes) or per-call
  based
• Lower basic charge, e.g. 20 c/min instead of 30
  c/min
• When congestion, raising price subject to upper
  limit
• Customer choices under congestion pay a premium
  to have best quality pay less by tolerating
  worse quality back off to call another time.
• Reduce overall network blocking rate

42
Outline

• Background
• RNAP architecture and messaging
• Pricing models
• Comparison of model
• Proposed pricing model
• User adaptation
• Testbed demonstration of Resource Negotiation
  Framework
• Simulation and discussion of Resource Negotiation
  Framework

Resource Negotiation Framework
43
Simulation Design

• Performance comparison
• Network with dynamic services and rate-adaptive
  users vs. network with non-adaptive users
• Fixed price policy (FP) (usage price holding
  price) versus congestion price based adaptive
  service (CPA) (usage price holding price
  congestion price)
• Four groups of experiments
• (1) Effect of traffic burstiness (2) Effect of
  traffic load (3) Load balance between classes
  (4) Effect of admission control
• Engineering metrics bottleneck traffic arrival
  rate, average packet loss and delay, user
  request blocking probability
• Economic metrics average and total user
  benefit, end-to-end price and its standard
  deviation, network revenue

44
Simulation Models

• Network Simulator (NS-2)
• Weighted Round Robin (WRR) scheduler
• Three classes EF, AF, BE
• EF tail dropping, limited to 50 packets load
  threshold 40, delay bound 2 ms, loss bound 10-6
• AF RED-with-In-Out (RIO), limited to 100
  packets load threshold 60, delay bound 5 ms,
  loss bound 10-4
• BE Random Early Detection (RED), limited to 200
  packets load threshold 90, delay bound 100 ms,
  loss bound 10-2
• Sources mix of on-off and Pareto on-off (shape
  parameter 1.5)
• Negotiation period 30 s, session length 10 min

45
Simulation Architecture
Topology 1 (60 users)
Topology 2 (360 users)
46
Effect of Traffic Burstiness
Average packet loss
Average packet delay
47
Effect of Traffic Burstiness (contd)
Price average and standard deviation of AF class
Average user benefit
48
Effect of Traffic Load (contd)
Average packet loss
Average packet delay
49
Effect of Traffic Load
Average user benefit
Price average and standard deviation of AF class
50
Load Balance between Classes (contd)
Average packet delay
Average packet loss
51
Load Balance between Classes
Variation over time of the price of AF class
Ratio of AF class traffic migrating through class
re-selection
52
Effect of Admission Control
Average packet loss
Average packet delay
53
Effect of Admission Control (contd.)
Average and standard deviation of AF class price
User request blocking rate
54
Simulation Results

• CPA policy coupled with user adaptation
  effectively limit congestion, provide lower
  blocking rate, higher user satisfaction and
  network revenue than with the FP policy
• Differentiated service requires different target
  loads in each class
• Without admission control, contracted service can
  be assured by restricting the load to the
  targeted level
• With admission control, blocking rate and price
  dynamics get reduced
• Allowing service class migration allows for the
  service assurance and further stabilizes price

55
Other Results

• Users with different demand elasticity share
  bandwidth proportional to their willingness to
  pay
• Even a small proportion of user adaptation
  results in a significant performance improvement
  for the entire user population
• Performance of CPA further improves as the
  network scales and more connections share the
  resources
• Both auction and tatonnement process can be used
  to calculate the congestion price auction scheme
  gains higher perceived user benefit and network
  utilization at cost of implementation complexity
  and setup delay

56
Conclusions

• RNAP
• Supports dynamic service negotiation, mechanisms
  for price and charge collation, auction bids and
  results distribution
• Allows for both centralized and distributed
  architectures
• Supports multi-party negotiation senders,
  receivers, or both
• Can be stand-alone, or embedded inside other
  protocols
• Reliable and scalable
• Pricing model
• Consider resource consumption, long-term user
  demand and short-term traffic fluctuation use
  congestion-sensitive component to motivate user
  demand adaptation during resource scarcity
• Application adaptation
• Maximize user perceptual value, tradeoff between
  quality and expenditure

57
Conclusions (contd)

• M-bid Auction Model
• Serves more users than comparable schemes, and
  has less signaling overhead, greater certainty of
  service availability, and lower setup delay
• Congestion price based adaptive service versus
  fixe price based static service
• Effectively limit congestion, allows for service
  assurance under high and bursty load
• Provide lower blocking rate, higher user
  satisfaction and network revenue

58
Further Work

• Propose light-weight resource management protocol
• Cost distribution in QoS-enhanced multicast
  network
• Pricing in the presence of alternatives path or
  competitive network
• User valuation models for different QoS
• Resource provision in wireless environment

59
Some References

• X. Wang, H. Schulzrinne, Auction or T?tonnement
  - Finding Congestion Prices for Adaptive
  Applications, submitted.
• X. Wang, H. Schulzrinne, Pricing Network
  Resources for Adaptive Applications in a
  Differentiated Services Network, In Proceeding
  of INFOCOM'2001, April 22-26, Anchorage,
  Alaska.
• X. Wang, H. Schulzrinne, An Integrated Resource
  Negotiation, Pricing, and QoS Adaptation
  Framework for Multimedia Applications, IEEE
  JSAC, vol. 18, 2000. Special Issue on Internet
  QoS.
• X. Wang, H. Schulzrinne, Performance Study of
  Congestion Price based Adaptive Service, In
  Proc. International Workshop on Network and
  Operating System Support for Digital Audio and
  Video (NOSSDAV'00), Chapel Hill, North Carolina,
  Jun. 2000.
• X. Wang, H. Schulzrinne, Comparison of Adaptive
  Internet Multimedia Applications, IEICE
  Transactions on Communications, Vol. E82-B, No.
  6, pp. 806--818, June 1999.

60
Measurements and Analysis of
LDAP Performance

• Xin Wang
• Internet Real -Time Laboratory
• Columbia University
• http//www.cs.columbia.edu/xinwang/LDAP.html
• Joint work with Henning Schulzrinne, Dilip
  Kandlur, and Dinesh Verma

61
Motivation and Experiment

• LDAP widely used, but little study on
  performance
• Our work developed a benchmark tool to analyze
  the performance of LDAP directories
• Experimental setup
• Hardware server- dual Ultra-2 processors, 200
  MHz CPUs, 256 Mb memory Clients- Ultra1, 170 MHz
  CPU, 128 MB memory 10 Mb/s Ethernet
• LDAP server OpenLDAP 1.2, Berkeley DB 2.4.14
• Search filter interface address, and
  corresponding policy object
• Default parameters 10,000 entries, entry size
  488 bytes

62
Results

• General Results
• response latency 8 ms up to 105 requests/second
• Maximum throughput 140 requests/second
• 5 ms processing latency - 36 from backend, 64
  from front end
• Connect time dominates at high load, and limits
  the throughput
• Disabling Nagle Algorithm reduces latency about
  50 ms
• Entry Caching
• for 10,000 entry directory, caching all entries
  gives 40 improvement in processing time, 25
  improvement in throughput
• CPU
• For in-memory operation, dual processors improve
  performance by 40.
• Connection Re-use
• 60 performance gain when connection left open.

63
Results (contd)

• Scaling with Directory Size - determined by
  back-end processing
• In memory operation, 10,000 -gt 50,000 processing
  time increases 60, throughput reduces 21.
• Out-of-memory, 50,000 -gt100,000 processing time
  increases another 87, and throughput reduces
  23.
• Scaling with Entry Size (488 -gt4880 bytes)
• In-memory, mainly increase in front-end
  processing, i.e., time for ASN.1 encoding .
  Processing time increases 8 ms, 88 due to ASN.1
  encoding, and throughput reduces 30.
  
• Out-of-memory, throughput reduces 70, mainly due
  to increased data transfer time.

64
IP Multicast Fault Recovery
in PIM over OSPF

• Xin Wang
• Internet Real -Time Laboratory
• Columbia University
• http//www.cs.columbia.edu/xinwang/LDAP.html
• Joint work with Chienming Yu, Henning
  Schulzrinne, Paul Stirpe and Wei Wu

65
Motivation and Experiment

• Many IP multicast applications require high
  availability
• Study failure recovery in a complete
  architecture IGMP OSPF (unicast) PIM-SM
  (multicast)
• Focus the interplay of underlying protocols the
  interactions of failure recovery, between router,
  link, WAN and LAN
• Method quantitative analysis Simulation over
  OPNET Study failure recovery and implementation
  issues on test-bed

66
Results (contd)

• General observations
• Channel recovery time dominated by unicast table
  re-construction time.
• Protocol control loads PIM DM control load
  increases proportionally with the redundancy
  factor and decreases inversely with the
  percentage of receivers OSPF load increases
  proportionally as OSPF Hello interval decreases
• Neither PIM nor OSPF has high control traffic
  during failure recovery.

67
Results (contd)

• PIM Enhancement for Fault Recovery
• Fast recovery from DR failure reduce
  Hello-Holdtime to detect neighbor failure faster
  Backup DR IGMP group information caching in all
  LAN routers.
• Fast recovery from last-hop router failure DR
  record the last-hop router address, not wait for
  an IGMP report to reactivate its oif to the LAN
  Use backup router PIM DM acting as DR for rapid
  detection of the last-hop router failure.
• Reducing extra delay due to polling interrupts