1. Resource Negotiation, Pricing and QoS
for Adaptive Multimedia Applications
Xin Wang
With Henning Schulzrinne
Internet Real -Time Laboratory
Columbia University

2. bandwidth, loss, delay, jitter, availability, price
Today’s IP Networks
Service Level Agreements (SLA) are negotiated based on Application Specific Needs
bandwidth, loss, delay, jitter, availability, price
Application SLA
ISP Networks &
Applications
IP Network
Service
User
Large number of new applications are appearing in the Internet. This includes the real-time audio, video, and mission-critical financial data. This provides ISP more business opportunity, and also challenge.
The value-added services normally require certain service expectations.
Since different applications have different requirements in bandwidth and quality, network resource provision is challenging.
SCOPE
Growth of new IP services and applications with different bandwidth and quality of service requirements
Presents opportunities and challenges for service providers
11/22/2018

3. The needs of Next Generation Service Providers
Revenue from the traditional connectivity services (raw bandwidth) is declining
Increase revenue by offering innovative IP services:
Deliver high-margin, differentiated services
VoIP, VPN, Applications Hosting etc
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
Since the revenue is declining, the network providers have to find other opportunities
Service provider needs to provide different premium services, without big cost. The network management and resource provisioning should be automatic and fast.
11/22/2018

4. Internet Structure End User LAN POP NAP Backbone Provider
Regional Provider
Private Network
Backbone
Provider
NAP
LAN
End User
Backbone Provider
POP
Private Peering
Before introducing an appropriate service model for ISP, let’s take a look at the situation of the current Internet.
Network is generally divided into different management domains, with direct peering or connect through Network Access Point (NAP).
The Network Access Point (NAP) allows Internet Service Providers (ISPs) to interconnect and exchange information among themselves. The exchanging of Internet traffic is generally referred to as "peering".
11/22/2018

5. NORDUnet Traffic Analysis
We show some traffic statistics of NORDUnet
NORDUnet interconnects the Nordic national networks for research and education and connects these networks to the rest of the world. The current physical connections are shown on the connectivity map.
NORDUnet provides its services by a combination of leased lines and Internet services provided by other international operators.
11/22/2018

6. NORDUnet Traffic Analysis
Results:
All access links (interconnect ISP’s or connect private networks to ISP’s), including 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.
Statistics shows ….
Even though average utilization is only 20-30%
the peak ….
The reasons for the congestion can be ascribed to the
11/22/2018

7. 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 to meet diverse user requirements?
No intrinsic upper limit on bandwidth use
How much does it cost to add capacity?
It is difficult to predict the various user requirements, especially due to the quick deployments of new applications
Demand:
Availability of more bandwidth will create its own demand through increasing utilization of bandwidth intensive applications” .real-time audio/video, 3D imaging, virtual reality, etc.
Supply:
Cost of transportation using fiber optics is declining drastically. However, network management cost: switches and routers, state of the art POP, data centers, etc, will cost money.
11/22/2018

8. Bandwidth Pricing
Reality: leased bandwidth price has not been dropping consistently and dramatically.
Facts:
300 mile T1 price:
1987: $10,000/month
1992: $4,000/month
1998: $6,000/month (thanks to high Internet demand)
100-mile cabling cost in 1998: $65,000
Links connecting ISP’s are very expensive
11/22/2018

9. Bandwidth Pricing (cont.)
Facts:
International Frame Relay with 256-kbps: thousands dollars a month.
Transit DS-3 link: $50,000/month between carriers.
Transit OC-3 link: $150,000/month between carriers.
Chicago NAP:
$3,900/month/DS-3,
$4,700/month/OC-3.
T megabits per second (24 DS0 lines)
T megabits per second (28 T1s)
OC megabits per second (100 T1s)
OC megabits per second (4 OC3s)
OC gigabits per seconds (4 OC12s)
OC gigabits per second (4 OC48s)
The price for a Chicago NAP connection is distance sensitive and based on the location where the ISP's network meets Ameritech's. ATM pricing also varies with contract length with price deductions for longer term contracts. NAP connection prices start at $3,900 per
month for a DS3 and $4,700 per month for an OC3. Duration of 12, 36 or 60 month terms are available.
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.
11/22/2018

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 QoS to meet diverse user requirements
How efficiently does a QoS mechanism manage bandwidth? How can a user select one out of a spectrum of services? How much does a user need to pay for QoS?
Application adaptation
Source rate adaptation based on network conditions can avoid congestion and lead to efficient bandwidth utilization
How about also QoS? Why would an application adapt?
Provision is more a business strategy.
Now we consider some more efficient service models than simply over-provisioning. What are the desirable things to have in such a model?
QoS: Protect the valuable applications through QoS. But will QoS add big complexity?
Resource reservation and provisioning tend to be conservative due to the lack of quantitative knowledge of traffic statistics.
Providing different servers needs differentiated pricing, otherwise, everyone will ask the best service and end up no services.We need to worry about and how to differentiate the different services through pricing
Adaptations in literature assume no QoS, do not have the motivation to adapt, since the no- adaptive service may perform better
11/22/2018

