Transcript Chapter 6

Chapter 6
Multimedia Networking
A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers).
They’re in powerpoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
represent a lot of work on our part. In return for use, we only ask the
following:
 If you use these slides (e.g., in a class) in substantially unaltered form,
that you mention their source (after all, we’d like people to use our book!)
 If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and
note our copyright of this material.
Thanks and enjoy! JFK / KWR
Modified by Lindsay Wishnick, Sarah Biggs, and Marga Koburger
Computer Networking: A
Top Down Approach
Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2002.
All material copyright 1996-2002
J.F Kurose and K.W. Ross, All Rights Reserved
1
Chapter 6 outline
 6.1 Multimedia Networking
Applications
 6.2 Streaming stored audio
and video
 RTSP
 6.3 Real-time, Interactive
Multimedia: Internet Phone
Case Study
 6.4 Protocols for Real-Time
Interactive Applications
 RTP,RTCP
 SIP
 6.5 Beyond Best Effort
 6.6 Scheduling and
Policing Mechanisms
 6.7 Integrated Services
 6.8 RSVP
 6.9 Differentiated
Services
2
IETF Integrated Services (Intserv)
 Specific architecture for providing QoS guarantees in
the internet for individual application sessions
 Two key features:
 Resource reservation: routers maintain state info
(a la Virtual Circuit) of allocated resources, QoS
requirements
 Call Setup: Admit/deny new call setup requests
3
Call Admission (Call Setup)
Router must determine whether or not its resources are
sufficient to meet the QoS requirements.
3 Step Process:
1. Arriving session must determine its needs
2. Arriving session signals for call setup
3. Router decides whether to admit the arriving session
(Per-element admission)
4
Call Setup: Step 1
Arriving session must determine its needs
 Declare its QoS requirement
 RSpec: defines the QoS being requested
 Characterize traffic it will send into network
 TSpec: defines traffic characteristics
Rspec and Tspec are defined in RFCs 2210 and 2215
5
Call Setup: Step 2
Arriving session signals for call setup
Signaling protocol: needed to carry RSpec and TSpec to
routers (where reservation is required)
 RSVP (RFC 2210) is currently the protocol of choice
for the Internet
6
Call Setup: Step 3
Question:
Can newly arriving flow be admitted with performance
guarantees while not violating QoS guarantees made
to already admitted flows?
This is Step 3!
Answer:
The router calculates the local resources required by
the session and considers the amount of resources it
has already devoted to other sessions. The router
only accepts the new session if it can still guarantee
QoS for all sessions.
7
8
Intserv: Call Setup Process
request/
reply
9
Setup Requests
QoS call signal
Request:
Specifies traffic and
QoS needs
Reply:
Whether the router can
satisfy the request
Router considers required
resources and unreserved
resources
10
Intserv Service Classes
Guaranteed service:
 Deals with worst case traffic arrival: leaky-bucket-policed source
 There is a simple (mathematically provable) bound on delay!
[Parekh 1992, Cruz 1988] RFC 2212
Controlled-Load Network Service:
 "a quality of service closely approximating the QoS that same
flow would receive from an unloaded network element.“ – RFC
2211
 targets real-time multimedia applications that do not perform
well when a network is loaded with traffic
11
Chapter 6 outline
 6.1 Multimedia Networking
Applications
 6.2 Streaming stored audio
and video
 RTSP
 6.3 Real-time, Interactive
Multimedia: Internet Phone
Case Study
 6.4 Protocols for Real-Time
Interactive Applications
 RTP,RTCP
 SIP
 6.5 Beyond Best Effort
 6.6 Scheduling and
Policing Mechanisms
 6.7 Integrated Services
 6.8 RSVP
 6.9 Differentiated
Services
12
RSVP (Resource reSerVation
Protocol)
 RSVP is a hop-by-hop signaling protocol that allows
applications to reserve resources in the internet so they
can receive the amount of bandwidth they need
 Implemented inside IP messages
 Supports quality of service requirements
 In this context “resources” refers to link bandwidth
 RFC 2205
13
Applying RSVP
 Hosts use RSVP to request a specific amount of
