Applicazioni Real-Time in Internet.ppt

1、1,Applicazioni Real-Time in Internet,2,Multimedia Networking: Overview,Classi di Applicazioni streaming audio/video streaming unidirezionale (multicast) di a/v real-time real-time interattivo audio/video Problematiche in applicazioni multimediali packet jitter packet loss / recovery,Protocolli Inter

2、net per applicazioni multimediali RTP/RTCP RTSP H.323 Multimedia Multicast Destination Set Splitting / Grouping Layering TCP-friendly rate adaptation,3,Approccio,Tecniche per applicazioni multimediali implementate a livello di trasporto e di applicazione. Modifiche allo strato di Rete per applicazio

3、ni multimediali (ex: IntServ, RSVP, Diffserv, scheduling, tariffazione, etc.),4,Classi di Applicazioni Multimediale,Sensibili al ritardo ma possono tollerare perdita di pacchetti. Messaggi contengono dati audio e video (“continuous media”), tre classi di applicazioni: Streaming Real-Time Unidirezion

4、ale Real-Time Interattivo Ogni classe pu richiedere trasmissione broadcast (multicast) o semplicemente unicast,5,Classi di Applicazioni (cont.),Streaming Clients richiedono files audio/video al server e direzionano i dati ottenuti dalla rete alla corrispondente applicazione (helper). Riproduzione co

5、ntinuata. Interattivo: utente pu controllare le operazioni (pausa, resume, avanti veloce, riavvolgi, etc.) Ritardo: dalla richiesta del client fino al playback possono intercorrere da 1 a 10 secondi. In alcune applicazioni richiesta la memorizzazione completa prima del playback (ex: Napster, Gnutell

6、a),6,Classi di Applicazione,Real-Time Unidirezionale: Simile alle stazioni TV e Radio, ma trasmesse sulla rete Non interattivo, solo ascolto o visione, oppure interattivo in seguito a memorizzazione Distribuzione a molteplici utenti attraverso tecniche di Multicast Real-Time Interattivo: Conversazio

7、ne telefonica o video conferenza Requisiti sul ritardo pi stringenti di Streaming e Real-Time unidirezionale Video: 150 msec acceptable Audio: 150 msec good, 400 msec acceptable,7,Problematiche,TCP/UDP/IP fornisce Qualit del Servizio best-effort, nessuna garanzia sul ritardo di un pacchetto, n sulla

8、 media n sulla varianza. Applicazioni Streaming: ritardo tipico di 5-10 secondi accettabile. Le prestazioni si deteriorano in presenza di congestione. Applicazioni Real-Time Interattive: requisiti sul ritardo e sullo jitter sono in genere soddisfatte attraverso il sovra-dimensionamento o la definizi

9、one di classi di priorit nellassegnazione della banda. Le prestazioni si deteriorano con laumento del carico.,8,Problematiche (cont.),La maggioranza dei router supportano solo First-Come-First-Served (FCFS) nel processamento dei pacchetti e nello scheduling di trasmissione. Per controbilanciare limp

10、atto di protocolli “best-effort”, possibile: Usare UDP per evitare il controllo sulla velocit di trasmissione da parte di TCP. Bufferizzare i dati al Client e controllare il playback per controllare lo jitter, ex ritardare di 100 msec la trasmissione Adattare il livello di compressione alla banda di

11、sponibile Assegnare timestamps che dirigano la riproduzione Ridondanza per ridurre la perdita di pacchetti,9,Soluzioni adottate in Reti IP.,Sovradimensionamento: fornire banda addizionale e capacit di caching (e se aumenta il carico?) Modifiche sostanziali ai protocolli : Incorporare la riservazione

12、 delle risorse (banda, processamento, bufferizzazione) e diverse politiche di scheduling. Stabilire accordi preliminari sul livello di servizio (Service Level Agreement, SLA) fornito alle applicazioni, verifica e implementazione degli accordi, corrispondente tariffazione. Modificare le politiche di

13、routing (i.e. non solo best-effort FIFO) per differenziare tra diverse applicazioni ed utenti,10,Compressione Audio e Video,Segnali audio/video necessitano la digitalizzazione e la compressione. Ex: Immagine 1024 x 1024, 24 bit per pixel, richiede 3 Mbit Segnale Audio analogico campionato ad 8000 ca

