Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Better-than-best-effort: QoS, IntServ,...
-
date post
20-Dec-2015 -
Category
Documents
-
view
224 -
download
0
Transcript of Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Better-than-best-effort: QoS, IntServ,...
Shivkumar KalyanaramanRensselaer Polytechnic Institute
1
Better-than-best-effort: QoS, IntServ, DiffServ, RSVP, RTP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
http://www.ecse.rpi.edu/Homepages/shivkuma
Based in part on slides of Ion Stoica, Jim Kurose, Srini Seshan, Srini Keshav
Shivkumar KalyanaramanRensselaer Polytechnic Institute
2
Why better-than-best-effort (QoS-enabled) Internet ? Quality of Service (QoS) building blocks End-to-end protocols: RTP, H.323 Network protocols:
Integrated Services(IntServ), RSVP. Scalable differentiated services: DiffServ
Control plane: QoS routing, traffic engineering, policy management, pricing models
Overview
Shivkumar KalyanaramanRensselaer Polytechnic Institute
3
Why Better-than-Best-Effort (QoS)?
To support a wider range of applicationsReal-time, Multimedia, etc
To develop sustainable economic models and new private networking servicesCurrent flat priced models, and best-effort
services do not cut it for businesses
Shivkumar KalyanaramanRensselaer Polytechnic Institute
4
Quality of Service: What is it?
Multimedia applications: network audio and video
network provides application with level of performance needed for application to function.
QoS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
5
What is QoS? “Better performance” as described by a set of
parameters or measured by a set of metrics.
Generic parameters: BandwidthDelay, Delay-jitterPacket loss rate (or loss probability)
Transport/Application-specific parameters:TimeoutsPercentage of “important” packets lost
Shivkumar KalyanaramanRensselaer Polytechnic Institute
6
What is QoS (contd) ? These parameters can be measured at several
granularities: “micro” flow, aggregate flow, population.
QoS considered “better” if a) more parameters can be specified b) QoS can be specified at a fine-granularity.
QoS spectrum:
Best Effort Leased Line
Shivkumar KalyanaramanRensselaer Polytechnic Institute
7
Fundamental Problems
In a FIFO service discipline, the performance assigned to one flow is convoluted with the arrivals of packets from all other flows! Cant get QoS with a “free-for-all” Need to use new scheduling disciplines which provide
“isolation” of performance from arrival rates of background traffic
B
Scheduling DisciplineFIFO
B
Shivkumar KalyanaramanRensselaer Polytechnic Institute
8
Fundamental Problems Conservation Law
(Kleinrock): (i)Wq(i) = K
Irrespective of scheduling discipline chosen: Average backlog (delay)
is constant Average bandwidth is
constant
Zero-sum game => need to “set-aside” resources for premium services
Shivkumar KalyanaramanRensselaer Polytechnic Institute
9
QoS Big Picture: Control/Data Planes
Internetw ork or W ANW orkstationRouter
Router
RouterW orkstation
Control Plane: Signaling + Admission Control orSLA (Contracting) + Provisioning/Traffic Engineering
Data Plane: Traffic conditioning (shaping, policing, markingetc) + Traffic Classification + Scheduling, Buffer management
Shivkumar KalyanaramanRensselaer Polytechnic Institute
10
QoS Components QoS => set aside resources for premium services QoS components:
a) Specification of premium services: (service/service level agreement design)
b) How much resources to set aside? (admission control/provisioning)
c) How to ensure network resource utilization, do load balancing, flexibly manage traffic aggregates and paths ?
(QoS routing, traffic engineering)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
11
QoS Components (Continued)
d) How to actually set aside these resources in a distributed manner ?
(signaling, provisioning, policy)e) How to deliver the service when the traffic
actually comes in (claim/police resources)?
(traffic shaping, classification, scheduling) f) How to monitor quality, account and price
these services?
(network mgmt, accounting, billing, pricing)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
12
How to upgrade the Internet for QoS?
Approach: de-couple end-system evolution from network evolution
End-to-end protocols: RTP, H.323 etc to spur the growth of adaptive multimedia applicationsAssume best-effort or better-than-best-effort
clouds
Network protocols: IntServ, DiffServ, RSVP, MPLS, COPS … To support better-than-best-effort capabilities
at the network (IP) level
Shivkumar KalyanaramanRensselaer Polytechnic Institute
13
QOS SPECIFICATION, TRAFFIC, SERVICE
CHARACTERIZATION, BASIC MECHANISMS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
14
Service Specification
Loss: probability that a flow’s packet is lost Delay: time it takes a packet’s flow to get from
source to destination Delay jitter: maximum difference between the
delays experienced by two packets of the flow Bandwidth: maximum rate at which the soource
can send traffic QoS spectrum:
Best Effort Leased Line
Shivkumar KalyanaramanRensselaer Polytechnic Institute
15
Hard Real Time: Guaranteed Services
Service contractNetwork to client: guarantee a deterministic
upper bound on delay for each packet in a session
Client to network: the session does not send more than it specifies
Algorithm supportAdmission control based on worst-case
analysisPer flow classification/scheduling at routers
Shivkumar KalyanaramanRensselaer Polytechnic Institute
16
Soft Real Time: Controlled Load Service
Service contract:Network to client: similar performance as an
unloaded best-effort networkClient to network: the session does not send
more than it specifies Algorithm Support
Admission control based on measurement of aggregates
Scheduling for aggregate possible
Shivkumar KalyanaramanRensselaer Polytechnic Institute
17
Traffic and Service Characterization
To quantify a service one has two knowFlow’s traffic arrivalService provided by the router, i.e., resources
reserved at each router Examples:
Traffic characterization: token bucketService provided by router: fix rate and fix
buffer space Characterized by a service model (service
curve framework)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
18
Token Bucket Characterized by three parameters (b, r, R)
b – token depthr – average arrival rateR – maximum arrival rate (e.g., R link capacity)
A bit is transmitted only when there is an available tokenWhen a bit is transmitted exactly one token is consumed
r tokens per second
b tokens
<= R bps
regulatortime
bits
b*R/(R-r)
slope R
slope r
Shivkumar KalyanaramanRensselaer Polytechnic Institute
19
Characterizing a Source by Token Bucket
Arrival curve – maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve
time
bits
Arrival curve
time
bps
Shivkumar KalyanaramanRensselaer Polytechnic Institute
20
Example Arrival curve – maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve
size of timeinterval
bitsArrival curve
time
bps
0 1 2 3 4 5
1
2
1 2 3 4 5
1
2
3
4
(b=1,r=1,R=2)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
21
Per-hop Reservation Given b,r,R and per-hop delay d Allocate bandwidth ra and buffer space Ba such that to
guarantee d
bits
b
slope rArrival curve
d
Ba
slope ra
Shivkumar KalyanaramanRensselaer Polytechnic Institute
22
What is a Service Model?
The QoS measures (delay,throughput, loss, cost) depend on offered traffic, and possibly other external processes.
A service model attempts to characterize the relationship between offered traffic, delivered traffic, and possibly other external processes.
“external process”
Network elementoffered traffic
delivered traffic
(connection oriented)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
23
Arrival and Departure Process
Network ElementRin Rout
Rin(t) = arrival process = amount of data arriving up to time t
Rout(t) = departure process = amount of data departing up to time t
bits
t
delay
buffer
Shivkumar KalyanaramanRensselaer Polytechnic Institute
24
Traffic Envelope (Arrival Curve) Maximum amount of service that a flow can send
during an interval of time t
slope = max average rate
b(t) = Envelope
slope = peak rate
t
“Burstiness Constraint”
Shivkumar KalyanaramanRensselaer Polytechnic Institute
25
Service Curve
Assume a flow that is idle at time s and it is backlogged during the interval (s, t)
Service curve: the minimum service received by the flow during the interval (s, t)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
26
Big Picture
t t
slope = C
t
Rin(t)
Service curvebits bits
bits
Rout(t)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
27
Delay and Buffer Bounds
t
S (t) = service curve
E(t) = Envelope
Maximum delay
Maximum buffer
bits
Shivkumar KalyanaramanRensselaer Polytechnic Institute
28
Mechanisms: Traffic Shaping/Policing Token bucket: limits input to specified Burst Size (b) and
Average Rate (r). Traffic sent over any time T <= r*T + b a.k.a Linear bounded arrival process (LBAP)
Excess traffic may be queued, marked BLUE, or simply dropped
Shivkumar KalyanaramanRensselaer Polytechnic Institute
29
Mechanisms: Queuing/Scheduling
Use a few bits in header to indicate which queue (class) a packet goes into (also branded as CoS)
High $$ users classified into high priority queues, which also may be less populated => lower delay and low likelihood of packet drop
Ideas: priority, round-robin, classification, aggregation, ...
Class C
Class B
Class A
Traffic Classes
Traffic Sources
$$$$$$
$$$
$
Shivkumar KalyanaramanRensselaer Polytechnic Institute
30
Mechanisms: Buffer Mgmt/Priority Drop
Ideas: packet marking, queue thresholds, differential dropping, buffer assignments
Drop RED and BLUE packets
Drop only BLUE packets
Shivkumar KalyanaramanRensselaer Polytechnic Institute
31
SCHEDULING
Shivkumar KalyanaramanRensselaer Polytechnic Institute
32
Packet Scheduling Decide when and what packet to send on output link
Usually implemented at output interface
1
2
Scheduler
flow 1
flow 2
flow n
Classifier
Buffer management
Shivkumar KalyanaramanRensselaer Polytechnic Institute
33
Focus: Scheduling Policies Priority Queuing: classes have different priorities;
class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc.
Transmit a packet from the highest priority class with a non-empty queue
Preemptive and non-preemptive versions
Shivkumar KalyanaramanRensselaer Polytechnic Institute
34
Scheduling Policies (more) Round Robin: scan class queues serving one from each class
that has a non-empty queue
Shivkumar KalyanaramanRensselaer Polytechnic Institute
35
Round-Robin Discussion
Advantages: protection among flows Misbehaving flows will not affect the performance
of well-behaving flowsMisbehaving flow – a flow that does not
implement any congestion control FIFO does not have such a property
Disadvantages: More complex than FIFO: per flow queue/state Biased toward large packets – a flow receives
service proportional to the number of packets
Shivkumar KalyanaramanRensselaer Polytechnic Institute
36
Generalized Processor Sharing(GPS) Assume a fluid model of traffic
Visit each non-empty queue in turn (RR)Serve infinitesimal from eachLeads to “max-min” fairness
GPS is un-implementable!We cannot serve infinitesimals, only packets
Shivkumar KalyanaramanRensselaer Polytechnic Institute
37
Generalized Processor Sharing A work conserving GPS is defined as
where wi – weight of flow i Wi(t1, t2) – total service received by flow i during [t1, t2) W(t1, t2) – total service allocated to all flows during [t1, t2) B(t) – number of flows backlogged
)(),(),(
)(
tBiw
dtttW
w
dtttW
tBj ji
i
Shivkumar KalyanaramanRensselaer Polytechnic Institute
38
Fair Rate Computation in GPS
Associate a weight wi with each flow i If link congested, compute f such that
Cwfr ii
i ),max(
8
6
244
2
f = 2: min(8, 2*3) = 6 min(6, 2*1) = 2 min(2, 2*1) = 2
10(w1 = 3)
(w2 = 1)
(w3 = 1)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
39
Bit-by-bit Round Robin
Single flow: clock ticks when a bit is transmitted. For packet i:Pi = length, Ai = arrival time, Si = begin
transmit time, Fi = finish transmit timeFi = Si+Pi = max (Fi-1, Ai) + Pi
Multiple flows: clock ticks when a bit from all active flows is transmitted round numberCan calculate Fi for each packet if number of
flows is known at all timesThis can be complicated
Shivkumar KalyanaramanRensselaer Polytechnic Institute
40
Standard techniques of approximating fluid GPS Select packet that finishes first in GPS
assuming that there are no future arrivals Important properties of GPS
Finishing order of packets currently in system independent of future arrivals
Implementation based on virtual time Assign virtual finish time to each packet upon
arrival Packets served in increasing order of virtual
times
Packet Approximation of Fluid System
Shivkumar KalyanaramanRensselaer Polytechnic Institute
41
Fair Queuing (FQ) Idea: serve packets in the order in which they would have
finished transmission in the fluid flow system Mapping bit-by-bit schedule onto packet transmission
schedule Transmit packet with the lowest Fi at any given time Variation: Weighted Fair Queuing (WFQ)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
42
Approximating GPS with WFQ
Fluid GPS system service order
0 2 104 6 8
Weighted Fair Queueing select the first packet that finishes in GPS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
43
FQ Example
F=10
Flow 1(arriving)
Flow 2transmitting Output
F=2
F=5
F=8
Flow 1 Flow 2 Output
F=10
Cannot preempt packetcurrently being transmitted
Shivkumar KalyanaramanRensselaer Polytechnic Institute
44
FQ Advantages FQ protect well-behaved flows from ill-behaved flows Example: 1 UDP (10 Mbps) and 31 TCP’s sharing a
10 Mbps link
FQ
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
1 4 7 10 13 16 19 22 25 28 31Flow Number
Thro
ughp
ut(M
bps)
RED
0
1
2
3
4
5
6
7
8
9
10
1 4 7 10 13 16 19 22 25 28 31Flow Number
Thro
ughp
ut(M
bps)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
45
System Virtual Time: V(t) Measure service, instead of time V(t) slope – rate at which every active flow receives service
C – link capacityN(t) – number of active flows in fluid system at time t
1 23
1 24
3 45
5 6Servicein fluid flow
systemtime
time
V(t)
)(
)(
tN
C
t
tV
Shivkumar KalyanaramanRensselaer Polytechnic Institute
46
System Virtual Time Virtual time (VGPS) – service that backlogged
flow with weight = 1 would receive in GPS
)(),(
),()(
tBiw
dtttWwdtttW
tBj jii
t
W
wt
V
tBj j
GPS
)(
1)()(
tBit
W
w
w
t
W
tBj j
ii
)(1
),(2
1)(
21 tBidtt
W
wwttW
t
tttBj j
ii
Shivkumar KalyanaramanRensselaer Polytechnic Institute
47
Service Allocation in GPS
The service received by flow i during an interval [t1,t2), while it is backlogged is
)(),(2
121 tBidt
t
VwttW
t
tt
GPSii
)())()((),( 1221 tBitVtVwttW GPSGPSii
Shivkumar KalyanaramanRensselaer Polytechnic Institute
48
Virtual Time Implementation of Weighted Fair Queueing
w j
kj
jj
LSF
0)0( V GPS
))(,max( kjjj aVFS
if session j backlogged
if session j un-backlogged
ajk – arrival time of packet k of flow j
Sjk – virtual starting time of packet k of flow j
Fjk – virtual finishing time of packet k of flow j
Ljk – length of packet k of flow j
kj
kj FS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
49
Virtual Time Implementation of Weighted Fair Queueing
Need to keep per flow instead of per packet virtual start, finish time only
System virtual time is used to reset a flow’s virtual start time when a flow becomes backlogged again after being idle
Shivkumar KalyanaramanRensselaer Polytechnic Institute
50
System Virtual Time in GPS
0 4 128 16
1/2
1/81/81/81/8
)(tVGPS
2*C
C2*C
Shivkumar KalyanaramanRensselaer Polytechnic Institute
51
Virtual Start and Finish Times Utilize the time the packets would start Si
k and finish Fik in
a fluid system
0 4 128 16
kiFkiS
i
kik
ik
i w
LSF
)(tVGPS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
52
Big Picture FQ does not eliminate congestion it just
manages the congestion You need both end-host congestion control and
router support for congestion controlend-host congestion control to adapt router congestion control to protect/isolate
Don’t forget buffer management: you still need to drop in case of congestion. Which packet’s would you drop in FQ?one possibility: packet from the longest queue
Shivkumar KalyanaramanRensselaer Polytechnic Institute
53
QoS ARCHITECTURES
Shivkumar KalyanaramanRensselaer Polytechnic Institute
54
Parekh-Gallager theorem
Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g
Let it be leaky-bucket regulated such that # bits sent in time [t1, t2] <= g(t2 - t1) +
Let the connection pass through K schedulers, where the kth scheduler has a rate r(k)
Let the largest packet size in the network be P
1
1 1
)(///___K
k
K
k
krPgPgdelayendtoend
Shivkumar KalyanaramanRensselaer Polytechnic Institute
55
Significance P-G Theorem shows that WFQ scheduling can
provide end-to-end delay bounds in a network of multiplexed bottlenecksWFQ provides both bandwidth and delay
guaranteesBound holds regardless of cross traffic
behavior (isolation)Needs shapers at the entrance of the network
Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time
Shivkumar KalyanaramanRensselaer Polytechnic Institute
56
Stateless vs. Stateful QoS Solutions
Stateless solutions – routers maintain no fine grained state about traffic scalable, robust weak services
Stateful solutions – routers maintain per-flow state powerful services
guaranteed services + high resource utilizationfine grained differentiationprotection
much less scalable and robust
Shivkumar KalyanaramanRensselaer Polytechnic Institute
57
Existing Solutions
Stateful Stateless
QoS
Tenet [Ferrari & Verma ’89] IntServ [Clark et al ’91] ATM [late ’80s]
DiffServ - [Clark & Wroclawski ‘97] - [Nichols et al ’97]
Network support for congestion control
Round Robin [Nagle ’85] Fair Queueing [Demers et al ’89] Flow Random Early Drop (FRED) [Lin & Morris ’97]
DecBit [Ramkrishnan & Jain ’88] Random Early Detection (RED) [Floyd & Jacobson ’93] BLUE [Feng et al ’99] REM [Low at al ’00]
Shivkumar KalyanaramanRensselaer Polytechnic Institute
58
Integrated Services (IntServ) An architecture for providing QOS guarantees in IP networks for
individual application sessions Relies on resource reservation, and routers need to maintain state
information of allocated resources (eg: g) and respond to new Call setup requests
Shivkumar KalyanaramanRensselaer Polytechnic Institute
59
Signaling semantics Classic scheme: sender initiated SETUP, SETUP_ACK, SETUP_RESPONSE Admission control Tentative resource reservation and confirmation Simplex and duplex setup; no multicast support
Shivkumar KalyanaramanRensselaer Polytechnic Institute
60
RSVP: Internet Signaling Creates and maintains distributed reservation
state De-coupled from routing:
Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling)
Receiver-initiated: scales for multicast Soft-state: reservation times out unless refreshed Latest paths discovered through “PATH”
messages (forward direction) and used by RESV mesgs (reverse direction).
Shivkumar KalyanaramanRensselaer Polytechnic Institute
61
Call Admission
Session must first declare its QOS requirement and characterize the traffic it will send through the network
R-spec: defines the QOS being requested T-spec: defines the traffic characteristics A signaling protocol is needed to carry the R-spec and
T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol
Shivkumar KalyanaramanRensselaer Polytechnic Institute
62
Call Admission
Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
63
Stateful Solution: Guaranteed Services
SenderReceiver
Achieve per-flow bandwidth and delay guarantees Example: guarantee 1MBps and < 100 ms delay to a flow
Shivkumar KalyanaramanRensselaer Polytechnic Institute
64
Stateful Solution: Guaranteed Services
SenderReceiver
Allocate resources - perform per-flow admission control
Shivkumar KalyanaramanRensselaer Polytechnic Institute
65
Stateful Solution: Guaranteed Services
SenderReceiver
Install per-flow state
Shivkumar KalyanaramanRensselaer Polytechnic Institute
66
SenderReceiver
Challenge: maintain per-flow state consistent
Stateful Solution: Guaranteed Services
Shivkumar KalyanaramanRensselaer Polytechnic Institute
67
Stateful Solution: Guaranteed Services
SenderReceiver
Per-flow classification
Shivkumar KalyanaramanRensselaer Polytechnic Institute
68
Stateful Solution: Guaranteed Services
SenderReceiver
Per-flow buffer management
Shivkumar KalyanaramanRensselaer Polytechnic Institute
69
Stateful Solution: Guaranteed Services
SenderReceiver
• Per-flow scheduling
Shivkumar KalyanaramanRensselaer Polytechnic Institute
70
Stateful Solution Complexity
Data path Per-flow classification Per-flow buffer management Per-flow scheduling
Control path install and maintain per-flow state for data and control paths
Classifier
Buffermanagement
Scheduler
flow 1
flow 2
flow n
output interface
…
Per-flow State
Shivkumar KalyanaramanRensselaer Polytechnic Institute
71
Stateless vs. Stateful
Stateless solutions are morescalable robust
Stateful solutions provide more powerful and flexible servicesguaranteed services + high resource utilization fine grained differentiationprotection
Shivkumar KalyanaramanRensselaer Polytechnic Institute
72
Question
Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures? Yes, in some interesting cases. DPS, CSFQ.
Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than end-to-end flows? Yes: Diff-serv
Shivkumar KalyanaramanRensselaer Polytechnic Institute
73
Differentiated Services (DiffServ) Intended to address the following difficulties with
Intserv and RSVP; Scalability: maintaining states by routers in high
speed networks is difficult sue to the very large number of flows
Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)
Simpler signaling: (than RSVP) many applications and users may only w ant to specify a more qualitative notion of service
Shivkumar KalyanaramanRensselaer Polytechnic Institute
74
Differentiated Services Model
Edge routers: traffic conditioning (policing, marking, dropping), SLA negotiation Set values in DS-byte in IP header based upon negotiated
service and observed traffic. Interior routers: traffic classification and forwarding (near
stateless core!) Use DS-byte as index into forwarding table
IngressEdge Router
EgressEdge Router
Interior Router
Shivkumar KalyanaramanRensselaer Polytechnic Institute
75
Diffserv ArchitectureEdge router:- per-flow traffic management
- marks packets as in-profile and out-profile
Core router:
- per class TM
- buffering and scheduling
based on marking at edge
- preference given to in-profile packets- Assured Forwarding
scheduling
...
r
b
marking
Shivkumar KalyanaramanRensselaer Polytechnic Institute
76
Packet format support
Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6: renamed as “DS”
6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive
2 bits are currently unused
Shivkumar KalyanaramanRensselaer Polytechnic Institute
77
Traffic Conditioning
It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if non-conforming
Shivkumar KalyanaramanRensselaer Polytechnic Institute
78
Per-hop Behavior (PHB)
PHB: name for interior router data-plane functions Includes scheduling, buff. mgmt, shaping etc
Logical spec: PHB does not specify mechanisms to use to ensure performance behavior
Examples: Class A gets x% of outgoing link bandwidth
over time intervals of a specified lengthClass A packets leave first before packets from
class B
Shivkumar KalyanaramanRensselaer Polytechnic Institute
79
PHB (contd) PHBs under consideration:
Expedited Forwarding: departure rate of packets from a class equals or exceeds a specified rate (logical link with a minimum guaranteed rate)Emulates leased-line behavior
Assured Forwarding: 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions Emulates frame-relay behavior
Shivkumar KalyanaramanRensselaer Polytechnic Institute
80
Question
Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures? Yes, in some interesting cases. DPS, CSFQ.
Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than end-to-end flows? Yes: Diff-serv
Shivkumar KalyanaramanRensselaer Polytechnic Institute
81
Scalable Core (SCORE) A trusted and contiguous region of network in which
edge nodes – perform per flow management core nodes – do not perform per flow management
core nodes edge nodesedge nodes
Shivkumar KalyanaramanRensselaer Polytechnic Institute
82
The DPS Approach1. Define a reference stateful network that
implements the desired service
Reference Stateful Network
SCORE Network
2. Emulate the functionality of the reference network in a SCORE network
Shivkumar KalyanaramanRensselaer Polytechnic Institute
83
The DPS Idea Instead of having core routers maintaining per-
flow state have packets carry per-flow state
Reference Stateful Network SCORE Network
Shivkumar KalyanaramanRensselaer Polytechnic Institute
84
Dynamic Packet State (DPS)
Ingress node: compute and insert flow state in packet’s header
Shivkumar KalyanaramanRensselaer Polytechnic Institute
85
Dynamic Packet State (DPS)
Ingress node: compute and insert flow state in packet’s header
Shivkumar KalyanaramanRensselaer Polytechnic Institute
86
Dynamic Packet State (DPS)
Core node: process packet based on state it carries
and node’s stateupdate both packet and node’s state
Shivkumar KalyanaramanRensselaer Polytechnic Institute
87
Dynamic Packet State (DPS)
Egress node: remove state from packet’s header
Shivkumar KalyanaramanRensselaer Polytechnic Institute
88
Example: DPS-Guaranteed Services Goal: provide per-flow delay and bandwidth guarantees How: emulate ideal model in which each flow traverses
dedicated links of capacity r
Per-hop packet service time = (packet length) / r
r r rflow(reservation = r )
Shivkumar KalyanaramanRensselaer Polytechnic Institute
89
Guaranteed Services Define reference network to implement service
control path: per-flow admission control, reserve capacity r on each link
data path: enforce ideal model, by using Jitter Virtual Clock (Jitter-VC) scheduler
Reference Stateful Network
Jitter-VC Jitter-VC Jitter-VCJitter-VC
Jitter-VCJitter-VCJitter-VC
Shivkumar KalyanaramanRensselaer Polytechnic Institute
90
Guaranteed Services Use DPS to eliminate per-flow state in core
control path: emulate per-flow admission control data path: emulate Jitter-VC by Core-Jitter
Virtual Clock (CJVC)
Reference Stateful Network SCORE Network
Jitter-VC Jitter-VC Jitter-VCJitter-VC
Jitter-VCJitter-VCJitter-VC
CJVCCJVC
CJVC
CJVC
CJVC
CJVC
Shivkumar KalyanaramanRensselaer Polytechnic Institute
91
End-to-end Adaptive Applications
Internet
End-to-end Closed-loop control
Video Coding, Error Concealment, Unequal Error Protection (UEP) Packetization, Marking, SourceBuffer Management
Congestion control
Video Coding, Error Concealment, Unequal Error Protection (UEP) Packetization, Marking, playoutBuffer Management
Congestion control
Shivkumar KalyanaramanRensselaer Polytechnic Institute
92
End-to-end: Real-Time Protocol (RTP) Provides standard packet format for real-time
application Typically runs over UDP Specifies header fields below Payload Type: 7 bits, providing 128 possible
different types of encoding; eg PCM, MPEG2 video, etc.
Sequence Number: 16 bits; used to detect packet loss
Shivkumar KalyanaramanRensselaer Polytechnic Institute
93
Real-Time Protocol (RTP)
Timestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network
Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source
Shivkumar KalyanaramanRensselaer Polytechnic Institute
94
RTP Control Protocol (RTCP) Protocol specifies report packets exchanged
between sources and destinations of multimedia information
Three reports are defined: Receiver reception, Sender, and Source description
Reports contain statistics such as the number of packets sent, number of packets lost, inter-arrival jitter
Used to modify sender transmission rates and for diagnostics purposes
Shivkumar KalyanaramanRensselaer Polytechnic Institute
95
Eg: Streaming & RTSP User interactive control is provided, e.g. the
public protocol Real Time Streaming Protocol (RTSP)
Helper Application: displays content, which is typically requested via a Web browser; e.g. RealPlayer; typical functions:DecompressionJitter removalError correction: use redundant packets to be
used for reconstruction of original streamGUI for user control
Shivkumar KalyanaramanRensselaer Polytechnic Institute
96
Using a Streaming Server Web browser requests and receives a Meta File
(a file describing the object) Browser launches the appropriate Player and passes it the Meta File; Player contacts a streaming server, may use a choice of UDP vs. TCP to get the stream
Shivkumar KalyanaramanRensselaer Polytechnic Institute
97
Receiver Adaptation Options If UDP: Server sends at a rate appropriate for client;
to reduce jitter, Player buffers initially for 2-5 seconds, then starts display
If TCP: sender sends at maximum possible rate; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP
Shivkumar KalyanaramanRensselaer Polytechnic Institute
98
H.323 H.323 is an ITU standard for multimedia
communications over best-effort LANs. Part of larger set of standards (H.32X) for
videoconferencing over data networks. H.323 includes both stand-alone devices and
embedded personal computer technology as well as point-to-point and multipoint conferences.
H.323 addresses call control, multimedia management, and bandwidth management as well as interfaces between LANs and other networks.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
99
H.323 Architecture
Shivkumar KalyanaramanRensselaer Polytechnic Institute
100
Inter-domain QoS: Challenge Provide high quality service across ISPs Problem: intermediate ISPs don’t have
incentive to provide “good” servicee.g., “hot-potato” policy
ISP 1
ISP 2
ISP 3?
Shivkumar KalyanaramanRensselaer Polytechnic Institute
101
Approach: Virtual ISP (V-ISP) Avoid crossing ISP boundaries
Each ISP will provide good service; V-ISP can easily verify it
Allocate/buy service across each ISP and compose them
ISP 1
ISP 2
ISP 3
Proxy(edge)
GPoP(core)
GPoP(core)
Proxy(edge)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
102
Composition Tools for QoS Dynamic Packet State (DPS):
Proxy (edge): maintain per flow state; label packets
Giga PoPs (core): maintain no per flow state; process packets based on their labels
I E
I
EI
E
Logical FIFO
B
Closed-loop building blocks: No core upgrades, smaller QoS service spectrum
Shivkumar KalyanaramanRensselaer Polytechnic Institute
103
Closed-Loop Building Blocks for QoS
International Linkor
International Linkor
Shivkumar KalyanaramanRensselaer Polytechnic Institute
104
Edge-based QoS building blocks
New: Closed-loop control !Policy/Bandwidth Broker
I E
I
EI
E
Logical FIFO
B
Shivkumar KalyanaramanRensselaer Polytechnic Institute
105
Closed-loop QoS Building Blocks
FIFO
B
Loops: differentiate service on an RTT-by-RTT basis using purely edge-based policy configuration.
B
Priority/WFQ
Scheduler: differentiates service on a packet-by-packet basis
Shivkumar KalyanaramanRensselaer Polytechnic Institute
106
Recall: Accumulation-based CC Schemes!
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
… …
106time
)(1f
ii dtq )(
1
J
jkkij dtq
)(tqiJ
1 j j+1 J
jd 1Jd
),( tdtI fii
)(tai
)( ttai
),( ttOi
fid
t
Shivkumar KalyanaramanRensselaer Polytechnic Institute
107
Recall: Accumulation-based CC Schemes!
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
… …
107time
)(1f
ii dtq )(
1
J
jkkij dtq
)(tqiJ
1 j j+1 J
jd 1Jd
),( tdtI fii
)(tai
)( ttai
),( ttOi
fid
t
Shivkumar KalyanaramanRensselaer Polytechnic Institute
108
Recall: Accln-based Control Policy
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
0)( ii ta
108
control objective : keep if , no way to probe increase of available
bandwidth;0)( tai
ttttdtttarec
thentaif
thentaif
if
iii
iii
iii
)],(),([),(:
)(
)(
control algorithm :
Shivkumar KalyanaramanRensselaer Polytechnic Institute
109
Recall: “Monaco” CC Scheme
109
congestion estimation:out-of-band and in-band control packets
congestion response: if qm < α, cwnd(k+1) = cwnd(k) + 1;
if qm > β, cwnd(k+1) = cwnd(k) – 1; [ 1 = α < β = 3 ]
Shivkumar KalyanaramanRensselaer Polytechnic Institute
110
Closed-Loop Service Differentiation: Loss-based or Accumulation-based ?
110
Shivkumar KalyanaramanRensselaer Polytechnic Institute
111
Closed-Loop QoS: Bandwidth Assurances
Flow 1 with 4 Mbps assured + 3 Mbps best effort
Flow 2 with 3 Mbps best effort
Shivkumar KalyanaramanRensselaer Polytechnic Institute
112
QoS: an application-level approach
sophisticated services in application• architecturally “above” network core• open services: let 1000 flowers bloom
simple, fast, diffserv network
Shivkumar KalyanaramanRensselaer Polytechnic Institute
113
QoS: an application-level approach
Application-level infrastructure• accommodate network-level service• additional tailoring of user services
Shivkumar KalyanaramanRensselaer Polytechnic Institute
114
BrowsersBrowsers
Web ServersWeb Servers
RoutersRouters
NetworksNetworks
Content Delivery Motivation: congestion
Shivkumar KalyanaramanRensselaer Polytechnic Institute
115
• Reduces load on server• Avoids network congestion
BrowsersBrowsers
Web ServerWeb Server
ReplicatedReplicatedcontentcontent
RouterRouter Content SourceContent SourceContent SinkContent Sink
Content Delivery: idea
Shivkumar KalyanaramanRensselaer Polytechnic Institute
116
Request Routing(RR)
Distribution System
Surrogate
Client
Origin
CDN: Architectural Layout
Publisher informs RR of Content Availability. Content Pushed to Distribution System. Client Requests Content, Requested redirected to RR. RR finds the most suitable Surrogate Surrogate services client request.
1
2
3
4
5
6
Shivkumar KalyanaramanRensselaer Polytechnic Institute
117
Summary
QoS big picture, building blocks Integrated services: RSVP, 2 services, scheduling,
admission control etc Diff-serv: edge-routers, core routers; DS byte
marking and PHBs Real-time transport/middleware: RTP, H.323 New problems: inter-domain QoS, Application-level
QoS, Content delivery/web caching