Università di Roma “La Sapienza”

Tesi di laurea in INGEGNERIA delle TELECOMUNICAZIONI



Titolo:

VERIFICA SIMULATIVA DI UNA TECNICA DI

CONTROLLO DI CONGESTIONE BASATA SU EQUAZIONE,

CONGIUNTA A FEC,

PER TRASMISSIONI VoIP MULTIRATE

A DIMENSIONE DI PACCHETTO VARIABILE















Laureando: Francesco Scialpi

Relatore: Prof. Alessandro Falaschi












Dedico il mio lavoro e la mia tesi

alla memoria di mio nonno Francesco,

ieri come oggi fulgido esempio di comportamento e di operosità.



Indice generale

1.Capitolo 1: Controllo di errore e di congestione per applicazioni real-time 4

1.1.La rete Internet e le applicazioni real-time 4

1.2.Tecniche di recupero di errore per stream audio 7

1.3.La “TCP-Friendliness”. Tecniche di controllo congestione di tipo TCP-Friendly 10

2.Capitolo 2: SFEC e TFRC. Lo stato dell'arte 13

2.1. Prestazioni aggregate di SFEC. L'esperienza di Podolsky 13

2.2. L'esperienza di Podolsky: conclusioni e completamento 17

2.3. La divisione ottimale tra encoding primario e ridondanza. Il risultato di Bolot 18

2.4. IL TCP-Friendly Rate Control - TFRC 18

2.5. TFRC ed i flussi a dimensione di pacchetto variabile 21

3. Capitolo3: Le simulazioni eseguite. Risultati e conclusioni 28

3.1. Estensione al meccanismo TFRC del protocollo RTP 28

3.2. Inserimento di più frame audio in un pacchetto RTP 29

3.3. I Codec Selezionati. IL Mean Opinion Score 31

3.4. Modelli di rete e di canale utilizzati. Il modello di Gilbert 33

3.5. Simulazioni con flussi separati 35

3.6. Simulazioni con flussi in concorrenza 39

3.6.1. Primo lotto – DropSwitch di Bernoulli 40

3.6.2. Primo lotto – DropSwitch di Gilbert 49

3.6.3. Secondo lotto – DropSwitch di Bernoulli 58

3.6.4. Secondo lotto – Dropswitch di Gilbert 66

3.7. Discussione e conclusioni 74

4. Appendice A: costruzione di una funzione tasso-distorsione tramite vocoder “SPEEX” 76

5. Bibliografia 84


  1. Capitolo 1: Controllo di errore e di congestione per applicazioni real-time


    1. La rete Internet e le applicazioni real-time


L'esplosione che la rete Internet ha conosciuto negli ultimi anni e' sotto gli occhi di tutti. Quello che non e' altrettanto evidente all'utente finale, e non deve esserlo per una precisa scelta di user-friendliness, e' l'insieme di azioni protocollari che concorrono a costituire i servizi da egli utilizzati (azioni che possono essere complesse e molto diverse tra loro).

Così come avere la patente e saper guidare un'automobile non implica la conoscenza del funzionamento del motore a scoppio, per utilizzare una rete non deve essere necessario conoscerne l'architettura. Idealmente, vogliamo che chiunque possa “premere un tasto” sulla propria interfaccia grafica tanto per avviare il download di un archivio via FTP quanto per instaurare una connessione telefonica via IP.

I due esempi riportati non sono scelti a caso. Si tratta infatti di applicazioni appartenenti a due categorie diverse, con diverse caratteristiche e necessità. Il donwload di un archivio e' un caso di applicazione di tipo dati non real-time. Altri esempi sono web browsing, e-mail, Telnet eccetera. Quando usiamo queste applicazioni, desideriamo una integrità dei dati il più elevata possibile (in quanto la mancata – o errata – ricezione anche di un solo pacchetto potrebbe significare dover scaricare l'archivio da capo), mentre non abbiamo requisiti particolari sul ritardo con cui i pacchetti debbano raggiungere il nostro terminale. Quando invece usiamo la rete per comunicazione vocale, ma anche per guardare un filmato, un video-clip, oppure per partecipare a una videconferenza o ad una sessione di gioco on-line, siamo in presenza di uno stream audiovideo con esigenze di tempo reale. Chi fruisce di un servizio simile non ha esigenze stringenti in termini di integrità dei dati (la perdita episodica di un pacchetto non inficia l'utilità del servizio), mentre e' fondamentale che i pacchetti vengano presentati in ricezione con un ritardo il più possibile costante.

Per rimediare al jitter si prevede la presenza di un buffer in ricezione, detto playout buffer, che comunque per vari motivi non può essere troppo grande.

Le differenze appena esposte sono tali da giustificare l'utilizzo di protocolli diversi per ognuna delle due categorie. Mentre il protocollo IP svolge in entrambi i casi le funzioni dei primi tre strati del modello OSI, le applicazioni non real-time utilizzano TCP come protocollo di strato 4, a differenza di quelle real-time che si servono di UDP (User Datagram Protocol). Al di sopra di UDP solitamente troviamo RTP (Real-Time Transport Protocol).




TCP e' un protocollo complesso, tra le cui funzioni troviamo:


  1. controllo di errore, ovvero capacità di accorgersi di un evento di perdita di pacchetto, e di correre ai ripari, ritrasmettendo il pacchetto;

  2. controllo di congestione, ovvero capacità di rendersi conto di quando la rete non e' in grado (temporaneamente o meno) di sopportare il flusso dati che le viene offerto, e di diminuire l'entità del flusso di conseguenza.

UDP e' invece un protocollo più semplice, che non fornisce questi servizi (o meglio ne delega la realizzazione agli strati più alti, cioè direttamente all'applicazione).

E' appena il caso di sottolineare l'importanza del controllo di congestione nella rete Internet: in sua assenza, davanti ad una rete congestionata che perde pacchetti, le applicazioni ritrasmetterebbero nuove copie dei pacchetti, che andrebbero perse anch'esse. Il traffico aumenterebbe anziché diminuire, e si giungerebbe al collasso della rete (congestion collapse). Inoltre, anche laddove le conseguenze non fossero così funeste, chiediamoci cosa succede quando un link limitato in banda viene condiviso da flussi che operano controllo di congestione e flussi che non lo operano. Inevitabilmente, i flussi appartenenti al secondo tipo si appropriano di tutta la banda che loro necessita, a spese dei flussi del primo tipo, i quali invece diminuiscono il proprio bitrate nell'interesse della rete. Questa condizione e' conosciuta come unfairness, e diremo che il flusso non disposto a cedere banda (o a cederne poca) è unfair nei confronti di un flusso che invece arretra di fronte a congestione.

Lo stato di buona salute in cui l'attuale Internet versa e' dovuto:



Riguardo quest'ultimo punto, però, le cose stanno rapidamente cambiando, e le applicazioni con esigenze di tempo reale diventano sempre più di uso quotidiano. Queste applicazioni, lo ripetiamo, hanno delle precise richieste di basso ritardo e banda minima garantita, che Internet così com'e' oggi non e' in grado di fornire.

