Multimedia networking

MULTIMEDIA NETWORKING
Presenters
1. NANKYA MARIAM

2013/HD05/496U

2. ASINGIRWE BARBARA KABWIGA

2013/HD05/475U

3. KYOMUHENDO SAMANTHA

2013/HD05/488U

4. THEMBO JIMMY

2013/HD05/467U

OVERVIEW
Introduction
Multimedia Networking Applications
Streaming Stored Video
Voice-Over-IP
Protocols for real-time Conversational Applications
Network Support for Multimedia


2

INTRODUCTION
Multimedia-Technology that enables humans to use computers
capable of processing textual data, audio and video, still pictures, and
animation.
Today, people not only use the internet to watch movies but also to
upload videos ( YouTube), make internet calls (Skype and Google
talk).
By the end of the decade and with emerging technologies like 4G
and Wi-Fi access, Internet will not only provide phone service for
less money, but will also provide numerous value-added services,
such as video conferencing, online directory services, and voice
messaging

3

Multimedia Networking Applications
Multimedia network application is any network application that
employs audio or video.
To Understand Internet Multimedia applications, first we look at the
characteristics (Properties) of video & audio.
Properties of Video
 Video has high bit rate (100Kbps for low-quality video conferencing to 3Mps
HD Movies)
 Video can be compressed, Compression can be used to create different
versions of a video with each having different video quality so users can
choose whichever version they can watch according to their available
bandwidth.

4

Properties of Audio
Basic encoding technique of converting analog audio into digital audio is called pulse
code modulation (PCM)
Examples of Sampling Rates
 Speech encoding (uses PCM) ;8000 samples per second and 8 bits per sample
 Audio compact disk (also uses PCM) ; 44,100 samples per second and 16 bits per
sample
PCM encoded speech not commonly used on the internet so compression techniques are
used to lower bit rates of audio streams
 MP3 is a compression technique and the encoders can compress rates most
commonly to 128 kbps
Note that digital audio has lower bandwidth compared to video although users are more
sensitive to audio malfunctions than video.

5

TYPES OF MULTIMEDIA NETWORK
APPLICATIONS
Multimedia applications are classified into three broad categories:
Streaming Stored Video/Audio
◦Underlying medium is prerecorded video, such as a movie or a prerecorded
user generated video (on YouTube).
◦These are stored on servers, and users send requests to the servers to view the
videos
Features of stored streaming video
 Streaming
 Interactivity
 Continuous Playout


6

Conversational Voice/Video Over IP
Real-time conversational voice over the Internet commonly known as internet
telephony (VoIP)
Video conversational systems allow users to create conferences with three or
more participants. Conversational voice and video are widely used in the Internet
today, Skype, QQ, and Google Talk
Two Important Application service requirement for CVVOIP
 Timing Considerations
Audio and video conversational applications are highly delay-sensitive
 Tolerance of Data loss
Conversational multimedia applications are loss-tolerant occasional loss only
causes occasional glitches in audio/video playback, and these losses can
often be partially or fully concealed

7

Streaming Live Audio &
Video
Similar to traditional broadcast radio and television, except that transmission
takes place over the Internet such as a live sporting event or news
Because the event is live, delay can also be an issue, although the timing
constraints are much less stringent than those for conversational voice
Delays of up to ten seconds or so from when the user chooses to view a live
transmission to when playout begins can be tolerated


8

Streaming Stored Video
For streaming video applications, prerecorded videos are placed on servers, and
users send requests to these servers to view the videos on demand.
User may watch the video from beginning to end without interruption, may stop
watching the video well before it ends, or interact with the video by pausing or
repositioning to a future or past scene
Streaming systems can be categorized as:

 UDP Streaming
 HTTP Streaming
 Adaptive HTTP Streaming


9

Cumulative data

Streaming Stored Video

1. video
recorded (e.g., 30
frames/sec)

2. video
sent
network delay
(fixed in this
example)

3. video received,
played out at client
(30 frames/sec)

time

streaming: at this time, client
playing out early part of video,
while server still sending later
part of video

