UniTO/anno2/YearI/FirstSem/CR/lesson11-06112017.md

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