bandwidth from the network on the behalf of an
application data flow
 Routers use RSVP to forward bandwidth reservation
requests
 RSVP provides reservations in multicast trees
 RSVP is receiver-oriented: the receiver of a data flow
initiates and maintains the resource reservation used for
that flow
 Being oriented towards the receiver allows
reservations from receivers with very different
characteristics
14
RSVP Characteristics
 Multicast
 Receiver-oriented: data originates from the sender, but
reservation messages come from the receivers
Data Flow
Merged
reservations
Merged
reservations
Reservation
message
15
Multiple Multicasts in RSVP
A session can consist of multiple multicast data flows
 Each sender in a session is the source of one or more
data flows (for example a video data flow and an audio
data flow)
 We assume routers and hosts identify the session to
which a packet belongs by the packet’s multicast
address
 The data flow to which a packet belongs must be
identified (i.e. through an identifier field like IPv6)
16
What RSVP is Not
 RSVP standard does not specify how networks provide
reserved bandwidth for data flows
 only a protocol for letting applications reserve link
bandwidth
 routers in the internet actually provide the reserved
bandwidth for the data flows: usually through
scheduling mechanisms from 6.6
 RSVP is not a routing protocol: it does not determine the
links where reservations are made
 underlying routing protocol determines the routes for
the flows
 once the routes are in place, RSVP can reserve
bandwidth along the route
17
Heterogeneous Receivers
Question: Consider a network in which some receivers can
receive a flow at 28.8 Kbps and others at 128 Kbps. If a
sender is multicasting a video to a to a group of such
heterogeneous receivers, should the sender encode the
video for low (28.8 Kbps) or high (128 Kbps) quality?
Answer: Video and audio are encoded in layers. For
example, a video could be encoded into a base layer at 20
Kbps and an enhancement layer at 100 Kbps. This way
receivers with 28.8 Kbps access rates can receive the
low-quality base-layer image and 128 Kbps receivers can
receive both layers to construct a high-quality image.
18
Heterogeneous Receivers
 The sender does not need to know the receiving rates of
the receivers – only the maximum rate of all the receivers
 The sender encodes the data in multiple layers and
sends all layers up to the maximum rate into the
multicast tree
 The receivers pick the layers that are appropriate for
their receiving rates
 Receivers communicate to the network the rates they
can handle to keep from wasting bandwidth
 RSVP gives foremost attention to the issue of reserving
resources for heterogeneous receivers
19
RSVP in Action!
20
More Action!
21
Reserving Bandwidth
The amount of bandwidth reserved by a router on a link
should not exceed the link’s capacity
 When a router receives a reservation message, it first
checks whether the upstream links have extra
bandwidth
 If the admission test fails, the router returns an error
message
 RSVP does not define an admission test, but it
assumes the router is performing them
 When the reservation message reaches the sender
successfully, a confirmation message is sent to the
receiver so it knows that the request is successful
22
Maintaining Reservations
 Reservations maintained with soft states in routers
 Each reservation is associated with a timer
 When the timer expires, the reservation is removed
 The receiver must periodically refresh the reservation
by sending reservation messages
 No need to break down or clean up link
 Can explicitly tear down state if wish
 Adapts easily to route and tree changes
23
Implementing RSVP
 RSVP can be implemented with other quality of service
protocols (e.g. differentiated service)
 Implemented with differentiated service, differentiated
service would mark and prioritize traffic while RSVP
secures the resources needed to transmit the traffic
 RSVP impairs performance on backbone routers
 too complex
 other protocols used on network backbone
http://www.networkmagazine.com/article/NMG20010720
S0009
24
Chapter 6 outline
 6.1 Multimedia Networking
Applications
 6.2 Streaming stored audio
and video
 RTSP
 6.3 Real-time, Interactive
Multimedia: Internet Phone
Case Study
 6.4 Protocols for Real-Time
Interactive Applications
 RTP,RTCP
 SIP
 6.5 Beyond Best Effort
 6.6 Scheduling and
Policing Mechanisms
 6.7 Integrated Services
 6.8 RSVP
 6.9 Differentiated
