Capitolo 4 -

Capitolo 4 -

Prove TCP

4.1 - Il Protocollo TCP (RFC 793)

Il Transport Control Protocol offre agli applicativi di livello superiore un servizio affidabile ed orientato alla connessione, con comunicazione full-duplex.

TCP realizza un controllo di flusso per accordare la velocità di invio dei dati dell'host trasmittente con la capacità di ricezione ed elaborazione dell' host ricevente. Infine, il protocollo TCP realizza un controllo di congestione per limitare la quantità di dati introdotta in rete dall'host trasmittente ed impedire il sovraccarico dei nodi intermedi. TCP è un protocollo molto resistente, in quanto non fa alcuna ipotesi sull'affidabilità dei livelli inferiori, ma presuppone di avere a disposizione un semplice servizio di tipo datagramma con possibilità di:

➢ perdita dei pacchetti (per errori di trasmissione, code piene, guasti hardware); ➢ arrivi fuori sequenza;

➢ ritardi variabili;

➢ duplicazione dei pacchetti.

L'obiettivo del protocollo TCP è fornire un servizio affidabile ed orientato alla connessione agli applicativi di livello superiore per sollevarli dalle problematiche di gestione della comunicazione di rete. Le principali caratteristiche del servizio di trasporto offerto da TCP sono le seguenti:

➢ Stream orientation: i dati sono visti come stream di bit organizzati in ottetti; il

processo TCP al ricevitore restituisce all'applicativo esattamente lo stesso stream di ottetti passati dal nodo sorgente al processo TCP di trasmissione.

➢ Virtual circuit connection: prima di trasferire i dati i due processi devono

stabilire una connessione. Chi inoltra la richiesta di apertura deve infatti aspettare la conferma prima di poter inviare i dati; è inoltre previsto un meccanismo di controllo per verificare la corretta ricezione dei dati e rilevare la caduta della connessione. Il termine circuito virtuale sottolinea che i processi vedono la connessione come un circuito dedicato, ma in realtà la rete non riserva risorse dedicate alla connessione.

➢ Trasferimento bufferizzato e stream non strutturato: i processi presenti sui

terminali generano e ricevono messaggi di dimensioni variabili a seconda delle applicazioni; essi sono inseriti in buffer e prelevati dal TCP che può riorganizzare la trasmissione in segmenti di dimensione opportuna al fine di ottenere un trasferimento dei dati più efficiente. Le applicazioni hanno comunque la possibilità di forzare il trasferimento dei dati generati, in modo tale da consentire a questi di giungere al ricevitore senza eccessivo ritardo nel caso di applicazioni interattive. Non è possibile per una applicazione conoscere la dimensione dei segmenti scelta da TCP poichè questa è una variabile che dipende dai livelli sottostanti ed in particolare dal livello collegamento che limita le dimensioni delle PDU sul canale trasmissivo. Va inoltre sottolineato che la suddivisione in segmenti non corrisponde ad una strutturazione del flusso dati: è pertanto necessario che gli applicativi si accordino su un formato per lo stream affinché il suo contenuto sia intelleggibile.

➢ Connessione full duplex: TCP consente il trasferimento bidirezionale dei dati:

esistono sempre due flussi indipendenti di informazione in direzioni opposte, senza apparente interazione. Questo tipo di connessione consente di inviare le informazioni di controllo per il flusso dati in un senso utilizzando i pacchetti che viaggiano in senso inverso: tale meccanismo e detto piggybacking e permette di ridurre il traffico di rete poiché si evita il trasferimento di pacchetti specifici per il controllo. Il protocollo TCP è utilizzato soprattutto da applicativi che richiedono la trasmissione affidabile dell'informazione, quali Telnet, File

Transfer Procol (FTP), Simple Mail Transfer Procol (SMTP), Hypertext Transfer Protocol (HTTP).

4.1.a - Porte, connessioni ed endpoints di TCP

Come descritto in precedenza, TCP consente la comunicazione contemporanea di più applicativi trasferendo i messaggi che raggiungono l'host al processo cui sono destinati. La destinazione finale è identificata sempre da un protocol port number. Ciascun “capo” di una connessione TCP è pertanto individuato da un endpoint, cioé da una coppia di numeri interi (host address, port number ), dove host address rappresenta l'indirizzo IP dell'host e port number e il TCP port number; questa coppia viene spesso chiamata socket. Una connessione TCP è individuata da entrambi i socket. Questo consente ai programmi di fornire lo stesso servizio sullo stesso port number di uno stesso host ad una molteplicit a di host di erenti.

4.1.b - Meccanismo a finestra in TCP

TCP utilizza un protocollo a finestra per trasmettere i segmenti in modo affiabile ed impedire perdite di dati, errori sui dati, duplicazioni, arrivi fuori sequenza. Il trasmettitore invia segmenti numerandoli in modo sequenziale per poterli distinguere. La numerazione in TCP è a livello di ottetti e non di segmenti: ogni segmento riporta il numero di sequenza del primo byte del segmento.

Il ricevitore invia conferme (ACKnowledge) a fronte del ricevimento di un segmento; anche gli ACK sono numerati in modo sequenziale e precisamente ogni ACK specifica il numero di sequenza del primo byte mancante al ricevitore. Gli ACK sono inoltre cumulativi, cioè confermano la ricezione consecutiva di tutti gli ottetti fino a quello indicato. La ricezione di un segmento fuori sequenza provoca l'immediata trasmissione di un ACK che conferma nuovamente la ricezione dell'ultimo segmento ricevuto in ordine: si parla quindi di ACK duplicato. Una volta trasmesso il segmento, il trasmetttiotre fa partire un timer di ritrasmissione di durata pari al tempo massimo di attesa della conferma del pacchetto.

Figura_4. 1

