Next: Integrated Services (IntServ) Up: La trasmissione in real-time Previous: La trasmissione in real-time Contents Index
Viene fatta qui una carrellata su quelli che sono i principali requisiti per realizzare una buona trasmissione real-time [7]. Come si vedrà, esistono due diversi tipi di requisiti, i primi più legati alla qualità del servizio mentre gli altri sono legati ad una gestione efficiente della trasmissione ed alla collezione delle informazioni provenienti dai vari host.
Nel primo caso la soluzione deve essere necessariamente affidata a tecniche che ci permettano di riservare la qualità del servizio, vengono quindi analizzate le due alternative più promettenti che sono Integrated Services e Differentiated Services.
Per la gestione della sessione invece è possibile utilizzare il protocollo Real Time Protocol (RTP), che completa UDP di quelle informazioni utili se si vuole trasmettere in tempo reale. Chiaramente le due soluzioni (qualità del servizio e RTP) non sono mutuamente esclusive ma bensì complementari, in quanto affrontano problemi diversi. C'è da dire però che al momento le tecniche per la prenotazione delle risorse di rete sono ancora in fase sperimentale, e quindi non disponibili sulla rete, anche perché richiedono modifiche alle infrastrutture della stessa. Per RTP, invece, non c'è alcun problema, essendo un protocollo di livello applicazione non necessita di modifiche particolari ai router o agli altri elementi della rete, è l'applicazione che lo vuole utilizzare che si deve accollare l'onere di implementarlo.
Una trasmissione in tempo reale deve essere caratterizzata da:
Si pensi ad esempio ad una applicazione di videoconferenza nella quale due o più persone si scambiano audio (ed eventualmente anche video) realizzando di fatto una conversazione tramite la rete. Se i pacchetti arrivassero con ritardi elevati sarebbe limitata l'interattività della sessione3.1, tutto questo renderebbe innaturale e poco pratica la conversazione.
Contenere il jitter (variazione del ritardo d'arrivo dei pacchetti) consente invece di ottenere una riproduzione fluida del flusso ricevuto. Per ammortizzare il jitter è certamente possibile implementare un sistema di buffering nella ricezione dei pacchetti, ma bufferizzare i pacchetti comporta l'introduzione di un ulteriore ritardo nella riproduzione.
Per risorse di rete intendiamo soprattutto l'ampiezza di banda. Infatti, se la capacità del collegamento è inferiore all'ampiezza di banda richiesta le code all'interno dei router tenderanno a crescere. In questo modo si avrà un aumento del ritardo d'arrivo dei pacchetti ed inoltre si potranno avere delle perdite.
Da quanto detto risulta subito chiaro tra i due protocolli di livello trasporto
la scelta ricade inevitabilmente su UDP. TCP, infatti,
al fine di garantire l'arrivo di tutti i pacchetti ed il loro riordino, introduce
ritardi (anche molto variabili) che si vanno a sommare a quelli introdotti dalla
rete, e si dimostra quindi del tutto inadatto alla trasmissione in tempo reale.
Non bisogna però pensare che UDP sia la soluzione a tutti i problemi. Infatti,
sebbene per la sua semplicità, esso non influenzi i ritardi dei pacchetti, non
è comunque in grado di garantire sull'attuale rete Internet tutte le caratteristiche
che sono state elencate in precedenza. Si richiedono, infatti, meccanismi che
permettano di riservare e garantire la qualità del servizio. Esistono diversi
filoni di ricerca che puntano su soluzioni diverse, i più promettenti sembrano
però essere il modello Integrated Services insieme al protocollo RSVP,
ed il modello Differentiated Services. Tali modelli vengono descritti
rispettivamente nei paragrafi ![[*]](crossref.png)
e .
Per semplificare il compito delle applicazioni che producono/ricevono flusso real time è importante avere alcune informazioni ausiliarie come:
Un timestamp è un'etichetta temporale che permette di risalire all'istante in cui il payload è stato acquisito e/o codificato. Conoscere i timestamp permette di ricostruire l'esatta tempificazione della sequenza ricevuta e quindi di riprodurla in modo più simile all'originale. Inoltre grazie ai timestamp si possono ricostruire informazioni quali il ritardo dei pacchetti oppure il jitter, e questo permette, ad esempio, di valutare la qualità della trasmissione.
In una trasmissione real-time come abbiamo visto perdere un pacchetto è preferibile rispetto a riceverlo con un forte ritardo, nonostante questo può essere molto utile numerare i pacchetti3.2. In questo modo, infatti, si riesce a stabilire se ci sono state perdite di pacchetti e si possono applicare tecniche che permettono di compensare in qualche modo questa perdita (tecniche di error concealment).
Utilizzare identificativi per i diversi tipi di payload (ad esempio per i diversi standard di codifica) consente di utilizzare applicazioni diverse per trattare uno stesso flusso, semplificando anche la realizzazione di applicazioni che gestiscano contemporaneamente più flussi diversi.
Nel paragrafo precedente si è concluso che per le trasmissioni real time è consigliabile
affidarsi ad UDP, tuttavia esso non dispone delle caratteristiche che sono state
elencate in questo paragrafo. Per questo motivo è stato pensato il protocollo
RTP che viene presentato nel paragrafo .