Multimedia Networks - 1- Introduction

7/28/2019 Multimedia Networks - 1- Introduction

1/101

Chapter 1Multimedia Networking

1: Introduction 1-1


2/101

1: Introduction 1-2

Multimedia and Quality of Service: Whatis it?

multimediaapplications: network

audio and video(continuous media)

network providesapplication with level of

performance needed forapplication to function.

QoS


3/101

1: Introduction 1-3

Chapter 1: goals

Principles

classify multimedia applications

identify network services applications need

making the best of best effort service

Protocols and Architectures

specific protocols for best-effort

mechanisms for providing QoS architectures for QoS


4/101

1: Introduction 1-4

Chapter 1 outline

1.1 multimedianetworking applications

1.2 streaming storedaudio and video

1.3 making the best outof best effort service

1.4 protocols for real-timeinteractive applications

RTP,RTCP,SIP

1.5 providing multipleclasses of service

1.6 providing QoSguarantees


5/101

1: Introduction 1-5

MM Networking Applications

Fundamentalcharacteristics:

typically delaysensitive

end-to-end delay delay jitter

loss tolerant:infrequent lossescause minor glitches

antithesis of data,which are lossintolerantbut delaytolerant.

Classes of MMapplications:

1) stored streaming

2) live streaming

3) interactive, real-time

Jitter is the variabilityof packet delays withinthe same packet stream


6/101

1: Introduction 1-6

Streaming Stored Multimedia

Stored streaming:

media stored at source transmitted to client

streaming: client playout beginsbefore all data has arrived

timing constraint for still-to-be transmitteddata: in time for playout


7/101

1: Introduction 1-7

Streaming Stored Multimedia:What is it?

1. videorecorded

2. videosent

3. video received,played out at client

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

part of video

networkdelay

time


8/101

1: Introduction 1-8

Streaming StoredMultimedia:Interactivity

VCR-like functionality: client canpause, rewind, FF, push slider bar

10 sec initial delay OK

1-2 sec until command effectOK

timing constraint for still-to-betransmitted data: in time for playout


9/101

1: Introduction 1-9

Streaming Live Multimedia

Examples:

Internet radio talk show

live sporting event

Streaming (as with streaming storedmultimedia)

playback buffer

playback can lag tens of seconds aftertransmission

still have timing constraintInteractivity

fast forward impossible

rewind, pause possible!


10/101

1: Introduction 1-10

Real-Time InteractiveMultimedia

end-end delay requirements:

audio: < 150 msec good, < 400 msec OK

includes application-level (packetization) and networkdelays

higher delays noticeable, impair interactivity

session initialization

how does callee advertise its IP address, port number,encoding algorithms?

applications: IP telephony, videoconference, distributed interactive

worlds


11/101


Multimedia Over Todays

Internet

TCP/UDP/IP:best-effort service

no guarantees on delay, loss

Todays Internet multimedia applicationsuse application-level techniques to mitigate

(as best possible) effects of delay, loss

But you said multimedia apps requiresQoS and level of performance to beeffective!

?? ??

?

?

? ??

?

?


12/101


How should the Internet evolve to bettersupport multimedia?

Integrated services philosophy: fundamental changes in

Internet so that apps canreserve end-to-endbandwidth

requires new, complex

software in hosts & routers

Laissez-faire

no major changes

more bandwidth whenneeded

content distribution,application-layer multicast

application layer

Differentiated servicesphilosophy:

fewer changes to Internetinfrastructure, yet provide1st and 2nd class service

Whats your opinion?


13/101


A few words about audiocompression

analog signal sampled atconstant rate

telephone: 8,000samples/sec

CD music: 44,100

samples/sec each sample quantized, i.e.,

rounded

e.g., 28=256 possiblequantized values

each quantized valuerepresented by bits

8 bits for 256 values

example: 8,000samples/sec, 256 quantizedvalues --> 64,000 bps

receiver converts bits backto analog signal:

