RIASSUNTO CAPITOLO 7

Le persone di tutto il mondo stanno sempre di pi utilizzando Internet non solo

per guardare video o per ricercare informazioni, ma anche per caricare tramite
esso i propri contenuti. Esistono tre tipi di applicazioni multimediali: streaming
stored audio/video, conversational video/voice-over-ip, streaming live
audio/video. Ognuna di queste tipologie ha i suoi requisiti che verranno
esaminati in seguito. Si definisce applicazione multimediale qualsiasi
applicazione che impiega audio o video. Prima di esaminare le tre tipologie una
per una conviene concentrarci sulle caratteristiche di audio e video:

Video: la caratteristica principale l'alto bit-rate (si va da 100kbps per

videoconferenze di bassa qualit a 3Mbps per lo streaming di film in alta
definizione). Il video pu essere compresso, ma questo determina una perdita di
qualit. La compressione video pu basarsi su due parametri: Spatial
redundancy (un'immagine con molti spazi bianchi ha un alto grado di
ridondanza e pu essere compressa senza troppa perdita di informazioni, perch
gli spazi non bianchi che costituiscono l'immagine vera sono pochi), Temporal
redundancy (immagini una di seguito all'altra che sono praticamente uguali. Si
indica nell'encoding che l'immagine che segue uguale a quella precedente ad
essa). Pi alto il bit rate e pi alta sar la qualit dell'immagine.

Audio: richiede un bit rate decisamente pi basso del video. L'audio digitale si
ottiene tramite due operazioni: campionamento e quantizzazzione. Il
campionamento consiste nel campionare il segnale (cio segnarsi quanto vale il
segnale) a intervalli regolari. Ad ogni campione prelevato poi vengono
assegnati uno o pi valori, questo il procedimento di quantizzazione.
Aumentando la frequenza di campionamenti e il numero di valori dati a ciascun
campione con la quantizzazione si ottiene un audio pi fedele all'originale, si ha
pi qualit. Questa tecnica di encoding prende il nome di Pulse code
modulation (PCM). In internet per non si usa questa tecnica di encoding, ma
vengono usate tecniche di compressione per ridurre il bit rate. Una tecnica
famosa di compressione usata per i CD e per la musica su Internet l'MP3.
L'audio, in una conversazione, pi importante del video perch le persone
sono molto pi sensibili ai disturbi e ai ritardi dell'audio piuttosto che a quelli
del video.

Analizziamo ora le tre categorie di applicazioni multimediali.

Streaming stored audio/video

In questo caso i video, i film che si guardano sono preregistrati e si trovano su
dei server a cui il client fa domanda per poterli vedere on demand. La tecnica
dello streaming consiste nel cominciare a riprodurre il video qualche secondo
dopo che lo si scaricato dal server. In questo modo, mentre l'utente sta
vedendo una parte del video, il client sta continuando a scaricare le parti
successive dal server. Questo evita di dover scaricare prima il file completo e
poi vederlo. Visto che il video preregistrato l'utente pu premere pausa,
mandarlo avanti o indietro. Ovviamente le parti del video devono arrivare dal
server al client in tempo per essere riprodotte in continuit, altrimenti si ha il
fenomeno del freezing per cui il video si blocca e l'utente deve aspettare. Per far
s che questo non accada la rete deve fornire all'applicazione streaming un
throughput almeno pari al bit rate del video.

Convertional voice/video-over-ip
Questo tipo di applicazioni riguardano ad esempio le applicazioni che
permettono di fare videoconferenze. Hanno due caratteristiche principali:
sensibilit ai ritardi (se in una videoconferenza ogni persona sente l'altra dopo
dieci secondi dopo un po' si stufano entrambe e il servizio diventa pessimo), ma
sono tolleranti alle perdite (anche se ogni tanto viene persa un po' di
informazione video o c' qualche disturbo lieve ogni tanto nell'audio le persone
si capiscono lo stesso).

Streaming live audio e video

Si tratta in questo caso di streaming di eventi che stanno accadendo live, cio
nel momento stesso in cui l'utente decide di vederli. Anche in questo caso il
throughput fornito dalla rete deve essere almeno pari al bit rate del video che si
sta vedendo. Dato che l'evento live possono esserci dei ritardi che in questo
caso sono pi tollerati rispetto ai conversational voice/video-over-ip. Si accetta
un ritardo di circa 10 secondi da quando l'evento accade a quando viene visto
dall'utente in streaming live.
Streaming stored video

I sistemi di streaming video utilizzati per vedere questo tipo di video sono tre:
UDP streaming, HTTP streaming e Adaptive HTTP streaming. Questi sistemi
sfruttano il client buffering: quando il video arriva al client non si comincia
subito la riproduzione, ma si immagazzinano alcuni secondi di video in un
buffer (cio una zona di memoria) dell'applicazione. Dopo aver memorizzato un
po' di secondi di video si comincia la riproduzione del video mentre si
continuano a scaricare le parti seguenti dal server. Il client buffering d due
vantaggi: assorbe i ritardi tra client e server (se un pezzo di video in ritardo,
ma arriva comunque prima che il buffer dove contenuto il video memorizzato
ma ancora non riprodotto si svuoti, allora questo ritardo non sar notato), se il
throughput fornito dalla rete dovesse diventare inferiore al bit rate del video,
l'utente pu comunque continuare a vedere il video finch il buffer non si
svuota. Nel caso dell'UDP streaming il server trasmette il video con un rate che
combacia con il bit rate del video. Se per esempio il video ha un bit rate di
2Mbps e ogni pacchetto UDP porta 8000 bit di video, allora il server invier un
pacchetto UDP ogni 8000bit/2Mbps = 4msec. Nel caso dell'UDP streaming, vi
un'ulteriore connessione aperta in parallelo a quella dello streaming video tra
client e server. Questa connessione serve affinch il client possa informare il
server sui cambiamenti di stato della sessione (pausa, continua, ecc..). una
connessione di controllo. Purtroppo lo streaming UDP ha degli svantaggi, uno
streaming a rate costante, mentre la banda tra client e server pu variare in
modo imprevedibile. Questo pu dare problemi per uno streaming continuo e
pu capitare che ci sia del freezing. Inoltre molti firewall bloccano il traffico
UDP.
Nel caso dell'HTTP streaming il video si trova memorizzato in un server HTTP
come un normalissimo file con uno specifico URL. Quando l'utente vuole
vedere il video si apre una connessione TCP tra client e server e il client manda
una HTTP GET request per quell'url. I dati del video vengono memorizzati in
un buffer dell'applicazione e quando questi dati superano una soglia
predeterminata comincia lo streaming del video. Il client pu per cercare di
scaricare il file ad un rate pi alto del consumption rate con un'operazione di
prefetching, ovvero di precattura di frames che sarebbero da consumare in
futuro. Questi frames vengono ovviamente memorizzati nel buffer
dell'applicazione sul client. Quando i dati vengono mandati dal server sono
immagazzinati in un TCP send buffer, prima di essere trasmessi in Internet.
Dopodich arrivano al TCP receive buffer e poi mandati al buffer
dell'applicazione del client. Se l'utente preme pausa, c' una reazione a catena
per cui tutti i buffer si riempiono e il server non pu pi mandare dati. Si stoppa
la trasmissione finch l'utente non preme il tasto per continuare a guardare il
video.
Se l'utente decide di passare ad un punto successivo del video, il client manda
una HTTP GET request con un header particolare, il byte range header che
serve per far capire al server quale range di byte mandare per far arrivare le
informazioni che interessano all'utente. Quando l'utente salta a una parte
successiva tutti i byte che sono stati immagazzinati nel client application buffer
potrebbero non servire pi e questo determina uno spreco di banda e di tempo.
Per questo motivo in genere i buffer delle client application non sono molto
grandi.
Il Dynamic Adaptive Streaming HTTP (DASH) un sistema in cui si hanno
diverse versioni del video, realizzate con encoding e bit rate diversi e ciascuna
con una qualit particolare. In questo modo il client, a seconda della banda
disponibile, pu scegliere se guardare una versione con una qualit pi alta o
una con una qualit pi bassa. Ogni versione del video immagazzinata nel
server HTTP, ciascuna con un diverso url. Il server contiene anche un manifest
file che indica le varie versioni del video disponibili con i rispettivi bit rate. Il
DASH permette anche di passare da una qualit maggiore a una inferiore
mentre si sta vedendo il video nel caso la larghezza di banda si riducesse. Oltre
a diverse versioni del video nel server sono contenute anche diverse versioni
dell'audio, anch'esse a una qualit diversa l'una dall'altra.
Il metodo pi efficace per distribuire i video con lo streaming sarebbe quello di
costruire un enorme data center, caricare in esso i video e da esso streammarli al
mondo. Il fatto per di avere un unico data center centralizzato comporta degli
aspetti negativi: se una persona lontana dal data center i dati arriveranno con
un ritardo maggiore, i byte dei video pi popolari saranno mandati sempre sugli
stessi link, un unico data center costituisce un unico punto di possibile
fallimento, se qualcosa va storto nel data center non si possono pi distribuire i
video. Per questo esistono delle CDN (Content Distribution Networks) che
gestiscono server per diffondere i video in pi parti del mondo. Queste CDN
possono essere private o appartenenti a terze parti. Le CDN adottano due
filosofie riguardo il piazzamento dei server: Enter deep (i server vengono messi
negli accessi ISP), il cui scopo quello di avvicinare il pi possibile gli utenti
all'insieme di server da cui ricevono i dati per diminuire i ritardi e Bring Home
(si piazzano gruppi di server in pochi luoghi chiave e li si connettono tra loro
con connessioni ad alta velocit). Le CDN, una volta posizionati i gruppi di
server li riempie di video. Alcuni video per non sono mandati a tutti i server,
per esempio quelli non popolari. Se un utente richiede un video a un server a
cui la CDN non l'ha dato, il server inoltra la richiesta alla CDN e si fa una copia
del video mentre lo streamma. Quando un browser nell'host di un utente
istruito nel ricercare un video tramite un URL, la CDN intercetta la richiesta,
determina un gruppo di server adatto a soddisfare la richiesta dell'utente e
reindirizza l'utente verso quel gruppo di server. Per determinare un gruppo di
server adatti, la CDN guarda l'indirizzo IP dell'host che ha fatto la richiesta e
poi pu usare diverse strategie:
- Assegnare come gruppo di server quelli pi vicini geograficamente all'host.
- Le CDN periodicamente testano i server per vedere quali sono i ritardi. Per
fare questo possono usare o il ping, oppure possono vedere quanto tempo passa
tra il SYN-ACK server-client e l'ack client-server durante la connessione TCP.
In questo modo sono in grado di rendeirizzare gli host verso il gruppo di server
con ritardi minori.
Analizziamo ora come funzionano Netflix, Youtube e Kankan:

Netflix: ha fatto molto uso di servizi cloud di terze parti e di CDNs per offrire il
suo servizio. Il sistema di Netflix si basa su quattro componenti: Server che
gestiscono le informazioni di registrazioni e pagamento, Amazon Cloud, CDN
providers e i clients. Netflix fornisce il suo servizio impiegando macchine o
macchine virtuali nell'Amazon cloud che include diverse funzioni: Content
Ingestion (Netflix riceve i vari video e poi li carica sugli host nell'Amazon
Cloud), Content processing (Vengono create diverse versioni di un video, sia
per poter usare il DASH, sia per adattare il video a ogni supporto di
registrazione (cellulari, pc, tablet)), Uploading version to the CDNs (una volta
che le varie versioni del video son state create gli host nell'Amazon cloud le
caricano sulla CDN). Netflix utilizza tre compagnie CDN di terze parti per
fornire il suo servizio. Quando un utente sceglie di vedere un video il client
dell'utente riceve un manifest file con indicate le varie versioni del video e un
elenco di ranked CDN. L'utente solitamente sceglie la CDN con il rank pi alto
e il client viene reindirizzato verso uno specifico server CDN. A questo punto il
client e il server CDN interagiscono usando il DASH.

Youtube: Anche youtube fa un uso estensivo della tecnologia CDN per

distribuire i video. Google gestisce i server con cui vengono distribuiti i video
di Youtube. Solitamente Google usa il DNS per ridirigere la richiesta di un
utente al gruppo di server con il minore RTT tra essi e l'utente. Se questo
gruppo di server non ha il video cercato dall'utente viene mandato un messaggio
HTTP all'utente reindirizzandolo verso un altro gruppo di server. Youtube usa
l'HTTP streaming (non il DASH), vengono create poche versioni a diversi bit
rate di un video e l'utente sceglie manualmente quale versione vedere. Su
Youtube non si possono vedere solo i video, ma anche caricarli. Nei data center
di Google i video ricevuti vengono processati, convertiti in uno formato adatto
a youtube e ne vengono create versioni a differenti bit rate. A differenza di
Netflix che usa strutture di terze parti, Youtube usa le infrastrutture di google
per offrire il suo servizio (data centers, CDN private).

Kankan: usa il modello peer-to-peer invece del modello client-server. Quando

un peer vuole vedere un video contatta un tracker per cercare altri peer nel
sistema che abbiano quel video. A quel punto il peer comincia a ricevere dagli
altri peer che hanno quel video i dati in parallelo. Il design di Kankan implica
un proprio tracker e un proprio DHT per tracciare i contenuti. Il sistema con cui
comunicano i peer, il peer e il tracker e il peer e il DHT l'UDP streaming.
Voice over IP
In questa sezione analizziamo come funzionano i sistemi conversazionali. Il
fatto che il protocollo IP sia un protocollo best effort e non offra garanzie
sull'arrivo delle informazioni pone dei problemi per i sistemi conversazionali
che sono particolarmente sensibili ai ritardi e alla perdita dei pacchetti.
Vedremo delle tecniche di tipo applicativo per cercare di offrire un buon
servizio di questo tipo. Quando l'applicazione VOIP genera un segmento UDP
esso viene incapsulato poi in un datagram IP che verr mandato sulla rete. Se
uno dei buffer dei router attraversato dal pacchetto durante il suo tragitto
pieno, il pacchetto potrebbe venir scartato dal router e questo genererebbe una
perdita di informazioni. Si potrebbe cercare di risolvere il problema usando il
TCP al posto dell'UDP, perch il TCP offre un servizio di affidabilit. Il TCP
per aumenta il ritardo end-to-end tra gli host che comunicano e il congestion
control implementato dal TCP potrebbe determinare una diminuzione delle
informazioni trasmesse. Il problema della perdita dei pacchetti non per cos
grave, generalmente se vengono persi dall'1% al 20% dei pacchetti la
conversazione pu comunque avvenire. Per quanto riguarda i ritardi, si
accettano ritardi fino a 400msec, un ritardo maggiore renderebbe scomoda e
impraticabile la conversazione. Dato che i pacchetti possono subire ritardi
variabili, il tempo da quando un pacchetto viene generato alla sorgente a
quando esso viene ricevuto al ricevitore pu variare da pacchetto a pacchetto.
Questo fenomeno prende il nome di jitter. Se il ricevitore ignora il jitter
l'audio al ricevitore pu facilmente diventare incapibile. Per fortuna esistono dei
modi per eliminare questo fenomeno:
- Marchiando ogni pacchetto con un timestamp: la sorgente indica su ogni
pacchetto quando esso stato generato.
- Ritardando la riproduzione di pacchetti al ricevitore.
Vediamo come queste tecniche combinate possono aiutare a risolvere il
problema del jitter. Esistono due strategie:

Fixed playout delay: i dati che arrivano al ricevitore vengono riprodotti

esattamente q secondi dopo che sono stati generati. Se un pacchetto alla
sorgente viene generato all'istante t e ha come timestamp t, verr riprodotto al
ricevitore all'istante t+q, supponendo che per quell'istante esso sia arrivato. Se
un pacchetto arriva dopo il tempo t+q viene scartato. Bisogna scegliere q non
troppo alto perch altrimenti si avrebbe un ritardo maggiore di 400msec, ma
nemmeno troppo basso perch altrimenti molti pacchetti verrebbero persi.

Adaptive playout delay: non si utilizza un ritardo di playout fisso come nel
caso precedente, ma un ritardo variabile che viene determinato in base a come
varia il ritardo sulla rete. All'inizio di ogni comunicazione il trasmettitore
aspetta un attimo prima di trasmettere in modo che possa essere stabilito questo
ritardo di playout.

Un altro problema importante a cui le VOIP application devono fare attenzione

la perdita dei pacchetti. Esistono due tecniche per cercare di anticipare la
perdita dei pacchetti: forward error correction e interleaving.

Forward error correction (FEC): consiste nell'aggiungere dell'informazione

ridondante al flusso originale di pacchetti. Questa informazione pu essere
usata per ricostruire un'approssimazione o copie esatte dei pacchetti persi.
L'informazione ridondante pu essere o un pacchetto ogni tot pacchetti oppure
un audio stream a bassa qualit.

Interleaving: le unit che compongono il file audio vengono mescolate tra loro
prima di essere trasmesse. Il ricevitore poi ricostruisce lo stream rimettendo le
unit nell'ordine in cui erano originariamente. Questo mitiga l'effetto di perdita
dei pacchetti.

Skype utilizza un protocollo proprietario e i pacchetti sono criptati, quindi

difficile capire come funziona. Tuttavia, grazie a delle ricerche, si capito pi o
meno il modo in cui Skype lavora. Skype utilizza UDP e quando questo
bloccato dai firewall utilizza il TCP. Per il recupero delle perdite usa la tecnica
FEC. Sia per i video che per l'audio i clients Skype hanno a loro disposizione
diversi codecs che sono in grado di fare l'encoding di audio e video a molti rate
e molte qualit diverse. Skype sfrutta delle tecniche peer-to-peer. Per Skype i
peer sono organizzati in una gerarchia in cui ci sono dei peer ordinari e dei
super peer. Quando una persona si registra essa viene collegata a un super peer
con cui pu iniziare una sessione. Questa sessione permette al peer di scambiare
messaggi di controllo con il super peer. Supponiamo che Alice voglia chiamare
Bob, allora Alice contatta il suo super peer che contatta il super peer di Bob che
informa Bob della chiamata di Alice. Se Bob accetta, i due super peer
selezionano un terzo super peer che si occupa di trasmettere i dati della
comunicazione tra Bob e Alice. Cosa succede quando si ha una conferenza con
pi di due persone? Ciascuna delle persone connesse manda i propri dati voce a
chi ha iniziato la chiamata, questo peer li combina tutti insieme in un unico
stream e ne manda una copia a ogni partecipante. Questo diminuisce il numero
di stream totali da N(N-1) (nel caso in cui ogni partecipante su N mandasse un
proprio stream agli altri N-1 partecipanti) a 2(N-1).

Esistono due protocolli usati dalle applicazioni VOIP: RTP e SIP.

RTP: il trasmettitore di una comunicazione VOIP aggiunge degli header ai
pacchetti per mettere il timestamp e il sequence number. RTP uno standard
che permette di inserire dei campi per i dati video e audio. Questo standard pu
essere usato per trasportare formati comuni come MP3, PCM per il suono e
MPEG per il video. Il trasmettitore incapsula i dati in un pacchetto RTP che
viene poi incapsulato in un segmento UDP. Quando questo segmento UDP
arriva al ricevitore esso estrae il pacchetto RTP dal segmento UDP, i dati dal
pacchetto RTP e li manda al media player per il rendering e il decoding.
Nell'header del pacchetto RTP il trasmettitore scrive le info su come fare
l'encoding dei dati mandati. L'incapsulamento RTP visibile solo all'end
system, i router non sono in grado di capire se i datagram ip contengono un
pacchetto RTP oppure no. I principali campi dell'header RTP sono:

- Payload type: indica il tipo di audio o video encoding

- Timestamp: indica l'istante di campionamento del primo byte contenuto nei
dati, viene usato per rimuovere l'effetto jitter.
- Sequence number: viene incrementato di uno per ogni pacchetto RTP
mandato, serve al ricevitore per rilevare perdite e ristabilire l'ordine della
sequenza dei pacchetti.
- Source identifier fields: identifica la sorgente dello stream RTP

SIP: un protocollo che permette di aprire, gestire e chiudere le chiamate.

Supponiamo che Alice voglia chiamare Bob e che conosca il suo indirizzo IP.
La sessione SIP inizia quando Alice manda un messaggio di invito a Bob che
assomiglia a una HTTP request, esso contiene un identificatore per Bob, un
identificatore dell'attuale indirizzo IP di Alice, un'indicazione relativa al fatto
che Alice vuole ricevere dell'audio e un campo dove si dice che Alice vuole
ricevere i dati alla porta 38060. Questo messaggio viene inviato tramite UDP
alla well known port 5060 del SIP. Bob risponde con un messaggio che
assomiglia a un HTTP response, sempre sulla well known port 5060. Alice
manda quindi un ack SIP e dopo questo i due possono parlare. Questo ci fa
capire che i messaggi SIP sono mandati in socket diversi da quelli in cui sono
mandati i dati (Perch Alice specifica su quale porta vuole ricevere i dati). Gli
identificatori utilizzati per gli utenti sono indirizzi SIP molto simili agli indirizzi
e-mail. Una volta mandato il messaggio di invito, l'infrastruttura SIP passer il
messaggio SIP al device ip che l'utente cercato sta utilizzando. Ogni utente
associato a un SIP registrar, in modo che quando un utente fa partire
un'applicazione SIP sul proprio device, il registrar a cui esso associato prende
nota dell'indirizzo IP di quel device. Se Alice vuole parlare con Bob, ma
conosce solo il suo indirizzo SIP e non quello IP, dovr mandare prima l'invito a
un Proxy SIP, che contatter il registrar a cui il device di Bob associato che a
sua volta contatter il device di Bob. A questo modo il device mander indietro
la response SIP al suo registrar, che lo mander al proxy a cui Alice ha fatto
riferimento che lo mander al device di Alice. Dopo questi passaggi potr
iniziare la comunicazione.
Network support for multimedia
Esistono tre approcci orientati al fornire un supporto di livello rete alle
applicazioni multimediali:
- I meccanismi di livello applicativo che abbiamo descritto precedentemente
possono essere usati in una rete ben studiata che minimizzi i ritardi tra gli end
systems e le perdite dei pacchetti.
- Offrendo un servizio differenziato si pu dare la priorit a determinati
pacchetti e non ad altri. Per esempio si pu dare la priorit ai pacchetti relativi a
una conversazione audio/video in tempo reale.
- Una banda garantita permette un servizio migliore e una chiamata di pi alta
qualit.

Dimensioning best effort networks: il problema relativo a come dimensionare

la rete, quale capacit dare ai singoli link per raggiungere un livello di qualit di
servizio richiesto conosciuto come Bandwidth provisioning. Il problema
relativo a stabilire una topologia di una rete adatta, come interconnettere i router
per raggiungere un livello di qualit richiesto conosciuto come Network
dimensioning. I seguenti punti possono aiutare a risolvere questi problemi:

- Modelli di domanda di traffico tra i network end points: i modelli devono

essere specificati sia a livello delle chiamate che a livello di pacchetti.
- Richieste di performance ben definite: per esempio la richiesta che la
probabilit che i ritardi dei pacchetti in un servizio sensibile ai ritardi (esempio
quello conversational) siano maggiori di un certo numero sia minore di un
determinato valore.
- Modelli per predire la performance tra due end systems dato un preciso carico
di lavoro e tecniche per trovare l'allocazione di banda di minore costo che
soddisfi le esigenze di tutti.

Providing multiple classes of service: si cerca di dividere il traffico in varie

tipologie, in modo da privilegiarne alcune. In questo caso la rete non avrebbe a
che fare con singole connessioni, ma con aggregati di traffico al cui interno i
pacchetti sono tutti dello stesso tipo. Questo permette di realizzare i meccanismi
per ottenere un servizio migliore in maniera pi semplice. Si possono dividere i
pacchetti in varie tipologie di traffico mettendo nei datagram ip che trasportano
un determinato tipo di dati il campo type of service, con cui indicare un
determinato tipo di traffico. Per offrire classi diverse di servizio e dividere i
pacchetti in varie classi, bisogna cercare di rispettare tre criteri: bisogna fare in
modo che i router siano in grado di distinguere tra i vari tipi di pacchetto
quando arrivano, questo mettendo un marchio su ogni pacchetto che faccia
capire a che tipologia di traffico appartiene. A questo serve il campo Type of
service nel datagram ip. Si deve cercare di fare in modo che ogni tipologia di
traffico sia isolata e protetta dalle altre. Per offrire questo isolamento si possono
implementare dei controlli che facciano s che un determinato tipo di traffico
debba rispettare determinati criteri. Se pacchetti appartenenti a questo tipo di
traffico vogliono entrare nella rete, ma non rispettano quei criteri, allora
vengono scartati o ritardati. Un altro modo per implementare questo isolamento
consiste nell'usare le risorse nella maniera pi efficiente, per esempio dando una
larghezza di banda determinata a ciascun tipo di traffico (es: a traffico HTTP si
assegnano 0,5 Mbps, ai pacchetti audio 1,0Mbps su una rete da 1,5Mbps in
totale. Se si smette di mandare audio il traffico HTTP potr avere al massimo
una larghezza di banda di 0,5Mbps, anche se non si sta mandando audio). Una
volta divisi i pacchetti in base al tipo di traffico a cui essi appartengono bisogna
capire come e quali pacchetti mandare sui link. A questo proposito esistono
diversi meccanismi:

FIFO (first in first out): questa tecnica seleziona i pacchetti da trasmettere sui
link usando l'ordine con cui i pacchetti sono arrivati in coda.

Priority queuing: in questa tecnica i pacchetti vengono messi in coda per

uscire in base alla tipologia di traffico a cui appartengono. Supponiamo che ci
siano due tipologie di traffico, una a alta priorit e una a bassa priorit. Il primo
pacchetto arriva ed a bassa priorit, esso viene trasmesso. Dopo la sua
trasmissione arrivano un pacchetto 2 e 3 che hanno rispettivamente bassa e alta
priorit. In questo caso viene mandato prima il 3 che appartiene alla classe con
alta priorit e poi il 2. Se mentre il 2 in trasmissione arriva il pacchetto 4
(classe alta priorit), non si interrompe la trasmissione del pacchetto 2, ma il 4
aspetta che sia finita la trasmissione del 2 e poi viene trasmesso.

Round Robin and Weighted Fair Queuing: con questa tecnica si trasmette un
pacchetto appartenente ad una classe con una determinata priorit, poi un altro
dell'altra classe, poi di nuovo uno della prima classe e cos via. C'
un'alternanza nella trasmissione dei pacchetti appartenenti a classi con priorit
diverse che non tiene conto dell'ordine in cui arrivano i pacchetti.

Vediamo ora come implementare il controllo, ovvero il rate a cui concesso a

un flusso o a una classe di mandare pacchetti sulla rete. Esistono tre criteri di
controllo:
- Average rate: dire quanti pacchetti mandare per unit di tempo. La rete limita
il numero di pacchetti mandati in un'unit di tempo.
- Peak rate: questo criterio consiste nel dare dei limiti di rate sia su un lungo
periodo di tempo che uno pi piccolo (es: massimo 6000 pacchetti al minuto
con un massimo di 1500 pacchetti al secondo).
- Burst size: la rete limita il numero di pacchetti che possono essere inviati in un
brevissimo periodo di tempo. Se questo tempo brevissimo tende a zero vuol
dire che la rete limita il numero di pacchetti che possono essere inviati
istantaneamente.

Il Leaky bucket pu essere visto come un cestino al cui interno ci sono dei
tokens che vengono generati dalla rete in numero tot ogni secondo. Questo
cestino pu contenere un massimo di tokens e se pieno i tokens che vengono
generati sono scartati. Questo leaky bucket pu essere usato per controllare un
flusso di pacchetti. Supponiamo che prima di essere mandato in rete un
pacchetto debba togliere un token dal cestino. Se il cestino vuoto il pacchetto
deve aspettare che venga generato un token per toglierlo e poter essere immesso
nella rete. Questo meccanismo aiuta a controllare il flusso di pacchetti perch
pone una limitazione al numero di pacchetti che possono essere immessi sulla
rete (rt + b con b numero di token totale che il cestino pu tenere e r rate con
cui vengono generati i tokens).

L'architettura Internet Diffserv serve a implementare la differenziazione dei vari

servizi, a gestire le varie classi di traffico in diverse vie in una maniera
scalabile. La scalabilit si ottiene implementando solo semplici funzioni nel
core della rete e funzioni complesse all'edge della rete. L'architettura Diffserv
consiste di due set di elementi funzionali:
- Edge functions (classificazione dei pacchetti e condizionamento del traffico):
All'edge della rete i pacchetti vengono marchiati grazie al campo DS
(differentiated service) dell'intestazione del pacchetto. Grazie a questo si
stabilisce a che classe o tipologia di traffico appartengono.
- Core function (forwarding): quando un pacchetto marchiato arriva ad un
router esso forwardato al next hop pi adeguato in accordo con il per-hop
behaviour associato alla classe a cui quel pacchetto appartiene. Questo per-hop
behaviour definisce come i buffer sei router e i link bandwidth sono condivisi
dalle varie classi di traffico. Quando dei pacchetti arrivano all'edge della rete,
per prima cosa vengono divisi in base alla classe a cui appartengono. Pu
capitare che un host voglia limitare il numero di pacchetti che manda per
adattarsi a un certo profilo di traffico, per esempio utilizzando il meccanismo
del leaky bucket. La funzione metering serve a controllare che un flusso in
arrivo rispetti un certo profilo di traffico. Ci sono diversi aspetti incorporati
nella definizione di PHB (a description of the externally observable forward-
ing behavior of a Diffserv node applied to a particular Diffserv behavior
aggregate):
- un HB pu risultare in diverse classi di traffico riceventi diverse performance
- Mentre un PHB definisce delle differenze nel comportamento tra le varie
classi, esso non richiede nessun particolare meccanismo per raggiungere quei
comportamenti.
- Le differenze nel comportamento devono essere osservabili e perci
misurabili.
Esistono due tipi di PHB: Expedited forwarding (specifica che il rate di
dipartura di una classe di traffico da un router debba eguagliare o eccedere un
determinato rate stabilito) e Assured forwarding (divide il traffico in 4 classi a
ciascuna delle quali garantito un minimo di banda e di traffico).

Per far s che una classe di traffico continui ad avere un determinato tipo di
servizio questi meccanismi non bastano, ma ne servono di aggiuntivi. Se le
risorse non sono sufficienti e una qualit del servizio deve essere garantita,
necessario un processo di call admission in cui i vari flussi di traffico dichiarano
i loro requisiti QoS (quality of service) e sono ammessi alla rete (al QoS
richiesti) o bloccati nell'accedere alla rete (se i loro requisiti QoS superano le
risorse della rete). Se per esempio due host mandano dei dati audio a 1Mbps su
una rete da 1,5 Mbps uno dei due flussi dovr per forza essere bloccato, perch
la capacit della rete non in grado di supportare entrambi i flussi di dati. I
nuovi meccanismi e protocolli che servono sono:
- Resource reservation: si allocano le risorse a un determinato servizio (per
esempio a una chiamata).
- Call admission: dato che le risorse non sono infinite, devono esistere dei
meccanismi per le richiesta di chiamata e per l'ammissione delle chiamate (call
admission). Quando si vuole fare una chiamata di fa una richiesta di chiamata
che viene rifiutata se non ci sono risorse disponibili. (Es: nella telefonia quando
non riusciamo a chiamare e riceviamo un segnale occupato perch le risorse
non sono disponibili in quel momento).
- Call setup signaling: il processo descritto sopra prevede che una chiamata sia
in grado di allocare sufficienti risorse ad ogni router della rete nel percorso dalla
sorgente alla destinazione per far s che i requisiti end-to-end di QoS siano
rispettati. Ogni router deve determinare le risorse locali richieste dalla sessione,
valutando anche le eventuali altre sessioni in corso e valutare se ha abbastanza
risorse per soddisfare i requisiti per-hop QoS della sessione nuova. Per
coordinare queste attivit c' bisogno di un protocollo, il protocollo RSVP (call
setup protocol).