Multimedia, Quality of Service: Cosa è?cmp/CorsoReti/slides06/Cap7-multimedia.pdf · network audio...

7: Multimedia Networking 7-1

Multimedia, Quality of Service: Cosa è?

Multimedia applications:network audio e video(“continuous media”)

network mette adisposizione applicazionicon il livello diperformance necessario

QoS


Chapter 7: Goals

Principiρ Classificare le applicazioni multimedialiρ Identificare i servizi di rete necessari alle appsρ Realizzare “the best of best effort service”ρ Meccanismi per erogare il QoSProtocolli e Architettureρ Specifici protocols per best-effortρ Architecture per QoS


Aplicazioni Multimediali

Fondamentalicaratteritiche

ρ Sensibili al delayµ end-to-end delayµ delay jitter

ρ Resistenti alla perdita dipacchetti: perditecontenute non vengonoapprezzate

ρ Antitetiche rispetto aidati, che tollerano iritardi ma non le perdite.

Classi di applicazioni MM:1) Streaming stored audio

and video2) Streaming live audio and

video3) Real-time interactive

audio and video

Jitter il ritardo variabiledei pacchetti tra di loro


Streaming Stored Multimedia

Streaming:ρ media stored at sourceρ transmitted to clientρ streaming: il client comincia a riprodurre

prima della fine trasmissioneρ Il ritardo viene riassorbito: in tempo per

la riproduzione


Streaming Stored Multimedia:Cosa è?

1. videorecorded

2. videosent 3. video received,

played out at client

Cum

ulat

ive

data

streaming: in questo momento il client riproduce la prima parte del video, mentre il server trasmette l'ultima

networkdelay time


Streaming Stored Multimedia Interattivo

ρ VCR-like functionality: il client può:pause, rewind, FF, ecc.µ 10 sec di ritardo inizale OKµ 1-2 sec per l'effetto del commando

è OKµ Protocollo spesso usato: RTSP

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


Streaming Live Multimedia

Examples:ρ Internet radio talk showρ Live sporting eventStreamingρ playback bufferρ playback può attendere decine di second dopo la

trasmissioneρ Esistono tuttavia vincol sul “timing”Interactivityρ fast forward è impossibileρ Rewind e pause sono possibili!


Interactive, Real-Time Multimedia

ρ end-end delay requirements:µ audio: < 150 msec good, < 400 msec OK

• includes application-level (packetization) and networkdelays

• Ritardi più elevati disturbano e rendono impossibileL'interattività.

ρ session initializationµ Come il chiamante segnale il suo IP address, port

number, algorithmo di compressione?

ρ applications: Voip, videoconferenza, distributedinteractive worlds


Multimedia oggi in Internet

TCP/UDP/IP: “best-effort service”ρ Nessuna garanzia su ritardi e perdite!

Oggi le applicazioni multimediali Internet usano tecniche a livello applicativo per

attenuare al meglio gli effetti di ritardi e perdite

Ma dicemmo che le apps multimediali richiedonoQoS e performance garanite per funzionare!

?? ?? ??

? ??

?

?


Come evolverà internet per supportare almeglio le apps multimediali?

Integrated services philosophy:ρ Modifiche fondamentali in

internet affincè le appsabbano banda end-to-endgarantita

ρ Si richiede nuovo ecomplesso sw in hosts &routers

Laissez-faireρ no major changesρ + banda quando richiestoρ content distribution,

application-layer multicastµ application layer

Differentiated servicesphilosophy:

ρ Poche modificheall'infrastruttura Internet,quindi erogazione di servizidi 1st and 2nd classe

Qual'è la tua opinione?


Alcune nozioni sulla compressione audioρ Il segnale analogico è

campionato a rate costante:µ telephone: 8,000

samples/secµ CD music: 44,100

samples/secρ Ogni campione è “discreto”

i.e., arrotondatoµ e.g., 28=256 possible

quantized valuesρ Ogni valore quantizzato è

codificato in bitsµ 8 bits for 256 values

ρ Esempio: 8,000samples/sec, 256quantized values -->64,000 bps

ρ Il Receiver lo riconvertein segnale analogico:µ Perdita di qualità