11. A More Efficient Service Model (cont’d)
Service selection and dynamic resource negotiation
An Integrated mechanism by which the user can select one out of a spectrum of services
Network commits resources for short intervals - better response to changes in network conditions and user demand; allows better QoS support for adaptive applications
Usage-,QoS-,demand-sensitive pricing
Allow network to price services based on resources consumed, and allocate resources based on user willingness-to-pay
Give user incentive to select appropriate service based on requirements, adapt demand during network resource scarcity in response to increase in price
To support services with QoS mechanisms, and user adaptation, a couple of other features are desirable…..
11/22/2018

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 with different QoS characteristics
Enables network to formulate and communicate prices and charges
Lightweight and flexible: embedded in other protocols, e.g., RSVP, or implemented independently
Ensures service predictability: commit service and price for an interval
Supports multi-party negotiation: senders, receivers, or both
Reliable and scalable
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
11/22/2018

13. What we add... (cont’d)
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
11/22/2018

14. Outline RNAP: Architecture and Messaging Pricing models:
Existing model
Usage and congestion-based pricing model
Pricing mechanism
User adaptation
Test-bed demonstration of Resource Negotiation Framework
Simulation and discussion of Resource Negotiation Framework
Resource Negotiation
Framework
11/22/2018

15. Protocol Architectures: Centralized
Host Resource
Negotiator
RNAP Messages
Network Resource
Negotiator
NRN
NRN
NRN
HRN
HRN
Access Domain - A
We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D)
In RNAP-C, user negotiates through a HRN, each network domain has a NRN.
In general, each NRN is in charge of admission control, monitoring network statistics, price quotation and charging for its domain.
When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain. This request is then propagated to next-domain NRN, and so on.
Edge Router
Access Domain - B
Internal Router
Intra-domain messages
Transit Domain
RNAP-C
11/22/2018

16. Protocol Architectures: Distributed
RNAP Messages
HRN
LRN
LRN
LRN
LRN
LRN
LRN
LRN
LRN
LRN
HRN
LRN
LRN
Access Domain - A
LRN
LRN
Edge Router
Access Domain - B
In RNAP-D, Local Resource Negotiators (LRN) were implemented on each router, for
admission control, monitoring network statistics, forming price for each service class.
At network edge, NRNs dynamically configure traffic conditioners, based on on-going user requests.
Internal Router
Transit Domain
RNAP-D
11/22/2018

17. RNAP Messages Periodic negotiation
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
11/22/2018

18. Message Aggregation (RNAP-D)
Turn off router alert
Turn on router alert
Sink-tree-based aggregation
11/22/2018

19. Message Aggregation (RNAP-C)
Sink-tree-based aggregation
11/22/2018

20. RNAP Message Aggregation Summary
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
Overhead Reduction
Processing overhead, storage of states
11/22/2018

21. Block Negotiation (network-network)
Aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics
Bandwidth
time
11/22/2018

22. Outline RNAP: Architecture and Messaging Pricing models:
Comparison of model
Usage and congestion-based pricing model
Pricing mechanism
User adaptation
Test-bed demonstration of Resource Negotiation Framework
Simulation and discussion of Resource Negotiation Framework
Resource Negotiation
Framework
11/22/2018

23. Pricing in Current Internet
Access-rate-dependent flat charge (AC)
Simple, predictable
Difficult to compromise between access speed and cost
No incentive for users to limit usage congestion
Usage-based charge
Volume-dependent charge (V)
Time-base charge (T)
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
Flat fee:
Predictable fee for both users and providers.
Avoid potentially considerable administrative costs of tracking, allocating and billing for usage
Network resource can only be provisioned based on some predictions
11/22/2018

24. Two Volume-based Pricing Strategies
Fixed-Price (FP): fixed unit volume price
FP-FL: per-byte charge are 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-dependent-Price (CP): FP + congestion-sensitive price component
CP-FL, CP-PR, CP-T, CP-PR-T
During congestion: users maintain service by paying more OR reducing sending rate OR switching to lower service class
Reduced rate of service blocking, packet dropping and delay
In period of resource scarcity, quality sensitive applications can maintain their resource levels by paying more
\Quality insensitive applications will reduce their sending rate or change to a lower service class
11/22/2018

25. Important Time Scales Technical levels of interaction
Monetary levels of interaction
atomic
short-term
medium-term
long-term
Retransmission
Error Handling
Flow Control
Resource
Reservation
Capacity
Planning
Scheduling
Feedback
Policing
Routing
time
Congestion
Time-of-day
Pricing
Flat Rates
Pricing
11/22/2018

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 provider’s profit
max [Σl 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)
11/22/2018

27. Usage Price for Differentiated Service
Usage price based on cost of class bandwidth:
lower target load (higher QoS) -> 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 [Σl (Aj / pu j ) pu j - f (C)], puj = pbasic /  j , s. t. Σl Aj / ( pu j  j )  C
Hence: pbasic = Σl Aj / C , puj = Σl Aj /(C j)
11/22/2018

