Sstem e Servz d TLC Lezone N. 9 Multmeda Networkng 24 Novembre 2005 (2h)
Applcazon multmedal n rete Caratterstche fondamental Tpcamente sono partcolarmente sensbl al rtardo (delay senstve) Sono tollerant alle perdte (loss tolerant): perdte occasonal causano soltanto occasonal buch nella rproduzone dell audo e del vdeo che possono essere parzalmente o completamente mascherat. Requst molto dvers da quell delle applcazon elastche, tpcamente loss ntolerant ma delay tolerant. Le applcazon multmedal sono anche dette contnuous meda Class d applcazon multmedal Streamng d audo e vdeo stored Lve streamng d audo e vdeo Real-tme nteractve vdeo
Applcazon multmedal n rete (2) Streamng stored MM Il clent rchede un fle audo/vdeo al server. Il fle vene trasmesso attraverso la rete e vsualzzato dal clent. Interattvtà: l utente può controllare le operazon (smle al VCR: pause, resume, fast forward, rewnd, etc.) Rtardo: tra la rchesta del clent e l nzo della vsualzzazone possono passare da 1 a 10 second Applcazon Real-Tme undrezonal Sml al broadcastng TV e rado, ma la trasmssone avvene sulla rete Internet Non-nterattve, solo lsten/vew Applcazon Real-Tme nterattve Audo o vdeo conferenza Requst n termn d rtardo pù strngent rspetto alle applcazon d streamng undrezonal a causa della natura real-tme Vdeo: < 150 msec accettable Audo: < 150 msec buono, <400 msec accettable
Applcazon multmedal n rete (3) La sute d protocoll TCP/IP fornsce un servzo d tpo besteffort, senza garanze d servzo n termn d rtardo end-to-end o d varazone del rtardo (jtter). Le applcazon d tpo streamng con un rtardo nzale d 5-10 second sono molto comun, ma le prestazon s deterorano se lnk sono congestonat (transoceanc). Le applcazon Real-Tme Interattve hanno requst rgd n termn d rtardo e d jtter. Il Jtter è la varazone del rtardo de pacchett appartenent allo stesso stream. La progettazone d applcazon multmedal sarebbe pù semplce se esstessero class d servzo dverse. In Internet tutt pacchett rcevono lo stesso trattamento. I pacchett contenent audo e vdeo real-tme nterattvo stanno n fla, come tutt gl altr. Sono state proposte e mplementate archtetture d rete n grado d fornre servz dfferenzat.
Applcazon multmedal n rete (4) Per ottenere l meglo dal modello d servzo best-effort è possble: Utlzzare l UDP ed evtare l basso throughput del TCP quando entra nella fase d slow-start Bufferzzare pacchett e rtardare la rproduzone presso l rcevtore n modo da lmtare gl effett del jtter Etchettare pacchett con un contrassegno temporale (tmestamp) che corrsponde all stante d generazone n modo che l rcevtore sappa quando devono essere rprodott Per lo streamng d audo e vdeo n dfferta cercare d adattare l lvello d compressone allo stato della rete. Invare nformazon rdondant per mtgare gl effett della perdta de pacchett ndotta dalla rete
L evoluzone d Internet per l supporto d applcazon multmedal Flosofa Integrated servces Sono necessar profond cambament negl host e ne router per consentre alle applcazon d prenotare esplctamente la capactà trasmssva necessara end-to-end Occorre un protocollo per prenotare la capactà trasmssva E necessaro modfcare le poltche d schedulng ne router Le applcaton devono fornre alla rete una descrzone del traffco generato, La rete, prma d accettare nuove prenotazon deve verfcare se le rsorse dsponbl sono suffcent per soddsfare le rcheste. Flosofa Dfferentated servces Il numero de cambament rchest è nferore Fornsce un servzo d prma classe e un servzo d seconda classe. I datagramma sono etchettat. L utente paga d pù per utlzzare la prma classe d servzo. Gl ISPs pagano d pù per trasmettere e rcevere sulla backbone pacchett appartenent alla prma classe d servzo.
L evoluzone d Internet per l supporto d applcazon multmedal Lassez-fare phlosophy Non è necessara nessuna varazone al modello d servzo best-effort e al protocollo IP E suffcente: 1. l aumento della capactà trasmssva con l crescere della domanda 2. L utlzzo d cache n punt strategc della rete: ISP Forntor d contenut P2P: peer con l contenuto d nteresse pù vcn Vrtual prvate networks (VPNs) Rservare n modo permanente capactà trasmssva. I Router dstnguono l traffco delle VPN n base agl ndrzz IP I Router utlzzano poltche d schedulng partcolar per fornre la capactà trasmssva rchesta
Streamng Stored Audo & Vdeo Streamng stored meda Il fle Audo/vdeo rsede su un server d tpo web o d tpo streamng Gl utent rchedono l fle audo/vdeo on demand. La rproduzone del fle Audo/vdeo nza entro, per esempo, 10 s dalla rchesta E permessa l nterattvtà. (pause, re-postonng, etc.) Meda player: Decompressone Elmnazone del jtter Correzone degl error Trasmssone d pacchett rdondant Rtrasmssone d pacchett pers Interpolazone de pacchett mancant GUI (Graphcal User Interface) con comand d controllo Il meda player può essere nserto nella fnestra del browser, ma vene eseguto ndpendentemente da esso
Streamng Audo/Vdeo da Web server (1) I fle audo e vdeo rsedono su un Web server. Sono oggett normal come fle HTML e JPEG. Approcco naf Il browser stablsce una connessone TCP con l server e rchede l fle con un messaggo d tpo HTTP request Il server Web nva l fle al browser n un messaggo d tpo HTTP response La lnea dell ntestazone HTTP Content-type ndca che l contenuto è un fle audo/vdeo e la codfca utlzzata Il browser lanca l meda player, e passa l fle al meda player Il meda player rproduce l fle Prncpale nconvenente Poché l meda player nteragsce con l server attraverso un ntermedaro (l web browser) l rtardo con l quale nza la rproduzone potrebbe essere troppo elevato e qund non accettable
Streamng da un Web server (2) Alternatva: nstaurare la connessone fra l web server e l player 1. Il Web browser rchede l fle audo/vdeo clccando su un hyperlnk: n rsposta rceve un meta fle (un fle che descrve l oggetto: URL del fle audo/vdeo, specfca applcazone audo/vdeo) nvece del fle stesso 2. Il campo dell header Content-type del meta fle ndca la specfca applcazone audo/vdeo 3. Il Browser esamna la lnea dell header Content-type, lanca l meda player assocato, passandogl l ntero corpo (l meta fle) del messaggo d rsposta 4. Il Player nstaura una connessone TCP con l server e nva la rchesta HTTP. 5. Il fle audo/vdeo è nvato al medaplayer all nterno d un messaggo d rsposta HTTP. Il meda player estrae lo stream del fle audo/vdeo Problem Il Meda player comunca utlzzando l HTTP (e qund anche con l TCP) che non consente all utente d utlzzare comand pause, ff, rwnd S potrebbe voler effettuare lo streamng con l protocollo UDP
Streamng da uno streamng server a un meda player Questa archtettura permette l utlzzo d protocoll dvers dall HTTP fra l server e l meda player Il server d streamng può essere propretaro o d pubblco domno Il fle audo/vdeo può essere trasmesso utlzzando l UDP nvece del TCP
Streamng da uno streamng server: opzon dsponbl 1. Utlzzando l protocollo UDP, trasmettere l audo/vdeo con un bt/rate costante uguale alla veloctà d svuotamento del buffer del rcevtore (che è la veloctà dell audo/vdeo codfcato). 2. Per mtgare gl effett del jtter, s bufferzza e s rtarda la rproduzone d 2-5 s. La veloctà d rempmento (Fll rate) x(t) è uguale alla veloctà d svuotamento (Dran rate) d tranne che n presenza d perdte [x(t) < d]. 3. Utlzzare l TCP e trasmettere meda alla massma veloctà possble. C sono due buffer: l buffer del TCP e l buffer del clent (meda player). Il TCP effettua le rtrasmsson necessare quando s verfcano error; x(t), che è la veloctà de rempmento del buffer del TCP adesso fluttua e può dventare molto pù grande d d (veloctà d lettura dal buffer del player). Il Player può utlzzare un buffer molto pù grande per rendere pù regolare la veloctà d estrazone de dat dal buffer. Il corretto dmensonamento del buffer del clent è fondamentale per le prestazon del sstema.
RTSP (Real Tme Streamng Protocol) HTTP I progettst dell HTTP avevano n mente meda fss : pagne HTML, mmagn, applets, etc. HTTP non prevede la trasmssone d stored contnuous meda (.e. audo, vdeo, etc.) RTSP: RFC 2326 E un protocollo del lvello applcatvo conforme al paradgma Clent- Server. Consente al meda player d effettuare operazon d controllo sulla rproduzone de meda contnu (rewnd, fast forward, pause, resume, repostonng, etc.) Che cosa non fa Non defnsce gl schem d compressone per audo e vdeo Non defnsce l modo n cu l flusso audo/vdeo deve essere ncapsulato per la trasmssone sulla rete (RTP o protocollo propretaro) Non pone restrzon alla modaltà d trasporto de fluss audo/vdeo (UDP o TCP) Non specfca come l meda player bufferzza fluss audo/vdeo (la rproduzone può avere nzo con un rtardo d poch second, quando l fle è stato nteramente rcevuto, oppure appena l fle arrva al clent) RealNetworks Il server e l player usano l protocollo RTSP per scambars nformazon d controllo
RTSP: protocollo out of band I messagg RTSP sono nvat out-of-band I messagg d controllo RTSP utlzzano un numero d porta (554) dverso dal flusso del meda, e sono qund spedt out-of-band. La specfca dell RTSP consente a messagg RTSP d utlzzare, a lvello d trasporto, sa TCP che UDP Il flusso del meda, la cu struttura non è defnta dall RTSP, è consderato n-band. Se messagg RTSP utlzzassero gl stess numer d porta del flusso de dat (meda stream), s drebbe che messagg RTSP sono nterallaccat con l flusso de dat.
RTSP nza e controlla la trasmssone Il browser rchede al server Web un fle d descrzone della presentazone multmedale, che può essere composta da pù meda stream. Web browser meda player HTTP GET presentaton desc. SETUP PLAY meda stream PAUSE TEARDOWN Web server meda server Il browser nvoca l meda player (helper applcaton) n base al campo tpo d contenuto del messaggo, che contene una descrzone della presentazone. La descrzone della presentazone nclude rferment a meda stream, utlzzando l metodo delle URL (rtsp://) Il player nva una rchesta RTSP SETUP; l server rsponde con un messaggo RTSP SETUP. clent server Il player nva una rchesta d tpo RTSP PLAY; l server rsponde con un messaggo RTSP PLAY. Il meda server trasmette l meda stream. Il Player nva una rchesta RTSP PAUSE; l server rsponde con un messaggo RTSP PAUSE. Il Player nva una rchesta RTSP TEARDOWN; l server rsponde con RTSP TEARDOWN.
Meta fle: esempo <ttle>twster</ttle> <sesson> <group language=en lpsync> <swtch> <track type=audo e="pcmu/8000/1" src = "rtsp://audo.example.com/twster/audo.en/lof"> <track type=audo e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audo.example.com/twster/audo.en/hf"> </swtch> <track type="vdeo/jpeg" src="rtsp://vdeo.example.com/twster/vdeo"> </group> </sesson>
Una sessone RTSP Ogn sessone RTSP ha un dentfcatore d sessone, scelto dal server. Il clent nza una sessone con una rchesta d SETUP, e l server rsponde alla rchesta con un dentfcatore. Il clent rpete l dentfcatore della sessone per cascuna rchesta, fnché l clent chude la sessone con una rchesta d TEARDOWN RTSP ha numero d porta 554. RTSP può essere trasmesso utlzzando a lvello d trasporto sa l protocollo UDP che l TCP. Ogn messaggo RTSP può essere nvato su una connessone TCP separata.
RTSP: esempo C: SETUP rtsp://audo.example.com/twster/audo RTSP/1.0 Cseq: 1 Transport: rtp/udp; compresson; port=3056; mode=play S: RTSP/1.0 200 OK Cseq: 1 Sesson 4231 C: PLAY rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Cseq: 2 Sesson: 4231 Range: npt=0- S: RTSP/1.0 200 OK Sesson 4231 Cseq: 2 C: PAUSE rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Cseq: 3 Sesson: 4231 Range: npt=37 S: RTSP/1.0 200 OK Cseq: 3 Sesson 4231 C: TEARDOWN rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Cseq: 4 Sesson: 4231 S: RTSP/1.0 200 OK Cseq: 4 Sesson 4231
RTSP: streamng cachng Il cachng de messagg RTSP ha poco senso. Però è desderable fare un cachng de fluss multmedal l pù vcno possble al clent. La maggor parte de meccansm d controllo della cache del protocollo HTTP/1.1 sono stat adottat dal protocollo RTSP. Le ntestazon necessare per l controllo della cache possono essere nserte nelle rcheste e nelle rsposte RTSP SETUP: If-modfed-snce:, Expres:, Va:, Cache-Control: La cache del Proxy può mantenere solo una parte de segment d un certo meda stream. La cache del Proxy può comncare a servre un clent dalla propra cache locale, e successvamente collegars al server d orgne e recuperare le part mancant, senza ntrodurre gap presso l clent. Quando l server d orgne trasmette un flusso verso un clent, e lo stream passa attraverso un proxy, l proxy può utlzzare l TCP per ottenere lo stream, ma l proxy manda ancora messagg d controllo RTSP al server d orgne.
Applcazon real-tme nterattve PC-2-PC phone PC-2-phone Dalpad Net2phone Vdeoconferenza Analzzeremo n dettaglo l funzonamento d un applcazone d telefona su IP (Internet Phone) fra due PC Webcams
Internet Phone over best-effort (1) Servzo Best effort Packet delay, loss e jtter Internet phone: esempo Esamnamo adesso come rtardo, perdte de pacchett e varabltà del rtardo sono gestt nel caso d un applcazone d telefona su IP (Internet Phone). Le applcazon d telefona su IP generano pacchett solo durante perod d parlato (talk spurts) Il bt rate è 64 kbps durante talk spurt Durante talk spurt, l applcazone genera un blocco d 160 byte ogn 20 msec (8 kbytes/sec * 20 msec) Ad ogn blocco l applcazone aggunge l ntestazone; po vene tutto (blocco+header) ncapsulato n un pacchetto UDP e spedto Alcun pacchett possono essere pers e l rtardo de pacchett può fluttuare. Il rcevtore deve determnare quando rprodurre un blocco e che cosa fare quando c sono blocch mancant.
Lmtazon d un servzo best-effort Perdta de pacchett Un segmento UDP è ncapsulato n un datagramma IP La coda de datagramma IP d un router può remprs fno a traboccare provocando lo scarto del datagramma Il TCP può elmnare le perdte, ma Le rtrasmsson ntroducono rtardo Il meccansmo d controllo della congestone del TCP lmta la veloctà d trasmssone La trasmssone d pacchett rdondant può essere d auto Rtardo end-to-end Accumulazone de rtard d trasmssone, propagazone e accodamento Un rtardo end-to-end superore a 400 msec dannegga n modo pesante l nterattvtà; pù pccolo è questo rtardo mglore è la Qualtà del Servzo Varabltà del rtardo (delay jtter) Consderamo due pacchett consecutv n un perodo d parlato L ntervallo d tempo nzale fra due pacchett è 20 msec, ma al rcevtore, a causa del rtardo d accodamento varable dovuto a router, l tempo d nterarrvo può essere maggore o mnore d 20 msec Audo: meccansm per rmozone del jtter al rcevtore Numer d sequenza: l trasmetttore ncrementa l numero d sequenza d un untà per ogn pacchetto che genera Tmestamp: l trasmetttore contrassegna cascun blocco con l tempo al quale l blocco è stato generato Rtardo d rproduzone (playout delay)
Internet Phone (3): playout delay fsso Il rcevtore cerca d rprodurre ogn blocco esattamente q msec dopo la sua generazone Se l tmestamp del blocco è t, l rcevtore lo rproduce all stante t+q. Se l blocco arrva dopo l stante t+q, l rcevtore lo scarta. I numer d sequenza non sono necessar. Può essere utlzzata una stratega d recupero opportuna per compensare le perdte. Compromesso per la scelta d q: q elevato: meno pacchett pers q pccolo: mglora l nterattvtà La scelta del valore d q deve essere effettuata tenendo conto dell ampezza del suo ntervallo d varazone La telefona Internet può tollerare rtard fno a 400 ms, sebbene valor nferor sano preferbl perché mglorano l nterattvtà
Internet phone (4): playout delay fsso Il trasmetttore genera pacchett ogn 20 msec durante talk spurt. Il prmo pacchetto vene rcevuto all stante temporale r La prma rproduzone è programmata con un rtardo nzale par a p-r La seconda rproduzone è programmata con un rtardo nzale par a p -r packets packets generated packets receved loss playout schedule p - r playout schedule p' - r tme r p p'
t r p r t d Adaptve playout delay (1) Stmare l rtardo ntrodotto dalla rete e aggustare l playout delay all nzo d ogn talk spurt. La regolazone adattva del rtardo d rproduzone provoca la compressone o l prolungamento de perod d slenzo d una pccola quanttà non rlevable I blocch sono rprodott ogn 20 msec durante talk spurt. = tmestamp of the th packet = the tme packet s receved by recever = the tme packet s played at recever = network delay for th packet = estmate of average network delay after recevng th packet Stma del valor medo del rtardo ntrodotto dalla rete nella rcezone dell esmo pachetto: d 1 u) d + u( r t ) dove u è una costante (.e., u = 0.01). = ( 1
Adaptve playout delay (2) S stma noltre la devazone meda del rtardo, v : v = ( 1 u) v 1 + u r t d Le stme d d e v sono aggornate per ogn pacchetto rcevuto, nonostante sano utlzzate solo all nzo d un talk spurt. Per l prmo pacchetto d un talk spurt, la rproduzone ha nzo all stante: p = t + d + Kv dove K è una costante con valore postvo. Il rtardo d rproduzone è: q = p t Per l j-esmo pacchetto dello stesso talk spurt, l pacchetto vene rprodotto all stante p = t + j j q
Adaptve playout delay (3) Come s determna se l pacchetto è l prmo n un talk spurt? Se non c fossero ma perdte, l rcevtore potrebbe semplcemente controllare tmestamp. Se la dfferenza fra successv tmestamp è maggore d 20 msec, un talk spurt ha nzo. Poché possono esserc perdte, l rcevtore deve controllare sa tmestamp che numer d sequenza. Se la dfferenza fra successv tmestamp è maggore d 20 msec e numer d sequenza sono prv d nterruzon, ha nzo un talkspurt
Recupero dalla perdta d pacchett (1) Perdta: l pacchetto non arrva o arrva oltre l stante d rproduzone programmato Forward Error Correcton (FEC): Per ogn gruppo d n blocch vene creato un chunk rdondante medante un operazone d XOR effettuata su blocch orgnal S trasmettono gl n+1 blocch, ncrementando la capactà trasmssva d un fattore 1/n Il Playout delay deve essere fssato n modo da consentre la rcezone d tutt gl n+1 pacchett Compromess ncrementando n: s spreca meno capactà trasmssva. Il rtardo d rproduzone è pù elevato La probabltà che 2 o pù blocch sano pers è maggore. E possble rcostrure gl n blocch orgnal se al pù vene perso 1 blocco fra gl n+1 blocch trasmess
Recupero dalla perdta d pacchett (2) Secondo schema d FEC Consstenell nvare uno stream audo a bassa rsoluzone come nformazone rdondante Per esempo, uno stream nomnale PCM a 64 kbps e uno stream rdondante GSM a 13 kbps. Il trasmetttorecreaun pacchetto prendendo l n-esmo chunk dallo stream nomnale e aggungendo ad esso l (n-1)-esmo chunk dallo stream rdondante. Quando le perdte non sono consecutve, l rcevtore può recuperare la perdta. La rproduzone può nzare dopo la rcezone d due pacchett Per superare l problema delle perdte consecutve s può aggungere l (n-1)-esmo e l (n-2)-esmo pacchetto
Recupero dalla perdta d pacchett (3) Cambo d sequenza (Interleavng) I chunk sono suddvs n untà pù pccole Per esempo, 4 untà d 5 msec per chunk Il mttente camba la sequenza delle untà d dat audo prma della trasmssone, n modo che le untà orgnaramente adacent sano separate da una certa dstanza nel flusso trasmesso I pacchett trasmess I chunk sono rassemblat al rcevtore Se un pacchetto vene perso, s rceve tuttava la maggor parte d ogn chunk contengono pccole untà provenent da dvers chunk
Recupero dalla perdta d pacchett (4) Recupero basato sul rcevtore d uno stream audo danneggato Tenta d sostture un pacchetto perso con uno smle all orgnale Garantsce buone prestazon nel caso d basse perdte e d pacchett pccol (4-40 msec) La tecnca pù semplce s basa sulla RIPETIZIONE Tecnche pù complcate utlzzano meccansm d INTERPOLAZIONE