Example ratesρ CD: 1.411 Mbpsρ MP3: 96, 128, 160 kbpsρ Internet telephony: 5.3 -

13 kbps


Alcuni concetti sulla compressione video

ρ Il video è una sequenzadi immagini riprodotte arate costanteµ e.g. 24 images/sec

ρ L'immagine digitale è unarray di pixels

ρ Ogni pixel èrappresentata da bits

ρ Ridondanzaµ spazialeµ temporale

Esempi:ρ 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


Streaming Stored Multimedia

Tecniche a livello diApplicazione streamingper realizzare ilmeglio delof best effort service:µ client side bufferingµ use of UDP versus TCPµ multiple encodings of

multimedia

ρ Rimozione del jitterρ decompressioneρ Correzione degli erroriρ graphical user interface

w/ controls forinteractivity

Media Player


Internet multimedia: un semplice approccio

audio, video not streamed:ρ no, “pipelining,” long delays until playout!

ρ audio or video stored in fileρ files trasferiti come HTTP object

µ Ricevuti dal clientµ Quindi inoltrati al player


Internet multimedia: streaming

ρ browser GETs metafileρ browser lancia il player, passandogli il metafileρ player contacts serverρ server streams audio/video to player


Streaming from a streaming server

ρ Questa architettura consente il non utilizzo di HTTP traserver e media player

ρ Può inoltre utilizzare UDP invece di TCP.


constant bit rate videotransmission

Cum

ulat

ive

data

time

variablenetwork

delay

client videoreception

constant bit rate video playout at client

client playoutdelay

buff

ered

vide

o

Streaming Multimedia: Client Buffering

ρ Client-side buffering, vengono compensati i ritardidella rete e il jitter aggingendo un adeguatoritardo che funge da buffer


Streaming Multimedia: Client Buffering

ρ Client-side buffering, playout delay assorbe ilritardo di rete e il jitter

bufferedvideo

variable fillrate, x(t)

constant drainrate, d


Streaming Multimedia: UDP or TCP?

UDPρ Il server spedisce ad una rate appropriata per il client

(oblivious to network congestion !)µ spesso: send rate = encoding rate = constant rateµ quindi, fill rate = constant rate - packet loss

ρ un playout delay contenuto (2-5 seconds) per compensareritardo e jitter

ρ error recover: time permitting

TCPρ Spedizione alla massima rate possibile con TCPρ La rate fluttua a causa del “TCP congestion control”ρ Necessita un ampio playout delay: annulla il TCP delivery rateρ HTTP/TCP attraversa più facilmente i firewalls


Streaming Multimedia: client rate(s)

Q: come gestire le diverse velocità di ricezionedei client?µ 28.8 Kbps dialupµ 100Mbps Ethernet

A: il server memorizza e trasmette diversecopie del video a diverse rate.

1.5 Mbps encoding

28.8 Kbps encoding


User Control of Streaming Media: RTSP

HTTPρ Non evidenzia contenuti

multimedialiρ Nessun comando per fast

forward, etc.RTSP: RFC 2326ρ Client-server application

layer protocol.ρ L'utente controlla la

riproduzione: rewind, fastforward, pause, resume,repositioning, etc…

Cosa non fa:

ρ Non definiscel'incapsulamento in streamingdell' audio/video sulla rete

ρ Non pone limiti al livello ditrasporto; può esseretrasportato sia con UDP orTCP

ρ Non specifica come il mediaplayer bufferizza audio/video


RTSP: controllo “out of band”FTP usa un “out-of-band”

control channel:ρ Il file è trasferito con

connessione TCPρ Le informazioni di controllo

(directory changes, filedeletion, file renaming,etc.) sono trasferite su unaconnessione TCP separata

ρ The “out-of-band” e “in-band” channels usanoport numbers differenti.

RTSP anche i messages sonospediti out-of-band:

ρ RTSP control messagesusano differenti portnumbers dal media stream:out-of-band.µ Port 554

ρ Il media stream èconsiderato “in-band”.


RTSP Example

Scenario:ρ I metafile comunicano via web browserρ Il browser lancia il playerρ Il player sets up una RTSP control connection, la data

