multimedia, quality of service: cosa è?cmp/corsoreti/slides06/cap7-multimedia.pdf · network audio...
TRANSCRIPT
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
7: Multimedia Networking 7-2
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
7: Multimedia Networking 7-3
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
7: Multimedia Networking 7-4
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
7: Multimedia Networking 7-5
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
7: Multimedia Networking 7-6
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
7: Multimedia Networking 7-7
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!
7: Multimedia Networking 7-8
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
7: Multimedia Networking 7-9
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!
?? ?? ??
? ??
?
?
7: Multimedia Networking 7-10
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?
7: Multimedia Networking 7-11
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
7: Multimedia Networking 7-12
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
7: Multimedia Networking 7-13
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
7: Multimedia Networking 7-14
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
7: Multimedia Networking 7-15
Internet multimedia: streaming
ρ browser GETs metafileρ browser lancia il player, passandogli il metafileρ player contacts serverρ server streams audio/video to player
7: Multimedia Networking 7-16
Streaming from a streaming server
ρ Questa architettura consente il non utilizzo di HTTP traserver e media player
ρ Può inoltre utilizzare UDP invece di TCP.
7: Multimedia Networking 7-17
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
7: Multimedia Networking 7-18
Streaming Multimedia: Client Buffering
ρ Client-side buffering, playout delay assorbe ilritardo di rete e il jitter
bufferedvideo
variable fillrate, x(t)
constant drainrate, d
7: Multimedia Networking 7-19
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
7: Multimedia Networking 7-20
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
7: Multimedia Networking 7-21
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
7: Multimedia Networking 7-22
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”.
7: Multimedia Networking 7-23
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
7: Multimedia Networking 7-24
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>
7: Multimedia Networking 7-25
RTSP Operation
7: Multimedia Networking 7-26
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
7: Multimedia Networking 7-27
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
7: Multimedia Networking 7-28
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
7: Multimedia Networking 7-29
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.
7: Multimedia Networking 7-30
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.
7: Multimedia Networking 7-31
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
7: Multimedia Networking 7-32
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
7: Multimedia Networking 7-33
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’
7: Multimedia Networking 7-34
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
7: Multimedia Networking 7-35
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
7: Multimedia Networking 7-36
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.
7: Multimedia Networking 7-37
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
7: Multimedia Networking 7-38
Recovery from packet loss (2)
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
7: Multimedia Networking 7-39
Recovery from packet loss (3)
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
7: Multimedia Networking 7-40
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
7: Multimedia Networking 7-41
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
7: Multimedia Networking 7-42
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
7: Multimedia Networking 7-43
RTP runs on top of UDP
Le librerie RTP estendono UDP: • port numbers, IP addresses• payload type identification• packet sequence numbering• time-stamping
7: Multimedia Networking 7-44
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.
7: Multimedia Networking 7-45
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.
7: Multimedia Networking 7-46
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.
7: Multimedia Networking 7-47
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.
7: Multimedia Networking 7-48
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
7: Multimedia Networking 7-49
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
7: Multimedia Networking 7-50
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.
7: Multimedia Networking 7-51
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
7: Multimedia Networking 7-52
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
7: Multimedia Networking 7-53
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:
7: Multimedia Networking 7-54
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
7: Multimedia Networking 7-55
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