Datagram Congestion Control Protocol: Analisi, Implementazione e Valutazione delle prestazioni

Introduzione 2
• Affidabilita`: i dati multimediali richiedono una tempificazione stret-
ta; infatti non possono essere inoltrati dopo una certa deadline (tipica-
mente 4 RTT) in quanto dopo non sarebbero piu` utili all’applicazione.
TCP puo` introdurre un ritardo arbitrario a causa dell’inoltro affidabile
ed in ordine dei messaggi. Questo ritardo e` inadatto alle applicazioni
multimediali.
Le applicazione UDP-based possono trasmettere ad un rate costante, in-
dipendentemente dalla reale banda disponibile. L’incremento di applicazioni
di traffico multimediale pone un serio problema per la stabilita` della rete
stessa, in quanto esse non utilizzano meccanismi di controllo di congestione;
tali meccanismi consentono di adattare il rate di trasmissione alla reale ban-
da disponibile e, dunque, di prevenire o di rilevare un’eventuale congestione.
Per tale motivo risulta fondamentale l’implementazione di un meccanismo
di controllo della congestione, al livello di trasporto o di applicazione. Tra
le alternative alla definizione di un nuovo protocollo vi e` l’implementazione
del controllo di congestione al livello di applicazione, utilizzando UDP come
protocollo di trasporto: questa tecnica presenta alcuni svantaggi, tra cui una
difficolta` nell’implementazione del controllo di congestione stesso. Inoltre
tale implementazione comporterebbe un deterioramento nelle prestazioni del-
l’applicazione stessa, poiche` tutte le operazioni non garantite dal livello di
trasporto, sono spostate al livello applicazione, con un carico applicativo non
indifferente. Per tale motivo si e` sentito il bisogno di definire un nuovo proto-
collo che fondesse le caratteristiche utili alle applicazioni multimediali sia di
UDP che di TCP. DCCP (Datagram Congestion Control Protocol) e` un pro-
tocollo di trasporto bidirezionale, con controllo di congestione indipendente
in ogni singola semi connessione unicast e l’invio inaffidabile dei datagram.
In particolare DCCP presenta le seguenti caratteristiche:
• Un flusso inaffidabile di datagram con ack: i datagram DCCP non
sono soggetti a ritrasmissioni, e` un protocollo adatto alle applicazioni
per cui la trasmissione tempestiva dei dati e` piu` importante della loro
Introduzione 3
consistenza, gli ack sono utilizzati per trasportare informazioni sullo
stato della congestione;
• Handshake affidabile per il setup e la terminazione della con-
nessione: DCCP e` un protocollo connection-oriented, per permettere
un’interazione migliore con i gateway intermedi. La fase iniziale della
connessione e` un handshake a tre vie, attraverso cui puo` essere effet-
tuato la negoziazione delle features, tale fase risulta essere affidabile,
poiche` i pacchetti di richiesta di connessione vengono ritrasmessi fino
a quando non c’e` risposta. DCCP introduce il concetto di servizi (un
campo a 32 bit) che identifica il servizio al livello applicazione a cui il
client sta provando a connettersi ; in TCP e UDP lo stesso ruolo viene
svolto dal numero di porto;
• Negoziazione affidabile delle opzioni: il protocollo permette la ne-
goziazione tra sender e receiver di varie opzioni, tra cui la scelta del tipo
di meccanismo di controllo di congestione da utilizzare per ogni semi-
connessione, tale meccanismo risulta essere affidabile, poiche` finche` la
negoziazione non va a buon fine, questa viene ripetuta, ritrasmettendo
l’opzione in tutti i pacchetti inviati;
• Meccanismi che permettono ai server di evitare di mantenere
lo stato per tentativi di connessione non confermati e connes-
sioni gia` finite: durante la fase di inizializzazione della connessione il
server genera un cookie che viene utilizzato per evitare di salvare le in-
formazioni di stato fino al completamento dell’handshake. Durante la
fase di terminazione della connessione, o in qualsiasi punto in cui viene
rilevato un malfunzionamento, una delle due parti (sender o receiver)
puo` terminare una connessione usando il pacchetto DCCP-Reset ed
eliminando tutto lo stato associato alla connessione;
• Controllo della congestione che include ECN (Explicit Con-
gestion Notification) e ECN Nonce: le implementazioni di DCCP
Descrizione del protocollo 4
sono ECN-aware e nella maggiore parte delle situazioni trattano i pac-
chetti marcati come ECN come pacchetti eliminati al fine del calcolo
del rate di trasmissione;
• Meccanismi di acknowledgement che comunicano la perdita di
pacchetti ed informazioni ECN: gli ack DCCP riportano i pacchetti
persi o marcati come ECN e i dati corrotti o eliminati;
• Discovery del PTMU (Path Maximum Trasmission Unit): DC-
CP fornisce il supporto PMTU. Un’implementazione di questo proto-
collo dovrebbe evitare che l’applicazione cerchi di inviare datagram piu`
grandi del MTU, almeno che essa non abbia richiesto esplicitamente di
effettuare la frammentazione;
• Una scelta dei meccanismi di controllo di congestione modu-
lari: le applicazioni hanno la possibilita` di scegliere i meccanismi di
controllo di congestione preferiti.
1.2 Descrizione del protocollo
Le dinamiche di una connessione DCCP sono simili a quelle di TCP. Esse
procedono attraverso tre fasi: inizializzazione, che include l’handshake a tre
vie, il trasferimento dei dati e la terminazione. Il flusso di dati puo` viaggia-
re in entrambe le direzioni della connessione. L’invio di acknowledgement da
parte del receiver, permette al sender di scoprire la quantita` di dati persi e di
implementare un meccanismo di controllo di congestione. Ogni connessione
DCCP e` stabilita tra due host: colui che inizia la connessione risulta essere
il client, mentre l’altro ruolo, inizialmente passivo, viene svolto dal server.
Logicamente una connessione DCCP consiste di due diverse connessioni uni-
direzionali, dette half connection. Ognuna di queste consiste di una serie di
dati inviati da un endpoint all’altro e dei relativi acknowledgement inviati
nella direzione opposta.
Descrizione del protocollo 5
Figura 1.1: Esempio Half-Connection
1.2.1 Tipi di pacchetti
Le funzioni del protocollo DCCP vengono implementate con dieci tipolo-
gie differenti di pacchetti; ad esempio ogni nuova connessione parte con un
pacchetto DCCP-Request inviato dal client. Questo pacchetto svolge una
funzione analoga al pacchetto SYN di TCP, ma, a differenza di quest’ultimo,
non e` possibile inviare una combinazione inaspettata di flag. Otto tipologie
di pacchetti possono essere tipicamente utilizzate durante una connessione
questi risultano essere:
Figura 1.2: Tipi di pacchetti e direzione di trasmissione [1]
Le altre due tipologie di pacchetti e cioe` DCCP-Sync e DCCP-SyncAck
sono utilizzate per la re-sincronizzazione dopo un burst di perdite. Le tipolo-
gie di pacchetti sono le seguenti:
Descrizione del protocollo 6
1. DCCP-Request: viene inviato da un client per iniziare la connessione;
in esso e` contenuto un campo Service Code di 32 bit, che descrive il
servizio del livello di applicazione a cui il client vuole connettersi;
2. DCCP-Response: e` inviato dal server in risposta ad un pacchet-
to DCCP-Request; esso contiene l’Acknowledgement Number del pac-
chetto DCCP-Request e il campo Service Code con lo stesso valore
contenuto nel pacchetto DCCP-Request;
3. DCCP-Data: viene usato per trasmettere i dati delle applicazioni;
4. DCCP-Ack: e` utilizzato per trasmettere puri acknowledgement e,
quindi, non trasportano dati dell’applicazione;
5. DCCP-DataAck: e` usato per trasmettere dati dell’applicazione rela-
tivi ad una half connection e gli Ack per i pacchetti ricevuti;
6. DCCP-CloseReq: e` inviato dal server come richiesta al client di
chiusura della connessione;
7. DCCP-Close: viene utilizzato dal client o dal server per chiudere una
connessione;
8. DCCP-Reset: e` utilizzato per terminare una connessione, sia normal-
mente che con errore;
9. DCCP-Sync: viene utilizzato per recuperare la sincronizzazione dopo
un burst di perdite;
10. DCCP-SyncAck: viene inviato in risposta ad un pacchetto DCCP-
Sync, per confermare la re-sincronizzazione.
Tutte le tipologie di pacchetti iniziano con un header generico ed inoltre
particolari tipi di pacchetti includono un header addizionale di dimensione
fissa. L’header generico ha differenti forme, in funzione del bit X (Extenden
Sequence Number bit):
Descrizione del protocollo 7
• X=1: il campo numero di sequenza e` 48 bit e l’header generico e` 16
byte;
Figura 1.3: Header in formato esteso [17]
• X=0: il campo numero di sequenza e` 24 bit e l’header generico e` 12
byte.
Figura 1.4: Header in formato ridotto [17]
Si illustra ora il significato dei campi contenuti nell’header generico:
• Source e Destination Port: Questi campi identificano, come per
TCP, i porti usati dai due endpoint in comunicazione. Ognuno di questi
campi ha dimensione 16 bit;
• Data Offset: Questo campo rappresenta l’offset, in word da 32 bit,
dall’inizio dell’header del pacchetto DCCP all’inizio dell’area conte-
nente i dati dell’applicazione. La sua dimensione e` 8 bit;
• CCVal: Questo campo di 4 bit viene settato in modo differente a sec-
onda del meccanismo di controllo della congestione (CCID) utilizzato;
• CsCov (Checksum Coverage): Questo campo di 4 bit determina
le parti del pacchetto su cui viene calcolata il checksum. Nel calcolo
della checksum sono sempre inclusi l’intestazione e le opzioni DCCP,
ma possono anche essere inclusi tutti i dati dell’applicazione o solo una
loro parte. Questo viene fatto per migliorare le performance su link
Descrizione del protocollo 8
rumorosi per quelle applicazione che possono tollerare la corruzione dei
dati;
• Checksum: Questo campo di 16 bit contiene la checksum per il pac-
chetto DCCP, la sua copertura dipende dal campo CsCov;
• Res (Reserved): Questo campo di 3 bit deve essere settato a zero dal
sender ed ignorato dal receiver;
• Type : Questo campo di 4 bit specifica il tipo del pacchetto. Sono
definiti i seguenti valori:
TIPO SIGNIFICATO
0 DCCP-Request
1 DCCP-Response
2 DCCP-Data
3 DCCP-Ack
4 DCCP-DataAck
5 DCCP-CloseReq
6 DCCP-Close
7 DCCP-Reset
8 DCCP-Sync
9 DCCP-SyncAck
10-15 Reserved
Tabella 1.1: Tipi di pacchetti
Il receiver deve ignorare ogni pacchetto con tipo riserved;
• X (Exended Sequence Numbers): Questo campo di 1 bit indica
se si sta usando l’intestazione generica estesa con sequence number e
acknowledge number a 48 bit;
• Sequence Number: Questo campo di 24/48 bit contiene il numero
di sequenza del pacchetto. Il suo valore viene incrementato di uno
per ogni pacchetto inviato, inclusi i pacchetti che non trasportano dati
d’applicazione.
Descrizione del protocollo 9
Ogni pacchetto DCCP puo` contenere delle opzioni, che occupano lo spazio
alla fine dell’header DCCP. Ogni opzione ha una dimensione che e` multiplo
di 8 bit. Il padding su multipli di 32 bit non viene applicato alla singola
opzione, ma viene applicato a tutte le opzioni contenute nel pacchetto. Il
primo byte di un opzione identifica il tipo; le opzioni con tipo che va da
0 a 31 sono opzioni a singolo byte di lunghezza, le altre sono a lunghezza
variabile e sono seguite da un byte che ne indica la dimensione. Questo
valore di lunghezza include i due byte del campo type e del campo length.
Le opzioni vengono processate sequenzialmente cosi come vengono inserite
nel pacchetto, iniziando dalla prima subito dopo l’header del pacchetto. Le
opzioni che fino ad ora sono state definite sono:
TIPO LUNGHEZZA SIGNIFICATO
0 1 Padding
1 1 Mandatory
2 1 Slow Receiver
3-31 1 Reserved
32 variabile Change L
33 variabile Confirm L
34 variabile Change R
35 variabile Confirm R
36 variabile Init Cookie
37 3-8 NDP Count
38 variabile Ack Vector [Nonce 0]
39 variabile Ack Vector [Nonce 1]
40 variabile Data Dropped
41 6 Timestamp
42 6/8/10 Timestamp echo
43 4/6 Elapsed Time
44 6 Data Checksum
45-127 variabile Reserved
128-255 variabile CCID-specific options
Tabella 1.2: Opzioni DCCP
Descrizione del protocollo 10
1.2.2 Stati del protocollo
Gli endpoint DCCP procedono durante il corso della connessione attraverso
stati differenti, che corrispondono alle tre fasi di inizializzazione, trasferimen-
to dati e terminazione.
Figura 1.5: Stati possibili in DCCP [1]
I nove possibili stati sono:
1. Closed: Rappresenta una connessione non esistente;
2. Listen: Rappresenta una socket dal lato server in uno stato passivo di
attesa;
3. Request : Una socket lato client entra in questo stato, da quello
Closed, dopo aver inviato un pacchetto DCCP-Request per provare
a stabilire una connessione;
4. Respond: Una socket lato server entra in questo stato, da quello listen,
dopo aver ricevuto un pacchetto DCCP-Request da un client;
5. Partopen: Una socket lato client entra in questo stato, da quello
Request, dopo aver ricevuto un pacchetto DCCP-Response dal server.
Questo stato rappresenta la terza fase dell’handshake a tre vie e il client
Descrizione del protocollo 11
puo` inviare dati dell’applicazione in questo stato, ma deve includere un
acknowledgement number su tutti i suoi pacchetti;
6. Open: Questo stato rappresenta la fase centrale di trasferimento dati
di una connessione DCCP. Il client ed il server entrano in questo stato
da Partopen e Respond rispettivamente;
7. Closereq: Una socket lato server entra in questo stato, da quello open,
per ordinare al client di chiudere la connessione e di entrare nello stato
Timewait;
8. Closing: Le socket server e client possono entrare entrambe in questo
stato per chiudere la connessione;
9. Timewait: Una socket rimane in questo stato per due MSL (Maximum
Segment Life 4 minuti) dopo che una connessione e` stata chiusa, per
evitare errori dovuti alla consegna di vecchi pacchetti. Solo uno dei due
endpoint deve entrare in questo stato e un server puo` richiedere che il
client entri in uno stato Timewait usando il pacchetto DCCP-CloseReq.
Descrizione del protocollo 12
Figura 1.6: Diagramma a stati del protocollo DCCP [17]
1.2.3 Handshake del protocollo
Nel protocollo DCCP si possono distinguere due fasi in cui viene effettuato
un handshake a tre vie tra i due endpoints coinvolti nella comunicazione:
fase di inizializzazione e quella di terminazione della connessione.
Inizializzazione della connessione
Per quanto riguarda la fase di inizializzazione della connessione, inizialmente
viene inviato un pacchetto DCCP-Request dal client. Alla ricezione di questo,
il server risponde inviando un pacchetto DCCP-Response ed infine un ack
viene inviato dal client; quest’ultimo puo` essere contenuto o in un pacchetto
DCCP-Ack o DCCP-DataAck.
Descrizione del protocollo 13
Figura 1.7: Handshake di inizializzazione in DCCP [1]
All’interno del pacchetto di DCCP-Request il client inserisce, oltre al nu-
mero di sequenza iniziale, le opzioni di negoziazione delle feature ed il Service
Code. Nel caso in cui non riceva nessuna risposta a questo pacchetto, il client
prova a rinviare un nuovo pacchetto DCCP-Request usando un timer setta-
to da un algoritmo di backoff esponenziale; ognuno di questi nuovi pacchetti
ha un numero di sequenza incrementato di uno rispetto al precedente. Come
detto ogni pacchetto DCCP-Request contiene un Service Code di 32 -bit, che
viene utilizzato pre identificare il servizio a cui l’applicazione client sta cer-
cando di connettersi. Nella seconda fase dell’handshake a tre vie, il server
si sposta dallo stato LISTEN allo stato RESPONDE e invia un messaggio
DCCP-Response al client. In questa fase il server puo` specificare le feature
che vorrebbe utilizzare, tra cui anche il meccanismo di controllo della con-
gestione scelto. Il server puo` rispondere ad un pacchetto DCCP-Request
con un pacchetto DCCP-reset per rifiutare la connessione. In particolare in
quest’ultimo pacchetto viene inserito il Reset Code che identifica il motivo
per cui la connessione viene rifiutata. Esempi di Reset Code sono il valore
7, Connection Refused, quando il porto di destinazione inserito nel pacchet-
to DCCP-Request non corrisponde al numero di porto in cui il server e` in
ascolto, oppure 8, Bad Service Code , quando il Service Code inserito nel pac-
chetto DCCP-Request non corrisponde al service code registrato con il por-
to destinazione identificato nel pacchetto stesso. Quest’ultimo codice viene
inserito poiche` ad ogni porto viene associato il relativo Service Code identif-
icante il servizio del livello applicazione che scambia pacchetti su di esso. A