connection invece verso lo streaming server


Metafile Example<title>Twister</title><session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group></session>


RTSP Operation


RTSP Exchange Example C: 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.0 Session: 4231

S: 200 3 OK


Chapter 7 outline

ρ 7.1 Multimedia NetworkingApplications

ρ 7.2 Streaming stored audioand video

ρ 7.3 Real-time Multimedia:Internet Phone case study

ρ 7.4 Protocols for Real-TimeInteractive Applicationsµ RTP,RTCP,SIP

ρ 7.5 Distributing Multimedia:content distributionnetworks

ρ 7.6 Beyond Best Effortρ 7.7 Scheduling and

Policing Mechanismsρ 7.8 Integrated

Services andDifferentiatedServices

ρ 7.9 RSVP


Real-time interactive applications

ρ PC-2-PC phoneµ instant messaging

services sono necessari

ρ PC-2-phoneµ Dialpadµ Net2phone

ρ videoconferenza conWebcams

Going to now look ata PC-2-PC Internetphone example indetail


Interactive Multimedia: Internet Phone

Introduzione di Internet Phone con un esempio

ρ speaker’s audio: alterna dialogo e silenziµ 64 kbps durante il dialogo

ρ pkts generated only during talk spurtsµ 20 msec chunks at 8 Kbytes/sec: 160 bytes data

ρ application-layer header aggiunti ad ogni chunk.

ρ Chunk+header encapsulated into UDP segment.

ρ application spedisce segmenti UDP ogni 20 msecduring i dialoghi.


Internet Phone: Packet Loss and Delay

ρ network loss: datagrammi IP persi a causa dellanetwork congestion (router buffer overflow)

ρ delay loss: IP datagrammi IP arrivano troppo tardiper la riproduzioneµ delays: processing, queueing in network; end-system

(sender, receiver) delaysµ typical maximum tolerable delay: 400 ms

ρ loss tolerance: dipende dai CODEC, perditetollerabili tra 1% and 10% can be tolerated.


constant bit ratetransmission

Cum

ulat

ive

data

time

variablenetwork

delay(jitter)

clientreception

constant bit rate playout at client

client playoutdelay

buff

ered

data

Delay Jitter

ρ Consideriamo che l' end-to-end delays tra duepacchetti consecutivi può essere di circa 20 msec


Internet Phone: Fixed Playout Delay

ρ Il ricevente tenta di riprodurre ogni “chunk”esattamente q msecs dopo la sua generazione.µ chunk hanno time stamp t: riproduzione a t+q .µ chunk arriveano dopo t+q: troppo tardi per la

riproduzione, sono persiρ Tradeoff for q:

µ large q: meno pacchetti persiµ small q: interazione migliore


Fixed Playout Delay

packets

time

packetsgenerated

packetsreceived

loss

r

p p'

playout schedulep' - r

playout schedulep - 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’


Adaptive Playout Delay, I

€

ti = timestamp of the ith packetri = the time packet i is received by receiverpi = the time packet i is played at receiverri − ti = network delay for ith packetdi = estimate of average network delay after receiving ith packet