28. Congestion price: first mechanism - Tatonnement
Tatonnement process (CPA-TAT): network applies 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)
11/22/2018

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 (one per user); 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
11/22/2018

30. Outline RNAP: Architecture and Messaging Pricing models:
Comparison of model
Usage and congestion-based pricing model
Pricing mechanism
User adaptation
Test-bed demonstration of Resource Negotiation Framework
Simulation and discussion of Resource Negotiation Framework
Resource Negotiation
Framework
11/22/2018

31. Rate Adaptation of Multimedia System
Enable multimedia applications to 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
11/22/2018

32. 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
11/22/2018

33. Two Rate Adaptation Models
User adaptation under CPA-TAT (tatonnement-based pricing)
Optimize perceived surplus subject to budget and application requirements: U = Σi Ui (xi (Tspec, Rspec)]
max [Σl Ui (xi ) - Ci (xi) ], s. t. Σl Ci (xi)  b , xmini  xi  xmaxi
With the example utility functions:
max [Σl U0i + 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: x i = bi / pi, with b i = b ( i / Σl  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
11/22/2018

34. 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
11/22/2018

35. Outline RNAP: Architecture and Messaging Pricing models:
Comparison of model
Usage and congestion-based pricing model
Pricing mechanism
User adaptation
Test-bed demonstration of Resource Negotiation Framework
Simulation and discussion of Resource Negotiation Framework
Resource Negotiation
Framework
11/22/2018

36. Test-bed 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 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
RAT
VIC
Mbus
HRN
RNAP
NRN
11/22/2018

37. Functions of Routers
Interior routers: per-class policing, e.g, TBMETER (in/out) for a class
Edge routers: flow conditioning/policing based on SLA
The NRN supports flexible definition of service classes and their specification. The spec is typically based on a set of QoS parameters. It also includes a pricing function for calculating price components. Identifier is typically a standard mechanism to identify the service to clients. For example, for a DiffServ service like Expedited Forwarding, the identifier is the DSCP.
The NRN at edge routers performs per-flow policing and conditioning. The policing function can for example use a token-bucket to measure the flow’s usage and take appropriate measures.
The NRN's running on interior routers do not maintain per-flow measurements. But they do keep track of per-flow allocation information. They do per-class policing using the DiffServ BA technique.
11/22/2018

38. 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
11/22/2018

39. Network States Per-class bandwidth and price variations
Reduction in blocking due to adaptation
11/22/2018

40. 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
Using our solution:
Optionally provide real-time pricing information, e.g., every 10 minutes or every call (lower average charge for reward)
Customers choices:
pay a premium to have best quality
pay less by tolerating worse quality
back off to call another time.
Reduce the blocking rate of overall network
11/22/2018

41. Outline RNAP: Architecture and Messaging Pricing models:
Comparison of model
Usage and congestion-based pricing model
Pricing mechanism
User adaptation
Test-bed demonstration of Resource Negotiation Framework
Simulation and discussion of Resource Negotiation Framework
Resource Negotiation
Framework
11/22/2018

42. Simulation Design Performance comparison: Four groups of experiments:
Network with dynamic services and rate-adaptive users versus 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
11/22/2018

43. 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
11/22/2018

44. Simulation Architecture
Topology 1 (60 users)
Topology 2 (360 users)
11/22/2018

45. Effect of Traffic Burstiness
Average packet delay
Average packet loss
11/22/2018

46. Price average and standard deviation of AF class
Effect of Traffic Burstiness (cont’d)
Price average and standard deviation of AF class
Average user benefit
11/22/2018

47. Effect of Traffic Load (cont’d)
Average packet loss
Average packet delay
11/22/2018

48. Price average and standard deviation of AF class
Effect of Traffic Load
Price average and standard deviation of AF class
Average user benefit
11/22/2018

49. Load Balance between Classes (cont’d)
Average packet delay
Average packet loss
11/22/2018

50. Load Balance between Classes
Variation over time of the
price of AF class
Ratio of AF class traffic migrating through class re-selection
11/22/2018

51. Effect of Admission Control
Average packet delay
Average packet loss
11/22/2018

52. Effect of Admission Control (cont’d.)
Average and standard deviation of AF class price
User request blocking rate
11/22/2018

53. Conclusions RNAP Pricing model Application adaptation
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
11/22/2018

54. Conclusions (cont’d) M-bid Auction Model Simulation results
Serves more users than comparable schemes, and has less signaling overhead, greater certainty of service availability, and lower setup delay
Simulation results
Differentiated service requires different target loads in each class
CPA policy coupled with user adaptation effectively limit congestion, provide lower blocking rate, higher user satisfaction and network revenue than with the FP policy
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
Without admission control, service assurance by restricting the load to the targeted level; with admission control, blocking rate and price dynamics get reduced
11/22/2018

55. Conclusions (cont’d) Future work
Allowing service class migration further stabilizes price
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
Future 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
11/22/2018

56. 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, 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
X. Wang, H. Schulzrinne, “Comparison of Adaptive Internet Multimedia Applications,” IEICE Transactions on Communications, Vol. E82-B, No. 6, pp , June 1999.
11/22/2018