# Randomizzazione nelle reti

## Active Queue Management (continua)

**Drop tail policy**: queue FIFO, pacchetti in eccesso scartati, non efficace: crea **latenza** (code nei router) e **perdite burst**, con rischio di sincronizzazione delle connessioni TCP e successiva **perdita di throughput**.

### Risoluzione dei problemi di Drop Tail

#### Random Early Detection (RED)

*Scarto casuale in anticipo*. I pacchetti sono accettati o scartati **prima di entrare nella coda**, con una certa **probabilita'**, dipendente dallo stato attuale (lunghezza) della coda. E' uno scarto probabilistico, **ogni flusso ha lo stesso tasso di perdita**. Questo crea:

1. Transizioni piu' morbide da nessuna perdita a burst loss
2. Non uccide i flussi a tasso basso (come succede con drop tail)
3. Evita la sincronizzazione degli eventi di perdita percepiti dalle sorgenti. I cicli di perdita seguiti da basso carico non sono piu' presenti.

* Problema: **picchi di traffico (burst) penalizzati.** Per questo i pacchetti non sono scartati con una funzione della lunghezza istantanea, ma mantenere una media della lunghezza. La media e' mantenuta con la tecnica di **media mobile esponenziale (Exponentially Weighted Moving Average)** [EWMA].

In RED, l'applicazione di EWMA consente di stabilire delle **fasce** di comportamento:
* **No drop**: se la coda e' in questo range, nessun pacchetto viene droppato
* **Probabilistic Early Drop** (fascia attorno ai valori medi della lunghezza della coda)
* **Forced Drop** (coda troppo lunga: pacchetti droppati)

*(vedi slides per probability drop graph e grafico RED)*
I vantaggi di RED rispetto a Drop-Tail sono in realta' poco significativi. E' quindi implementato nei router, ma pochissimo utilizzato, a causa dei sostantivi svantaggi.

* **Svantaggi di RED**: complessita' di EWMA e RED rende difficile adattare i parametri (**5 parametri, vedi drop graph**) all'utilizzo ottimale, che dipende dal tipo di traffico (durata della connessione, carico, etc).

Uno svantaggio inoltre e' **il jump da maxp a 100% nel probability drop graph**, che si e' migliorato utilizzando il **Gentle RED** (invece di saltare, transizione lineare *ripida*.

##### EWMA

**Filtro passa basso**: trasforma i picchi in variazioni minori (**smoother**)

L = lunghezza attuale (*vera*)
Lmobile = lunghezza mobile
L(n-1) = valori precedenti di L
a = parametro arbitrariamente vicino a 0 (L molto maggiore), o vicino a 1 (L(n-1) molto maggiore)

```
Lmobile = a*L(n-1) + (1-a)*L
```
* Vantaggi: evita di penalizzare i burst di traffico eccessivamente, ma reagisce ai cambiamenti su scala di tempo piu' lunga (in quanto *sudden changes* hanno un peso minore.

##### Approccio alternativo a RED, real-time

In applicazioni real-time (telefonia, video...) e' stato proposto un approccio di drop-head (invece di drop-tail) per favorire i pacchetti nuovi (in arrivo) rispetto a quelli vecchi (rimasti piu' a lungo in coda).

## BitTorrent

Protocollo P2P, 2002, molto usato (*cacheLogic: 35% di internet totale*). Fa uso estensivo della randomizzazione.

* Pensato per grandi files
* Divisione di files in piccole parti (pezzi da 256KB, a sua volta suddiviso in blocchi da 16KB).
* Pensato per utilizzare la capacita' di upload dei peers, che si suppone siano collegati in numero efficace ad ogni momento. Piu' peer, piu' banda *aggregata*.

Costruisce uno swarm (torrent) per ogni file, in cui gli utenti si *aiutano* per scaricare il file. Essendo il file spezzettato (in pezzi da 256KB, a sua volta suddiviso in blocchi da 16KB).

Nomenclatura:
1. seed: peer che ha in locale (e in condivisione) l'intero file
2. leech: peer che ha in locale parti del file
3. tracker: server di raccoglimento dei dati di seeders e leechers. Ogni nuovo peer utilizza un file *.torrent*, che contiene l'IP del tracker, di modo che il nuovo peer ottenga una lista di peer (peerset). **Il tracker rende il sistema attaccabile: senza di esso, non funziona il protocollo**.
4. peerset: lista di peer distribuita da un tracker. Inizialmente e' **casuale**, formata da 50 peer. Prima fonte di randomizzazione del sistema. 50 per garantire che lo swarm sia **sempre connesso, mai partizionato**. (Grafi casuali).
5. **tit-for-tat**: upload verso il peer da cui ho maggiormente scaricato durante gli ultimi 30 secondi, per ogni 4 peer. Questo favorisce i seeders e penalizza i freeriders (che si connettono per scaricare e poi lasciano lo swarm). **Piu' upload, piu' peer rimangono connessi**.
6. **rarest-first**: priorita' di invio al pezzo piu' raro tra quelli posseduti dai vicini. La rarita' dei pezzi e' stabilita scambiando con i 4 peer delle **bitmap** che indicano i pezzi posseduti dai vicini. Questo permette al sistema di utilizzare tutta la capacita' del servizio.

