Xin Wang With Henning Schulzrinne Internet Real -Time Laboratory Columbia University

Download Report

Transcript Xin Wang With Henning Schulzrinne Internet Real -Time Laboratory Columbia University

Xin Wang
With Henning Schulzrinne
Internet Real -Time Laboratory
Columbia University
http://www.cs.columbia.edu/~xinwang/RNAP.html
Today’s IP Networks
Service Level Agreements
(SLA) are negotiated based
on Application Specific Needs
bandwidth, loss, delay, jitter,
availability, price
ISP Networks &
Applications
Application SLA
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
5/23/2016
2
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


5/23/2016
Evolve from static network management to dynamic service provisioning
Reduce costs by automating network and service management
3
Internet Structure
End User
Regional
Provider
LAN
POP
Regional
Provider
NAP
Backbone
Provider
Private Peering
Backbone
Provider
5/23/2016
Private Peering
Private
Network
4
NORDUnet Traffic Analysis
5/23/2016
5
NORDUnet Traffic Analysis

Results:
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:
 All
 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.
5/23/2016
6
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?
5/23/2016
7
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
5/23/2016
8
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.
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.
5/23/2016
9
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?
5/23/2016
10
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
5/23/2016
11
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


5/23/2016
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
12
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
5/23/2016
13
Outline


RNAP: Architecture and Messaging
Pricing models:
 Existing
model
 Usage and congestion-based pricing model
 Pricing mechanism



Resource Negotiation
Framework
User adaptation
Test-bed demonstration of Resource Negotiation
Framework
Simulation and discussion of Resource
Negotiation Framework
5/23/2016
14
Protocol Architectures: Centralized
Host Resource
Negotiator
RNAP
Messages
NRN
NRN
Network Resource
Negotiator
NRN
HRN
HRN
Access Domain - A
Edge Router
Internal Router
Access Domain - B
Transit Domain
Intra-domain
messages
RNAP-C
5/23/2016
15
Protocol Architectures: Distributed
RNAP
Messages
HRN
LRN
LRN
LRN
LRN
LRN
Access Domain - A
LRN
LRN
LRN
LRN
LRN
LRN
HRN
LRN
Edge Router
Internal Router
LRN
Access Domain - B
Transit Domain
RNAP-D
5/23/2016
16
RNAP Messages
Query: Inquires about available services, prices
Periodic negotiation
Query
Quotation
Quotation: Specifies service availability,
accumulates service statistics, prices
Commit
Reserve: Requests services and resources,
Modifies earlier requests
Reserve
Quotation
Reserve
Commit: Admits the service request at a specific
price or denies it.
Commit
Close
Close: Tears down negotiation session
Release: Releases the resources
Release
5/23/2016
17
Message Aggregation (RNAP-D)
Turn off router alert
Turn on router alert
Sink-tree-based aggregation
5/23/2016
18
Message Aggregation (RNAP-C)
NRN
Sink-tree-based aggregation
5/23/2016
19
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
5/23/2016
overhead, storage of states
20
Block Negotiation (network-network)
Aggregated resources are added/removed in
large blocks to minimize negotiation overhead and
reduce network dynamics
Bandwidth

time
5/23/2016
21
Outline


RNAP: Architecture and Messaging
Pricing models:
 Comparison
of model
 Usage and congestion-based pricing model
 Pricing mechanism



Resource Negotiation
Framework
User adaptation
Test-bed demonstration of Resource Negotiation
Framework
Simulation and discussion of Resource
Negotiation Framework
5/23/2016
22
Pricing in Current Internet

Access-rate-dependent flat charge (AC)




Usage-based charge



Simple, predictable
Difficult to compromise between access speed and cost
No incentive for users to limit usage
congestion
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


5/23/2016
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
23
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



5/23/2016
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
24
Important Time Scales

Technical levels of interaction
atomic
short-term
medium-term long-term
time

Monetary levels of interaction
5/23/2016
25
Pricing Strategies