10

Streaming Stored Video: Challenges




Continuous Playout constraint: once client Playout begins, playback must
match original timing
 … but network delays are variable (jitter), so will need client-side buffer
to match Playout requirements
Other challenges:
 Client interactivity: pause, fast-forward, rewind, jump through video
 Video packets may be lost, retransmitted


11

Client-side Buffering, Playout
Buffer fill level, Q(t)

Playout rate,
e.g., CBR r

Variable fill
rate, x(t)
Client application
buffer, size B

Video Server

Client

1. Initial fill of buffer until Playout begins
2. Playout begins a
3. Buffer fill level varies over time as fill rate x(t) varies and playout rate r
is constant

12

Client-side Buffering, Playout
buffer fill level, Q(t)

playout rate,
e.g., CBR r

variable fill
rate, x(t)
client application
buffer, size B

video server

Playout buffering: average fill rate (x), playout rate (r):
x < r: buffer eventually empties (causing freezing of video playout until buffer
again fills)
x > r: buffer will not empty, provided initial playout delay is large enough to absorb
variability in x(t)
 Initial playout delay tradeoff: buffer starvation less likely with larger delay, but
larger delay until user begins watching

13

Advantages of client-Side Buffering
Client side buffering can absorb variations in server-to-client delays;
particular piece of video data is delayed, as long as it arrives before the
reserve of received-but-not yet played video is exhausted, this long delay
will not be noticed.
If the server-to-client bandwidth briefly drops below the video
consumption rate, a user can continue to enjoy continuous playback, as
long as the client application buffer does not become completely drained.


14

UDP Streaming
UDP streaming, ..Server transmits video at a rate that matches the client’s video
consumption rate by clocking out the video chunks over UDP at a steady rate.
Drawbacks of UDP Streaming
Its unpredictable and varying amount of available bandwidth between server and
client, constant-rate UDP streaming can fail to provide continuous playout
It requires a media control server, such as an RTSP server, to process client-toserver interactivity requests and to track client state
 Third drawback is that many firewalls are configured to block UDP traffic,
preventing the users behind these firewalls from receiving UDP video


15

Streaming Multimedia: HTTP
Multimedia file retrieved via HTTP GET
Send at maximum possible rate under TCP
variable rate,
x(t)
Video
file

TCP send buffer

TCP receive
buffer

Server

Application playout
buffer

Client

Fill rate fluctuates due to TCP congestion control, retransmissions (in-order
delivery)
Larger playout delay: smooth TCP delivery rate
HTTP/TCP passes more easily through firewalls and NATS

16

Streaming Multimedia: DASH
DASH: Dynamic, Adaptive Streaming over HTTP
Server:
 Divides video file into multiple chunks
 Each chunk stored, encoded at different rates
 Manifest file: provides URLs for different chunks
Client:
 Periodically measures server-to-client bandwidth
 Consulting manifest, requests one chunk at a time
◦Chooses maximum coding rate sustainable given current bandwidth
◦Can choose different coding rates at different points in time (depending on
available bandwidth at time)

17

DASH Cont.……………
DASH: Dynamic, Adaptive Streaming over HTTP
“intelligence” at client: client determines
◦When to request chunk (so that buffer starvation, or overflow does
not occur)
◦What encoding rate to request (higher quality when more bandwidth
available)
◦Where to request chunk (can request from URL server that is “close”
to client or has high available bandwidth)


18

Content Distribution Networks (CDN)
Challenge: How to stream content (selected from millions of videos) to hundreds
of thousands of simultaneous and distributed users?
Option 1: Build single, large “Mega-Server”
Drawbacks
◦Single point of failure
◦Point of network congestion
◦Long path to distant clients
◦Multiple copies of video sent over outgoing link
This solution: Use of Content Distribution Networks (CDNs)


18

Content Distribution Networks
Challenge: How to stream content (selected from millions of videos) to hundreds of
thousands of simultaneous users?
Option 2: Store/Serve multiple copies of videos at multiple geographically
distributed sites (CDN)
Enter deep: Push CDN servers deep into many access networks
◦Close to users
◦Used by Akamai, 1700 locations
Bring home: smaller number (10’s) of larger clusters in POPs near (but not within)
access networks
◦Used by Limelight


