I protocolli di trasporto per multimedia RTP e RTCP

1. I protocolli di trasporto per multimediaRTP e RTCP

2. Il problema della QoS • Problema: fornire un’adeguata qualità di servizio (perdite, ritardi, banda minima…) ad applicazioni aventi requisiti diversi • Storicamente, due possibili soluzioni: (vedi Scott Shenker: Fundamental Design Issues for the Future Internet) • “gettare banda” sul problema • Controllare il traffico, a livello di rete, a livello di connessione, a livello di pacchetto • Il controllo del traffico è più difficile, ma dà risultati migliori

3. Sommario • Applicazioni e protocolli di Trasporto • Classi di Applicazioni • I protocolli di trasporto: UDP e TCP • RTP/UDP per applicazioni multimediali • Requisiti delle applicazioni

4. Tassonomia delle applicazioni • Due classi (dal punto di vista del controllo del traffico) • Applicazioni elastiche (opportunistiche) • Se ci sono risorse, le applicazioni elastiche cercano di usarle • Se le risorse sono temporaneamente indisponibili, le applicazioni elastiche possono “attendere” (es: WWW, email, FTP…) • Applicazioni “multimedia” • Ogni applicazione richiede una minima quantità di risorse • Se la quantità minima è presente, l’applicazione funziona • Se la quantità minima è indisponibile, l’applicazione non funziona

5. Applicazioni elastiche Un utente “umano” attende informazioni da un server Preferibile un basso ritardo end-to-end (non essenziale) Banda istantanea richiesta: bassa Perdite di pacchetti recuperate dal protocollo di trasporto, a scapito del ritardo end-to-end Applicazioni “multimedia” Due utenti umani interagiscono ai capi della rete Essenziale un basso ritardo (un pacchetto in ritardo equivale ad un pacchetto perso) Banda richiesta elevata Robuste a perdite contenute di pacchetti Applicazioni elastiche e “Multimedia”

6. Applicazioni Multimedia • Applicazioni multimediali conversazionali • Voce o video su IP per audio/videoconferenze • Applicazioni multimediali interattive • Simulazioni distribuite, giochi in rete • Applicazioni multimediali non interattive (streaming) • Insegnamento a distanza, video on demand

7. Quale protocollo di trasporto? UDP è adatto a: Richieste-risposte (LAN) Applicazioni multimediali Multicast TCP (affidabilità) è adatto a : Trasferimenti di file Emulazione di terminale Richiesta-risposta (WAN) unicast Applicazioni e stack protocollare DNS Telnet http ftp Email NFS BGP … DNS RTP Real Audio NFS SNMP Real time apps > 4 4 3 < 2 TCP UDP IP Non Specificati Internet Protocol Suite

8. Il livello Rete: IP • E’ un protocollo di livello 3 • Si occupa quindi dell’indirizzamento e instradamento dei pacchetti (o datagram)in rete • La consegna dei pacchetti IP ha caratteristiche di: • inaffidabilità (unreliable) • assenza di connessione (connectionless)

9. Il livello Rete: IP • IP non offre garanzie sulla consegna dei datagram • In caso di guasti prima della consegna (es. un router fuori servizio), il protocollo IP • scarta il datagram • cerca di inviare un messaggio di errore al mittente • L’affidabilità va garantita dai livelli superiori • Il servizio offerto da IP è detto best-effort

10. Il livello Rete: IP • IP non conserva informazioni di stato sui datagram in corso di trasmissione • Ogni datagram viene instradato in modo indipendente dai precedenti • Può quindi accadere che due pacchetti provenienti dallo stesso host e aventi la stessa destinazione facciano strade diverse

11. Il protocollo UDP (1) • UDP (User Datagram Protocol ) permette alle applicazioni di un host l’invio di datagram ad altre applicazioni di un host remoto • Definito da RFC-768 (1980) • UDP fornisce un servizio di livello 4, ma: • connectionless (pacchetti fuori sequenza) • non affidabile (pacchetti persi) • senza controllo di flusso (saturazione del ricevitore) Gruppo Reti - Politecnico di Torino