some quality reduction

Example rates

CD: 1.411 Mbps

MP3: 96, 128, 160 kbps

Internet telephony: 5.3kbps and up


14/101


A few words about videocompression

video: sequence ofimages displayed atconstant rate

e.g. 24 images/sec

digital image: arrayof pixels

each pixel representedby bits

redundancy

spatial (within image)

temporal (from oneimage to next)

Examples: MPEG 1 (CD-ROM) 1.5

Mbps

MPEG2 (DVD) 3-6

Mbps MPEG4 (often used in

Internet, < 1 Mbps)

Research:

layered (scalable)video

adapt layers to availablebandwidth


15/101


Chapter 1 outline





RTP,RTCP,SIP




16/101


Streaming Stored Multimedia

application-levelstreaming techniquesfor making the best outof best effort service:

client-side buffering

use of UDP versusTCP

multiple encodingsof multimedia

jitter removal

decompression error concealment

graphical user interfacew/ controls forinteractivity

Media Player


17/101


Internet multimedia: simplestapproach

audio, video not streamed:

no, pipelining, long delays until playout!

audio or video stored in file

files transferred as HTTP object

received in entirety at client

then passed to player


18/101


Internet multimedia:streaming approach

browser GETs metafile browser launches player, passing metafile

player contacts server

server streams audio/video to player


19/101


Streaming from a streamingserver

allows for non-HTTP protocol between server, mediaplayer

UDP or TCP for step (3), more shortly


20/101


constant bitrate video

transmission

time

variable

networkdelay

client videoreception

constant bitrate video

playout at client

client

playoutdelay

buffere

d

video

Streaming Multimedia: ClientBuffering

client-side buffering, playout delaycompensate for network-added delay,

delay jitter


21/101


Streaming Multimedia: ClientBuffering

client-side buffering, playout delaycompensate for network-added delay,

delay jitter

buffered

video

variable fill

rate, x(t)

constantdrain

rate, d


22/101


23/101


Streaming Multimedia: clientrate(s)

Q: how to handle different client receive ratecapabilities?

28.8 Kbps dialup

100 Mbps Ethernet

A: server stores, transmits multiple copies ofvideo, encoded at different rates

1.5 Mbps encoding

28.8 Kbps encoding


24/101


User Control of StreamingMedia: RTSP

HTTP

does not targetmultimedia content

no commands for fast

forward, etc.

RTSP: RFC 2326

client-serverapplication layer

protocol

user control: rewind,fast forward, pause,resume, repositioning,

etc

What it doesnt do: doesnt define how

audio/video isencapsulated for

streaming overnetwork

doesnt restrict howstreamed media istransported (UDP orTCP possible)

doesnt specify howmedia player buffersaudio/video


25/101


RTSP: out of band control

FTP uses an out-of-band

control channel: file transferred over one

TCP connection.

control info (directorychanges, file deletion,

rename) sent overseparate TCP connection

out-of-band, in-bandchannels use differentport numbers

RTSP messages also sent

out-of-band: RTSP control messages

use different portnumbers than mediastream: out-of-band.

port 554

media stream isconsidered in-band.


26/101


RTSP Example

Scenario: metafile communicated to web browser

browser launches player

player sets up an RTSP control connection,data connection to streaming server


27/101


Metafile Example

Twister


28/101


RTSP Operation


29/101


RTSP Exchange ExampleC: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0

Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK

Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0Session: 4231

S: 200 3 OK


30/101


Chapter 1 outline





RTP,RTCP,SIP




31/101


Real-time interactiveapplications PC-2-PC phone

Skype

PC-2-phone

Dialpad

Net2phone

Skype

videoconference with

webcams Skype

Polycom

Going to now lookat a PC-2-PCInternet phone

example in detail


32/101


Interactive Multimedia:Internet Phone

Introduce Internet Phone by way of an example

speakers audio: alternating talk spurts, silent periods.

64 kbps during talk spurt