TCP usa un meccanismo a finestra mobile (Sliding Window), che consente la trasmissione di più pacchetti (tutti quelli compresi nella dimensione della finestra) prima di ricevere le conferme. Per conservare tutte le informazioni necessarie, al trasmettitore sono definiti tre puntatori ( figura 4.1) che puntano rispettivamente al limite sinistro della nestra, il più recente ottetto trasferito e il limite destro della nestra (l'ottetto con il più alto numero di sequenza che può essere trasferito senza ricevere la prima conferma, valore legato alla dimensione della finestra stessa). Quando viene confermato il segmento più vecchio, la finestra trasla a destra verso i numeri di sequenza più alti, consentendo l'invio di un ulteriore segmento. Anche il ricevitore dispone di una finestra di dimensione maggiore di uno per ricostruire correttamente il flusso dati, anche nel caso in cui i segmenti arrivino fuori sequenza.

4.2 - Controllo di flusso e di congestione in TCP.

I controlli di flusso e di congestione effettuati da TCP sono realizzati dimen-sionando in modo opportuno la finestra di trasmissione: regolando dinamicamente la dimensione della finestra durante una connessione infatti si regola la velocità di trasmissione. Il controllo di flusso in TCP permette di evitare la trasmissione di dati ad una velocità superiore a quella a cui il ricevitore è in grado di ricevere. Tale controllo è ottenuto con una variazione della finestra di trasmissione indotta dal ricevitore. Il ricevitore dispone di una finestra di ricezione di dimensione massima pari a IWmax. Gli ACK contengono un campo chiamato window advertisement che indica la nuova dimensione della finestra disponibile in ricezione, ovvero lo spazio di memoria libero (non occupato da segmenti ricevuti ma non ancora elaborati e

quindi consegnati all'applicativo) che il ricevitore ha dedicato alla connessione. Se il ricevitore è lento, lo spazio di memoria si riduce e di conseguenza la finestra disponibile in ricezione viene ridotta. La finestra del trasmettitore non può mai superare la dimensione della finestra disponibile in ricezione. Se questa viene ridotta, sarà ridotta anche quella del trasmettitore, fino ad arrivare eventualmente a dimensione nulla, nel qual caso si arresta la trasmissione. IWmax è decisa in modo autonomo dal ricevitore, il quale non la comunica al trasmettitore se non attraverso il campo window advertisement di cui sopra. Il controllo di congestione permette di evitare di congestionare la rete. Una rete si congestiona nei momenti in cui il traffico in ingresso ad un router supera la capacità di trasmissione su uno dei canali di uscita. L'effetto della congestione è quello di aumentare il numero di pacchetti in attesa di trasmissione, arrivando alla perdita di pacchetti per la dimensione finita dei buffer presenti nei router. La congestione è un fenomeno che tende ad autoalimentarsi: la crescita delle code di attesa nei router conduce alle perdite e quindi alla ritrasmissione dei pacchetti, incrementando ulteriormente il traffico. Al fine di eseguire il controllo di congestione, il trasmettitore autoimpone una dimensione massima della finestra in funzione delle perdite riscontrate per mancato arrivo di ACK, secondo degli algoritmi .

4.2.a - Determinazione del timeout

TCP deve determinare un valore ragionevole da assegnare al timeout per funzionare in modo efficiente. E' necessario a tale scopo la conoscenza di una stima del round trip time (RTT). Purtroppo il round trip time è fortemente variabile nella rete Internet a causa della variabilità del traffico e della diversità di percorsi che i vari segmenti possono seguire, almeno da un punto di vista teorico, all'interno della rete. Per stimare il valore del round trip time, per ogni segmento viene calcolata la differenza di tempo last RTT sample tra l'istante di invio del segmento e l'istante di ricezione dell'ACK corrispondente; questo valore, opportunamente pesato con un coeffiente , aggiorna la stima del RTT:

Possono tuttavia nascere dei problemi in quanto ACK cumulativi non sono facilmente associabili ad un preciso segmento, soprattutto nel caso di ritras-missioni. Infatti, nel caso in cui si utilizzi per la misura ACK relativi a segmenti ritrasmessi, è necessario decidere se associare la ricezione dell'ACK all'invio della prima o dell'ultima copia del segmento ritrasmesso. Se si associa l'ACK al primo segmento inviato, RTT è sovrastimato. Se si associa invece l'ACK all'ultimo segmento trasmesso nascono problemi quando si verifica un improvviso aumento dei ritardi tra due trasmissioni consecutive dello stesso segmento. Se si riceve l'ACK relativo alla prima trasmissione in ritardo, a causa dell'aumento del round trip time, ma lo si associa alla seconda trasmissione, si stima un round trip time piccolo e si determina di conseguenza un RTO insufficente rispetto alla mutata situazione di rete. Tale stima crea un nuovo duplice invio del segmento seguente, con analogo effetto; tale situazione rischia di ripetersi nel tempo.

Determinazione del timeout: algoritmo di Karn

Per risolvere i problemi di calcolo del round trip time, TCP utilizza l'algoritmo di Karn: i campioni relativi a segmenti che sono stati ritrasmessi non aggiornano la stima. Tale regola da sola sarebbe insufficiente: infatti, se si verifica un aumento del

ritardo, il segmento deve essere ritrasmesso poiché scade il timeout; gli ACK ricevuti non sono utilizzabili per aggiornare la stima del round trip time RTT, che rimane inferiore al round trip time reale. Per evitare questo problema si utilizza una strategia di backoff esponenziale sul valore assegnato al timeout RTO dopo ogni ritrasmissione:

RTO = γ • RTO

dove γ assume un valore pari a 2. La determinazione del valore da assegnare al timeout è separata dalla stima del round trip time. Se si deve ritrasmettere si aumenta il valore del timeout per ogni trasmissione senza ricezione di ACK, finché il segmento non viene trasferito con successo; la stima del round trip time non viene modificata. Non appena la trasmissione di un segmento ha successo si utilizza la nuova misura del round trip time per aggiornarne la stima. Nelle versioni più recenti del protocollo, si tiene conto anche della varianza delle misure; la formula utilizzata e la seguente:

dove DEV è la deviazione standard stimata, δ è un coeffiente compreso tra 0 ed 1 che controlla quanto velocemente il nuovo campione ha effetto sulla media pesata, ρ è un coeffiente tra 0 ed 1 che controlla quanto velocemente il nuovo campione ha effetto sulla deviazione media e µ è un fattore che controlla quanto la deviazione ha effetto sul timeout.

4.3 - Il formato del segmento TCP

La PDU (Protocol Data Unit) utilizzata nel protocollo TCP è detta segmento. Come rappresentato in figura 2.2, ogni segmento è composto da un header, ossia la PCI (Protocol Control Information), ed un campo data, ossia la SDU (Segment Data Unit). La dimensione dei segmenti può variare da un valore minimo pari ai 20

byte dell'header nel caso dell'ACK, fino ad un valore massimo MTU (Maximum Transmission Unit) pari ai 20 byte dell'header più la MSS del campo data, concordabile con il ricevitore. La dimensione dipende anche dallo stream dei livelli superiori. L'header a sua volta comprende i seguenti campi.

➢ Source e destination port: contengono i TCP port number che individuano gli

estremi della connessione.

➢ Sequence number: indica la posizione, nel flusso di byte del trasmettitore, del

primo ottetto contenuto nel segmento.

➢ L'Initial Sequence Number (ISN) viene estratto in maniera casuale ed inviato al

ricevitore al momento dell'apertura della connessione.

➢ Acknowledgment number: indica il numero di sequenza del byte che il ricevitore

si aspetta di ricevere (si riferisce al usso di dati in senso opposto); e pari al sequence number dell'ultimo byte di dati ricevuto correttamente + 1.

➢ Hlen: speci ca la lunghezza dell'header in multipli di 32 bit (righe): e necessario

poich e il campo option ha una dimensione variabile.

➢ Reserved: è un campo riservato per usi futuri.

➢ Flags: è usato per specificare il contenuto del segmento. E' costituito da sei bit di

flag, di cui possono esserne settati uno o più contemporaneamente. Il nome dei flag e riportato in tabella 4.1.

URG Il campo urgent è valido ACK Il campo acknowledgment è valido

PSH Questo segmento richiede una PUSH RST Reset della connessione SYN Sincronizza i numeri di sequenza

FYN Il trasmettitore ha raggiunto la fine dello stream

Tabella 4.1

Il campo urgent pointer viene utilizzato quando alcuni dati presenti nel campo data devono essere trasmessi in modalità urgente, cioè devono essere consegnati quanto prima ai livelli superiori senza rispettare la sequenzialit a dei dati “normali”. Il meccanismo utilizzato per trattare i dati urgenti consiste nel marcare il bit URG e nello specificare nel campo urgent pointer la posizione di tali dati all'interno del segmento. Il bit PSH viene utilizzato quando le applicazioni intendono forzare un

trasferimento di dati: il trasmettitore invia tutti i dati generati senza aspettare che il buffer sia pieno e il ricevitore è forzato a renderli disponibili alle applicazioni senza alcun ritardo. I bit SYN, RST e FIN servono rispettivamente per la gestione di aper-tura, reset e chiusura delle connessioni.Window: specifica la dimensione corrente della finestra di ricezione che serve per il controllo di flusso. Urgent pointer: specifica la posizione di eventuali dati urgenti all'interno del campo data. Options: permette di specificare un certo insieme di opzioni. Tra queste vi è quella che consente agli applicativi interessati alla comunicazione di negoziare la MSS: ogni endpoint di una connessione solitamente specifica questa opzione nel primo segmento scambiato (quello con il flag SYN settato) indicando la dimensione massima che è in grado di ricevere. La scelta della MSS è molto importante in quanto ha notevole in uenza sull'efficienza della trasmissione. L'invio di segmenti troppo piccoli risulta poco efficiente a causa dell'elevato rapporto tra informazione di controllo (header) e informaziobne utile (data); segmenti troppo grandi d'altra parte richiedono di essere frammentati dai livelli sottostanti e quindi sono confermati o ritrasmessi in maniera indipendente l'uno dall'altro: basta pertanto perdere un singolo frammento perché l'intero segmento venga perso. Un aumento della dimensione della MSS diminuisce quindi la probabilità di successo della trasmissione. Cio nonostante, la negoziazione della MSS tipicamente non avviene e se ne assume un valore di default System Dependent, purché non inferiore a 512 byte. Checksum: contiene un intero su 16 bit usato per veri care l'integrità dei dati e delle informazioni di controllo contenute nell'header. Per il calcolo del checksum si fa precedere il segmento da uno pseudo-header (composto dai campi source IP address, destination IP address, protocol, lenght, zero), si allineano lo pseudo-header, l'intestazione e i dati su blocchi da 16 bit e si calcola il complemento a uno della somma in complemento a uno dei blocchi.

4.4 - Il controllo di congestione in TCP: gli algoritmi

TCP realizza il controllo di congestione tramite l'implementazione di quattro algoritmi: Slow Start, Congestion Avoidance, Fast Retransmit e Fast Recovery .

4.4.a - Slow Start e Congestion Avoidance

Gli algoritmi di Slow Start e Congestion Avoidance sono implementati nel trasmettitore TCP con lo scopo di controllare la quantità di dati che viene immessa nella rete. Al fine di implementare tali algoritmi è necessario aggiungere due variabili alla caratterizzazione dello stato della connessione considerata:

➢ congestion window, cwnd: rappresenta la nestra di congestione; essa definisce il

limite superiore alla quantità di dati che possono essere trasmessi prima che sia arrivato un nuovo ACK al trasmettitore.

➢ receiver window, rwnd: indica la massima dimensione della nestra del ricevitore

consigliata al fine di realizzare il controllo di flusso.

Il trasmettitore non dovrà mai inviare un numero di segmenti superiore al valore minino tra cwnd e rwnd. Inoltre, relativamente alle dimensioni della cwnd, viene definita una soglia (slow start threshold size, ssthresh) che permette di determinare se si stia utilizzando l'algoritmo di Slow Start o quello di Congestion Avoidance per controllare la trasmissione. Entrambi gli algoritmi si basano sull'assunzione che la

perdita di pacchetti per errori di trasmissione è molto bassa (molto meno dell'1%) e quindi la perdita di un segmento può essere causata unicamente dalla congestione della rete. Tuttavia, quando si inizia la trasmissione sulla rete non se ne conoscono

le condizioni ed è pertanto necessario sondarla lentamente al fine di determinarne la capacità ed evitare di congestionarla trasmettendo burst di dati eccessivamente grandi (fase di Slow Start). Gli algoritmi di Slow Start e Congestion Avoidance sono indipendenti, tuttavia quando si verifica la congestione è necessario abbassare la velocità di trasmissione della rete e quindi invocare sempre lo Slow Start; essi vengono quindi solitamente implementati insieme come segue.

Il valore iniziale di cwnd (IW) è solitamente preso pari ad 1 MSS mentre ssthresh è posta pari a 65535 byte. Si inizia quindi ad incrementare cwnd di un segmento per ogni ACK ricevuto che confermi un nuovo dato. Ciò corrisponde ad una crescita esponenziale della cwnd, nell'ipotesi che il ricevitore invii un ACK per ogni segmento ricevuto. La fase di Slow Start termina quando cwnd supera la soglia

ssthresh o quando viene rilevata la congestione. Una volta superata la soglia, la

crescita di cwnd rallenta e si entra nella fase di Congestion Avoidance. In questa fase cwnd e incrementata di 1 segmento per ogni RTT, ovvero solo quando tutti i segmenti della nestra sono stati confermati; ciò equivale ad applicare a cwnd l'equazione:

cwnd=cwnd MSS∗ MSS

cwnd

ogni volta che al trasmettitore arriva un ACK non duplicato. Si passa in questo modo ad una crescita lineare della cwnd. Questa fase continua finché non venga rilevata congestione, oppure cwnd non abbia raggiunto il valore rwnd (in tal caso la finestra smette di crescere e rimane costantemente pari a rwnd). Quando si verifica la congestione, indicata da un timeout o dalla ricezione di tre ACK duplicati, ssthresh è posta a metà della dimensione della nestra corrente; il trasmettitore ritrasmette il segmento mancante e poi riparte in Slow Start. L'algoritmo di Congestion Avoidance e l'utilizzo di rwnd permettono inoltre di realizzare il controllo di flusso. Il primo si basa sulla stima, da parte del trasmettitore, della congestione della rete; mentre la seconda e legata alla quantità di spazio libero nel buffer del ricevitore.

4.4.b - Fast Retransmit e Fast Recovery

L'algoritmo di Fast Retransmit fu proposto nel 1990 come modifica dell'algoritmo di Congestion Avoidance. Abbiamo precedentemente descritto come TCP generi immediatamente un ACK duplicato nel momento in cui al ricevitore arrivi un segmento fuori sequenza; lo scopo di tale ACK e di far sapere al trasmettitore che e stato ricevuto un segmento fuori sequenza e quindi quale SN sia invece atteso. Dal momento che TCP non è in grado di sapere se un ACK duplicato è causato da una

situazione grave di perdita del segmento, e quindi di congestione, o piuttosto da una situazione di banale “sorpasso” dei pacchetti all'interno della rete, esso attende un certo numero di ACK duplicati al fine di poter eseguire tale distinzione. Più precisamente, si assume che si tratti di un semplice scambio di pacchetti se ci saranno solo uno o due ACK duplicati prima che venga processato il segmento atteso. La ricezione di tre o più ACK duplicati pu o essere quindi considerata come una forte in- dicazione del fatto che quel segmento sia stato perso. In tal caso TCP esegue quindi la ritrasmissione di quello che si suppone essere il segmento mancante senza aspettare che scada il relativo timer di ritrasmissione.

L'algoritmo di Fast Recovery segue alla ritrasmissione del pacchetto ritenuto perso. Esso si occupa della trasmissione di nuovi segmenti (se consentito dalla cwnd) fino all'arrivo di un nuovo ACK, forzando TCP a non entrare nella fase di Slow Start. Il motivo di tale implementazione è che la ricezione di ACK duplicati non si limita ad indicare la perdita di un segmento; infatti, poiché il ricevitore può generare un ACK solo se riceve un ulteriore segmento, quest'ultimo deve per forza aver raggiunto il buffer di ricezione e quindi aver lasciato la rete. Tutto ciò significa che vi sono

ancora dati transitanti in rete e sarebbe dannoso interromperne brutalmente il flusso entrando nella fase di Slow Start. L'algoritmo di Fast Recovery comporta

quindi un miglioramento in quanto permette di mantenere un alto throughput anche quando ci si trovi in condizioni di congestione moderata. Gli algoritmi di Fast Retransmit e Fast Recovery sono solitamente implementati insieme come segue: 1) Quando arriva al ricevitore il terzo ACK duplicato, ssthresh è posta a metà della

cwnd corrente, ma non meno di due MSS. Il segmento man cante viene ritrasmesso e cwnd è posta a ssthresh più tre MSS. Questo ingrandisce la finestra del numero di segmenti che hanno lasciato la rete e che sono memorizzati nel ricevitore.

2) Ogni volta che arriva un altro ACK duplicato, cwnd è incrementata di un MSS. Questo amplia la finestra per tenere conto degli ulteriori segmenti che hanno lasciato la rete. Se consentito dal nuovo valore di cwnd, viene trasmesso un nuovo pacchetto.

3) Quando arriva un nuovo ACK, cwnd e posta a ssthresh (e precisamente al valore stabilito nel passo 1). Questo ACK dovrebbe essere la conferma al segmento