20

CDN Cont.……………
CDN manages servers in multiple geographically distributed
locations.
Stores copies of the videos (and other types of Web content,
documents, images, and audio).
 Direct each user request to a CDN location that will provide
the best user experience.


21

CDN: Simple Operation
Bob (client) requests video http://netcinema.com/6Y7B23V
Video stored in CDN at http://KingCDN.com/NetC6y&B23V
1. Bob gets URL for for video
http://netcinema.com/6Y7B23V
from netcinema.com
web page
2

1
6. request video from
KINGCDN server,
streamed via HTTP

netcinema.com

netcinema’s
authorative DNS

2. resolve http://netcinema.com/6Y7B23V
via Bob’s local DNS
5

3. netcinema’s DNS returns URL
http://KingCDN.com/NetC6y&B23V
3

4

4&5. Resolve
http://KingCDN.com/NetC6y&B23
via KingCDN’s authoritative DNS,
which returns IP address of KIingCDN
server with video

KingCDN
authoritative DNS

KingCDN.com

CDN Cluster Selection Strategy
Challenge: how does CDN DNS select “good” CDN node to stream to client
◦Pick CDN node geographically closest to client
◦Pick CDN node with shortest delay (or min # hops) to client (CDN nodes
periodically ping access ISPs, reporting results to CDN DNS)
◦IP anycast
Alternative: Let client decide - give client a list of several CDN servers
◦Client pings servers, picks “best”
◦Netflix approach


23

Case study: Netflix
30% downstream US traffic in 2011
owns very little infrastructure, uses 3rd party services:
 own registration, payment servers
 Amazon (3rd party) cloud services:
◦Netflix uploads studio master to Amazon cloud
◦create multiple version of movie (different endodings) in cloud
◦Upload versions from cloud to CDNs
◦Cloud hosts Netflix web pages for user browsing
 Three 3rd party CDNs host/stream Netflix content: Akamai, Limelight, Level-3


24

Case Study: Netflix
upload copies of multiple
versions of video to CDNs

Amazon cloud

Netflix registration,
accounting servers
2. Bob browses
Netflix video

2

3. Manifest file
returned for
requested video

Akamai CDN

Limelight CDN

3

1
1. Bob manages
account

Netflix
4. DASH streaming


Level-3 CDN

25

Voice-Over-IP
Involves taking analog audio signals and converting them into digital data
which can be transmitted over the Internet.
 Voice telephony over the internet
Example: the sender generates bytes at a rate of 8,000 bytes per second; every
20 msecs the sender gathers these bytes into a chunk. A chunk and a special
header are encapsulated in a UDP segment.
 UDP segment is sent every 20 msecs.
When each packet manages to get to the receiver with a continuous end-to-end
delay, then packets arrive at the receiver occasionally every 20 msecs.
 Receiver plays back each chunk as it is received
Problem: some packets get lost and don’t have the same end-to-end delay

26

LIMITATIONS OF VoIP: PACKET LOSS
The UDP segment is encapsulated in an IP datagram.
While datagram moves through network, it goes through router buffers as it
waits for transmission on outbound links.
 Problem: One or more of the buffers in the path from sender to receiver may
be full therefore arriving IP datagram may be discarded (not arrive to receiver)
This loss can be removed by using TCP rather than UDP
 Problem: This retransmission increases end-to-end delay
 Upside: Loss of packets between 1 and 20 can be tolerated depending on how
loss is obscured at receiver and voice encoding


27

END-TO-END DELAY
Accumulation of transmission, processing, and queuing delays in routers;
propagation delays in links; and end-system processing delays.
For real-time conversational applications, end-to-end delays;
 Under 150 msecs are not known to a human listener (good)
 Between 150 and 400 msecs can be acceptable though not good (bad)
 Above 400 msecs can be problematic in voice conversations. (really bad)