14、mp/sec. Ogni campione rappresentato con 8 bit: 64Kb/sec (superiore a connessione modem!) CD audio: 705,6 Kb/sec (mono), 1411 Kb/sec (stereo) La fedelt della ricostruzione dipende dalla frequenza del campionamento,11,Compressione Audio e Video,Compressione Audio: GSM(13Kb/sec), G.729 (8 Kb/sec), G.72

15、3.3 (6,4 Kb/s) MPEG layer3, MP3. Comprime musica a 128 Kb/s con piccola degradazione del suono. Ogni parte dellMP3 ancora ascoltabile separatamente. Video: Compressione spaziale e temporale. MPEG 1 per CD-ROM (1,5 Mb/s), MPEG 2 per DVD (3-6 Mb/s),12,Terminologia per Applicazioni Multimediali,Session

16、e Multimediale: una sessione che contiene diverse tipologie di dati e.g., un filmato contenente sia audio e video Sessione Countinuous Multimedia: una sessione la cui informazione deve essere trasmessa continuamente. ex:, audio, video, ma non testo Streaming: applicazione che usa i dati durante la t

17、rasmissione,Data stream,Playback punto,Ric. punto,In trasmissione o da essere trasmesso,13,Streaming,Importante applicazione in crescita a causa della riduzione dei costi di memorizzazione, aumento nellaccesso ad alta velocit, miglioramento del caching e introduzione QoS in reti IP Streaming il magg

18、iore consumatore di banda ad esempio attraverso applicazioni peer-to-peer. Ancora non invece decollata la ditribuzione di streaming di alta qualit File compressi possono essere distribuiti attraverso normali Server Web o attraverso appositi Server streaming File Audio/Video segmentato ed inviato att

19、raverso TCP, UDP o protocollo pubblico di segmentazione: Real Time Protocol (RTP),14,Streaming,Permette controllo interattivo da parte dellutente, ex il protocollo pubblico Real Time Streaming Protocol (RTSP) Applicazione Helper: mostra lo stream tipicamento richiesto attraverso un Web browser; e.g.

20、 RealPlayer; funzionalit tipiche: Decompressione istantanea Rimozione dello Jitter attraverso bufferizzazione Correzione degli errori e recupero delle informazioni perse a causa di congestione: pacchetti ridondanti, ritrasmissione, interpolazione. GUI per il controllo utente,15,Streaming da Web Serv

21、ers,Audio: il file inviato come oggetto HTTP Video: audio ed immagini interleaved in un singolo file, oppure due files separati inviati al client che sincronizza il display, inviati come oggetti HTTP Il Browser richiede gli oggetti che vengono completamente scaricati e poi passati ad un helper per i

22、l display No pipelining Ritardo non accettabile per file di moderata lunghezza,16,Streaming da Web Server (cont.),Alternativa: stabilisci un collegamento socket diretto tra server ed media player Web browser richiede e riceve un Meta File (un file che descrive loggetto da scaricare ) invece del file

23、 stesso Il browser lancia lappropriato helper e gli passa il Meta File; Il media player stabilisce una connessione HTTP con il Web Server ed invia un messaggio di richiesta Il file audio/video inviato dal server al media player,17,Richieste di Meta file,Non permette di interagire in modo strutturato

24、 con il server, ex: pause, rewind E vincolato ad usare TCP,18,Streaming Server,Permette di evitare HTTP, di scegliere UDP piuttosto che TCP, ed un protocollo a livello applicazione appositamente progettato per le esigenze dello streaming.,19,Opzioni nelluso di uno Streaming Server,Usa UDP, ed il Ser

25、ver invia ad una velocit (Compressione e Trasmissione) appropriata per il client; per ridurre lo jitter, il Player bufferizza inizialmente per 2-5 secondi, quindi inizia il display Sender usa TCP alla massima velocit possibile; ritrasmette quando un errore viene incontrato; il Player utilizza un buf