12. Il protocollo UDP (2) • Pacchetti di formato semplice con checksum opzionale • Applicazioni end-to-end identificate da: • Indirizzo IP sorgente, Indirizzo IP destinazione • Porta UDP sorgente, porta UDP sorgente

13. Formato del pacchetto UDP 0 15 1631 UDP Source Port UDP Destination Port UDP Message Length UDP Checksum (opt.) DATA 32 bit

14. Il protocollo TCP (1) • TCP (Transmission Control Protocol ) è un protocollo di livello 4 (trasporto) • Definito da RFC 1122/1123… e decine di altri! • E’ un protocollo connection-oriented • E’ un protocollo affidabile • E’ un protocollo full-duplex Gruppo Reti - Politecnico di Torino

15. Il protocollo TCP (2) • Ritrasmette se non riceve conferma di ricezione • Esegue controllo di congestione end-to-end per evitare che la rete venga utilizzata oltre la sua capacità • Esegue controllo di flusso end-to-end perchè un host veloce non saturi un host lento • Frammenta (o raccoglie) l’informazione in segmenti di dimensione opportuna • Risequenza i datagram IP che arrivano fuori sequenza

16. 0 15 1631 Source port Number Destin. Port Number Sequence Number Acknowledgement Number HLEN Resv. Dimens. Finestra TCP flags checksum Urgent Pointer 32 bit Formato pacchetto TCP Gruppo Reti - Politecnico di Torino

17. Comunicazioni Multimediali: problematiche • La pacchettizzazione • Campioni audio pari a pochi bit • Immagine singola di dimensioni molto elevate • Come si distingue tra codifiche differenti in ricezione? • Come porre rimedio ai “limiti” di IP? • Perdita di pacchetti • Riordinamento di pacchetti • Duplicazione di pacchetti • Come notificare la corretta ricezione alla sorgente? • Come supportare comunicazioni tra più utenti?

18. Trasporto di comunicazioni multimediali: TCP • Si può usare TCP? • TCP offre un trasporto affidabile, ma le ritrasmissioni e il controllo di flusso/congestione causano ritardi in caso di perdita • TCP non supporta multicast • TCP può essere usato per trasferire “file” multimediali (in email o in pagine Web)

19. Trasporto di comunicazioni multimediali: UDP • Si può usare UDP? • UDP supporta multicast • Non riordina dati ricevuti fuori sequenza • Non rileva perdite • Non reagisce a variazioni del ritardo • Non identifica contenuti multimediali • IETF: introduzione di RTP “sopra” UDP

20. RTP: Real-time Transport Protocol • Introdotto dall’RFC 1889 • Costituisce un “framework” su cui realizzare applicazioni multimediali • Fornisce i meccanismi di base per il trasferimento di dati multimediali • Composto da due “sotto-protocolli”: • RTP: governa il flusso di dati multimediali (porte pari) • RTCP: fornisce un feedback al trasmettitore sulla qualità della trasmissione in corso (porte dispari) • Funzioni complementari possono essere aggiunte nelle applicazioni

21. Esempio: applicazione multimediale • Telefonia su IP: tre differenti problematiche • Stabilire la comunicazione, trovare l’indirizzi IP per raggiungere l’interlocutore, negoziare il tipo di codifica o compressione • Quando la sessione è stata stabilita, trasferire i pacchetti audio • Periodicamente, inviare delle informazioni di feedback al trasmettitore per indicare la qualità della ricezione H.323 SIP RTP RTCP

22. RTP e la perdita di pacchetti • UDP/IP non garantiscono che ogni pacchetto percorra la stessa strada verso la destinazione • Pacchetti possono essere persi o essere consegnati fuori sequenza • RTP prevede dei numeri di sequenza nell’intestazione RTP

23. RTP e il problema del jitter (1) • In presenza di segnali sincroni (voce), viene inviato un pacchetto ogni T secondi • La rete introduce ritardi variabili anche se non ci sono perdite (es., in un buffer di un router) Come recuperare il segnale sincrono in ricezione? R