Packets delayed for a very long time may be effectively lost by receiver


28

PACKET JITTER
During end-to-end delays there are varying queuing delays that a packet faces in the network’s
routers. As a result of these delays, the time between sending and receiving a packet can fluctuate
from packet to packet which is referred to as packet jitter.
Difference between the two consecutive packets may be more or less than 20msec
Once jitters are ignored by receivers and chunks are played out as they come, then the audio
quality can become meaningless to the receiver.
 Upside: jitters can be removed by using sequence numbers, timestamps, and a playout delay


29

REMOVING JITTERS: FIXED PLAYOUT
DELAY
Receiver attempts to play out each chunk exactly q msecs after the chunk is
generated.
Chunk is timestamped at the sender at time t
Receiver plays out the chunk at time t + q, if chunk has arrived by stipulated
time.
Packets that arrive late are lost.
Variation of q
 Large q: less packet loss
 Small q: Better conversational experience
 q much smaller than 400msec: high packet loss

30

ADAPTIVE PLAYOUT DELAY
With large initial playout delays, most packets will make their deadlines hence there will be
slight loss;
 Problem: in conversational services such as VoIP, long delays may become annoying and
intolerable so playout delay should be minimized so as to decrease the loss percentage.
So as to address the above problem, there should be an estimate of the network delay and
the variance of the network delay.
Sender’s silent periods should be condensed and elongated
So as to estimate the network delay; the algorithm below is used by the receiver
di = (1 – u) di–1 + u (ri – ti)
Average
network delay
after ith packet

fixed
constant, e.g.
0.1

time received time sent
(timestamp)
end-to-end delay of ith packet

31

RECOVERING FROM PACKET LOSS
Retransmitting lost packets may not be practical in a real-time conversational application such as VoIP and
may not easily be accomplished on time for the conversation to remain understandable.
VoIP applications use forward error correction (FEC) and interleaving to anticipate loss.
FEC
 Add redundant information to original packet stream which is used to reconstruct exact or approximate
version of lost packet.
Simple FEC
 when a group on n chunks are sent, add redundant encoded chunk by exclusive OR-ing the n original
chunks
If a packet from a group of n + 1 packets is lost, the receiver is able reconstruct the lost packet.
 Problem: If two or more packets in a group are lost, the receiver cannot reconstruct the lost packets.
Transmission rate will be increased by a factor of 1/n if n + 1 group size is small.
Play out delay increased because receiver has to wait for the whole group of packets to begin play out

32

Another mechanism under FEC
 send a lower-resolution audio stream as the redundant information.
For example
 Stream PCM encoding at 64 kbps (nominal stream) with low resolution audio, a GSM
encoding at 13kbps)
sender creates the nth packet when it takes nth chunk from the nominal stream and appends it to
the (n – 1)st redundant chunk (low bit rate)
Receiver conceals loss by playing out low bit rate chunk if nonconsecutive packet loss occurs.
Low bit rate chunks give less quality than nominal chunks.


33

Interleaving
Before transmission, sender breaks down the audio parts and separates packets by a certain
distance in stream.
 This lowers the effects of packet loss because loss of packet results in smaller gaps in the
reconstructed stream compared to if the gaps is large
Error concealment
 Produce replacement for lost packet that is similar to the original
 Works because audio signals are usually almost the same in short term.
 Works for small loss rates (less than 15 percent) and for small packets (4–40 msecs).
Packet repetition can also be used for recovery from packet loss where lost packets are replaced
with copies that arrive immediately before loss.


34

VoIP APPLICATION: SKYPE
It’s a proprietary application
 control and media packets are encrypted

Sends audio and video packets over UDP but control packets are sent over TCP as well as
media packets once UDP streams are blocked by firewalls.
Uses FEC for packet loss recovery (voice and video streams) sent over UDP.
Uses P2P where peers communicate with each other in real time.
 Important for also determining user location

Peers are organized into a hierarchical overlay network (super peer or an ordinary peer).
Keeps an index that maps Skype usernames to current IP addresses (and port numbers)
 Index is distributed over the super peers.