26、fer di dimensioni molto maggiori per ammortizzare la velocit di trasmissione fluttuante di TCP,20,Real Time Streaming Protocol (RTSP),Permette allutente di controllare il display di media continuativi: rewind, fast forward, pause, resume, etcProtocollo fuori banda (usa due connessioni, una per i mes

27、saggi di controllo (Port 554) ed una per i media stream)RFC 2326 permette luso sia di TCP e UDP per la connessione per i messaggi di controllo detto RTSP ChannelNon specifica codifica audio/video, segmentazione dello stream, o modalit di bufferizzazioneCome per Streaming Server, i meta file sono com

28、unicati al Web Browser che lancia il media playerIl Player stabilisce una connessione RTSP per i messaggi di controllo in aggiunta alla connessione per i dati streaming,21,Esempio di Meta File,Twister ,Sincronia audio video,Audiio e video appartengono al medesimo group,22,Comandi RTSP,HTTP protocol,

29、RTSP protocol,23,Esempio di Comunicazione RTSP,C: SETUP rtsp:/ RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp:/ RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/ RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/ RTSP/1.0 Session

30、: 4231 S: 200 3 OK,24,Multimedia vs. Applicazioni Dati,Multimedia e.g., Audio/Video Tollera una certa perdita di pacchetti Vincoli rigidi sul playout,Applicazioni Dati e.g., FTP, web page, telnet Pacchetti persi devono essere recuperati Vicoli temporali: recapito veloce sempre preferibile,Perch non

31、usare semplicemente TCP per traffico multimedia?non necessita un alto livello di affidabilitvelocit pu rallentare o variare “troppo”,25,Trasmissione Multimedia Problematiche e Soluzioni,Jitter Bufferizzazione, tempi di generazione, time-stamps Perdita di Pacchetti Applicazioni tolleranti alle perdit

32、e Interleaving Ritrasmissione (ARQ) o Packet-Level Forward Error Correction (FEC) Single-rate Multicast Destination Set Splitting Layering,26,Jitter,Internet non offre garanzie sul tempo di recapito dei pacchetti Considera una sessione telefonica IP:,Speaker,Listener,Time,Hi There, Whats up?,27,Jitt

33、er (cont.),Intervallo rcv desiderato: Si+1 - Si Intervallo rcv: Ri+1 - Ri Jitter tra pacchetti i e i+1: (Ri+1 - Ri) - (Si+1 - Si),Pkt i,Pkt i+1,Si,Si+1,Ri,Ri+1,Sender:,Pkt i+1,Pkt i,Time,Receiver:,Lo jitter di una coppia di pacchetti la differenza tra lintervallo di tempo che intercorre tra la trasm

34、issione e la ricezione dei due pacchetti,jitter,28,Buffering: un rimedio allo Jitter,Ritarda il playout dei pacchetti ricevuti fino al tempo Si + C (C una costante) Come scegliere il valore di C? Grande jitter valore maggiore di C C piccolo: pi probabile Ri Si + C deadline mancata C grande: Richiede

35、 la bufferizzazione di pi pacchetti Maggiore ritardo di playout Vincoli temporali sullapplicazione limitano C: Applicazioni interattive (telefonia IP) non possono tollerare un grande ritardo di playout (e.g., effetto tipo chiamate internazionali) non-interattive: pi tolleranti al ritardo, ma non ill

36、imitato,29,Telefonia su IP Best-Effort,Applicazioni telefoniche su Internet generano pacchetti durante i periodi di gettito di parole Bit rate 8 KBs, e ogni 20 msec, il mittente forma pacchetti di 160 Bytes + un header La voce codificata incapsulata in un pacchetto UDP ed inviata Alcuni pacchetti po

37、ssono essere persi; perdita fino al 20 % tollerabile;usando TCP si elimina la perdita ma al prezzo considerevole di una maggiore varianza nel ritardo; FEC (Forward Error Correction) in alcuni caso usato per correggere errori e recuperare perdite,30,Telefonia su IP Best-Effort,Ritardo end-to-end sopr

38、a 400 msec non pu essere tollerato; pacchetti che subiscono tale ritardo sono ignorati al ricevente Lo jitter gestito usando timestamps (tempi ti trasmissione), numeri di sequenza progressivi per I pacchetti, e ritardando il playout al ricevitore di una quantit fissa o variabile Con ritardo fissato

39、di playout, il ritardo deve essere quanto pi piccolo possibile senza rischiare di perdere troppi pacchetti; il ritardo non pu eccedere i 400 msec. Tipicamente 150 msec.,31,Telefonia su Internet con ritardo di playout fissato,Compromesso tra ritardo e perdita di pacchetti,32,Ritardo di playout adatti