ritrasmesso (quello citato sempre nel passo 1), un RTT dopo la ritrasmissione. Inoltre questo ACK dovrebbe confermare tutti i segmenti intermedi trasmessi tra il pacchetto perso e la ricezione del primo ACK duplicato, se nessuno di questi fosse stato perso.

Questo algoritmo ha però il difetto di non recuperare in maniera effiente la perdita multipla di pacchetti appartenenti ad una singola finestra di trasmissione. Infatti, per quanto descritto al passo 3, il nuovo ACK viene considerato come la conferma di tutti i segmenti inviati tra il pacchetto perso e la ricezione del primo ACK duplicato, ponendo subito la cwnd pari a sstresh. Ma in caso di perdita multipla si rientra in Fast Recovery ad ogni terzo ACK duplicato, con la conseguente rapida riduzione di sstresh e cwnd.

4.5 - TCP su Wireless

TCP è un protocollo che, ideato per operare su reti cablate dove errori di trasmissione sono relativamente rari, interpreta la perdita di segmenti come la presenza di un fenomeno di congestione. In ambito wireless, invece, quasi mai le

perdite di pacchetti sono causate da congestioni di rete; quanto, piuttosto, da fenomeni di fading, shadowing, ecc., nonché dalle operazioni di handover. Sul