35

PROTOCOLS
There are some protocols that are used to support real time traffic over the
internet. The following named protocols will be discussed:
RTP (Real Time Protocol)
RTCP (Real Time Control Protocol)
SIP (Session Initiation protocol)
RTSP (Real Time Streaming Protocol)

36

RTP
This protocol is used for real time data transport, in this case video and audio.
It specifies a standard packet format for delivering audio and video over IP
networks.
The Audio-Video Transport Working Group of the
Internet Engineering Task Force (IETF) developed RTP and was first published
in 1996 as RFC 1889 but this was later superseded by RFC 3550 in 2003.


37

RTP PROTOCOL COMPONENTS
The following information is needed to send streaming data:
 Timestamps (for synchronization),
 Sequence numbers (for packet loss and reordering detection)
 The payload format which indicates the encoded format of the data.
 Frame Indication (this marks the beginning and end of each frame).
 Source identification (identifies the originator of the frame)


38

RTP runs on UDP Cont’d


39

RTP Header Fields (Optional)


40

RTP – Time Stamp, Sequence Number and
Source Identifier
Sequence number field.
 The sequence number field is 16 bits long. The sequence number increments
by one for each RTP packet sent, and may be used by the
Timestamp field.
 The timestamp field is 32 bits long. It reflects the sampling instant of the first
byte in the RTP data packet.
 Timestamp clock rate for video is 90,000 Hz and the timestamp clock rate for
audio 8000 Hz.
 Synchronization source identifier (SSRC).
 The SSRC field is 32 bits long. It identifies the source of the RTP stream.
Typically, each stream in an RTP session has a distinct SSRC.


41

Why RTP can not use TCP
TCP forces the receiver application to wait for retransmission(s) in case of
packet loss, which causes large delays.
TCP cannot support multicast.
 TCP headers are larger than a UDP header (40 bytes for TCP compared to 8
bytes for UDP).
TCP doesn’t contain the necessary timestamp and encoding information needed
by the receiving application.


42

RTCP – Real Time Control Protocol
RTP is a protocol that provides basic transport layer for real time applications but does
not provide any mechanism for error and flow control, congestion control, quality
feedback and synchronization. For that purpose the RTCP is added as a companion to
RTP to provide end-to-end monitoring and data delivery, and QoS.
RTCP is responsible for three main functions:
 Feedback on performance of the application and the network
 Correlation and synchronization of different media streams generated by the same sender (e.g.
combined audio and video)
 The way to convey the identity of sender for display on a user interface

43

RTCP Components
 Quality of

service (QoS)

 Feedback: Includes the numbers of lost packets, round-trip time, and jitter, so
that the sources can adjust their data rates accordingly;
Session control: uses the RTCP BYE packet to allow participants to indicate
that they are leaving a session;
Identification, which includes a participant's name, e-mail address, and
telephone number for the information of other participants; I
Intermedia synchronization, which enables the synchronization of separately
transmitted audio and video streams.


44

SIP – Session Initiation Protocol
SIP is a text-based transaction protocol similar to HTTP. It uses commands
(called methods) and responses.
This lightweight protocol provides mechanisms that make it possible to make
calls over an IP network.
Peer-to-peer application protocol transported via UDP or TCP
Designed to establish, modify and terminate stateful multimedia
communication sessions/conferences/instant messaging …)


45

SIP Commands
SIP Responses


46

Setting up a call to a known IP Address


47

SIP Cont’d
User Agent
 User agent client (end-device, calling party)
 User agent server (end-device, called party)
SIP Proxy Server
 An intermediary entity that acts as both a server and a client for the purpose of
making requests on behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a request is sent to another
entity "closer" to the targeted user.
SIP Registrar
 Maintains user’s whereabouts in location database (location service). It is a
server that accepts REGISTER requests and places the information it receives
in those requests into the location service for the domain it handles.

48

