128 lines
8.4 KiB
Markdown
128 lines
8.4 KiB
Markdown
# 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
|
|
```
|