# Analisi protocollo CSMA/CD

Vogliamo comprendere quantitativamente le prestazioni del protocollo CSMA/CD (che riguardano Ethernet e Wifi).

## Ipotesi

* Lunghezza pacchetti fissa
* tempo di trasmissione di un pacchetto pari a 1 unita' di tempo
* **G** e' il **carico offerto**, ossia il numero di trasmissioni tentate per unita' di tempo
* **S** e' il **throughput**, ossia il ratio (pacchetti/sec trasmessi sul canale). Dipende da G, vale inoltre S < G, `0<S<1`

## Il modello Poisson
La probabilita' di avere k tentativi di trasmissione in t unita' di tempo e' una **distribuzione di Poisson** (modello Poisson):

```
P[k in [0,t]] = (G*t)^k*e^(-(G*t))/k!

con k = 0:

p[k=0] = e^(-G*t)
```
Questo e' un modello a popolazione infinita (idealmente).

* Definiamo quindi la **capacita' di un protocollo ad accesso multiplo**, ossia il massimo valore di S tra tutti i valori possibili di G.

### Nota: perche' Poisson?

Il modello di poisson e' utilizzato ogni volta che si verificano una serie di avvenimenti (arrivi) nel tempo che siano indipendenti tra loro. Possono essere gocce di pioggia che cadono come trasmissioni su di una rete.

## Analisi

Suddividendo l'attivita' sul canale in **cicli**, formati da:
* idle phase: (durata I)
* busy phase: (durata B)

I e B sono **variabili casuali** e la durata di ciclo successiva e' indipendente dalla precedente, essendo che I e B sono casuali.

Il ciclo sara' quindi di durata `C = I+B`.

Se considero **p come probabilita' di successo di una trasmissione in un periodo busy**, con distribuzione esponenziale:
```
p = p( 0 trasmissions in a) = e^(-a*G) // non ci sono altre trasmissioni nell'intervallo di vulnerabilita'
```
* Ogni periodo busy comincia con una trasmissione
* una trasmissione che comincia un periodo busy ha successo se non avvengono altre trasmissioni durante l'intervallo a.

Ottengo il throughput come (**Renewal Reward Theory**):

```
S = p/E[C] = p/(E[I] + E[B]) // S e' il throughput sulla rete
```
### I

I e' distribuito esponenzialmente a media 1/G (e' il tempo medio tra due arrivi).

### B

Due casi:

#### Caso 1: busy senza collisioni (NC)

Se non ci sono collisioni, il periodo busy dura 1+a: infatti, nonostante il tempo di trasmissione sia 1, il tempo di propagazione sul canale permette ai restanti peer di vedere il canale come libero solo dopo 1+a.

```
E[B|NC] = 1 + a con P(NC) = e^(-aG)
```
#### Caso 2: busy con collisioni (C)

Sapendo che la probabilita' di collisione sul canale e' `P(C) = 1 - e^(-a*G)`. Per calcolare E[B], suppongo (semplificando) che **una sola trasmissione interferisca col pacchetto che comincia il periodo busy**.
Posso affermare:

* Il pacchetto interferente arriva in media **a/2 dopo l'inizio del pacchetto busy**.
* Il pacchetto interferente trasmette per **a unita' di tempo** prima che venga rivelata la collisione, nel caso peggiore.
* Dopo che il pacchetto interferente viene fermato, occorre **tempo a addizionale prima che il canale diventi idle**.

Quindi:
```
E[B|C] = 5*a/2
```
Dalla formula generale di media condizionata:

```
E[B] = P(NC)*E[B|NC] + P(C)*E[B|C]
```
Avendo E[I] ed E[B], posso ottenere il throughput S della rete dalla precedente formula.
*(vedi slides per plot)*

## Risultati

Dal plot di throughput / load (S/G), posso notare:

* a (tempo di propagazione) limita il valore massimo del throughput: Piu' e' grande, minore e' il throughput
* al crescere del carico (G) diminuisce il throughput, una volta superato il valore massimo di carico. Prima di superare il valore massimo di carico, il throughput e' crescente con il carico.

Da questo si evince che la variabile cruciale del sistema e' **il tempo di propagazione**.

Ethernet utilizza quindi la randomizzazione per **desincronizzare le trasmissioni**. Un algoritmo distribuito adattativo per spargere il carico nel tempo in caso di contesa per l'accesso multiplo al canale.

# (De)Sincronizzazione di aggiornamenti di routing periodici

Negli anni '90 sono state osservate **perdite periodiche nel traffico end-to-end in Internet**. Queste perdite sono state studiate utilizzando *ping* tra due nodi per monitorare la rete. *(vedi slides per grafico)*
Sembrava che la rete avesse dei momenti di congestione periodici, anche senza traffici anomali generati dagli utenti. Questo era dovuto a una **sincronizzazione dei router**, in particolare i router sincronizzavano il momento in cui trasmettevano in broadcast **le informazioni per l'aggiornamento dell'algoritmo link-state** usato per il routing. Essendo che queste trasmissioni avvenivano tutte nello stesso momento, il risultato erano **picchi di traffico non desiderati** che causavano la perdita di altri pacchetti.

Il fenomeno della **sincronizzazione spontanea** tra router si verificava in quanto ogni volta che un router riceveva un'aggiornamento da un link vicino, questo droppava il proprio aggiornamento e spendeva del tempo per processare l'aggiornamento ricevuto. Questo fa si che **il tempo speso nello stato di calcolo dell'aggiornamento dipende dai messaggi ricevuti dagli altri router**, ed essendo che questi non possono essere calcolati in maniera deterministica, il comportamento dei router sul lungo periodo da luogo a comportamenti patologici, tra cui la sincronizzazione. *(vedi slides per grafico)*

La possibilita' che si crei sincronizzazione dipende anche dai parametri del sistema. Per evitare la sincronizzazione, il **tempo di attesa** che un router passava (in cui non stava quindi calcolando Dijkstra) e' formato da **una componente fissa e una componente casuale**. Se la componente casuale e' troppo ridotta, si verifica sincronizzazione tra i router.

Se invece il tempo casuale e' dello stesso ordine di grandezza del tempo fissato (per esempio, Tr compreso tra [0.5Tp, 1.5 Tp], la sincronizzazione non avviene, nemmeno in tempi lunghi. Il tempo casuale ottimale e' pero' al di la' delle capacita' analitiche attuali, quindi al momento i valori sono fissati per induzione.

# Randomizzazione nella gestione attiva delle code (Active Queue Management)

Normalmente, i buffer dei router sono FIFO: quando si saturano, la coda effettua una procedura **drop-tail**, scartando i pacchetti che arrivano ma non stanno nel buffer.

Problematiche:
* le code si intasano, generando **ritardo end-to-end** determinato dalla lunghezza delle code nei commutatori
* code in overflow sono un male per protocolli come TCP (che e' puramente deterministico): 

1. connessioni con alto tasso di trasmissione *uccidono* connessioni a basso tasso di trasmissione
2. connessioni **sincronizzano** la loro risposta alla congestione. In presenza di router poco potenti, questo puo' voler dire che ci sono periodi in cui la coda e' vuota (e quindi i pacchetti non vengono trasmessi) e periodi in cui la coda e' congestionata. Spreco di risorse (perche' non sto utilizzando il link al meglio).