RTSP – Real Time Streaming Protocol
This is protocol is used to enhance control in streaming media servers in the
entertainment and communications industry.
It provides “network remote control”.
RTSP messages are sent out of band over port 544
Works with unicast and multicast
RTSP doesn’t mandate encapsulation. Can be proprietary over UDP or TCP, or
RTP (preferred)
Clients of media servers issue VCR-like commands, such as play and pause, to
facilitate real-time control of playback of media files from the server.


49

RTSP – Cont’d


50

Network Support for Multimedia
Observed how application-level mechanisms are used by multimedia
applications to improve multimedia performance.
Also learned how content distribution networks and P2P overlay networks
provide a system-level approach for delivering multimedia content.
Such techniques and approaches are all designed to be used in today’s besteffort Internet.
Internet provides only a single, best-effort class of service.


51

Network Support for Multimedia
There are three approaches
 Making the best of best-effort service.
 Differentiated service.
 Per-connection Quality-of-Service (QoS) Guarantees.


52

Dimensioning Best-Effort Networks
Approaches to improving the quality of networked multimedia
Provide enough link capacity throughout the network
 Such that network congestion, and its consequent packet delay and loss never occur
 No queuing delay or loss.

Drawbacks:
 Bandwidth Provisioning.
o How much capacity to provide at network links

 Network Dimensioning
o How to design a network topology


53

Providing Enough Capacity
Issues to be addressed in order to predict application-level performance between two
network end points;
 Models of traffic demand between network end points.
 Well-defined performance requirements.
 Models to predict end-to-end performance for a given workload model, and
techniques to find a minimal cost bandwidth allocation that will result in all user
requirements being met.


54

Providing Multiple Classes of Service
Simplest development to the one-size-fits-all best-effort service model is;
 To divide traffic into classes,
 Provide different levels of service to these different classes of traffic.

motivating scenarios.
H1

H2

H3

R1

R1 output
interface
queue

R2

1.5 Mbps link


H4

55

Scenario 1: mixed HTTP and VoIP
Example: 1Mbps VoIP, HTTP share 1.5 Mbps link.
 HTTP bursts can congest router, cause audio loss
 In the best-effort Internet-transmitted in a first-in-first-out (FIFO) order
 How should we solve this potential problem?
 want to give priority to audio over HTTP
R1

R2

Insight 1: Packet marking allows a router to distinguish among packets belonging to different classes of traffic .

56

Scenario 1: Mixed HTTP and VoIP
Suppose: Router is configured to give priority to packets marked as belonging to the 1 Mbps audio
application.
What happens if the audio application starts sending packets at a rate of 1.5 Mbps or higher?
Similarly; If multiple applications (for example, multiple audio calls), were sharing the link’s bandwidth;
they too could collectively starve the FTP session.
Ideally; Need a degree of isolation among classes of traffic so that one class of traffic can be protected from
the other.

Insight 2: It is desirable to provide a degree of traffic isolation among classes so that one class is not
adversely affected by another class of traffic that misbehaves.


57

Traffic isolation Mechanisms
Traffic policing
 Policing mechanism ensures that these criteria are indeed observed.
 Policed application misbehaves-policing mechanism takes some action.
 Traffic entering the network conforms to the criteria.
Marking & Policing - network edge
1 Mbps
phone

R1

R2
1.5 Mbps link

packet marking and policing

58

Traffic isolation Mechanisms; Cont.
Link-level packet-scheduling
 Explicitly allocate a fixed amount of link bandwidth to each class
A class only uses the amount of bandwidth that has been allocated
Wastes bandwidth

1 Mbps
phone

1 Mbps logical link

R1

R2
1.5 Mbps link

0.5 Mbps logical link

Insight 3: While providing isolation among classes or flows, it is desirable to use resources (for example, link
bandwidth and buffers) as efficiently as possible.

59

Scheduling Mechanisms
Link-scheduling discipline is the manner in which queued packets are selected for transmission on the link.
First-In-First-Out (FIFO)
o Packets are send in order of arrival to queue.
 Packet-discarding policy:
 If there is not space for the arriving packets, determines whether;
