Better-Than-Best-Effort: Qos, Intserv, Diffserv, RSVP, RTP

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute

1
Better-than-best-effort: QoS,
IntServ, DiffServ, RSVP, RTP
shivkuma@ecse.rpi.edu
http://www.ecse.rpi.edu/Homepages/shivkuma
Based in part on slides of Ion Stoica, Jim Kurose, Srini Seshan, Srini Keshav
2
Overview
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
3
Why Better-than-Best-Effort (QoS)?
To support a wider range of applications
Real-time, Multimedia, etc
To develop sustainable economic models and
new private networking services
Current flat priced models, and best-effort
services do not cut it for businesses
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
5
What is QoS?
Better performance as described by a set of
parameters or measured by a set of metrics.
Generic parameters:
Bandwidth
Delay, Delay-jitter
Packet loss rate (or loss probability)
Transport/Application-specific parameters:
Timeouts
Percentage of important packets lost
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
7
Fundamental Problems
B
Scheduling Discipline
FIFO
B
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
8
Fundamental Problems
Conservation Law
(Kleinrock): (i)W
q
(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
9
QoS Big Picture: Control/Data Planes
Internetwork or WAN
Workstation
Router
Router
Router
Workstation
Control Plane: Signaling + Admission Control or
SLA (Contracting) + Provisioning/Traffic Engineering
Data Plane: Traffic conditioning (shaping, policing, marking
etc) + Traffic Classification + Scheduling, Buffer management
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)
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)
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 applications
Assume 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
13
QOS SPECIFICATION,
TRAFFIC, SERVICE
CHARACTERIZATION,
BASIC MECHANISMS
14
Service Specification
Loss: probability that a flows packet is lost
Delay: time it takes a packets 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
15
Hard Real Time: Guaranteed
Services
Service contract
Network 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 support
Admission control based on worst-case
analysis
Per flow classification/scheduling at routers
16
Soft Real Time: Controlled Load
Service
Service contract:
Network to client: similar performance as an
unloaded best-effort network
Client to network: the session does not send
more than it specifies
Algorithm Support
Admission control based on measurement of
aggregates
Scheduling for aggregate possible
17
Traffic and Service Characterization
To quantify a service one has two know
Flows traffic arrival
Service provided by the router, i.e., resources
reserved at each router
Examples:
Traffic characterization: token bucket
Service provided by router: fix rate and fix
buffer space
Characterized by a service model (service
curve framework)
18
Token Bucket
Characterized by three parameters (b, r, R)
b token depth
r average arrival rate
R maximum arrival rate (e.g., R link capacity)
A bit is transmitted only when there is an available token
When a bit is transmitted exactly one token is
consumed
r tokens per second
b tokens
<= R bps
regulator
time
bits
b*R/(R-r)
slope R
slope r
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
20
Example
Arrival curve maximum amount of bits transmitted by
time t
Use token bucket to bound the arrival curve
size of time
interval
bits
Arrival 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)
21
Per-hop Reservation
Given b,r,R and per-hop delay d
Allocate bandwidth r
a
and buffer space B
a
such that to
guarantee d
bits
b
slope r
Arrival curve
d
B
a
slope r
a
22
What is a Service Model?
external process
Network element
offered traffic
delivered traffic
(connection oriented)
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.
23
Arrival and Departure Process
Network Element
R
in
R
out
R
in
(t) = arrival process
= amount of data arriving up to time t
R
out
(t) = departure process
= amount of data departing up to time t
bits
t
delay
buffer
24
Traffic Envelope (Arrival Curve)
slope = max average rate
b(t) = Envelope
slope = peak rate
t
Burstiness Constraint
Maximum amount of service that a flow can send
during an interval of time t
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)
26
Big Picture
t
t
slope = C
t
R
in
(t)
Service curve
bits
bits
bits
R
out
(t)
27
t
S(t) = service curve
E(t) = Envelope
Maximum delay
Maximum buffer
bits
Delay and Buffer Bounds
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
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
$$$$$$
$$$
$
30
Mechanisms: Buffer Mgmt/Priority Drop
Ideas: packet marking, queue thresholds,
differential dropping, buffer assignments
Drop RED and BLUE packets
Drop only BLUE packets
31
SCHEDULING
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
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
34
Scheduling Policies (more)
Round Robin: scan class queues serving one
from each class that has a non-empty queue
35
Round-Robin Discussion
Advantages: protection among flows
Misbehaving flows will not affect the performance
of well-behaving flows
Misbehaving 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
36
Generalized Processor Sharing(GPS)
Assume a fluid model of traffic
Visit each non-empty queue in turn (RR)
Serve infinitesimal from each
Leads to max-min fairness
GPS is un-implementable!
We cannot serve infinitesimals, only packets
37
Generalized Processor Sharing
) (
) , ( ) , (
) (
t B i
w
dt t t W
w
dt t t W
t B j
j i
i

+
=
+

A work conserving GPS is defined as
where
w
i
weight of flow i
W
i
(t
1
, t
2
) total service received by flow i during [t
1
, t
2
)
W(t
1
, t
2
) total service allocated to all flows during [t
1
, t
2
)
B(t) number of flows backlogged
38
Fair Rate Computation in GPS
Associate a weight w
i
with each flow i
If link congested, compute f such that
C w f r
i
i
i
=
) , max(
8
6
2
4
4
2
f = 2:
min(8, 2*3) = 6
min(6, 2*1) = 2
min(2, 2*1) = 2
10
(w
1
= 3)
(w
2
= 1)
(w
3
= 1)
39
Bit-by-bit Round Robin
Single flow: clock ticks when a bit is transmitted.
For packet i:
P
i
= length, A
i
= arrival time, S
i
= begin
transmit time, F
i
= finish transmit time
F
i
= S
i
+P
i
= max (F
i-1
, A
i
) + P
i
Multiple flows: clock ticks when a bit from all
active flows is transmitted round number
Can calculate F
i
for each packet if number of
flows is known at all times
This can be complicated
40
Packet Approximation of Fluid
System
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
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 F
i
at any given time
Variation: Weighted Fair Queuing (WFQ)
42
Approximating GPS with WFQ
Fluid GPS system service order
0 2 4 6 10 8
Weighted Fair Queueing
select the first packet that finishes in GPS
43
FQ Example
F=10
Flow 1
(arriving)
Flow 2
transmitting
Output
F=2
F=5
F=8
Flow 1 Flow 2
Output
F=10
Cannot preempt packet
currently being transmitted
44
FQ Advantages
FQ protect well-behaved flows from ill-behaved flows
Example: 1 UDP (10 Mbps) and 31 TCPs 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 31
Flow Number
T
h
r
o
u
g
h
p
u
t
(
M
b
p
s
)
RED
0
1
2
3
4
5
6
7
8
9
10
1 4 7 10 13 16 19 22 25 28 31
Flow Number
T
h
r
o
u
g
h
p
u
t
(
M
b
p
s
)
45
System Virtual Time: V(t)
Measure service, instead of time
V(t) slope rate at which every active flow receives service
C link capacity
N(t) number of active flows in fluid system at time t
1 2
3
1 2
4
3 4
5
5 6
Service
in fluid flow
system
time
time
V(t)
) (
) (
t N
C
t
t V
=
46
System Virtual Time
Virtual time (V
GPS
) service that backlogged
flow with weight = 1 would receive in GPS
) (
) , (
) , (
) (
t B i
w
dt t t W
w dt t t W
t B j
j
i i

+
= +

t
W
w t
V
t B j
j
GPS
) (
1
) (
) (
t B i
t
W
w
w
t
W
t B j
j
i i

) (
1
) , (
2
1
) (
2 1
t B i dt
t
W
w
w t t W
t
t t
t B j
j
i i

47
Service Allocation in GPS
The service received by flow i during an interval
[t
1
,t
2
), while it is backlogged is
) ( ) , (
2
1
2 1
t B i dt
t
V
w t t W
t
t t
GPS
i i

=
) ( )) ( ) ( ( ) , (
1 2 2 1
t B i t V t V w t t W
GPS GPS i i
=
48
Virtual Time Implementation of
w
j
k
j
j j
L
S F + =
0 ) 0 ( =
V
GPS
)) ( , max(
k
j j j
a V F S =
if session j backlogged
if session j un-backlogged
k
j
k
j
F S =
a
j
k
arrival time of packet k of flow j
S
j
k
virtual starting time of packet k of flow j
F
j
k
virtual finishing time of packet k of flow j
L
j
k
length of packet k of flow j
49
Virtual Time Implementation of
Need to keep per flow instead of per packet
virtual start, finish time only
System virtual time is used to reset a flows
virtual start time when a flow becomes
backlogged again after being idle
50
System Virtual Time in GPS
0 4 12 8 16
1/2
1/8
1/8
1/8
1/8
) (t V
GPS
2*C
C
2*C
51
Virtual Start and Finish Times
0 4 12 8 16
k
i
F
k
i
S
i
k
i
k
i
k
i
w
L
S F + =
) (t V
GPS
Utilize the time the packets would start S
i
k
and
finish F
i
k
in a fluid system
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 control
end-host congestion control to adapt
router congestion control to protect/isolate
Dont forget buffer management: you still need to
drop in case of congestion. Which packets would
you drop in FQ?
one possibility: packet from the longest queue
53
QoS ARCHITECTURES
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 [t
1
, t
2
] <= g(t
2
- t
1
) +
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
k r P g P g delay end to end
55
Significance
P-G Theorem shows that WFQ scheduling can
provide end-to-end delay bounds in a network of
multiplexed bottlenecks
WFQ provides both bandwidth and delay
guarantees
Bound 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
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 utilization
fine grained differentiation
protection
much less scalable and robust
57
Existing Solutions
DecBit [Ramkrishnan &
Jain 88]
Random Early Detection
(RED) [Floyd & Jacobson
93]
BLUE [Feng et al 99]
REM [Low at al 00]
Round Robin [Nagle
85]
Fair Queueing
[Demers et al 89]
Flow Random Early
Drop (FRED) [Lin &
Morris 97]
Network
support for
congestion
control
DiffServ
- [Clark &
Wroclawski 97]
- [Nichols et al 97]
Tenet [Ferrari &
Verma 89]
IntServ [Clark et al
91]
ATM [late 80s]
QoS
Stateless Stateful
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
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
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).
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
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.
63
Stateful Solution: Guaranteed
Services
Achieve per-flow bandwidth and delay guarantees
Example: guarantee 1MBps and < 100 ms delay to a flow
Sender
Receiver
64
Services
Allocate resources - perform per-flow admission
control
Sender
Receiver
65
Services
Install per-flow state
Sender
Receiver
66
Challenge: maintain per-flow state consistent
Services
Sender
Receiver
67
Services
Per-flow classification
Sender
Receiver
68
Services
Per-flow buffer management
Sender
Receiver
69
Services
Per-flow scheduling
Sender
Receiver
70
Stateful Solution Complexity
Classifier
Buffer
management
Scheduler
flow 1
flow 2
flow n
Per-flow State
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
output interface
71
Stateless vs. Stateful
Stateless solutions are more
scalable
robust
Stateful solutions provide more powerful and
flexible services
guaranteed services + high resource utilization
fine grained differentiation
protection
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
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
74
Differentiated Services Model
Ingress
Edge Router
Egress
Edge Router
Interior Router
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
75
Diffserv Architecture
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
Edge router:
- per-flow traffic
management
- marks packets as in-
profile and out-profile
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
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
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 length
Class A packets leave first before packets from
class B
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
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
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 nodes
edge nodes
82
The DPS Approach
1. 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
83
The DPS Idea
Instead of having core routers maintaining per-
flow state have packets carry per-flow state
SCORE Network
84
Dynamic Packet State (DPS)
Ingress node: compute and insert flow state
in packets header
85
Ingress node: compute and insert flow state
in packets header
86
Core node:
process packet based on state it carries
and nodes state
update both packet and nodes state
87
Egress node: remove state from packets
header
88
Example: DPS-Guaranteed Services
r r r
flow
(reservation = r )
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
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
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
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)
SCORE Network
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
Jitter-VC
CJVC
CJVC
CJVC
CJVC
CJVC
CJVC
91
End-to-end Adaptive Applications
Internet
End-to-end
Closed-loop control
Congestion control
Packetization,
Marking, playout
Buffer Management
Congestion control
Video Coding, Error
Concealment,
Unequal Error
Protection (UEP)
Video Coding, Error
Concealment,
Unequal Error
Protection (UEP)
Packetization,
Marking, Source
Buffer Management
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
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
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
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:
Decompression
Jitter removal
Error correction: use redundant packets to be
used for reconstruction of original stream
GUI for user control
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
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
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.
99
H.323 Architecture
100
Inter-domain QoS: Challenge
Provide high quality service across ISPs
Problem: intermediate ISPs dont have
incentive to provide good service
e.g., hot-potato policy
ISP 1
ISP 2
ISP 3
?
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)
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
E
I
E
Logical FIFO
B
Closed-loop building blocks:
No core upgrades, smaller QoS service spectrum
103
Closed-Loop Building Blocks for QoS
International Link
or
International Link
or
104
Edge-based QoS building blocks
New: Closed-loop control !
I
E
I
E
Logical FIFO
B
Policy/
Bandwidth Broker
I
E
105
Closed-loop QoS Building Blocks
Priority/WFQ
B
FIFO
Loops: differentiate service on an RTT-by-RTT basis