canale radio, quindi, gli errori di trasmissione sono più frequenti e in un tale scenario le attuali implementazioni di TCP non forniscono buone prestazioni. Più precisamente, i principali parametri che influiscono negativamente sulle prestazioni di TCP in una rete wireless sono i seguenti.

➢ Lunghi Round Trip Time: i mezzi trasmissivi wireless sono caratterizzati da

ritardi maggiori rispetto quelli cablati. Questo provoca una diminuzione del throughput ed un aumento del ritardo percepito dagli utenti. Le versioni più recenti di TCP alleviano un certo numero di ineffienze rispetto alla versione Tahoe, ma continuano comunque ad incrementare la Congestion Window proporzionalmente al rate degli acknowledgment ricevuti.

➢ Perdite casuali: i mezzi wireless sono più affetti dalle perdite poiché possono

riferimento a mezzi cablati, caratterizzato da un Bit Error Rate (BER) dell'ordine di 10-6 _{- 10}-8 _{; in ambiente wireless tale valore è edll'ordine di 10}-3 _{o più elevato.}

Le perdite casuali sono il più grave problema citato in letteratura; il problema non sta tanto nel fatto stesso di dover ritrasmettere i pacchetti, ma piuttosto nel fatto che, a causa delle perdite, vengono invocati gli algoritmi di controllo di congestione, i quali riducono la finestra di trasmissione; in questo modo un errore transitorio porta TCP ad un rallentamento non necessario e quindi ad una diminuzione del throughput.