### Funzionamento

* Il nuovo peer sceglie 4 peer a caso dal peerset iniziale. Altra fonte di randomizzazione.

* Il nuovo peer inizia uno scambio di chunks con i 4 peer scelti.

* Ogni 30 secondi, il peer che seeda di meno viene escluso e un altro peer viene scelto. (tit-for-tat). 

#### Selezione dei chunks (dettagli)

All'inizio, il nuovo peer scarica chunks **casualmente**. Questo per ottenere pezzi facilmente scambiabili, perche' rarest first rende l'inizio del download molto lento. Dopo aver ottenuto 4 pezzi, rarest first comincia. Inoltre, i pezzi **unici** dai seed vanno scaricati (per renderli piu' comuni nei leech).

* Fase **fine-del-gioco**: Problema basato sull'osservazione empirica (non dimostrabile). Alla fine del download, il tempo di scaricamento aumenta (ultimi pezzi sono i piu' rari). Per questo le ultime richieste vengono fatte non solo ai 4 peer scelti, ma a **tutto il peerset**, per massimizzare lo scaricamento dei blocchi critici.

Anche facendo richiesta a tutto il peerset, il problema dei pezzi critici non e' completamente risolto. Questo anche perche' **i peer che ottengono tutti i pezzi critici potrebbero uscire dallo swarm**. Per questo motivo, quasi tutti i client incoraggiano gli utenti a restare attivi (diventare seed) dopo lo scaricamento dei files (rimanendo spesso attivi in background).
Un'altra soluzione e' il **network coding**, che invece di scaricare pezzi, scarica una **combinazione lineare di pezzi** (es. XOR di alcuni pezzi). Questo crea un *mescolamento* di chunks, che e' pero' **invertibile** (posso ottenere i pezzi veri a partire da quelli mescolati).
Questo rende i pezzi rari meno frequenti, e quindi piu' facilmente scaricati. Introduce pero' troppa complessita', e quindi non e' utilizzata.

#### Selezione dei peers (dettagli)

Un set di 4 peer **unchoked**.

* Ogni 30 secondi si scarta il peer con il piu' basso tasso di download, e si fa **unchoke** id un peer **casuale** (optimistic unchoking).

Questo ha molti vantaggi, tra cui:
1. **load balancing** tra i peers. (permette di sfruttare meglio la capacita' di upload aggregata nel sistema).
2. permette l'ingresso di nuovi client / peers
3. mantiene la rete connessa, dato che **ogni peer ha probabilita' non nulla di interagire con un altro peer**.

## Randomizzazione e Load balancing

### La potenza delle due scelte (power of two choices)

Il problema del bilanciamento del carico e' dato dalla difficolta', posti piu' server che mi offrono un servizio, di scegliere **in quale coda entrare** (e quindi quale server utilizzare).

Approcci:
* Random - scelta casuale
* Join shortest queue (SQ): ottimale, ma **non si puo' conoscere lo stato di tutte le code del sistema formato da piu' server**, quindi non posso scegliere una coda in base al numero di peer in coda (non posso scegliere la coda piu' corta).
* SQ(d): una variante di Join shortest queue che estrae `d` code a caso, ottiene solo lo stato di quelle `d` code ed entra in quella piu' corta. Questo e' di solito utilizzato con `d=2`, che rispetto a random, **diminuisce la latenza di un fattore `log(n)`**. Aumentando d>2 la latenza diminuisce solo di un fattore costante, che non e' particolarmente vantaggioso. *(vedi slides per esempio balls and bins)*.

#### Supermarket Model: dimostrazione delle due scelte

Il modello del supermercato *(vedi slides)* mostra una situazione di code di arrivo multiple in cui i clienti devono scegliere in che coda andare. Utile per dimostrare la complessita' della potenza delle due scelte.

* Ipotesi:
1. Rate of arrival = **Poisson random variable**
2. Exponential service times

Td = ritardo atteso nel caso di `d` scelte (da minimizzare)
n = numero di server
lambda = rate coefficient
u = tempo di smaltimento delle code

```
n*u > n*lambda

Risultati:

SQ(1) = T1 = 1 / (1/(u-lambda))

SQ(d) = Td = log(T1) / log(d), d > 1
```