Abbiamo quindi:


Va da sé che la prima soluzione richiederebbe tempi medio-lunghi e uno sforzo non indifferente di standardizzazione a livello internazionale. Inoltre va considerato il fatto che, anche il giorno in cui saranno disponibili delle classi a qualità garantita, il loro utilizzo presumibilmente comporterà un costo monetario per l'utente finale. Anche allora, pertanto, dovremo aspettarci che una percentuale di utenza preferisca servirsi della classe best effort, fruendo di una qualità inferiore ma a costo zero. Per questi motivi, e' opinione diffusa che la seconda soluzione (realizzare applicazioni real-time adatte alla rete Internet così com'é oggi) sia un valido oggetto di ricerca.

Verrebbe da chiedersi, se TCP ha dei meccanismi di controllo di congestione e di errore, per di più estremamente validi, perchè non utilizzare gli stessi meccanismi anche in UDP?

Purtroppo le cose non sono così semplici:



La vastità dell'argomento esposto è tale che nell'ambito di questa tesi è stato necessario ridursi ad un sottocaso. In particolare, si è scelto di considerare specificamente il problema della trasmissione del parlato. Un modello di applicazione VoIP (Voice Over IP), dotato di controllo di congestione e di errore, è stato sviluppato e implementato all'interno del simulatore di reti Omnet++. Quindi è stata condotta una serie di simulazioni al fine di valutare, sotto diverse condizioni, tanto la fairness di questa applicazione rispetto alle applicazioni TCP, in termini di throughput, quanto la qualità audio riscontrata al ricevitore.

Prima di entrare in ulteriore dettaglio, si effettua una panoramica delle soluzioni possibili.


    1. Tecniche di recupero di errore per stream audio


La prima distinzione da effettuare e' quella tra



Come e' facile immaginare, il primo tipo di tecnica e' meno efficace, ma e' computazionalmente meno oneroso. Si ricordi inoltre che spesso il sender e' una singola workstation che gestisce diverse connessioni contemporaneamente, quindi spostare parte del peso computazionale dal sender verso il receiver e' spesso una buona idea.

Specularmente, le tecniche sender-based presentano una complessità computazionale più elevata, ma garantiscono risultati migliori.

E' il caso di dire che le due tecniche non sono mutualmente esclusive, anzi sono adatte a lavorare in maniera complementare. Una applicazione real-time potrebbe servirsi di un metodo sender-based per riparare la maggior parte degli errori, con buona qualità della riparazione, e utilizzare un metodo receiver-based più scadente per gli sporadici errori a cui non e' stato possibile rimediare applicando la prima tecnica.

Nell'ambito delle tecniche receiver-based, distinguiamo:


  1. schemi basati sull'inserzione di un pacchetto sostitutivo. Un frame audio non pervenuto viene sostituito da un frame di silenzio, di rumore bianco, oppure dalla ripetizione del pacchetto precedente. In quest'ultimo caso è possibile, oltre che opportuno, operare un fading del volume di ascolto. Con l'eccezione del primo caso, le cui prestazioni sono davvero scarse, il miglioramento percettivo è piuttosto pronunciato. E' stato dimostrato che rumore bianco o ripetizione del pacchetto precedente sono, per l'apparato cerebro-uditivo umano, stimoli sufficienti per l'attivazione del processo noto come restaurazione fonemica, tramite il quale un ascoltatore inconsciamente “indovina” qual e' il frame audio corretto. Un frame di silenzio, oltre a non innescare la restaurazione fonemica, spesso viene erroneamente interpretato come una pausa nella conversazione, con ricadute pesanti sulla gradevolezza della comunicazione.

  2. Schemi basati sull'interpolazione, in cui vengono usate tecniche di pattern matching per generare, a partire dai pacchetti precedenti (e a volte anche da quelli successivi), un pacchetto sostitutivo appropriato. Alcuni di questi schemi si basano sulla riproduzione della forma d'onda, altri sulla riproduzione del pitch, altri ancora su sistemi diversi

  3. Schemi basati sulla rigenerazione di un pacchetto. Conoscendo cioé l'algoritmo di compressione applicato all'audio, si cerca di ricavare dei parametri plausibili del codec, e di sintetizzare un pacchetto sostitutivo. Molti codec sono “basati sullo stato” (state-based), quindi per la riparazione è possibile usare una grossa quantità di informazione, con risultati apprezzabili.

In generale, tutte le tecniche receiver-based forniscono dei risultati accettabili solo se la durata temporale di un evento di perdita e' inferiore a quella di un fonema (5-100ms), in caso contrario si ha un brusco calo delle prestazioni.

Tra le tecniche sender-based, distinguiamo invece:


  1. l'interleaving, che consiste nell'inserire, in un singolo pacchetto, unità audio non adiacenti, ma separate da una certa distanza temporale garantita. Se un pacchetto, ad esempio, contiene quattro unità audio, potremmo inviare nel primo pacchetto le unità 1,5,9,13, nel secondo pacchetto le unità 2,6,10,14, e così via. La perdita di un pacchetto in ricezione comporterà la presenza, nel flusso ricostruito, di più gap piccoli anziché un solo gap più grande, la qual cosa sarebbe molto più grave. L'interleaving è una tecnica sender-based che non incrementa la quantità di banda utilizzata, ma di contro introduce un delay addizionale, accettabile solo per comunicazioni a basso grado di interattività.


  2. L'introduzione di FEC (Forward Error Correction) o ridondanza. A ogni pacchetto vengono associati dei bit di ridondanza, che viaggiano in pacchetti differenti, tramite i quali e' possibile ricostruire l'informazione persa. Di norma questi ulteriori bit non viaggiano in pacchetti separati, ma condividono lo spazio di pacchetto con il flusso primario di informazione, al fine di ridurre la quantità di overhead.

Per la generazione dei bit di ridondanza, abbiamo due scelte. Come “mattone” fondamentale, la più piccola unità indivisibile, possiamo scegliere il bit, e quindi utilizzare codici di protezione a livello di bit (parità, Reed-Solomon...). Oppure possiamo scegliere il frame audio, e quindi come protezione utilizzeremo una seconda copia del frame, eventualmente generata utilizzando un codec differente al fine di ridurne la dimensione, che viaggia in un pacchetto differente, e viene utilizzata se il pacchetto contenente la copia originale non dovesse giungere a destinazione. In quest'ultimo caso si parla di Signal-Based Processing o SFEC.




Interleaving e SFEC sono tecniche effettivamente utilizzate in alcuni strumenti per audioconferenza disponibili al grosso pubblico, quali ad esempio RAT e FreePhone.


    1. La “TCP-Friendliness”. Tecniche di controllo congestione di tipo TCP-Friendly


Un flusso è normalmente considerato “TCP-friendly” se si comporta, in caso di congestione, allo stesso modo di un flusso TCP. Un flusso TCP-Friendly è reattivo alle notifiche di congestione, e in steady-state non usa più banda di un flusso TCP che si trovi nelle stesse condizioni (drop rate, RTT, MTU ecc.).

Fra le tecniche di controllo di congestione, possiamo distinguere:



Alcuni metodi applicano un comportamento di tipo AIMD (Additive Increase, Multiplicative Decrease) ovvero: in assenza di segnali di congestione, incrementano il rate in maniera lenta. In presenza di segnali di congestione, diminuiscono il rate in maniera rapida. Un approccio del genere conduce a un rate che varia in maniera brusca, e presenta il tipico andamento “a dente di sega”, inadatto alla trasmissione di stream multimedia.

Un’altra possibilità è utilizzare un modello predittivo a lungo termine del rate di un flusso TCP. Un esempio di questo modello può essere l’equazione di Padhye, di cui parleremo diffusamente più avanti. Con un approccio del genere, otteniamo dei flussi la cui entità varia lentamente nel tempo, ma che risultano comunque TCP-friendly nel lungo periodo.

Esempi di metodi basati su finestra di trasmissione sono il RAP (Rate Audio Protocol) e l’LDA+ (Loss-Delay Based Adaption Algorithm). Un metodo basato su equazione è il TFRC (TCP-Friendly Rate Control), mentre il TEAR (TCP Emulation at Receiver) è un protocollo ibrido che combina aspetti window-based con aspetti rate-based.

Si accenna infine a una tecnica di controllo di congestione forse più adatta al caso multicast, ma applicabile in alcune forme a una connessione punto-punto. Tale tecnica é nota come layered encoding.

E’ noto che un flusso audio contiene dei bit più significativi, che contengono gran parte dell’informazione, e bit meno significativi, che arricchiscono il contenuto informativo del flusso, e di conseguenza la sua intelligibilità e gradevolezza, senza essere essenziali. Un possibile modo di amministrare il rate di una sorgente audio è dividere il flusso di bit in strati (i layer) e procedere alla trasmissione di più o meno strati secondari a seconda del bitrate permesso dalla rete.


  1. Capitolo 2: SFEC e TFRC. Lo stato dell'arte

    1. Prestazioni aggregate di SFEC. L'esperienza di Podolsky


L'utilizzo di SFEC (inserzione in piggy-back, in un pacchetto inviato successivamente, di una copia del frame audio attuale, eventualmente a bitrate e qualità inferiori) come tecnica di packet loss recovery è stato suggerito da Hardman et al., e Bolot et al. Nei loro studi sull'argomento, si sostiene e si dimostra che la qualità uditiva di un flusso audio viene senz'altro migliorata dall'utilizzo di questo metodo di recupero di errore. Questa conclusione è però tratta nella particolare situazione in cui le sorgenti audio con SFEC non sono una percentuale significativa del numero di sorgenti presenti nella rete. Ci aspettiamo quindi che il traffico aggiuntivo dovuto alla ridondanza sia una percentuale trascurabile rispetto al traffico totale presente nella rete. In tali condizioni, la qualità del flusso non può che migliorare, ma se le sorgenti audio con SFEC aumentano, il traffico aggiuntivo generato dalla ridondanza aumenta in proporzione, ed è possibile che le performance complessive della rete peggiorino e che si verifichi un aggravarsi dello stato di congestione. Questo porterebbe a un incremento della probabilità di perdita, e danneggerebbe tutti i flussi presenti nella rete, audio e non.

Il desiderio di investigare su quanto accade in una situazione come quella descritta è stata la motivazione che ha spinto Podolsky et al. A svolgere una serie di simulazioni sull'argomento.

In dettaglio, Podolsky inizia con l'argomentare che l'SFEC è una tecnica di error recovery valida, in quanto introduce ritardi addizionali largamente inferiori alle tecniche di ritrasmissione o al block-based FEC, e le sue prestazioni sono molto superiori a quelle raggiungibili da una tecnica receiver-based. Si tratta di un “punto di mezzo” ottimale.

Vengono quindi descritte le specifiche osservate durante le simulazioni. Podolsky si limita a considerare il caso in cui ogni pacchetto contiene la ridondanza del solo pacchetto immediatamente precedente, e non di altri pacchetti ancora più lontani nel tempo passato. I pacchetti recuperabili saranno quelli derivanti da perdite isolate, più l'ultimo pacchetto di un burst di perdite consecutive, al costo di un leggero incremento del ritardo end-to-end (dovremo attendere l'arrivo del pacchetto n+1 per restituire all'utente il pacchetto n).

Sono opportune alcune considerazioni sulla validità o meno di questa scelta. Alla luce di studi anche successivi alla pubblicazione del lavoro di Podolsky, risulta che il fenomeno di perdite di pacchetto nella rete Internet presenta una distribuzione approssimativamente geometrica (in realtà la distribuzione del numero di pacchetti persi consecutivi è geometrica, ma presenta una coda che per il momento non è stata ricondotta a nessuna struttura specifica). Quindi ci aspettiamo che il numero di perdite isolate sia superiore al numero di pacchetti persi in burst, e quindi che gli eventi riparabili tramite il metodo illustrato siano la maggioranza.

Inoltre non bisogna dimenticare che proteggere pacchetti più distanti temporalmente implica aumentare il ritardo end-to-end, e che se tale ritardo supera i 150 millisecondi la qualità soggettiva della trasmissione degrada rapidamente.

Per questi motivi riteniamo che la scelta di proteggere, tramite ridondanza, solo il pacchetto immediatamente precedente, sia nel complesso tanto semplice quanto efficace.

Podoslky fornisce quindi una curva “tasso-distorsione” per la valutazione della qualità audio al ricevente, che viene sviluppata tramite considerazioni teoriche, ed è per stessa ammissione degli autori una approssimazione. In particolare, si tratta di una stima legata al rapporto segnale a rumore in ricezione, che, come è noto, non rispecchia la qualità soggettiva dell'audio. E' stato riscontrato che, a seconda della frase pronunciata, in alcuni casi un ascoltatore umano assegna una valutazione percettiva superiore a spezzoni audio con rapporto segnale a rumore inferiore.

Il metodo di valutazione della qualità audio è dunque una prima scelta suscettibile di essere migliorata.

In ogni modo, viene costruita la suddetta funzione tasso-distorsione, le viene data una forma del tipo

e si pongono c1 e c2 tali che D(65 Kbps) = 0 e D(0) =1.

Si fa in modo che ogni simulazione tracci il numero di pacchetti ricevuti, il numero di pacchetti persi ma recuperabili, e il numero di pacchetti irrimediabilmente persi. Tale numeri vengono normalizzati, al fine di convertirli in probabilità, e la distorsione al ricevitore viene valutata come



Le sorgenti audio vengono modellate come sorgenti ON-OFF, con periodi di attività e inattività di durata media 40% e 60%. Questo serve a simulare una conversazione interattiva tra due persone con soppressione dei silenzi. Si assume una durata del frame audio pari a 20 millisecondi, un coding rate di base pari a 65Kbps, un coding rate di ridondanza che va da zero a 35 Kbps. Le sorgenti condividono un “collo di bottiglia” della capacità di 1.5Mb/s. Viene variato il numero delle sorgenti, e viene poi aggiunto traffico di tipo dati fino a raggiungere il 100% della capacità del bottleneck. Si conducono tre lotti di simulazioni:





Le simulazioni, all'interno di un lotto, vengono condotte fissando a priori la dimensione di pacchetto (ovvero, la quantità di ridondanza non cambia dinamicamente durante la simulazione: è fissata a priori)

I risultati, in sunto, sono i seguenti:



    1. L'esperienza di Podolsky: conclusioni e completamento


Tirando le somme, il lavoro di Podolsky ci dice che i risultati migliori, in termini di qualità audio aggregata, non si raggiungono quando le sorgenti reagiscono alla congestione aggiungendo FEC in maniera incontrollata, ma quando contemporaneamente aggiungono FEC e limitano il proprio sending rate complessivo. In presenza di numerose sorgenti, audio e non, che condividono lo stesso bottleneck, si ha un impatto benefico tanto per le sorgenti audio (la cui qualità complessiva migliora), quanto per il traffico dati, che regola la propria entità al fine di semplicemente collaborare al congestion control, anziché accollarsene interamente la responsabilità.

Appare naturale, a questo punto, preoccuparsi della realizzazione di un metodo congiunto congestion control/rate control per le applicazioni di tipo audio su Internet, e di una sua valutazione.

Nel presente lavoro, e come vedremo in dettaglio nel successivo capitolo, ci si preoccupa di effettuare una verifica simulativa della validità di un metodo congiunto che ricade sotto questa categoria. Tale metodo si serve di RTP come protocollo, con modifiche al funzionamento ammesse dalle sue specifiche, di SFEC come metodo di error recovery, e di TFRC, opportunamente modificato, come meccanismo di rate control.

Per quanto riguarda l'SFEC, si espone nel prossimo paragrafo un ultimo risultato, dovuto a Bolot e Fosse-Parisis, sullo split ottimale tra encoding primario e ridondanza. Successivamente si espone il funzionamento di TFRC.


    1. La divisione ottimale tra encoding primario e ridondanza. Il risultato di Bolot

Si è disquisito della necessità di una sorgente audio di regolare il proprio sending rate in base allo stato della rete, nonché la quantità di ridondanza inserita all'interno di ogni pacchetto. Si tratta di un problema di ottimo vincolato, enunciabile così:

dati i vincoli del meccanismo di rate control, ovvero dato un rate massimo a cui la sorgente può trasmettere, trovare la combinazione di encoding primario e di ridondanza che fornisce la massima qualità audio percepita al ricevitore.

Il problema viene affrontato da Bolot e Fosse-Parisis, i quali, servendosi di tecniche basate sui moltiplicatori di Lagrange, giungono a una serie di risultati degni di nota. In questo ambito si riporta il seguente:

per massimizzare la qualità audio al ricevitore, soggetta a vincolo sul rate, l'informazione principale dovrebbe sempre essere codificata con la massima qualità, ovvero con il miglior encoder tra quelli a disposizione.

Di conseguenza, se un pacchetto ha dimensione massima fissata dal meccanismo di rate control, ed è destinato a contenere la codifica primaria del frame n e la codifica secondaria del frame n-1, dovremo sempre fare in modo che la codifica primaria occupi più spazio possibile.


    1. IL TCP-Friendly Rate Control - TFRC


Per il calcolo del sending rate massimo, TFRC si affida ad una equazione, dovuta a Padhye, che restituisce il throughput di una connessione Reno-TCP in base ad alcuni parametri della connessione. L’equazione è la seguente:




E’ il caso di specificare che il loss event rate è in generale diverso dal packet loss rate, in quanto più pacchetti persi all’interno di un round trip time vengono tutti considerati come indicatori dello stesso evento di congestione. Di conseguenza un evento di perdita di pacchetto non è conteggiato come loss event a priori. Quando si rileva una perdita di pacchetto:

se questo evento dista temporalmente più di un round trip time dall’ultimo loss event, allora è la prima perdita di un nuovo loss event. Se dista meno di un round trip time, fa parte del loss event esistente.

Questo meccanismo è mutuato dal TCP, che di norma dimezza la propria finestra di trasmissione solo una volta nell’arco di un round trip time.

Si definisce loss interval il numero di pacchetti ricevuti tra un loss event e l'altro. Il loss event rate viene calcolato come l'inverso della media pesata dei loss interval più recenti. Ovvero:

L'equazione di Padhye nel TFRC non viene applicata così com'é, bensì si introduce la piccola semplificazione di porre il valore del retransmission timeout pari a quattro volte il valore misurato del round trip time.

Forniamo adesso una spiegazione colloquiale, non dettagliata, del funzionamento del TFRC:

il receiver misura il loss event rate e invia questa informazione al sender, tramite pacchetti di feedback;

il sender si serve dei pacchetti di feedback sia per estrarne il loss event rate, sia per calcolare il round trip time;

tramite equazione di Padhye, il sender calcola il massimo transmit rate accettabile;

il sender modifica il proprio transmit rate per avvicinarsi a quello calcolato, con dei vincoli che evitano le transizioni troppo brusche.

E’ interessante notare che, in assenza di pacchetti ricevuti, il receiver smette di inviare feedback. In assenza di feedback ricevuti per un certo tempo, il sender diminuisce il proprio send rate. Quindi, se si verifica una situazione di congestione in cui un certo numero di pacchetti consecutivi viene scartato prima di raggiungere il receiver, TFRC rileva l’evento e reagisce di conseguenza.


    1. TFRC ed i flussi a dimensione di pacchetto variabile


Il VoIP è un esempio di applicazione che utilizza pacchetti di dimensione sensibilmente più piccola rispetto alla MTU. Se vogliamo che una conversazione si possa definire interattiva, somigliando così ad una telefonata su linea analogica, abbiamo un requisito molto stringente sul ritardo “da un capo all'altro” accettabile. Se questo valore supera la soglia dei centocinquanta millisecondi, l'interattività della conversazione, e in ultima analisi la sua gradevolezza, subisce un netto calo (threshold effect). Per questo motivo, di norma una applicazione VoIP produrrà pacchetti contenenti poche unità audio, tipicamente venti o trenta millisecondi di parlato, e li invierà a cadenza fissa. Un'altra motivazione che ci spinge a inviare pacchetti piccoli è il fatto che la qualità della conversazione sarebbe severamente minacciata da perdite di informazione della durata paragonabile a quella di un fonema, mentre un'assenza di informazione più breve è molto più tollerabile. L'utilizzo di pacchetti piccoli rende molto meno probabile il verificarsi della prima ipotesi. Lo svantaggio che ne deriva è un basso rapporto tra lunghezza del payload e lunghezza totale del pacchetto.

Una forma di rate control adeguata per il VoIP consiste quindi nel servirsi di una frequenza di pacchetto fissa e modificare la dimensione del pacchetto tramite un cambio di codec.

Ora, TFRC mira a regolare il sending rate di una sorgente utilizzando una dimensione fissa di pacchetto (packet size) e variando invece il numero di pacchetti inviati al secondo (packet rate). Di conseguenza la dimensione di pacchetto è spesso vicina alla MTU (Maximum Transmission Unit) del percorso, e la spaziatura temporale tra i pacchetti non è uniforme.

Nella RFC 3488, per la definizione di un meccanismo che controlli il bitrate variando la dimensione di pacchetto anziché la frequenza di un pacchetto, si rimanda ad un documento futuro. Allo stato attuale delle cose, tale documento non è ancora stato emanato. Tuttavia esistono, e sono state rese pubbliche, delle ricerche sulla possibilità di adattare il TFRC al caso delle applicazioni con packet rate fisso. Ne forniamo un sunto.

Si è detto che le applicazioni VoIP generano pacchetti molto più piccoli della MTU, al fine di limitare il ritardo end-to-end. Eventuali flussi TCP che condividano un link limitato in banda con queste applicazioni utilizzeranno invece una dimensione di pacchetto prossima alla MTU. Poiché nell'equazione di Padhye il bitrate è legato linearmente al packet size, ne risulta che le applicazioni TCP otterranno più banda rispetto alle applicazioni che usano pacchetti piccoli. Un primo passo (ma vedremo che non è sufficiente) per ritornare verso una situazione di fairness è modificare la definizione di flusso TCP-friendly, che si ritiene opportuno riportare:

Un flusso è considerato “TCP-friendly” se si comporta, in caso di congestione, allo stesso modo di un flusso TCP. Un flusso TCP-Friendly è reattivo alle notifiche di congestione, e in steady-state non usa più banda di un flusso TCP che si trovi nelle stesse condizioni (drop rate, RTT, MTU ecc.)

Nel corso di questo documento, da adesso in poi diremo invece che

Un flusso è considerato “TCP-friendly” se si comporta, in caso di congestione, allo stesso modo di un flusso TCP. Un flusso TCP-Friendly è reattivo alle notifiche di congestione, e in steady-state non usa più banda di un flusso TCP che si trovi nelle stesse condizioni e che utilizzi la MTU del link come dimensione di pacchetto (drop rate, RTT ecc.)”.

Una conseguenza immediata di questa correzione è la necessità di sostituire, nell'equazione che ci restituisce il massimo transmit rate accettabile, la dimensione di pacchetto s con il valore della MTU. L'equazione acquista la seguente forma:

Posto che gli altri parametri della formula (RTT e loss event rate) rimangano invariati, i flussi otterranno tutti lo stesso throughput e divideranno equamente la banda disponibile, indipendentemente dalla dimensione di pacchetto utilizzata.

L'ipotesi che il RTT non dipenda dalla dimensione di pacchetto è senz'altro accettabile, ma sul valore del loss event rate si rende necessario un approfondimento.

A parità di banda utilizzata, diminuire il packet size implica aumentare il packet rate. Se aumenta la frequenza con cui i pacchetti vengono inviati, aumenta la probabilità che più eventi di perdita di pacchetto avvengano nell'arco di un round trip time, e siano pertanto considerati facenti parte di un unico loss event. La stessa cosa avviene se aumenta la probabilità di perdita di un pacchetto. Nella situazione descritta, all'aumentare della probabilità di perdita il loss event rate non aumenta in maniera proporzionale al numero di pacchetti su cui viene stimato. Il risultato è che un flusso che usa pacchetti piccoli sottostima il loss event rate, e quindi totalizza un throughput superiore a quello equo, in maniera tanto più marcata quanto più è alta la probabilità di perdita.

Il risultato appena esposto può essere dimostrato in maniera rigorosa e quantificato. Ricordiamo che un evento di perdita di pacchetto inizia un loss event solo se dista temporalmente più di un round trip time dall'ultimo evento simile. Se invece la distanza è inferiore a un round trip time, l'evento di perdita è considerato facente parte del loss event esistente. In altre parole, un evento di perdita di pacchetto che inizia un loss event costituisce l'inizio di un periodo, lungo un round trip time, durante il quale eventuali perdite di pacchetto non aumentano il loss event rate. Ci riferiremo a questo periodo con il nome di Loss Insensitive Period, LIP per brevità.

Assumiamo ora che in un round trip time vengano inviati N pacchetti, e che il fenomeno di perdita dei pacchetti sia bernoulliano. Un loss interval, misurato in pacchetti, conterrà :




Un loss interval vale quindi

e il suo valore atteso è

Dunque, se all'aumentare della frequenza di pacchetto aumenta N, allora aumenta anche il valore atteso di un loss interval, e quindi diminuisce il loss event rate. E' stato introdotto un bias in favore dei flussi a maggiore frequenza di pacchetto. Se vogliamo che questi flussi mostrino una fairness verso i flussi che si servono di pacchetti più grandi, inviati con minore frequenza, occorre rimuovere il bias.


Widmer et al. Si sono occupati di definire alcune strategie per la rimozione del bias, e di valutarne l'efficacia tramite simulazione. In dettaglio:

  1. L'unbiasing: si misurano separatamente il loss interval e il bias, e poi si rimuove il bias. In formule, il nostro flusso non manda N pacchetti in un round trip time, tutti di grandezza S, ma raggiunge lo stesso bit rate inviando Nµ pacchetti di dimensione S/µ, sempre in un round trip time. Il valore atteso di un loss interval diventa Apparentemente, basta sottrarre N(µ -1) per ottenere un valore atteso adeguato. L'efficacia di questo metodo presenta il grosso difetto di dipendere dai valori di N e µ, che in genere variano rapidamente nel tempo. Questo metodo è l'unico, tra quelli proposti, che modifica a posteriori un valore di loss interval calcolato in maniera tradizionale. I metodi che presentiamo nel seguito comportano invece una modifica direttamente nel meccanismo di misura delle perdite, e mirano a rimuovere il bias generando una stima più realistica dei loss interval.

  1. I pacchetti virtuali: questo metodo si basa sull'idea di aggregare, ai fini dell'algoritmo TFRC, più pacchetti piccoli in un solo pacchetto, grande quanto la MTU. Quando un receiver riceve un numero di pacchetti tale che il loro ammontare in byte è pari alla MTU, allora e solo allora esso registra l'arrivo di un pacchetto virtuale. Similmente, quando si perde un numero di pacchetti tale che il loro ammontare in byte è pari alla MTU, allora e solo allora si registra la perdita di un pacchetto virtuale. Le definizioni di loss event e loss interval vanno modificate nel seguente modo:


  1. Il random sampling: similmente all'approccio dei pacchetti virtuali, questo metodo mira a fornire una stima modificata e corretta di un loss interval, ovvero del numero di pacchetti ricevuti tra due loss event. Ai fini dell'algoritmo TFRC:

    Il numero di pacchetti in un loss interval diviene così µ volte più piccolo. In formule:


  1. il LIP scaling. Consiste nel ridurre la durata del LIP di una quantità pari a µ. Si abbiano un flusso che in un round trip time invia N pacchetti grandi quanto la MTU, e un flusso che nello stesso tempo invia Nµ pacchetti grandi MTU / µ . Il primo flusso invierà N -1 pacchetti in un LIP. Se vogliamo che il secondo flusso perda la stessa quantità di pacchetti, è sufficiente usare un valore del LIP µ volte inferiore.

    Un effetto collaterale, che non va ignorato, è una diminuzione dei tempi di reazione del flusso alle condizioni della rete, cosa che potrebbe generare degli effetti oscillatori nella misura del loss interval. Si prevede pertanto come contromisura un incremento dell'arco temporale su cui viene calcolata la media dei loss interval (cioé della loss history), proporzionale a µ. Questo ci assicura che la loss history avrà all'incirca la stessa durata di quella calcolata dal flusso “pacchetti grandi”, mentre il loss event rate sarà calcolato su una quantità superiore di pacchetti.



I quattro metodi esposti sono stati sottoposti a verifica tramite simulazione, e si sono riscontrate differenze significative nelle prestazioni da esse raggiunti, in termini di TCP-fairness.

In dettaglio, se il modello di canale utilizzato è tale che la probabilità di perdita di un pacchetto non dipende dalla sua dimensione, solo gli approcci “random sampling” e “virtual packets” risultano validi, totalizzando un throughput paragonabile a quello di un flusso TCP in tutte le condizioni. L'approccio “virtual packets” risponde in maniera più lenta alle variazioni dello stato della rete rispetto al “random sampling”. Ciò ha due effetti:


I metodi “unbiasing” e “LIP scaling” si rivelano in generale troppo aggressivi per essere di reale utilità.

Se invece il modello di canale comporta che la probabilità di perdita di un pacchetto dipende dalla sua dimensione (cosa possibile ad esempio se i router adottano una politica di gestione delle code di tipo RED), l'unico metodo che fornisce buoni risultati è il “virtual packets”.

E' interessante notare che l'equazione di Padhye, di cui il TFRC si serve per il calcolo di un send rate TCP-friendly, è stata specificamente sviluppata nell'ipotesi di un processo di perdita di pacchetto di tipo bernoulliano. Se tale ipotesi non è verificata, ovvero le perdite avvengono a burst, il throughput stimato è decisamente superiore a quello realmente totalizzato da una connessione TCP, in particolar modo in caso di alte probabilità di perdita. Il TFRC non modificato, nella situazione descritta, è quindi “unfair” nei confronti del TCP. Il buon comportamento di “virtual packets” e “random sampling” è dovuto a due effetti contrastanti, che si controbilanciano:


Il risultato finale è un rate TCP-friendly nella maggior parte delle situazioni.



  1. Capitolo3: Le simulazioni eseguite. Risultati e conclusioni


Dopo aver parlato diffusamente di SFEC come tecnica di packet loss recovery e di TFRC come meccanismo di rate control, in questo capitolo illustriamo le modalità con cui è stato realizzato un impianto simulativo atto a valutare le prestazioni ottenibili da un flusso audio end-to-end, che si serva di entrambi i meccanismi, in concorrenza con altri flussi audio e dati. Riportiamo i risultati ottenuti e le conclusioni da essi scaturite.


    1. Estensione al meccanismo TFRC del protocollo RTP

Omnet++ è il simulatore di eventi discreti utilizzato per le nostre prove. Esso è dotato di librerie, scaricabili a parte, che contengono i protocolli IP, TCP, UDP e RTP.

Il TFRC è stato da noi incorporato all'interno di RTP. Questo permette di evitare l'introduzione di un nuovo protocollo, con tutti i problemi che ne possono derivare. Inoltre il protocollo sottostante UDP non viene modificato, ulteriore assicurazione che le modifiche al protocollo saranno di tipo end-to-end, e coinvolgeranno solo gli estremi della trasmissione, anziché la rete con i suoi nodi intermedi.

TFRC richiede che ogni pacchetto inviato dal sender contenga:


Il receiver dovrà invece inviare periodicamente dei messaggi di feedback al sender. Tali messaggi dovranno normalmente essere inviati almeno una volta ogni round trip time, a meno che il sender non invii meno di un pacchetto per round trip time, nel qual caso dovrebbe essere mandato un pacchetto di feedback per ogni pacchetto dati ricevuto. Inoltre si dovrebbe inviare un pacchetto di feedback ogni volta che viene rilevato un loss event, senza aspettare la fine del RTT. Ogni pacchetto di feedback dovrà contenere:


Si riporta quanto detto in una tabella:


Campi addizionali richiesti per il sender

Campi addizionali richiesti per il receiver

Sequence Number

Sequence Number

Timestamp

Timestamp

Stima del Round Trip Time

Stima del rate in ricezione


Stima del loss event rate


Per i pacchetti dati inviati dal sender, sequence number e timestampsono già presenti nell'header RTP. Per il terzo campo, le specifiche ci mettono a disposizione un extension header, che comporta l'ulteriore invio di otto byte per ogni pacchetto.

RTP è dotato di un meccanismo di feedback receiver-sender, che prevede l'invio periodico degli RTCP Receiver Report. I Receiver Report viaggiano all'interno di pacchetti chiamati RTCP Compound Packet. All'interno di un Compound Packet possiamo prevedere la presenza di un “Application-defined RTCP packet”. Di questo ultimo ci siamo serviti per l'invio delle informazioni di feedback relative a TFRC. Infine, la frequenza dei Receiver Report è molto più bassa di quella, richiesta da TFRC, di uno ogni round trip time, ma è possibile cambiare la temporizzazione senza uscire dalle specifiche (ed é ciò che abbiamo fatto).

    1. Inserimento di più frame audio in un pacchetto RTP

La modalità di inserimento, in un pacchetto RTP, di due frame audio appartenenti a momenti temporali differenti, è oggetto della RFC 2198: “RTP Payload for redundant audio data”.

Si richiede l'introduzione di un header addizionale, lungo 4 byte, atto a contenere informazioni sul blocco di ridondanza. Nello specifico, queste informazioni sono:



Questo header trova posto immediatamente dopo l'header RTP. Esso è seguito da un ulteriore byte di overhead, che indica la presenza dell'ultimo blocco di dati, unitamente al suo tipo di payload. Seguono i due blocchi di dati, contigui, non allineati a 32 bit. Solamente l'ultima riga del pacchetto verrà arrotondata, tramite bit di padding, a 32 bit, ma all'interno del pacchetto le due codifiche possono essere contigue.

Nella figura di esempio che segue, vediamo la struttura di un pacchetto RTP contenente un frame audio da 20ms, soggetto a codifica primaria tramite codec DVI4, e un frame di ridondanza con codifica LPC.





    1. I Codec Selezionati. IL Mean Opinion Score


Al fine di eseguire delle prove il più possibile realistiche, si è scelto di collegare la dimensione dei pacchetti RTP simulati ai bitrate di alcuni codec per il parlato esistenti, e utilizzati nella pratica. Per valutare la loro qualità ci si è affidati al loro MOS score.

Il MOS score è una forma di valutazione soggettiva della qualità audio, che viene realizzata nel seguente modo. I campioni audio codificati vengono fatti ascoltare a un numero molto grande di persone diverse, messi nelle condizioni di ascolto più simili possibile. Ad ogni ascoltatore viene chiesto di esprimere un punteggio relativo alla qualità del passaggio audio ascoltato, con una votazione che va da 1 (scadente) a 5 (eccellente). Il MOS score è la media delle votazioni ricevute dal campione.

Un codec che riceva una valutazione tra 4.0 e 4.5 appartiene alla classe “network quality” o “toll quality”, ovvero la sua qualità è paragonabile a quella di una telefonata su linea fissa. Una valutazione compresa tra 3.5 e 4.0 è indice di “communication quality”, ovvero qualità paragonabile a quella di una comunicazione tra telefoni cellulari. Sotto il 3.5 si parla di “synthetic quality”, ovvero di parlato intelligibile ma vistosamente innaturale, riconoscibile come generato da una macchina.

Esistono in letteratura dei valori di MOS score per diversi codec. Nelle nostre prove, la qualità audio al ricevitore è stata ottenuta assegnando:

Quindi il valore ottenuto è stato mediato sul valore di tutti i pacchetti inviati (anche quelli non ricevuti, dunque).

Codec primario e secondario vengono scelti, istante per istante, in modo da fornire una dimensione di pacchetto tale da fornire un bitrate non superiore a quello consentito da TFRC. Presentiamo una tabella dei codec utilizzati:


Codec

Kbit/s

MOS score

Dimensione frame (20 ms) in byte

g.711

64

4,5

160

g.726

32

4,3

80

g.728

16

4,1

40

GSM

13

4

32

g.729

8

3,5

20

LPC-10

2,4

2,3

6


La tabella che segue mostra invece le possibili dimensioni del pacchetto IP risultante. Tali dimensioni tengono conto di:


  1. 20 byte di overhead IP;

  2. 8 byte di overhead UDP;

  3. 12 byte di overhead RTP;

  4. 8 byte di overhead per l'RTP extension header;

  5. 5 byte per segnalare la presenza di due frame audio;

  6. eventuali byte di padding.

Codec primario

Codec secondario

Dimensione payload

Dimensione pacchetto

MOS encoding primario

MOS encoding secondario

Note

g.711

g.726

240

296

4,5

4,1


g.711

g.728

200

256

4,5

4


g.711

GSM

192

248

4,5

3,5


g.711

g.729

180

236

4,5

3,2


g.711

LPC-10

166

220

4,5

2,3


g.726

g.726

160

216

4,1

4,1


g.726

g.728

120

176

4,1

4


g.726

GSM

112

168

4,1

3,5


g.726

g.729

100

156

4,1

3,2


g.726

LPC-10

86

140

4,1

2,3


g.728

g.728

80

136

4

4


g.728

GSM

72

128

4

3,5


g.728

g.729

60

116

4

3,2


g.728

LPC-10

46

100

4

2,3


GSM

GSM

64

120

3,5

3,5

Non usato

GSM

g.729

52

108

3,5

3,2

Non usato

GSM

LPC-10

38

92

3,5

2,3


g.729

g.729

40

96

3,2

3,2

Non usato

g.729

LPC-10

26

80

3,2

2,3



Si noti che alcune dimensioni di pacchetto vengono scartate, in quanto esistono dimensioni di pacchetto inferiori con un encoding primario dalla qualità superiore. In ossequio al risultato di Bolot e Fosse-Parisis, queste ultime dimensioni forniscono una qualità complessiva superiore, pur richiedendo l'emissione di un numero inferiore di byte al secondo, quindi vanno senz'altro preferite alle dimensioni scartate.


    1. Modelli di rete e di canale utilizzati. Il modello di Gilbert





Ove non diversamente indicato, il modello di rete utilizzato è stato il “dumbbell” illustrato in figura. Un numero variabile di sender è connesso al primo router, lo stesso numero di receiver è connesso al secondo router, i due router sono connessi da un “bottleneck”, che ha un certo ritardo e un certo datarate. In particolare, per tutte le simulazioni, il ritardo del bottleneck è stato posto pari a 125 millisecondi (dunque il round trip time è circa 250 millisecondi), e il datarate del canale è stato calcolato come 100 kilobit/s moltiplicato per il numero di sorgenti.

Inoltre un dropswitch si incarica di eliminare in maniera casuale dei pacchetti, al fine di simulare delle perdite lungo il canale.

Sono state utilizzate due varianti del dropswitch:


Riteniamo utile parlare più diffusamente del modello di Gilbert. Esso è un modello a due stati. Nello stato zero non si hanno perdite di pacchetto, mentre nello stato uno i pacchetti si perdono, in maniera deterministica. Si denota con p la probabilità di passare dallo stato zero allo stato uno, con q la probabilità di passare dallo stato uno allo stato zero.


Si dimostra che la probabilità di perdita di pacchetto viene a valere p/ (p+q), e il tempo medio di permanenza nello stato uno vale 1/q. Se p + q = 1, si dimostra che le perdite di pacchetto divengono bernoulliane (indipendenti).

Il dropswitch di Gilbert è stato da noi sviluppato secondo queste considerazioni: il dropswitch riceve, come parametri, il packet loss rate desiderato e il datarate del bottleneck. Data la dimensione (fissa) della MTU, pari a 1500 byte, e il datarate, viene calcolata la durata temporale di un pacchetto grande quanto la MTU, quindi si impone (arbitrariamente) che il dropswitch permanga in uno stato o nell'altro con durata media pari a dieci volte questo “tempo di pacchetto”. Altrettanto arbitrariamente, si impone che il dropswitch si interroghi sul proprio stato trenta volte durante il tempo di permanenza in uno stato. Si ricava q come l'inverso del tempo medio di permanenza in uno stato, e p dal valore di q e plr (packet loss rate).

Infine, tutte le simulazioni sono state condotte su un arco temporale pari a dieci minuti.


    1. Simulazioni con flussi separati


Si è proceduto ad eseguire una serie di simulazioni con sole sorgenti TCP o sole sorgenti TFRCps, al variare:


I risultati ottenuti si riportano in due forme, tabellare e grafica:











































Da questi dati risulta che, benché il TFRCps sia nel complesso TCP-friendly, esso è moderatamente più aggressivo del TCP nel caso di dropswitch di Gilbert (ovvero perdite a burst). Si tratta in realtà di un risultato atteso. In presenza di numerosi pacchetti persi consecutivi, TCP diminuisce la propria finestra di trasmissione al punto che, nel momento in cui può riprendere a trasmettere, il numero di pacchetti trasmissibili è talmente basso da non permettere il “fast recovery”. TFRCps, che non usa una finestra di trasmissione, adotta un comportamento diverso, e nel complesso più aggressivo.


    1. Simulazioni con flussi in concorrenza


Dopo esserci assicurati che il comportamento delle sorgenti TCP e di quelle TFRCps, separate le une dalle altre e quindi in una situazione piuttosto controllata, si comportassero nella maniera attesa, si sono eseguiti due lotti di simulazioni con entrambi i tipi di flusso nella stessa rete.

Nel primo lotto si è mantenuto il numero totale di flussi pari a 28, e si è variata la sua composizione, a gruppi di 4. Quindi la prima simulazione contiene 4 sorgenti TFRCps e 24 sorgenti TCP, la seconda 8 TFRCps e 20 TCP, e così via, fino a 24 TFRCps e 4 TCP.

Un secondo lotto di simulazioni è stato invece condotto fissando il numero di sorgenti di un tipo, e variando il numero di sorgenti dell'altro tipo. Quindi 14 sorgenti TFRCps e 4, 8 o 12 TCP; e poi 14 TCP e 4, 8 o 12 TFRCps. Le sorgenti TFRCps variano la propria dimensione di pacchetto come se contenessero frame audio appartenenti ai codec elencati. Quindi le variazioni di dimensione di pacchetto sono leggermente più brusche. Inoltre possiamo servirci del MOS score per valutare la qualità audio al ricevitore.

Di seguito i risultati delle simulazioni:


      1. Primo lotto – DropSwitch di Bernoulli















































































      1. Primo lotto – DropSwitch di Gilbert













































































      1. Secondo lotto – DropSwitch di Bernoulli



































































      1. Secondo lotto – Dropswitch di Gilbert

































































    1. Discussione e conclusioni


Alcuni dei risultati forniti da queste simulazioni sono previsti, altri piuttosto inaspettati. In dettaglio:


Quello che accade, per basse probabilità di errore, è che TFRCps è più aggressivo di TCP. Esso tende quindi ad appropriarsi di una quantità di banda superiore al “fair share”. Le sorgenti TCP riceveranno invece una quantità di banda inferiore al fair share. In particolare, più sono le sorgenti TFRCps e maggiore è la quantità di banda sottratta da TFRCps a TCP. Similmente, minore è il numero di sorgenti TCP, minore sarà la banda che tali sorgenti possono spartirsi. Di conseguenza, laddove le sorgenti TFRCps siano numericamente superiori al TCP, il traffico dati si vede assegnare una banda molto bassa, ed è costretto ad arretrare.


In sintesi, dunque: il traffico audio governato da TFRCps, in concorrenza con traffico dati governato da TCP, mostra una buona fairness nei confronti di quest'ultimo se la probabilità di errore è superiore all'1%. In particolare, la fairness è ottima per perdite di tipo bernoulliano, buona per perdite riconducibili al modello di Gilbert. Per probabilità di errore inferiori, il grado di fairness è minore, e se le sorgenti TFRCps superano numericamente quelle TCP, il traffico audio sottrae una quantità significativa di banda al traffico dati.

Riteniamo quest'ultima conclusione il più importante risultato del presente lavoro. Nel breve periodo, ci si aspetta che il traffico dati sia comunque preponderante rispetto al traffico multimedia, e quindi che il “caso peggiore” considerato non si verifichi. In un futuro in cui, invece, il traffico multimedia costituisca una percentuale significativa del traffico totale presente nella rete, ci aspetteremo che i flussi multimedia sottraggano banda a quelli dati, e che tale fenomeno possa essere non trascurabile. Se per allora il modello di rete Internet non sarà cambiato, è bene che il TFRCps sia stato corretto in modo da essere realmente fair in tutte le situazioni.


  1. Appendice A: costruzione di una funzione tasso-distorsione tramite vocoder “SPEEX”


Speex è un coder pensato espressamente per il parlato (vocoder) e per il caso VoIP. Idealmente è la controparte dedicata allo speech di Vorbis, un coder invece dedicato all'audio nella sua interezza.

Speex offre la possibilità di codificare un campione audio con una qualità a scelta dell'utente, e con un bitrate variabile, a seconda della complessità o meno del singolo frame. In una prima fase dello sviluppo di questa tesi, si era pensato di realizzare una funzione tasso-distorsione sfruttando queste feature di Speex, con le seguenti modalità:



Sebbene questo approccio si sia rivelato inadeguato alle caratteristiche date in seguito alle nostre simulazioni, cionondimeno si riportano i risultati conseguiti in questa esperienza. Oltre ad avere valore come testimonianza del lavoro svolto, riteniamo possano risultare utili per successivi studi, che siano condotti da chi scrive o meno, che siano affini o meno al lavoro presente. Per questi motivi riteniamo comunque opportuno rendere pubblici questi risultati. I campioni audio sono stati raccolti con un tasso di campionamento pari a 8000 Hz, ne sono stati selezionati un numero totale di venti (dieci per ogni sesso).

Di seguito, alcune tabelle:











Seguono le curve tasso-distorsione, in forma grafica:








Delle ultime due curve non riportiamo i dati. Esse mostrano:







  1. Bibliografia


Widmer, Denda, Mauve, “A Survey on TCP-friendly Congestion Control”.


Perkins. Hodosn, Hardman, “A survey of packet loss recovery techniques for streaming audio”.


Perkins, Hodson, “Options for repair of streaming media”.


Floyd, Handley, Kohler, “Proble Statement for DCCP”.


Floyd, Kempf, “IAB Concerns regarding Congestion Control for Voice Traffic in the Internet”.


Floyd, “Congestion Control Principles”.


Hardman, Sasse, Hanley, Watson, “Reliable Audio for Use Over the Internet”.


Bolot, Garcia, “The case for FEC-based error control for packet audio in the Internet”.


Bolot, Garcia, “Control Mechanisms for packet audio in the Internet”.


Podolsky, Romer, McCanne, “Simulation of FEC-based error control for packet audio on the Internet”


Gharai, Perkins, “Implementing congestion control in the real world”.


Mahdavi, Floyd, “TCP-Friendly unicast rate flow control”.


Floyd, Handley, Padhye, “Equation-based congestion control for unicast applications: the extended version”.


Handley, Floyd, Padhye, Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 3448


Vasallo, “Variable packet size equation-based congestion control”


Widmer, Boutremans, Le Boudec, “End-to-end congestion control for flows with variable packet size”.


Schulzrinne, Casner, Frederick, jacobson, “RTP: a transport protocol for real-time applications”, RFC 1889


Schulzrinne, Casner, “RTP profile for audio and video conferences with minimal control”


Perkins, Kouvelas, Hodson, Hardman, Handley, Bolot, Garcia, Fosse-Parisis, “RTP Payload for redundant audio data”.


Sangoma Technologies, “TCP/IP and IPX routing tutorial”.


Varga, “Omnet++ user Manual”.


Kaage, Kahmann, “An Omnet++ TCP model”


Meylan, Boutremans, “Realisation of an adaptive audio tool”


Kiviluoto, “Speech Coding Standards”


Boutremans, Le Boudec, “Adaptive joint playout buffer and FEC adjustement for Internet telephony”

Bolot, Fosse-Parisis, “Adaptive FEC-based error control for Internet Telephony”


Blefari-Melazzi, “Internet: architettura, principali protocolli e linee evolutive”


Padhye, “Towards a comprehensive congestion control framework for continous media flows in best effort networks”

Padhye, Firoiu, Towsley, Kurose, “Modeling TCP throughput: a simple model and its empyric validation”


Widmer, “TCP-Friendly equation based congestion control”.