➢ Mobilità degli utenti: il termine mobilità significa che l'utente può muoversi

liberamente ed allo stesso tempo continuare ad usufruire dei servizi di rete senza interruzioni. Quando l'utente passa da una cella ad un'altra (handover) è necessario che tutte le informazioni siano trasferite tra le due BTS cosicché la connessione non sia interrotta. Le implicazioni della mobilità sulle prestazioni di TCP sono elevate e sarebbe quindi utile che il protocollo TCP fosse in grado di distinguere tra perdite dovute alla congestione, alla casualità ed alla mobilità.

➢ Trasferimenti brevi: la maggior parte del traffico sulla rete Internet è

attualmente costituito dal Web browsing e dalla posta elettronica. Entrambi questi servizi richiedono la trasmissione di quantità di dati piuttosto piccole . Questo significa che, quando l'applicativo instaura una connessione TCP per il trasferimento, c' è una elevata probabilità che l'intero trasferimento sia completato mentre il trasmettitore TCP si trova ancora nella fase di Slow Start (paragrafo ); e quindi che la connessione TCP non venga mai ad usufruire completamente della banda disponibile.

In questi ultimi anni sono stati fatti molti studi per cercare di risolvere i problemi inerenti alle prestazioni di TCP nell'ambiente wireless. Ci sono fondamentalmente due approcci distinti per migliorare le prestazioni di TCP in tali sistemi. Il primo approccio consiste nel nascondere al trasmettitore TCP ogni perdita non dovuta alla congestione; pertanto non si richiede di apportare modifiche alle implementazioni già esistenti del trasmettitore TCP. L'idea dietro questo approccio è che, essendo la perdita un problema locale, esso dovrebbe essere risolto localmente ed il livello trasporto non deve essere conscio delle caratteristiche del collegamento. Il secondo approccio cerca invece di rendere il trasmettitore conscio che la perdita di alcuni

pacchetti non è dovuta alla congestione. Il trasmettitore può quindi evitare di invocare gli algoritmi per il controllo di congestione.

4.6 - Scenario Prove

Per questo tipo di prove lo scenario è stato di due tipi:

1. Una prima prova è stata effettuata in un parcheggio alle distanze di 50 e 100 metri in tecnologia 802.11b e 802.11g, in condizioni non sempre ottimali a causa del transito di persone e mezzi durante la prova.

2. Una seconda prova è stata effettuata in mare aperto tra due unità navali alla distanza di circa 150 metri, sempre in 802.11b e 802.11g.

4.7 - Configurazione pc per le prove

I due terminali usati nelle prova sono un computer portatile con sistema operativo Linux Debian, kernel ricompilato alla versione 2.4.27, una patch per il programma Magnet; a questo ho collegato una scheda pmcia Cisco Aironet 350 Series per le prove in 802.11b, mentre per quelle in g ho usato una scheda pmcia Proxim Orinoco 11a/b/g; l'altro terminale era composto da un pc fisso sempre con Linux Debian connesso tramite ethernet al bridge Cisco Aironet 1300 con una antenna della Cisco AIR-ANT2414S-R..La prova è stata effettuata impostando uno dei due computer come server ftp tramite netperf , http://www.netperf.org/netperf/NetperfPage.html , con il comando

/etc/init.d/netperf start

Sull'altro pc andavo a prendere i risultati della prova usando il programma Magnet, http://public.lanl.gov/radiant/software/magnet.html . Prima di iniziare l' invio dei

statistiche

mkmagnet -b 100000000 prova_tcp

In seguito ho caricato il modulo della scheda wireless che mi permette di prelevare i dati inerenti il rapporto Segnale rumore dal file /proc/net/wireless , (modulo in Appendice l),

insmod wireless_mon.o

posso cosi iniziare a prendere i dati dalla scheda wireless con magnet

magnet-read prova_tcp

e subito poi far iniziare l'invio dei dati mediante netperf con il comando

netperf -t TCP_STREAM -l 60 -H indirizzo_server

Al termine del passaggio dei dati passo nella fase di elaborazione dei stessi.

4.8 - Elaborazione dati TCP

Per prima cosa vado a modificare prova_tcp per renderlo in un formato comprensibile :

magnet-parse < prova_tcp > prova_tcp_leggib

In seguito, mediante alcuni script awk, in particolare con awk.elab_tcp in Appendice r) , vado ad estrarre i parametri di interesse da prova_tcp_leggib

awk -f awk.elab_tcp < prova_tcp_leggib > prova_tcp_leggib_elab

di “ascolto” di Magnet ) di questo tipo :

Times Tipo SEQ ACK Qlink CWND SSTHR

ESH SRTT RTO Signal_Livel Noise_Livel

... ... ... ... ... ... ... ... ... ... ...

da cui estrarre i dati che poi vado a graficare tramite gnuplot.

4.9 - Parametri del TCP durante il trasferimento dati.

Gli algoritmi previsti dal TCP sono standardizzati dall’RFC 2581 [4]: esso specifica anche il comportamento che dovrebbe assumere una connessione TCP in seguito ad un periodo relativamente lungo di inattività.

Per il meccanismo di Congestion Control, la sorgente TCP utilizza due algoritmi: lo Slow Start ed il Congestion Avoidance. Per implementare tali algoritmi è necessario introdurre alcune variabili:

• RMSS (Receiver Maximum Segment Size): dimensione massima di dati che la sorgente è in grado di trasmettere (esclusi gli header TCP/IP e le opzioni). Questo valore coincide con quello specificato nell’opzione MSS inviato dal ricevitore durante la fase di avvio della connessione (di default vale 536 bytes).