pkts generated only during talk spurts

20 msec chunks at 8 Kbytes/sec: 160 bytes data

application-layer header added to each chunk.

chunk+header encapsulated into UDP segment.

application sends UDP segment into socket every 20msec during talkspurt

Internet Phone: Packet Loss


33/101


Internet Phone: Packet Lossand Delay

network loss: IP datagram lost due tonetwork congestion (router bufferoverflow)

delay loss: IP datagram arrives too late

for playout at receiver delays: processing, queueing in network;

end-system (sender, receiver) delays

typical maximum tolerable delay: 400 ms

loss tolerance: depending on voiceencoding, losses concealed, packet lossrates between 1% and 10% can be

tolerated.


34/101


constant bitrate

transmission

time

variable

networkdelay(jitter)

clientreception

constant bitrate playout

at client

client

playoutdelay

buffere

d

data

Delay Jitter

consider end-to-end delays of two consecutive packets:difference can be more or less than 20 msec(transmission time difference)

Internet Phone: Fixed


35/101


Internet Phone: FixedPlayout Delay

receiver attempts to playout eachchunk exactly q msecs after chunk wasgenerated.

chunk has time stamp t: play out chunk at

t+q . chunk arrives after t+q: data arrives too

late for playout, data lost

tradeoff in choosing q:

large q: less packet loss small q: better interactive experience


36/101


Fixed Playout Delay

packets

time

packets

generated

packets

received

loss

r

p p'

playout schedule

p' - r

playout schedule

p - r

sender generates packets every 20 msec during talk spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at p


37/101


Adaptive Playout Delay (1)

packetithreceivingafterdelaynetworkaverageofestimated

acketpithfordelaynetworktr

receiveratplayedisipackettimethep

receiverbyreceivedisipackettimether

packetiththeoftimestampt

i

ii

i

i

i

