I protocolli di trasporto per multimedia RTP e RTCP

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 Scott Shenker: Fundamental Design Issues for the Future Internet. IEEE JSAC 13(7): 1176-1188 (1995))

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

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

Applicazioni elastiche e “Multimedia” 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 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

Applicazioni e stack protocollare DNS Telnet http ftp Email NFS BGP … DNS RTP Real Audio NFS SNMP Real time apps 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 > 4 4 3 < 2 TCP UDP IP Non Specificati Internet Protocol Suite

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) 2

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 4

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 5

Gruppo Reti - Politecnico di Torino 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 35

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 36

Formato del pacchetto UDP 0 15 16 31 UDP Source Port UDP Destination Port UDP Message Length UDP Checksum (opt.) DATA 32 bit 37

Gruppo Reti - Politecnico di Torino 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 2

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 3

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

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?

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)

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

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

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

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

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

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 ogni T secondi La dimensione del buffer emula un ritardo fisso di Dm secondi Dm compromesso tra bassi ritardi e basse perdite ritardo massimo Dm Distr. # pacchetti ritardo Df

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

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

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

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

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

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

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

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

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)

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

Compensazione del ritardo e del jitter: buffering trasmissione audio CBR Ritardo di rete variabile Ricezione audio Riproduzione di audio CBR Dati complessivi audio in buffer Ritardo di playout al ricevitore tempo Buffering dal lato ricevitore, il ritardo di playout compensa il ritardo e il jitter di rete Ritardo fisso Ritardo adattativo

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à

Ritardo di playout fisso

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à

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

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

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

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

Multimedia Streaming con buffering del client

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

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"> 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>

Operazioni RTSP

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 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 S: 200 3 OK