Dynamic estimate of average delay at receiver:)()1( 1 iiii trudud −+−= −

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

ρ Goal: minimizzare il playout delay,ρ Approach: adaptive playout delay adjustment:

µ Stimare i ritardi di rete, impostare i ritardi all'inizio di ogni dialogo.µ I silenzi vengono compressi o allungatiµ Chunks riprodotti ancora ogni 20 msec durante i dialoghi


Adaptive playout delay II

Also useful to estimate the average deviation of the delay, vi :

||)1( 1 iiiii dtruvuv −−+−= −

The estimates di and vi are calculated for every received packet,although they are only used at the beginning of a talk spurt.

For first packet in talk spurt, playout time is:

where K is a positive constant.

Remaining packets in talkspurt are played out periodically


Adaptive Playout, III

Q: How does receiver determine whether packet isfirst in a talkspurt?

ρ If no loss, receiver looks at successive timestamps.µ difference of successive stamps > 20 msec -->talk spurt

begins.ρ With loss possible, receiver must look at both time

stamps and sequence numbers.µ difference of successive stamps > 20 msec and sequence

numbers without gaps --> talk spurt begins.


Recovery from packet loss (1)

forward error correction(FEC): simple scheme

ρ Per ogni gruppo di n chunksse ne crea uno ridondanterisultato di una exclusiveOR-ing tra gli n chuncks

ρ Si spediscono così n+1chunks, incrementado labanda di un fattore 1/n.

ρ Si può ricostruireinteramente un chuncksperso dagli n+1 chunks

ρ Playout delay deve esserestabilito al tempo diricezione degli n+1 packets

ρ Tradeoff:µ increase n, meno

restrizione di bandaµ increase n, aumento

del palyout delayµ increase n, maggiori

probabilità di perdite



2nd FEC scheme• “piggyback lower quality stream” • send lower resolutionaudio stream as theredundant information• for example, nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps.

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



Interleavingρ chunks are broken

up into smaller unitsρ for example, 4 5 msec units

per chunkρ Packet contains small units

from different chunks

ρ if packet is lost, still havemost of every chunk

ρ has no redundancy overheadρ but adds to playout delay


Summary: Internet Multimedia:

ρ usa UDP per evitare il controllo di congestione diTCP (delays)

ρ client-side adaptive playout delay: per compensarei ritardi

ρ server side matches stream bandwidth to availableclient-to-server path bandwidtµ chose among pre-encoded stream ratesµ dynamic server encoding rate

ρ error recovery (on top of UDP)µ FEC, interleavingµ retransmissions, time permittingµ conceal errors: repeat nearby data


Chapter 7 outline

ρ 7.1 Multimedia NetworkingApplications

ρ 7.2 Streaming stored audioand video

ρ 7.3 Real-time Multimedia:Internet Phone study

ρ 7.4 Protocols for Real-TimeInteractive Applicationsµ RTP,RTCP,SIP

ρ 7.5 Distributing Multimedia:content distributionnetworks

ρ 7.6 Beyond Best Effortρ 7.7 Scheduling and

Policing Mechanismsρ 7.8 Integrated

Services andDifferentiatedServices

ρ 7.9 RSVP


Real-Time Protocol (RTP)

ρ RTP una struttura apacchetti pervideoconferenze

ρ RFC 1889.ρ RTP packet offre:

µ payload typeidentification

µ packet sequencenumbering

µ timestamping

ρ RTP è un livelloapplicativo a livelloclient

ρ RTP usa UDPρ Interoperabilità: due

applicazioni RTPpossono lavorareinsieme


RTP runs on top of UDP

Le librerie RTP estendono UDP: • port numbers, IP addresses• payload type identification• packet sequence numbering• time-stamping


RTP Example

ρ Consider sending 64 kbpsPCM-encoded voice overRTP.

ρ Application collects theencoded data in chunks,e.g., every 20 msec = 160bytes in a chunk.

ρ The audio chunk alongwith the RTP headerform the RTP packet,which is encapsulatedinto a UDP segment.

ρ RTP header indicatestype of audio encoding ineach packetµ sender can change

encoding during aconference.

ρ RTP header also containssequence numbers andtimestamps.


RTP and QoS

ρ RTP does not provide any mechanism to ensuretimely delivery of data or provide other quality ofservice guarantees.

ρ RTP encapsulation is only seen at the end systems:it is not seen by intermediate routers.µ Routers providing best-effort service do not make any

special effort to ensure that RTP packets arrive at thedestination in a timely matter.


RTP Header

Payload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, sender informs the receiver through this payload type field.

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

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


SIP

ρ Session Initiation Protocolρ Comes from IETFSIP long-term visionρ Telefonate e videoconferenze su Internetρ Gli utenti sono identificati da uid. (STUN), solo in

parte dal n. telρ Si raggiunge il chiamante a prescindere dal media

che uilizza o dalla sua connessione.


SIP Services

ρ Setting up a callµ Provides mechanisms for

caller to let callee knowshe wants to establish acall

µ Provides mechanisms sothat caller and callee canagree on media type andencoding.

µ Provides mechanisms toend call.

ρ Determine current IPaddress of callee.µ Maps mnemonic

identifier to current IPaddress

ρ Call managementµ Add new media streams

during callµ Change encoding during

callµ Invite othersµ Transfer and hold calls


Setting up a call to a known IP address• Alice’s SIP invite messageindicates her port number & IPaddress. Indicates encodingthat Alice prefers to receive(PCM ulaw)

• Bob’s 200 OK messageindicates his port number, IPaddress & preferred encoding(GSM)

• SIP messages can be sentover TCP or UDP; here sentover RTP/UDP.

•Default SIP port number is5060.time time

Bob'sterminal rings

Alice

167.180.112.24

Bob

193.64.210.89

port 5060

port 38060

µΛαω αυδιο

ΓΣΜπορτ 48753

ΙΝςΙΤΕ βοβ≅193.64.210.89χ=ΙΝ ΙΠ4 167.180.112.24µ=αυδιο 38060 ΡΤΠ/ΑςΠ 0

πορτ 5060

200 ΟΚχ=ΙΝ ΙΠ4 193.64.210.89µ=αυδιο 48753 ΡΤΠ/ΑςΠ 3

ΑΧΚπορτ 5060


Setting up a call (more)ρ Codec negotiation:

µ Suppose Bob doesn’t havePCM ulaw encoder.

µ Bob will instead reply with606 Not Acceptable Replyand list encoders he canuse.

µ Alice can then send a newINVITE message,advertising an appropriateencoder.

ρ Rejecting the callµ Bob can reject with

replies “busy,” “gone,”“payment required,”“forbidden”.

ρ Media can be sent over RTPor some other protocol.


Example of SIP message

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 167.180.112.24From: sip:[email protected]: sip:[email protected]: [email protected]: application/sdpContent-Length: 885

c=IN IP4 167.180.112.24m=audio 38060 RTP/AVP 0

Notes:ρ HTTP message syntaxρ sdp = session description protocolρ Call-ID is unique for every call.

• Here we don’t know Bob’s IP address. Intermediate SIPservers will be necessary.

• Alice sends and receives SIP messages using the SIP default port number 506.

• Alice specifies in Via:header that SIP client sends and receives SIP messages over UDP


Name translation and user locataion

ρ Caller wants to callcallee, but only hascallee’s name or e-mailaddress.

ρ Need to get IPaddress of callee’scurrent host:µ user moves aroundµ DHCP protocolµ user has different IP

devices (PC, PDA, cardevice)

ρ Result can be based on:µ time of day (work, home)µ caller (don’t want boss to

call you at home)µ status of callee (calls sent

to voicemail when callee isalready talking tosomeone)

Service provided by SIPservers:

ρ SIP registrar serverρ SIP proxy server


SIP Registrar

REGISTER sip:domain.com SIP/2.0Via: SIP/2.0/UDP 193.64.210.89From: sip:[email protected]: sip:[email protected]: 3600

ρ When Bob starts SIP client, client sends SIPREGISTER message to Bob’s registrar server

(similar function needed by Instant Messaging)

Register Message:


SIP Proxy

ρ Alice sends invite message to her proxy serverµ contains address sip:[email protected]

ρ Proxy responsible for routing SIP messages tocalleeµ possibly through multiple proxies.

ρ Callee sends response back through the same setof proxies.

ρ Proxy returns SIP response message to Aliceµ contains Bob’s IP address

ρ Note: proxy is analogous to local DNS server


ExampleCaller [email protected] with places a call to [email protected]

(1) Jim sends INVITEmessage to umass SIPproxy. (2) Proxy forwardsrequest to upenn registrar server. (3) upenn server returnsredirect response,indicating that it should try [email protected]

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

SIP client217.123.56.89

SIP client197.87.54.21

SIP proxyumass.edu

SIP registrarupenn.edu

SIPregistrareurecom.fr

1

2

34

5

6

7

8

9

Multimedia, Quality of Service: Cosa è?cmp/CorsoReti/slides06/Cap7-multimedia.pdf · network audio...

Documents

Transcript of Multimedia, Quality of Service: Cosa è?cmp/CorsoReti/slides06/Cap7-multimedia.pdf · network audio...