o the packet will be dropped (lost) - tail drop
o other packets will be removed from the queue to make space for the arriving packet
◦ priority: drop/remove on priority basis
◦ random: drop/remove randomly
packet
arrivals

queue
(waiting area)

link
(server)


packet
departures

60

Scheduling Mechanisms: cont.
Priority Queuing
 Packets arriving at the output link are classified into priority classes at the output queue.
 Packet’s priority depends:
o Explicit marking ,destination IP address or destination port number.

 Each priority class typically has its own queue.
 Choosing a packet to transmit, from the highest priority class
 The choice among packets in the same priority class is typically done in a FIFO manner
2

high priority queue
(waiting area)

1

5

4

3

arrivals
arrivals

departures
packet in
service
classify
low priority queue
(waiting area)

link
(server)

1

4

2

3

5

departures

1

3

2

4

5
61

Scheduling Mechanisms: Cont.
Round Robin
 Packets are sorted into classes as with priority queuing.
 Round Robin scheduler alternates service among the classes.
 A work-conserving queuing discipline will never allow the link to remain idle whenever there are packets (of
any class) queued for transmission.
2
1

5

4

3

arrivals
packet in
service

1

2

3

4

5

departures

1

3

3

4

5
62

Scheduling Mechanisms: cont.


63

Policing Mechanisms -The Leaky Bucket


64

The Leaky Bucket - Implementation
Before a packet is transmitted into the network, it must first remove a token from the token
bucket.
If the token bucket is empty, the packet must wait for a token.
The maximum burst size for a leaky-bucket policed flow is b packets.
The token generation rate is r
The maximum number of packets that can enter the network of any interval of time of length t
is rt + b.


65

Diffserv
Provides service differentiation
The ability to handle different classes of traffic in different ways within the Internet in a
scalable manner.
Need for scalability arises from:
 The fact that millions of simultaneous source-destination traffic flows may be present at a
backbone router.
The Diffserv architecture consists of two sets of functional elements:
Edge functions: packet classification and traffic conditioning.
At the incoming edge of the network arriving packets are marked.
Marks packets as in-profile and out-profile

Core function: forwarding.
DS-marked packet arrives at a Diffserv MULTIMEDIA NETWORKING
capable router,

66

Diffserv Architecture
 The packet is forwarded onto its next hop according to the per-hop behavior (PHB) associated
with that packet’s class.
 Buffering and scheduling based on marking at edge.
 Preference given to in-profile packets over out-of-profile packets


67

PHB - Per-Hop Behavior
Key component of the Diffserv architecture
PHB is a description of the externally observable forwarding behavior of a Diffserv node applied to a particular Diffserv
behavior aggregate”
Important considerations embedded within:
 A PHB can result in different classes of traffic receiving different performance/behaviors
 It does not mandate any particular mechanism for achieving these behaviors.
 Differences in performance must be observable and hence measurable.
Two PHBs have been defined:
Expedited forwarding
• PHB specifies that the departure rate of a class of traffic from a router must equal or exceed a configured rate.
Assured forwarding
• Divides traffic into four classes, where each AF class is guaranteed to be provided with some minimum amount of
bandwidth and buffering.

68

Per-Connection (QoS) Guarantees

1 Mbps
phone
1 Mbps
phone

R1

R2

1.5 Mbps link


69

Per-Connection (QoS) Guarantees: Cont.
If a call is to be guaranteed a given quality of service once it begins, The Network
mechanisms and protocols needed are:
Resource reservation. Process to guarantee that a call will have the resources
(link bandwidth, buffers) needed to meet its desired QoS is to explicitly allocate
those resources to the call.
Call admission. If resources are to be reserved, then the network must have a
mechanism for calls to request and reserve resources.
Call setup signaling. The call admission process described requires that a call be
able to reserve sufficient resources at each and every network router on its sourceto-destination path to ensure that its end-to-end QoS requirement is met.


70

The End
THANK YOU FOR LISTENING


71

Multimedia networking

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Multimedia networking

Semelhante a Multimedia networking (20)

Último

Último (20)

Multimedia networking

Notas do Editor