24. RTP e il problema del jitter (2) • Possibile soluzione: introdurre ritardo alla destinazione • Uso buffer di playback • Pacchetti in arrivo sono memorizzati • Viene letto un pacchetto ogniT secondi • La dimensione del buffer emula unritardo fisso di Dm secondi • Dm compromesso tra bassi ritardi e basse perdite ritardo massimo Dm Distr. # pacchetti ritardo Df

25. RTP e il problema del jitter (3) • Se ho soppressione del silenzio in trasmissione? • Durante intervalli parlati: un pacchetto ogni T secondi • Durante silenzi: nessun pacchetto • … un pacchetto può essere in ritardo perché • è stato ritardato nella rete • è stato preceduto da un periodo di silenzio • Il numero di sequenza non basta • Bisogna introdurre un ‘timestamp’ nell’intestazione del pacchetto RTP

26. Formato pacchetto RTP/UDP 32 bits Marker Può essere usato per indicareestremi di un fotogramma Destination port Source port UDP Header 8 B Checksum Length PType Indica il tipo di codifica usato nelpayload del pacchetto Sequence number V PX CC M PType RTP Header 12 B Timestamp Synchronization source (SSRC) identifier Sequence number Sequenza monotonica crescente (+1 per ogni RTP PDU) Possible header extension Timestamp Istante in cui l’informazione contenuta nella PDUè stata prodotta. Diverse PDU possono avere lostesso timestamp. Il timestamp è generato da unclock indipendente dall’applicazione Payload SSRC Identificativo della sorgente che ha creatoil contenuto del payload. L’identificativo èscelto a caso dalla sorgente Contenuto in formato dipendentedall’applicazione

27. RTCP: obiettivi • Qualità del servizio e controllo di congestione • I pacchetti RTCP sono usati come “ACK a bassa frequenza” per indicare la qualità della ricezione • In base ai “report” RTCP il server può adattare la codifica allo stato della comunicazione • Identificazione • Fornisce più informazioni sull’applicativo utente che partecipa alla trasmissione (segnalazione) • Stima del numero di partecipanti multicast • Necessaria per frazionare la banda usata da RTCP

28. RTP Control Protocol (RTCP) • Protocollo di controllo per il flusso dati RTP • Definisce lo scambio di informazioni tra sorgente e destinazione • Vari tipi di ‘pacchetti’ RTCP: • SR (sender report): inviato da tutte le sorgenti attive a tutti i partecipanti; include statistiche di TX e RX • RR (receiver report): inviato da tutte le sorgenti passive a tutti i partecipanti; include statistiche di RX • SDES: descrizione della sorgente • BYE: fine della sessione • APP: application-specific

29. RTCP Sender Report • Il SR è usato per riassumere la quantità di informazione appena inviata • Un SR contiene: • Timestamp assoluto (NTP) all’istante di invio • Timestamp relativo al flusso RTP in corso • Quantità di dati inviati dall’inizio della sessione • Numero totale di pacchetti RTP inviati • Numero totale di byte inviati

30. RTCP Receiver Report • I RR vengono inviati per informare i mittenti della qualità della ricezione • Viene inviato un RR ad ogni sorgente da cui si è ricevuto un SR • Un RR contiene: • Indicazione della sorgente ascoltata • Timestamp dell’ultimo SR ricevuto • Ritardo dalla ricezione dell’ultimo SR • Numero di sequenza più alto ricevuto dalla sorgente • Numero di pacchetti RTP della connessione persi • Frazione di pacchetti RTP della connessione persi • Stima del jitter dei pacchetti RTP della connessione

31. RTCP SDES • Usato dalle sorgenti e dai ricevitori per “presentarsi” • Un SDES può contenere: • CNAME: identificativo dell’utente (user@host.domain) • NAME: nome della persona che usa l’applicazione • EMAIL • PHONE • LOC: indicazione geografica dell’utente • TOOL: applicazione che sta usando RTP • NOTE