• FULL-SIZED-SEGMENT: segmento contenente il massimo numero di byte di dati permesso.

• RWND (Receiver Window): la più recente dimensione della window del ricevitore dichiarata.

• CWND (Congestion Window): variabile di stato del TCP che limita la quantità di dati che un trasmettitore può inviare. In qualsiasi istante il TCP non deve inviare pacchetti con Sequence Number più elevato della somma tra il maggior Sequence Number confermato ed il minimo tra CWND e RWND. La trasmissione dei dati è regolata dal minimo tra la CWND e la RWND.

• IW (Initial Window): dimensione iniziale della CWND del trasmettitore, subito dopo che si è stabilita la connessione (mediante il Three-way-handshake).

• FLIGHT SIZE: quantità di pacchetti che sono stati inviati, ma di cui ancora non è stato ricevuto acknowledgment.

• SSTHRESH (Slow Start Threshold): variabile di stato introdotta per determinare in quali casi deve essere utilizzato il meccanismo di Slow Start o quello di Congestion Avoidance.

All’inizio di una trasmissione, è richiesto al TCP di esaminare la rete per determinarne la capacità disponibile ed evitare di congestionarla con trasmissioni di dati inadeguatamente ingenti.

Secondo quanto afferma l’RFC 2001, il valore iniziale di CWND, ossia l’IW, deve essere :

IW < 2*SMMS con il limite massimo di 2 segmenti.

Nelle nostre prove abbiamo notato che il TCP inizializza la CWND ad un valore talvolta superiore a 2 segmenti. Dai grafici si nota infatti che la CWND assume in alcuni casi il valore iniziale di 3 segmenti. Nell’RFC 2581 viene fatto riferimento al valore sperimentale, non-standard, che prevede l’uso di una IW definita dall’equazione:

IW = min ( 4*SMMS, max ( 2* SMMS, 4380 bytes))

Con questa estensione una sorgente TCP può impiegare una IW pari anche a 3 o 4 segmenti (il limite superiore è stabilito a 4380 bytes).

Il valore iniziale della SSTHRESH può essere arbitrariamente elevato (alcune implementazioni, per esempio, lo pongono uguale alla RWND), ma viene ridotto in seguito ad una congestione della rete. Quando CWND è minore o uguale al valore di SSTHRESH si utilizza l’algoritmo di Slow Start, mentre quando CWND è maggiore di SSTHRESH viene adottata la procedura di Congestion Avoidance. Durante lo Slow Start, il TCP incrementa la CWND di un valore pari a SMSS bytes per ogni ACK ricevuto in conferma di nuovi pacchetti ricevuti. Questo dà origine ad

un incremento esponenziale della CWND. Tale algoritmo termina quando la CWND raggiunge o supera la SSTHRESH , o quando viene rilevata una congestione della rete.

Segue quindi la fase di Congestion Avoidance, durante la quale la CWND è incrementata di 1 Full-sized-segment ogni RTT. Una formula comunemente riportata per l’aggiornamento della CWND, effettuato in seguito all’arrivo di un ACK non duplicato, è data da:

CWND = CWND + ( SMSS * SMSS ) / CWND

Un altro modo valido per aggiornare la CWND durante la Congestion Avoidance è quello di contare il numero di bytes di cui sono stati ricevuti gli ACK; quando tale valore raggiunge quello della CWND, essa può essere incrementata di SMMS bytes. La perdita di uno o più pacchetti può essere rilevata dal trasmettitore in due casi: quando allo scadere del Timeout non ha ancora ricevuto un ACK (situazione che si verifica durante l’Handover), oppure in seguito alla ricezione di un numero prefissato di ACK duplicati (solitamente stabilito a 3).

Nel caso di perdita di pacchetti, il TCP prevede due algoritmi implementati in maniera conguinta [4] detti “Fast Retransmit” e “Fast Recovery” per rimediare alla perdita dei dati e basati sull’osservazione degli ACK duplicati. Se il destinatario riceve pacchetti identificati da un Sequence Number inatteso (non sequenzaiale al precedente ricevuto), esso provvede ad inviare ACK duplicati relativi all’ultimo pacchetto correttamente ricevuto, detti DUPACK. In seguito alla ricezione da parte del trasmettitore del terzo ACK duplicato, il TCP setta SSTHRESH pari al massimo tra la metà della Transmission Window (minimo tra CWND e RWND) e il doppio dell’MSS:

SSTHRESH = max ( FlightSize / 2, 2 * SMMS )

Il segmento che non è stato ricevuto viene quindi ritrasmesso e alla CWND viene assegnato un valore pari alla somma di SSTHRESH più 3 volte MSS; all’arrivo di altri DUPACK la CWND è incrementata della dimensione di un MSS e viene

trasmesso il pacchetto richiesto. La trasmissione dei segmenti avviene solo se consentita dal nuovo valore di CWND e di RWND. Nell’istante in cui giunge un ACK che riconosce un nuovo segmento, si assegna a CWND il valore della SSTHRESH e si prosegue nella trasmissione. Il protocollo TCP in questi casi deve anche riscontrare tutti i segmenti intermedi che sono stati ricevuti tra il segmento presunto perso e quelli che hanno provocato la generazione dei DUPACK al ricevitore.

4.10 Prove TCP Outdoor

I dati relativi all’instaurazione della connessione non sono stati oggetto dei nostri studi, perciò all’istante zero il trasferimento risulta già attivo e a regime.

4.10.a - Prove a 50 metri in 802.11b

Figura_4. 3

I punti viola rappresentano il valore del Retransmission TimeOut (RTO), che indica l’intervallo di tempo dopo il quale il trasmettitore, in seguito ad una mancata ricezione dell’ACK atteso, considera perso il pacchetto inviato e procede con la sua

ritrasmissione. Possiamo notare come nelle zone tra i 5 e 10 sec e tra 15 e 20 sec si ha un innalzamento del valore dell' RTO poichè in quelle zone la Qualità del canale (in celeste) raggiunge il suo valore minimo. Qualcosa di interessante accade intorno al 15 secondo, e lo si vede meglio nella figura 4.2:

Figura_4. 4

il valore della CWND viene abbatto dal suo max che è di 45 a quello minino 1, ossia quel valore iniziale di inizio connessione infatti tra 15 e 15.5 ci deve esser stata una dissociazione della scheda, infatti dalla tabella 1

Time Type Seq Ack Qlink CWND SSTHRESH SRTT RTO