40、vo,Per alcune applicazioni, il ritardo di playout non deve necessariamente essere fissato Esempi: Il parlato ha periodi di parlato seguiti da intervalli di silenzio Si pu stimare il ritardo di riproduzione allinizio di ciascun periodo di attivit vocale. Questa regolazione adattiva del ritardo di rip

41、roduzione far si che le pause dei trasmittenti siano compresse o prolungate, scondo la necessit,33,Ritardo di playout adattivo (cont.),Obiettivo usare valori per il ritardo che seguono la stima di ritardo della rete durante la sessione Il ritardo di playout calcolato per ogni intervallo di parlato s

42、ulla base del ritardo medio e della varianza osservati Il ritardo medio e la varianza stimati sono calcolati in modo simile alla stima del Round Trip Time in TCP I valori usati per un periodo di parlato sono i valori osservati sul primo pacchetto del periodo,34,Ritardo di playout adattivo (cont.),ti

43、: tempo di generazione delli-esimo pacchetto ri: tempo di ricezione pi: tempo di riproduzione Stima del ritardo: di = (1-u) di-1 + u (ri - ti) Stima della varianza vi = (1-u) vi-1 + u |ri ti di|Primo pacchetto del periodo di parlato pi = ti + di + K vi Pacchetti successivi: pj = tj + di + K vi, una

44、media pesata dei ritardi di rete osservati,35,Ritardo di playout adattivo (cont.),Dobbiamo individuare i periodi di attivit Se non c perdita Una differenza nei timestamp di almeno 20 msec tra due pacchetti nuovo periodo di attivit Se vi perdita di pacchetti due pacchetti consecutivi possono apparten

45、ere allo stesso periodo di parlato anche se hanno marcature temporali superiori a 20 msec Lanalisi dei numeri di sequenza congiuntamente ai timestamps pu aiutare nel determinare il primo pacchetto di un periodo di parlato,36,Riduzione delle perdite,Problema: pacchetti devono essere recuperati prima

46、della deadline dellapplicazione Soluzione 1: usa ARQ (Automatic Repeat Request: i.e., ACKs & NAKs) Ricorda: non accettabile per applicazioni interattive Soluzione 2: Forward Error Correction (FEC) Invia un “repair” prima che la perdita individuata Simplest FEC: trasmetti copie ridondanti,Pkt i,Pkt i

47、,Pkt i+1,Pkt i+1,Pkt i+2,Pkt i+2,Sender:,Receiver:,Pkt i,Pkt i+1,Pkt i+1,duplicate,i+2 lost,37,Tecniche FEC pi avanzate,FEC spesso usato a livello di bit per riparare bit corrotti o mancanti (i.e., al livello data link)Consideriamo FEC (Erasure Codes) allo strato di rete (pacchetti speciali di retti

48、fica):,header,data,FEC bits,Data 1,Data 2,Data 3,FEC 1,FEC 2,38,Un semplice codice XOR,Per bassi tassi di perdita (e.g. 5%), inviare duplicati costoso (banda sprecata) Codice XOR XOR un gruppo di pacchetti per produrre un pacchetto di recupero Trasmetti dati + XOR: pu recuperare un pacchetto perso,1

49、0101,11100,00111,11000,10110,10101,11100,00111,11000,10110,39,Fec (Hamming Code),000 001 010 100 011 101 110 111,000,111,tx,rx,1 errore,2 errori,correzione,No correzione,0,1,Trasmetto 0,Distanza di hamming Es: 000,110 sono a distanza 2,40,Reed-Solomon Codes,Basati su semplice algebra lineare recuper

50、a n variabili da n equazioni ogni pacchetto rappresenta un valore Mittente e ricevitore conoscono a quali equazioni appartiene ogni pacchetto (i.e., information in header) Rcvr pu ricostruire n pacchetti da ogni insieme di n dati pi pacchetti di recupero Invia n pacchetti dati + k pacchetti di recupero, quindi se non pi di k pacchetti sono persi tutti i dati possono essere recuperati In pratica, per limitare la computazione, algebra lineare eseguita su campi diversi da ,