32. Traffico Multimediale • Interattivo • Telefonia su IP, la gestione dei ritardi • Streaming • RTSP, il controllo del playback

33. Traffico Multimedia interattivo: Internet Phone • Audio in ingresso: alternanza di suoni e silenzi • Pacchetti generati a rate costante o quando potenza sonora è oltre un certo valore: • Es: 20 ms di campioni audio a 8kb/s • Pacchetti subiscono ritardi (da compensare) e perdite: • Perdite in rete, congestione (max tollerabili: 10%) • Perdite per ritardi (datagram IP troppo tardi per playout) ritardo max tollerabile: 400 ms • Tecniche di compensazione • Al trasmettitore (codifiche adattative) • Al ricevitore (bufferizzazione)

34. Reazione a perdite, ritardo e jitter • Uso codificatore a bit-rate variabile • Invio pacchetti di piccole dimensioni quando c’è congestione e il ritardo è elevato • Invio pacchetti di grosse dimensioni se la rete è scarica • Mi occorrono meccanismi di stima della qualità di ricezione, ed un algoritmo di controllo del bit rate del trasmettitore, reazionato in funzione di: • Perdite istantanee e medie • Ritardo relativo e/o assoluto • jitter

35. Ricezione audio Ritardodi retevariabile audio in buffer Compensazione del ritardo e del jitter: buffering • Buffering dal lato ricevitore, il ritardo di playout compensa il ritardo e il jitter di rete • Ritardo fisso • Ritardo adattativo trasmissioneaudio CBR Riproduzionedi audio CBR Dati complessivi Ritardo di playout al ricevitore tempo

36. Ritardo di playout fisso • Il ricevitore riproduce ogni campione esattamente q secondi dopo la generazione del campione • Se il campione ha timestamp t, riproduco a t+q • Se il campione arriva dopo t+q, il campione è considerato perso • Il valore di ‘q’: • q elevato: meno pacchetti persi, più ritardo, più buffer • q basso: migliore interattività

37. Ritardo di playout fisso

38. Ritardo di playout adattativo • Obiettivo: minimizzare il ritardo di playout, mantenendo basso il livello di perdite • Stima del ritardo di rete, adattività del ritardo di playout all’inizio del parlato • Periodi di silenzio compressi o allungati • Campioni sempre riprodotti a distanza di 20 ms nei periodi di attività

39. Multimedia Streaming • Streaming • File multimediale memorizzato alla sorgente • Trasmesso al client • La riproduzione al client inizia mentre il trasferimento è ancora in corso • Vincolo: dati mancanti devono arrivare prima che la riproduzione abbia termine

40. 2. video inviato 1. video registrato streaming: a questo istante, il client inizia a riprodurre la parteiniziale del video, mentre il serversta ancora inviando Multimedia Streaming Dati complessivi 3. video ricevuto, riprodotto dal client Ritardo di rete tempo Video server

41. Multimedia:l’approccio più semplice • audio o video memorizzato in un file • File trasferito come oggetto HTTP • Ricevuto per intero dal client • Inviato al player audio, video non in “streaming”: • non vi è pipelining, ritardi elevati prima di riproduzione

42. Multimedia: l’approccio streaming • Il browser del client riceve il metafile con la descrizione del file multimedia streaming • Il browser lancia il player e gli passa il metafile • Il player contatta il server • Il server manda in streaming l’audio e il video

43. Multimedia Streaming con buffering del client

44. Controllo utente di streaming multimedia: il protocollo RTSP • Real Time Streaming Protocol (RTSP): RFC 2326 • Supporta controllo utente: rewind, FF, pausa, riprendi • Protocollo fuori banda: • Una porta (544) per messaggi di controllo e segnalazione • Una porta per lo stream multimediale • Uso TCP o UDP per connessione di controllo • Operazioni • Invio di un “metafile” al browser • Il browser attiva il player appropriato • Il player attiva una connessione di controllo e una connessione dati RTSP verso il server

45. Esempio di metafile <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>

46. Operazioni RTSP

47. Esempio di messaggi RTSP 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