dynamic estimate of average delay at receiver:)()1( 1 iiii trudud

where u is a fixed constant (e.g., u = .01).

Goal:minimize playout delay, keeping late loss rate low

Approach:adaptive playout delay adjustment: estimate network delay, adjust playout delay at beginning

of each talk spurt.

silent periods compressed and elongated.

chunks still played out every 20 msec during talk spurt.


38/101


Adaptive playout delay (2)

also useful to estimate average deviation of delay, vi:

||)1( 1 iiiii dtruvuv

estimates di , vicalculated for every received packet(but used only at start of talk spurt

for first packet in talk spurt, playout time is:iiii Kvdtp

where K is positive constant

remaining packets in talkspurt are played out periodically


39/101

R f k t l (1)


40/101


Recovery from packet loss (1)

Forward Error Correction(FEC): simple scheme

for every group ofn chunkscreate redundant chunk byexclusive OR-ing n originalchunks

send out n+1 chunks,increasing bandwidth byfactor 1/n.

can reconstruct original nchunks if at most one lost

chunk from n+1 chunks

playout delay: enough

time to receive all n+1packets

tradeoff:

increase n, lessbandwidth waste

increase n, longerplayout delay

increase n, higherprobability that 2 ormore chunks will be

lost


41/101



2nd FEC schemepiggyback lowerquality stream send lower resolutionaudio stream asredundant information

e.g., nominalstream PCM at 64 kbpsand redundant streamGSM at 13 kbps.

whenever there is non-consecutive loss,receiver can conceal the loss. can also append (n-1)st and (n-2)nd low-bit ratechunk


42/101



Interleaving

chunks divided into smaller

units

for example, four 5 msec unitsper chunk

packet contains small unitsfrom different chunks

if packet lost, still have most

of every chunk no redundancy overhead, but

increases playout delay


43/101


Content distribution networks(CDNs)

Content replication challenging to stream large files(e.g., video) from single originserver in real time

solution: replicate content athundreds of servers throughout

Internet content downloaded to CDN

servers ahead of time

placing content close touser avoids impairments

(loss, delay) of sendingcontent over long paths

CDN server typically inedge/access network

origin server

in North America

CDN distribution node

CDN server

in S. America CDN server

in Europe

CDN server

in Asia


44/101


Content distribution networks(CDNs)Content replication

CDN (e.g., Akamai)customer is the contentprovider (e.g., CNN)

CDN replicates customers

content in CDN servers. when provider updates

content, CDN updatesservers

origin server

in North America

CDN distribution node

CDN server

in S. America CDN server

in Europe

CDN server

in Asia


45/101


CDN example

origin server (www.foo.com)

distributes HTML

replaces:http://www.foo.com/sports.ruth.gif

withhttp://www.cdn.com/www.foo.com/sports/ruth.gif

HTTP request for

www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for

www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

origin server

CDNsauthoritative

DNS server

CDN server near client

CDN company (cdn.com)

distributes gif files

uses its authoritativeDNS server to routeredirect requests

client


46/101


More about CDNs

routing requests CDN creates a map, indicating distances from

leaf ISPs and CDN nodes

when query arrives at authoritative DNS

server: server determines ISP from which query originates

uses map to determine best CDN server

CDN nodes create application-layer overlay

network


47/101


48/101


Chapter 1 outline





RTP, RTCP, SIP




49/101


Real-Time Protocol (RTP)

RTP specifies packetstructure for packetscarrying audio, videodata

RFC 3550 RTP packet provides

payload typeidentification

packet sequencenumbering

time stamping

RTP runs in endsystems

RTP packetsencapsulated in UDPsegments

interoperability: if twoInternet phoneapplications run RTP,then they may be able

to work together


50/101


RTP runs on top of UDP

RTP libraries provide transport-layer interfacethat extends UDP:

port numbers, IP addresses payload type identification

packet sequence numbering time-stamping


51/101


RTP Example

consider sending 64

kbps PCM-encodedvoice over RTP.

application collectsencoded data in

chunks, e.g., every20 msec = 160 bytesin a chunk.

audio chunk + RTP

header form RTPpacket, which isencapsulated in UDPsegment

RTP header indicatestype of audio encodingin each packet

sender can changeencoding duringconference.

RTP header alsocontains sequencenumbers, timestamps.


52/101


RTP and QoS

RTP does not provide any mechanism toensure timely data delivery or other QoSguarantees.

RTP encapsulation is only seen at endsystems (not) by intermediate routers.

routers providing best-effort service, making nospecial effort to ensure that RTP packets arrive

at destination in timely matter.

RTP Header


53/101


RTP Header

Payload Type (7 bits): Indicates type of encoding currently beingused. If sender changes encoding in middle of conference, senderinforms receiver via payload type field.

Payload type 0: PCM mu-law, 64 kbpsPayload type 3, GSM, 13 kbpsPayload type 7, LPC, 2.4 kbpsPayload type 26, Motion JPEGPayload type 31. H.261Payload type 33, MPEG2 video

Sequence Number (16 bits): Increments by one for each RTP packetsent, and may be used to detect packet loss and to restore packetsequence.

RTP H d (2)


54/101


RTP Header (2)

Timestamp field (32 bytes long): sampling instant of

first byte in this RTP data packet for audio, timestamp clock typically increments by one for

each sampling period (for example, each 125 usecs for 8KHz sampling clock)

if application generates chunks of 160 encoded samples,

then timestamp increases by 160 for each RTP packetwhen source is active. Timestamp clock continues toincrease at constant rate when source is inactive.

SSRC field (32 bits long): identifies source of t RTP stream.Each stream in RTP session should have distinct SSRC.

RTSP/RTP Programming


55/101


RTSP/RTP ProgrammingAssignment

build a server that encapsulates storedvideo frames into RTP packets

grab video frame, add RTP headers, create UDPsegments, send segments to UDP socket

include seq numbers and time stamps

client RTP provided for you

also write client side of RTSP

issue play/pause commands server RTSP provided for you

Real-Time Control Protocol


56/101


Real-Time Control Protocol(RTCP) works in conjunction with

RTP.

each participant in RTPsession periodicallytransmits RTCP controlpackets to all otherparticipants.

each RTCP packet containssender and/or receiverreports

report statistics useful toapplication: # packetssent, # packets lost,interarrival jitter, etc.

feedback can be used to

control performance

sender may modify itstransmissions based onfeedback

RTCP C ti d


57/101


RTCP - Continued

each RTP session: typically a single multicast address; all RTP /RTCP packetsbelonging to session use multicast address.

RTP, RTCP packets distinguished from each other via distinct port numbers.

to limit traffic, each participant reduces RTCP traffic as number of conferenceparticipants increases


58/101


59/101


Synchronization of Streams

RTCP can synchronizedifferent media streamswithin a RTP session

consider videoconferencingapp for which each sender

generates one RTP streamfor video, one for audio.

timestamps in RTP packetstied to the video, audiosampling clocks

nottied to wall-clocktime

each RTCP sender-reportpacket contains (for mostrecently generated packetin associated RTP stream):

timestamp of RTP packet

wall-clock time for whenpacket was created.

receivers uses associationto synchronize playout ofaudio, video


60/101


RTCP Bandwidth Scaling

RTCP attempts to limit itstraffic to 5% of sessionbandwidth.

Example

Suppose one sender,

sending video at 2 Mbps.Then RTCP attempts tolimit its traffic to 100Kbps.

RTCP gives 75% of rate

to receivers; remaining25% to sender

75 kbps is equally sharedamong receivers:

with R receivers, eachreceiver gets to send RTCPtraffic at 75/R kbps.

sender gets to send RTCPtraffic at 25 kbps.

participant determines RTCPpacket transmission periodby calculating avg RTCP

packet size (across entiresession) and dividing byallocated rate

SIP: Session Initiation


61/101


SIP: Session InitiationProtocol[RFC 3261]

SIP long-term vision:

all telephone calls, video conference calls take place overInternet

people are identified by names or e-mail addresses, ratherthan by phone numbers

you can reach callee, no matter where callee roams, nomatter what IP device callee is currently using


62/101


SIP Services

Setting up a call, SIPprovides mechanisms..

for caller to letcallee know shewants to establisha call

so caller, callee canagree on media

type, encoding

to end call

determine current IPaddress of callee:

maps mnemonicidentifier to current IPaddress

call management:

add new media streamsduring call

change encoding during

call invite others

transfer, hold calls

ett ng up a ca to nown IP


63/101


g paddress

Alices SIP invitemessage indicates her

port number, IP address,encoding she prefers toreceive (PCM ulaw)

Bobs 200 OK messageindicates his portnumber, IP address,preferred encoding(GSM)

SIP messages can be

sent over TCP or UDP;here sent over RTP/UDP.

default SIP portnumber is 5060.

time time

Bob's

terminal rings

Alice

167.180.112.24

Bob

193.64.210.89

port5060

port 38060

m Law audio

GSMport 48753

[email protected]=INIP4167.180.112.24m=audio38060RTP/AVP0port5060

200OK

c=INIP4193.64.210.89

m=audio48753RTP/AVP

3

ACKport5060


64/101


Setting up a call (more) codec negotiation:

suppose Bobdoesnt have PCMulaw encoder.

Bob will instead

reply with 606 NotAcceptable Reply,listing his encodersAlice can then send

new INVITEmessage,advertising differentencoder

rejecting a call

Bob can rejectwith repliesbusy, gone,payment

required,forbidden

media can be sentover RTP or some

other protocol

Example of SIP message


65/101


Example of SIP message

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 161.180.112.24

From: sip:[email protected]

To: sip:[email protected]

Call-ID: [email protected]

Content-Type: application/sdp

Content-Length: 885

c=IN IP4 161.180.112.24

m=audio 38060 RTP/AVP 0

Notes:

HTTP message syntax

sdp = session description protocol

Call-ID is unique for every call.

Here we dont knowBobs IP address.Intermediate SIPservers needed.

Alice sends,receives SIPmessages using SIPdefault port 506

Alice specifies inVia:header that SIP clientsends, receives SIPmessages over UDP

Name translation and user


66/101


Name translation and userlocataion

caller wants to call callee,but only has callees nameor e-mail address.

need to get IP address ofcallees current host:

user moves around DHCP protocol

user has different IPdevices (PC, PDA, cardevice)

result can be based on:

time of day (work, home)

caller (dont want boss tocall you at home)

status of callee (calls sentto voicemail when callee is

already talking tosomeone)

Service provided by SIPservers:

SIP registrar server

SIP proxy server

i


67/101


SIP Registrar

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89

From: sip:[email protected]

To: sip:[email protected]: 3600

when Bob starts SIP client, client sends SIP

REGISTER message to Bobs registrar server(similar function needed by Instant Messaging)

Register Message:


68/101

Example


69/101


ExampleCaller [email protected] places acall to [email protected]

(1) Jim sends INVITEmessage to umass SIPproxy. (2) Proxy forwardsrequest to upennregistrar server.

(3) upenn server returnsredirect response,indicating that it shouldtry [email protected]

(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrarforwards INVITE to 191.81.54.21, which is running keiths SIP client. (6-8)SIP response sent back (9) media sent directlybetween clients.Note: also a SIP ack message, which is not shown.

SIP client

217.123.56.89

SIP client

197.87.54.21

SIP proxy

umass.edu

SIP registrar

upenn.edu

SIP

registrar

eurecom.fr

1

2

34

5

6

7

8

9

C i ith H 323


70/101


Comparison with H.323

H.323 is another signalingprotocol for real-time,interactive

H.323 is a complete,vertically integrated suite of

protocols for multimediaconferencing: signaling,registration, admissioncontrol, transport, codecs

SIP is a single component.

Works with RTP, but doesnot mandate it. Can becombined with otherprotocols, services

H.323 comes from the ITU(telephony).

SIP comes from IETF:Borrows much of itsconcepts from HTTP

SIP has Web flavor,whereas H.323 hastelephony flavor.

SIP uses the KISS principle:Keep it simple stupid.

Ch t 1 tli


71/101


Chapter 1 outline

1.1 multimedia

networking applications


1.3 making the best out

of best effort service


RTP, RTCP, SIP

1.5 providing multiple

classes of service


Providing Multiple Classes of


72/101


Providing Multiple Classes ofService thus far: making the best of best effort service

one-size fits all service model

alternative: multiple classes of service

partition traffic into classes

network treats different classes of traffic differently

(analogy: VIP service vs regular service)

0111

granularity: differentialservice among multipleclasses, not amongindividual connections

history: ToS bits

Multiple classes of service:


73/101


Multiple classes of service:scenario

R1R2

H1

H2

H3

H41.5 Mbps linkR1 output

interfacequeue

Scenario 1: mixed FTP and


74/101


Scenario 1: mixed FTP andaudio Example: 1Mbps IP phone, FTP share 1.5 Mbps link.

bursts of FTP can congest router, cause audio loss

want to give priority to audio over FTP

packet marking needed for router todistinguish between different classes; andnew router policy to treat packets accordinglyPrinciple 1

R1 R2

Principles for QOS Guarantees


75/101


Principles for QOS Guarantees(more) what if applications misbehave (audio sends higher than

declared rate) policing: force source adherence to bandwidth allocations

marking and policing at network edge:

similar to ATM UNI (User Network Interface)

provide protection (isolation) for one class from others

Principle 2

R1 R2

1.5 Mbps link

1 Mbpsphone

packet marking and policing



76/101


c p es o QOS Gua a tees(more)

Allocating fixed(non-sharable) bandwidth to flow:

inefficientuse of bandwidth if flows doesnt use itsallocation

While providing isolation, it is desirable to useresources as efficiently as possible

Principle 3

R1 R2

1.5 Mbps link

1 Mbps

phone

1 Mbps logical link

0.5 Mbps logical link

Scheduling And Policing


77/101


g gMechanisms scheduling: choose next packet to send on link

FIFO (first in first out) scheduling: send in order of arrivalto queue

real-world example?

discard policy: if packet arrives to full queue: who to discard?

Tail drop: drop arriving packet

priority: drop/remove on priority basis

random: drop/remove randomly

Sched ling Policies mo e


78/101


Scheduling Policies: more

Priority scheduling: transmit highest priorityqueued packet

multiple classes, with different priorities

class may depend on marking or other header info,e.g. IP source/dest, port numbers, etc..

Real world example?

Scheduling Policies: still more


79/101



round robin scheduling:

multiple classes

cyclically scan class queues, serving one fromeach class (if available)

real world example?



80/101



Weighted Fair Queuing:

generalized Round Robin

each class gets weighted amount of service ineach cycle

real-world example?

Policing Mechanisms


81/101


Policing Mechanisms

Goal: limit traffic to not exceed declaredparameters

Three common-used criteria:

(Long term) Average Rate:how many pkts canbe sent per unit time (in the long run)

crucial question: what is the interval length: 100 packetsper sec or 6000 packets per min have same average!

Peak Rate: e.g., 6000 pkts per min. (ppm) avg.;1500 ppm peak rate

(Max.) Burst Size: max. number of pkts sentconsecutively (with no intervening idle)

Policing Mechanisms


82/101


Policing Mechanisms

Token Bucket: limit input to specified Burst Size and Average

Rate.

bucket can hold b tokens

tokens generated at rate r token/secunless bucket full

over interval of length t: number of packets admitted lessthan or equal to (r t + b).

Policing Mechanisms (more)


83/101


Policing Mechanisms (more)

token bucket, WFQ combine to provideguaranteed upper bound on delay, i.e., QoSguarantee!

WFQ

token rate, rbucket size, b

per-flowrate, R

D = b/Rmax

arriving

traffic

IETF Differentiated Services


84/101


IETF Differentiated Services

want qualitative service classes

behaves like a wire

relative service distinction: Platinum, Gold, Silver

scalability: simple functions in network core,relatively complex functions at edge routers

(or hosts) signaling, maintaining per-flow router state difficult

with large number of flows

dont define define service classes, provide

functional components to build service classes


85/101

Edge-router Packet Marking


86/101


Edge router Packet Marking

class-based marking: packets of different classes markeddifferently

intra-class marking: conforming portion of flow markeddifferently than non-conforming one

profile: pre-negotiatedrate A, bucket size B

packet marking at edge based on per-flow profile

Possible usage of marking:

User packets

Rate AB

Classification and Conditioning


87/101



Packet is marked in the Type of Service(TOS) in IPv4, and Traffic Class in IPv6

6 bits used for Differentiated ServiceCode Point (DSCP) and determine PHB

that the packet will receive 2 bits are currently unused



88/101



may be desirable to limit traffic injection rate ofsome class:

user declares traffic profile (e.g., rate, burst size)

traffic metered, shaped if non-conforming

Forwarding (PHB)


89/101


Forwarding (PHB)

PHB result in a different observable(measurable) forwarding performancebehavior

PHB does not specify what mechanisms touse to ensure required PHB performancebehavior

Examples:

Class A gets x% of outgoing link bandwidth overtime intervals of a specified length

Class A packets leave first before packets fromclass B

Forwarding (PHB)


90/101


Forwarding (PHB)

PHBs being developed: Expedited Forwarding: pkt departure rate

of a class equals or exceeds specified rate

logical link with a minimum guaranteed rate

Assured Forwarding: 4 classes of traffic

each guaranteed minimum amount ofbandwidth

each with three drop preference partitions

Chapter 1 outline


91/101


Chapter 1 outline

1.1 multimedia

networking applications1.2 streaming stored

audio and video

1.3 making the best out

of best effort service1.4 protocols for real-time

interactive applications

RTP, RTCP, SIP

1.5 providing multiple

classes of service




92/101


(more)

Basic fact of life: can not support trafficdemands beyond link capacity

Call Admission: flow declares its needs, network mayblock call (e.g., busy signal) if it cannot meet needs

Principle 4

R1R2

1.5 Mbps link

1 Mbpsphone

1 Mbpsphone

QoS guarantee scenario


93/101


QoS guarantee scenario

Resource reservation

call setup, signaling (RSVP)

traffic, QoS declaration

per-element admission control

QoS-sensitivescheduling (e.g.,WFQ)

request/reply


94/101


IETF Integrated Services

architecture for providing QOS guarantees inIP networks for individual application sessions

resource reservation: routers maintain stateinfo (a la VC) of allocated resources, QoS reqs

admit/deny new call setup requests:

Question: can newly arriving flow be admitted

with performance guarantees while not violatedQoS guarantees made to already admitted flows?

Call Admission


95/101


Call Admission

Arriving session must : declare its QOS requirement

R-spec: defines the QOS being requested

characterize traffic it will send into

network T-spec: defines traffic characteristics

signaling protocol: needed to carry R-

spec and T-spec to routers (wherereservation is required)

RSVP

Intserv QoS: Service models [rfc2211,


96/101


rfc 2212]

Guaranteed service:

worst case traffic arrival:leaky-bucket-policed source

simple (mathematicallyprovable) boundon delay[Parekh 1992, Cruz 1988]

Controlled load service:

"a quality of serviceclosely approximating theQoS that same flow wouldreceive from an unloaded

network element."

WFQ

token rate, rbucket size, b

per-flow

rate, RD = b/R

max

arriving

traffic

Signaling in the Internet


97/101


Signaling in the Internet

connectionless(stateless)

forwarding by IProuters

best effortservice

no networksignalingprotocols

in initial IPdesign

+ =

New requirement: reserve resources along end-to-end path(end system, routers) for QoS for multimedia applications

RSVP: Resource Reservation Protocol [RFC 2205]

allow users to communicate requirements to network inrobust and efficient way. i.e., signaling !

earlier Internet Signaling protocol: ST-II [RFC 1819]

RSVP Design Goals


98/101


RSVP Design Goals

1. accommodate heterogeneous receivers(different bandwidth along paths)

2. accommodate different applications withdifferent resource requirements

3. make multicast a first class service, with

adaptation to multicast group membership4. leverage existing multicast/unicast routing, with

adaptation to changes in underlying unicast,multicast routes

5. control protocol overhead to grow (at worst)

linear in # receivers6. modular design for heterogeneous underlying

technologies

RSVP: does not


99/101


RSVP: does not

specify how resources are to be reserved

rather: a mechanism for communicating needs

determine routes packets will take

thats the job of routing protocols

signaling decoupled from routing

interact with forwarding of packets

separation of control (signaling) and data

(forwarding) planes

RSVP: overview of operation


100/101


RSVP: overview of operation

senders, receiver join a multicast group

done outside of RSVP senders need not join group

sender-to-network signaling

path message: make sender presence known to routers

path teardown: delete senders path state from routers receiver-to-network signaling

reservation message: reserve resources from sender(s)to receiver

reservation teardown: remove receiver reservations

network-to-end-system signaling

path error

reservation error

Chapter 1: Summary


101/101

Chapter 1: Summary

Principles classify multimedia applications

identify network services applications need

making the best of best effort service

Protocols and Architectures

specific protocols for best-effort

mechanisms for providing QoS

architectures for QoS

multiple classes of service

QoS guarantees, admission control

Documents

Multimedia Networks - 1- Introduction