Holding price and charge: based on cost of blocking other
users by holding bandwidth even without sending data


Usage price and charge: optimize the provider’s profit



phj =  j (pu j - pu j-1) , chij (n) = ph j r ij (n) j
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)
5/23/2016
26
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)
5/23/2016
27
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)
5/23/2016
28
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:





5/23/2016
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
29
Outline


RNAP: Architecture and Messaging
Pricing models:
 Comparison
of model
 Usage and congestion-based pricing model
 Pricing mechanism



Resource Negotiation
Framework
User adaptation
Test-bed demonstration of Resource Negotiation
Framework
Simulation and discussion of Resource
Negotiation Framework
5/23/2016
30
Rate Adaptation of Multimedia System


Utility/cost/budget

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
5/23/2016
U1
U2
U3
Cost
Budget
Bandwidth
31
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



5/23/2016
U (x) = U0 +  log (x / xm) - kd d - kl l , for x  xm
kd : sensitivity to delay
kl : sensitivity to loss
32
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:
[Σ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 )
 max


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
5/23/2016
33
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
5/23/2016
34
Outline


RNAP: Architecture and Messaging
Pricing models:
 Comparison
of model
 Usage and congestion-based pricing model
 Pricing mechanism



Resource Negotiation
Framework
User adaptation
Test-bed demonstration of Resource Negotiation
Framework
Simulation and discussion of Resource
Negotiation Framework
5/23/2016
35
Test-bed Architecture
RAT
VIC

Demonstrate functionality and
performance improvement:

Mbus

Host


HRN



5/23/2016
HRN negotiates resources for a system
Host processes (HRN, VIC, RAT)
communicate through Mbus
Network

NRN
blocking rate, average loss and delay,
price stability, perceived media quality
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
36
Functions of Routers

Interior routers: per-class policing, e.g, TBMETER (in/out) for a class

Edge routers: flow conditioning/policing based on SLA
5/23/2016
37
Network Resource Negotiator (NRN)

Monitor statistics and provide price for each service class

Measurement-based admission control

5/23/2016
predict future demand, update congestion price based on predictions
38
Network States


Per-class bandwidth and price variations
Reduction in blocking due to adaptation
5/23/2016
39
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
5/23/2016
the blocking rate of overall network
40
Outline


RNAP: Architecture and Messaging
Pricing models:
 Comparison
of model
 Usage and congestion-based pricing model
 Pricing mechanism



Resource Negotiation
Framework
User adaptation
Test-bed demonstration of Resource Negotiation
Framework
Simulation and discussion of Resource
Negotiation Framework
5/23/2016
41
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)
(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
5/23/2016
42
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
5/23/2016
43
Simulation Architecture
Topology 1 (60 users)
5/23/2016
Topology 2 (360 users)
44
Effect of Traffic Burstiness
Average packet delay
5/23/2016
Average packet loss
45
Effect of Traffic Burstiness (cont’d)
Price average and standard
deviation of AF class
5/23/2016
Average user benefit
46
Effect of Traffic Load (cont’d)
Average packet delay
5/23/2016
Average packet loss
47
Effect of Traffic Load
Price average and standard
deviation of AF class
5/23/2016
Average user benefit
48
Load Balance between Classes (cont’d)
Average packet delay
5/23/2016
Average packet loss
49
Load Balance between Classes
Variation over time of the
price of AF class
5/23/2016
Ratio of AF class traffic migrating
through class re-selection
50
Effect of Admission Control
Average packet delay
5/23/2016
Average packet loss
51
Effect of Admission Control (cont’d.)
Average and standard deviation of AF
class price
5/23/2016
User request blocking rate
52
Conclusions

RNAP






Pricing model


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
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
5/23/2016
53
Conclusions (cont’d)

M-bid Auction Model


Serves more users than comparable schemes, and has less signaling
overhead, greater certainty of service availability, and lower setup delay
Simulation results




5/23/2016
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
54
Conclusions (cont’d)





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





5/23/2016
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
55
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.
5/23/2016
56