Services
25
IETF Differentiated Services
Difficulties associated with Intserv:
 Scalability:
 Using RSVP, need to process resource
reservations and maintain per-flow state for each
flow going through the router
 At a backbone router, this can incur potentially
significant overhead in large networks
 Flexible Service Models:
 Intserv provides for a small number of service
classes
 Service classes do not allow more qualitative or
relative definitions of service distinctions
 Relative service distinction: Platinum, Gold, Silver
26
IETF Differentiated Services
Diffserv approach:
 Scalability: simple functions placed in network core, with
relatively complex functions at “edge” routers (or hosts)
 Flexibility: Does not define specific services or service
classes, instead provides functional components with
which service classes can be built
27
Diffserv Architecture
r marking
scheduling
Edge router:
- per-flow traffic management
- marks packets as in-profile
and out-profile
b
..
.
Core router:
- per class traffic management
- buffering and scheduling
based on marking at edge
- preference given to in-profile
packets
- Assured Forwarding
28
Edge-router Packet Marking
 Profile: pre-negotiated rate A,
bucket size B
 Packet marking at edge based
on per-flow profile
Rate A
B
User packets
Possible usage of marking:
 Class-based marking: packets of different classes marked
differently
 Intra-class marking: conforming portion of flow marked
differently than non-conforming one
29
Distinguishing Packets
Question:
A differentiated services router distinguishes between
packet flows by using the packets’
 A: markings
 B: source IP address
 C: source IP address and markings
 D: none of the above
Answer:
A: markings
30
Classification and Conditioning
 Packet’s mark is in the DS field in the IPv4 or IPv6 packet
header
 6 bits used for Differentiated Service Code Point (DSCP) ,
determines per-hop behavior (PHB) that the packet will
receive
 2 bits are currently unused
31
Traffic Classification and
Conditioning
 Packets that arrive at the edge of the network are
“classified”
 Classifier selects packets based on values in packet
header fields
 Examples: source address, destination address,
source port, destination port, protocol ID
 Packet then sent through appropriate marking function
 DS field is set according to the marker
 Packets then forwarded to destination
32
Classifying Packets
Question:
In a differentiated services architecture, packets can be
classified according to their
 A: Protocol identifiers
 B: Source and destination port numbers
 C: Source and destination IP address
 D: All of the above
Answer:
D: All of the above
33
Traffic Classification and Conditioning
(more)
Sometimes, may be desirable to limit traffic injection rate
of some class:
 user declares traffic profile, in which limits are set for
peak rate and “burstiness”
 Incoming packet flow compared with negotiated profile,
packet shaped/dropped if non-conforming
34
Forwarding (Per-Hop Behaviors)
Defined as “a description of the externally observable
forwarding behavior of a Diffserv node applied to a
particular Diffserv behavior aggregate”
 Can result in different classes of traffic receiving
different performances (different observable behaviors)
 Does not specify what 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
35
Per-Hop Behavior
Question:
While a per-hop behavior defines differences in
performance among classes, it does not mandate any
particular mechanism for achieving these
performances, True or False
Answer:
True
36
Forwarding (Per-Hop Behaviors)
Per-Hop Behaviors currently being developed:
 Expedited Forwarding: Packet departure rate of a class
must equal or exceed a configured rate
 Provides a class with a minimum guaranteed rate
 Assured Forwarding: Creates 4 classes of traffic
 Each class is guaranteed a minimum amount of
bandwidth
 Each class is subdivided into three drop preference
partitions, so packets will be dropped based on their
drop preference values
37
How has QoS been implemented?
 ATM
 Very complicated Signaling and TSPEC
 TSPEC didn’t make much sense to application developers
 ATM “to the desktop” never took off
 IETF: Integrated Services Group (Intserv)
 Per flow guarantees, Token Buckets, RSVP, Scheduling
 Very expensive to implement – doesn’t scale well
 IETF: Differentiated Services Group (Diffsrv)
 No resource reservation protocol
 Coarse-grain guarantees
 Very scalable
 Of limited use
38