using purely edge-based policy configuration.
B
Scheduler: differentiates service on a packet-by-
packet basis
106
Recall: Accumulation-based CC Schemes!
1 j j+1 J
ij

i,j+1
d
j
f
i
i

106
time
) (
1
f
i i
d t q
) (
1
J
j k
k ij
d t q
) (t q
iJ
1 j j+1 J
j
d
1 J
d
) , ( t d t I
f
i i

) (t a
i
) ( t t a
i
+
) , ( t t O
i

f
i
d
t
107
Recall: Accumulation-based CC Schemes!
1 j j+1 J
ij

i,j+1
d
j
f
i
i

107
time
) (
1
f
i i
d t q
) (
1
J
j k
k ij
d t q
) (t q
iJ
1 j j+1 J
j
d
1 J
d
) , ( t d t
f
i

) (t a
i
( t t a
i
+
) , ( t t O
i

f
i
d
t
I
i
)
108
1 j j+1 J
ij

i,j+1
d
j
f
i
i
0 ) ( > =
i i
t a
108
control objective : keep
if , no way to probe increase of available
bandwidth;
0 ) ( = t a
i
t t t t d t t t a rec
then t a if
then t a if
i
f
i i i
i i i
i i i
=
>
<
)] , ( ) , ( [ ) , ( :
) (
) (

control algorithm :
Recall: Accln-based Control Policy
109
Recall: Monaco CC Scheme
congestion estimation:
out-of-band and in-band control packets
congestion response:
if q
m
< , cwnd(k+1) = cwnd(k) + 1;
if q
m
> , cwnd(k+1) = cwnd(k) 1; [ 1 = < = 3 ]
109
110
Closed-Loop Service Differentiation:
Loss-based or Accumulation-based ?
110
111
Closed-Loop QoS: Bandwidth
Assurances
Flow 1 with 4 Mbps assured
+ 3 Mbps best effort
Flow 2 with 3 Mbps best effort
112
QoS: an application-level approach
sophisticated services in application
architecturally above network core
open services: let 1000 flowers bloom
simple, fast, diffserv network
113
QoS: an application-level approach
Application-level infrastructure
accommodate network-level service
additional tailoring of user services
114
Content Delivery Motivation: congestion
Browsers Browsers
Web Servers Web Servers
Routers Routers
Networks Networks
115
Content Delivery: idea
Reduces load on server
Avoids network congestion
Browsers Browsers
Web Server Web Server
Replicated Replicated
content content
Router Router
Content Source Content Source
Content Sink Content Sink
116
CDN: Architectural Layout
Request
Routing(RR)
Distribution
System
1
2
3
4
5
6
Client
Origin
Surrogate
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.
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

Better-Than-Best-Effort: Qos, Intserv, Diffserv, RSVP, RTP

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Better-Than-Best-Effort: Qos, Intserv, Diffserv, RSVP, RTP

Hochgeladen von

Copyright:

Verfügbare Formate

Shivkumar Kalyanaraman

Rensselaer Polytechnic Institute

Loops: differentiate service on an RTT-by-RTT basis

Das könnte Ihnen auch gefallen