14.852758646011 SEQ 5954785 N/A N/A 45 2147483647 0,11 0,34

15.070728302002 WIR N/A N/A 18 N/A N/A N/A N/A

15.085045814514 SEQ 5892521 N/A N/A 1 22 0.11 0.34

15.788183450699 WIR N/A N/A 18 N/A N/A N/A N/A

15.789031505585 ACK N/A 5895417 N/A 2 22 0.29 1.76

15.789042472839 SEQ 5956233 N/A N/A 44 65535 0.29 1.76

15.789044857025 SEQ 5957681 N/A N/A 44 65535 0.29 1.76

15.789049148560 ACK N/A 5898313 N/A 45 65535 0.44 2.81

Tabella 4.1

si può notare che al 15.070728302002 sec si ha un dato di tipo WIR che indica un valore della qualità del canale pari a 18, ossia le condizioni del collegamento sono talmente peggiorate, che c'è stata una dissociazione. Poi il valore della Cwnd viene messo a 1, ossia al valore di instaurazione della connessione per poi aumentare di

seguito con il ricevimento del primo ACK.

Figura_4. 5

Si vede come l'aumento dei valori del RTO e di conseguenza del SRTT non sia dovuto a delle ritrasmissioni; uesto aumento è dovuto ad un peggioramento della qualità del canale e a delle ritrasmissioni ai livelli superiori rispetto a quello fisico.

4.10.b - Prove a 50 metri in 802.11g

Il rate trasmissivo medio è stato di circa 16 Mbps, con un forte ribasso intorno al 43 sec per motivi che andremo ora a esaminare.

Figura_4. 7

Dalla figura 4.9 si può notare l'andamento dei SEQ e degli ACK nel tempo, e il rispettivo valore del RTO. Dallo zoom del grafico nella zona interessata si può notare un brusco incremento del RTO dal 43.6 a 43.8.

Figura_4. 8

Come si può vedere dalla figura 4.9 nella zona interessata si ha un abbassamento della qualità del canale, in viola, tale da far aumentare di proporzione i valori

dell'RTO e dell'SRTT.

Figura_4. 9

E' da notare, nella tabella 4.3 e soprattutto dal grafico 4.10, come per il pacchetto il numero 83400217, precedente al volore dell'ultimo Seq il valore della CWND venga abbattuto al valore minimo.

Time Type Seq Ack Qlink CWND SSTHRESH SRTT RTO

43.378643512726 SEQ 83462481 N/A N/A 45 2147483647 0.02 0.25

43.399946928024 WIR N/A N/A 34 N/A N/A N/A N/A

43.499942302704 WIR N/A N/A 34 N/A N/A N/A N/A

43.5999422073 WIR N/A N/A 34 N/A N/A N/A N/A

43.619954586029 SEQ 83400217 N/A N/A 1 22 0.02 0.25

43.661350965500 ACK N/A 83403113 N/A 2 22 0.06 0.38

43.661355257034 SEQ 83463929 N/A N/A 44 65535 0.06 0.38

43.661360025406 SEQ 83465377 N/A N/A 44 65535 0.06 0.38

Figura_4. 10

4.10.c – Prove a 100 metri in 802.11b

Figura_4. 11

La figura mostra l'andamento dei Seq e dei rispettivi Ack nel tempo, e si nota subito qualcosa di interessante tra i 23 e i 26 secondi. Ponendo l'attenzione nello zoom della zona interessata,e nella tabella 4.4, si nota che c'è la ritrasmissione del pacchetto 17081145 all'istante 23.786, con la cwnd che viene messa a 1, la ssthresh

a metà del precedente valore della cwnd, e il seguente processo di backoff esponenziale che porta al raddoppio del valore dell'Rto.

Time Typ

e Seq Ack Qlink CWND SSTHRESH SRTT RTO

23.561456680298 ACK N/A 17081145 N/A 45 2147483647 0.12 0.35

23.561457872391 SEQ 17141961 N/A N/A 45 2147483647 0.12 0.35

23.561459302902 SEQ 17143409 N/A N/A 45 2147483647 0.12 0.35

23.786728858948 SEQ 17081145 N/A N/A 1 22 0.12 0.35

24.238958835602 SEQ 17081145 N/A N/A 1 22 0.12 0.70

24.419274330139 ACK N/A 17098521 N/A 2 22 0.28 1.60

Tabella 4.4

Figura_4. 12

Al 25° secondo si nota che il valore della qualità del link arriva fino a 176, valore che indica la disassociazione.

Time Type Seq Ack Qlink CWND SSTHRESH SRTT RTO

24.605265617371 ACK N/A 17127481 N/A 12 22 1.14 4.06

24.620606899261 WIR N/A N/A 105 N/A N/A N/A N/A

...

25.654279232025 WIR N/A N/A 176 N/A N/A N/A N/A

25.677252292633 ACK N/A 17127481 N/A 12 22 1.14 4.06

Figura_4. 13

Si nota bene da questo ingrandimento il “buco” tra i 24.6 e i 25.6 causato dalla disassociazione, e si può vedere come tra 24 e 26 sec la cwnd sia minore del valore della ssthresh, ossia ci si trova in una situazione di Slow Start e la cwnd incrementa molto rapidamente, mentre dai 26 sec in poi si nota un incremento graduale della

cwnd, infatti la cwnd > ssthresh e ci si trova in Congestion Avoidance.

4.10.d - Prove a 100 metri in 802.11g

Dall’osservazione dell’andamento della Congestion Window (CWND) nel grafico 4.15, è possibile notare il susseguirsi di fasi di Slow Start e di Congestion Avoidance. La Slow Start Threshold (SSTHRESH, in verde) ne è un indicatore: quando CWND è minore o uguale a SSTHRESH si osserva che la CWND incrementa più velocemente, quindi siamo in una fase di Slow Start. Al superare della SSTHRESH, invece, la CWND modifica il suo andamento, aumentando di 1 Full-Sized-Segment ogni RTT. Dal grafico si vede che una zona in cui si ha il meccanismo della Slow Start è nei primi due e tra 6 e 8 secondi. Facendone uno zoom si vede che non ci sono ritrasmissioni ma solo una perdita della connessione.

Figura_4. 15

Dopo quei cinque valori si riparte come al solito con CWND = 1 e viene poi raddoppiata all'arrivo del primo ACK.

Time Type Seq Ack Qlink CWND SSTHRES

H SRTT RTO

5.939586877823 SEQ 3805105 N/A N/A 45 22 0.20 0.44

5.943697929382 WIR N/A N/A 18 N/A N/A N/A N/A

6.008301496506 WIR N/A N/A 18 N/A N/A N/A N/A

6.072918891907 WIR N/A N/A 18 N/A N/A N/A N/A

6.13751006126 WIR N/A N/A 18 N/A N/A N/A N/A

6.202116966248 WIR N/A N/A 18 N/A N/A N/A N/A

6.221511602402 SEQ 3742841 N/A N/A 1 22 0.20 0.44

6.284923553467 ACK N/A 3745737 N/A 2 22 0.28 1.08

Figura_4. 16

Figura_4. 17

Dalla figra 4.18 , ma soprattutto dalla tabella 4.7 si nota come avvenga la ritrasmissione del Seq 13620433, con l'abbattimento della CWND a 1 e come il valore dell'Rto raddoppi nel caso di mancato Ack. Confrontando inoltre gli istanti di ritrasmissione del pacchetto in questione con i valori dell’RTO nella tabella 4.5, si nota che ogni ritrasmissione avviene precisamente allo scadere del Timeout.

Time Type Seq Ack Qlink CWND SSTHRESH SRTT RTO

20.310933351517 ACK N/A 13620433 N/A 24 9 0.08 0.31

20.505778074265 SEQ 13620433 N/A N/A 1 12 0.08 0.31

20.906332492828 SEQ 13620433 N/A N/A 1 12 0.08 0.62

21.707441329956 SEQ 13620433 N/A N/A 1 12 0.08 1.24

23.309659004211 SEQ 13620433 N/A N/A 1 12 0.08 2.48

26.514089822769 SEQ 13620433 N/A N/A 1 12 0.08 4.96

32.922952413559 SEQ 13620433 N/A N/A 1 12 0.08 9.92

32.956972837448 ACK N/A N/A N/A 2 12 0.08 22.10

Tabella 4.7

4.11 - Prove TCP in Mare a 150 metri

4.11.a Prova in 802.11b

Abbiamo riscontrato un rate medio di 4Mbps.

Figura_4. 18

11161689 per cinque volte, il raddoppiamento del Rto e il valore della ssthresh a 22 pari alla metà della cwnd come da standard.

Time Type Seq Ack Qlin

k CWND SSTHRESH SRTT RTO

17.220268726349 ACK 11222505 11161689 N/A 45 14 0.25 0.59

17.220273256302 SEQ 11223953 N/A N/A 45 14 0.25 0.59

17.220277309418 SEQ 11161689 N/A N/A 45 14 0.25 0.59

17.621802330017 SEQ 11161689 N/A N/A 1 22 0.25 0.59

18.509364128113 SEQ 11161689 N/A N/A 1 22 0.25 1.18

20.375598669052 SEQ 11161689 N/A N/A 1 22 0.25 2.36

23.439208984375 SEQ 11161689 N/A N/A 1 22 0.25 4.72

29.536903619766 SEQ 11161689 N/A N/A 1 22 0.25 9.44

29.539146184921 ACK N/A 11184857 N/A 2 22 2.64 22.03

29.539149999619 SEQ 11184857 N/A N/A 2 22 2.64 22.03

Tabella 4.8

Prendendo in considerazione l'andamento della cwnd nel tempo, si vede dalla figura 4.15 come questa aumenta bruscamente fintanto che è minore della ssthresh, per poi aumentare più dolcemente nel momento in cui ne supera il valore.

4.11.b Prova in 802.11g

Dalla figura 4.22 si può vedere l'evoluzione del rate durante la prova e si nota (in verde) un rate medio molto basso per essere in tecnologia 802.11g, solo 4Mbps, questo a causa dei 14 sec di interruzione del collegamento dal 20 al 34.

Dalla figura 4.23 si nota come nella zona di depressione del rate si hanno delle ritrassioni di pacchetti, accentuato nella figura 4.24.

Figura_4. 22

Infatti andando a considerare la Tabella 4.9 , si vede come avvenga la ritrasmissione del pacchetto 12454092 per ben 6 volte, e cosi accade fintanto che non si arriva al

pacchetto n°

Time Type Seq Ack Qlink CWND SSTHRESH SRTT RTO

14.631739139557 SEQ 12454092 N/A N/A 45 15 0.06 0.33

14.632046461105 ACK N/A 12391057 N/A 45 15 0.06 0.33

14.632047891617 SEQ 12454092 N/A N/A 45 15 0.06 0.33

14.632050514221 SEQ 12454092 N/A N/A 45 15 0.06 0.33

14.633099317551 ACK N/A 12393953 N/A 45 15 0.06 0.33

14.633100748062 SEQ 12454092 N/A N/A 45 15 0.06 0.33

14.633103370667 SEQ 12454092 N/A N/A 45 15 0.06 0.33

14.633391857147 ACK N/A 12396849 N/A 45 15 0.06 0.33

14.633393287659 SEQ 12454092 N/A N/A 45 15 0.06 0.33

Tabella 4.9

Dalla figua 4.25 si può notare il susseguirsi della fasi di Slow Start e di Condition Avoidance: ci si trova sempre in uno stato di Congestion Avoidance tranne nella zona delle ritrasmissioni, tra i 20 e i 34 secondi, in cui ci si trova nella fase di Slow Start.

Nelle implementazioni Linux lo stimatore del Round Trip Time (RTT) ed il calcolo dell’RTO differiscono rispetto alle specifiche standard proposte dall’IETF . Linux

segue il principio base fornito nell’RFC 2988, ma si discosta dalla specifica nella gestione della RTTVAR. Una significativa differenza tra l’RFC 2988 e l’implementazione Linux riguarda il limite minimo del valore dell’RTO: in Linux esso è posto a 200 ms, invece dei 1000 ms dati dall’RFC 2988. Si osserva che, grazie agli algoritmi di Congestion Control, lo stream di ricezione è identico a quello di trasmissione: allo scadere dell’RTO il trasmettitore entra in uno stato detto ‘Loss state’ [c], secondo cui tutti i segmenti non confermati vengono considerati persi e allo scadere del Timeout, l’RTO viene aggirnato con un Exponential Backoff. Il trasmettitore esce dal ‘Loss state’ solo in seguito alla ricezione degli ACK relativi a tutti i datagrammi considerati persi.