domani mcad
This commit is contained in:
Francesco Mecca
parent
fcadefaf38
commit
637cc132e2
1373 changed files with 93 additions and 552667 deletions
|
|
@ -1,138 +0,0 @@
|
||||||
# SDN
|
|
||||||
|
|
||||||
## Piano di controllo di rete aperto
|
|
||||||
|
|
||||||
Astraendo il piano di controllo si ottiene un piano di controllo **aperto**, centralizzato rispetto alle macchine (che quindi si occupano solo di smistare i pacchetti). Sul piano di controllo e' possibile implementare applicativi quali SmartGrid, routing, TE, Mobility.
|
|
||||||
|
|
||||||
Il piano di controllo astratto (**NetOS**) puo' avere varie implementazioni, la piu' comune e' **openflow**.
|
|
||||||
|
|
||||||
## OpenFlow
|
|
||||||
|
|
||||||
SDN non e' openflow, openflow e' un'implementazione di SDN.
|
|
||||||
|
|
||||||
OpenFlow introduce delle astrazioni, la principale e' il **flusso**, che rappresenta la **granularita'** del controllo. I flussi sono identificati tramite 10 (circa) combinazioni di valori di *headers (vedi slides)*, valide per switch ethernet, router IP, NAT, firewall, etc. I flussi **non permettono di processare pacchetti individuali**, per cui non e' possibile effettuare **per-packet processing, deep packet inspection**, etc.
|
|
||||||
|
|
||||||
### Switch OpenFlow
|
|
||||||
|
|
||||||
Tre componenti:
|
|
||||||
* **Flow Table**: specifica l'azione che lo switch compie sul flusso. (inoltro verso porta x, scarto, etc).
|
|
||||||
* **Canale di comunicazione sicuro**: verso il controllore, per l'installazione di entries nella flow table, segnalazione di eventi, etc.
|
|
||||||
* **OpenFlow protocol**: per lo scambio di messaggi tra il processo del controllore e lo switch.
|
|
||||||
|
|
||||||
Tra le varie regole di gestione dei pacchetti:
|
|
||||||
* Pattern (bit-matching sul valore degli header files)
|
|
||||||
* Azioni (scarto, inoltro, modifica, invio al controllore, invio alla *processing pipeline* dell'hardware (se e' in grado))
|
|
||||||
* Priorita' per disanbiguare pattern sovrapposti
|
|
||||||
* Contatori: num bytes, num pacchetti
|
|
||||||
|
|
||||||
*(vedi slides per entries nella flow table)*
|
|
||||||
*(vedi slides per esempi)*
|
|
||||||
|
|
||||||
Quando un pacchetto e' ricevuto, si procede con il bit-match su ogni valore della flow table. Identificato il match, si procede all'azione definita. => **In base alle caratteristiche dell'header del pacchetto**, questo viene processato, e cio' vale per tutti i pacchetti di uno stesso tipo. Un flow e' quindi una categoria (astrazione) di pacchetti a cui corrisponde una determinata azione.
|
|
||||||
Inoltre, in base al tipo di device che voglio implementare (router, switch, firewall, etc) considero entry diverse nella fflow table. Cio' rende l'astrazione di OpenFlow molto potente e versatile. Notare che le regole di flusso definite nella flow table sono valide per tutti i device sulla rete.
|
|
||||||
|
|
||||||
* Ogni azione OpenFlow puo' essere configurata tramite vari parametri *(vedi slides)*
|
|
||||||
|
|
||||||
### Programmabilita' del controllore
|
|
||||||
|
|
||||||
Il controllore e' formato da un applicativo implementato sul NetOS e il NetOS stesso. Raccoglie processa eventi dagli switch, rispondendo con comandi inviati agli switch.
|
|
||||||
|
|
||||||
#### Esempio: controllo di accesso dinamico
|
|
||||||
|
|
||||||
*(vedi slides per disegno)*
|
|
||||||
1. ispezione del primo pacchetto del flusso da parte del controllore (sito in un punto centralizzato, es. server)
|
|
||||||
2. Il controllore consulta le sue policy riguardanti il pacchetto ispezionato
|
|
||||||
3. il controllore installa una regola per bloccare / instradare il flusso sull'**intera rete**
|
|
||||||
4. il traffico puo' fluire tra sorgente e destinazione
|
|
||||||
|
|
||||||
Senza SDN, il controllo di accesso dinamico e' molto piu' complesso, in quanto installare regole sull'intera rete e' molto piu' complesso.
|
|
||||||
|
|
||||||
#### Esempio: mobilita' trasparente
|
|
||||||
|
|
||||||
1. Flusso in corso
|
|
||||||
2. host si muove, inviando pacchetti attraverso un nuovo switch della stessa rete
|
|
||||||
3. il controllore modifica le regole per instradare il flusso, identificando un nuovo percorso ottimale
|
|
||||||
4. il traffico procede lungo il nuovo percorso
|
|
||||||
|
|
||||||
#### Esempio: load balancing (bilanciamento del carico)
|
|
||||||
|
|
||||||
0. Pre-installazione di policy di load balancing su switch
|
|
||||||
1. Due host connessi allo stesso switch
|
|
||||||
2. Il traffico dei due host e' **diviso** in base al source IP, attraverso path diversi sulla rete, per evitare il sovraccarico dei nodi.
|
|
||||||
|
|
||||||
Questo approccio e' statico, ma ci sono alternative piu' intelligenti che sfruttano un approccio dinamico.
|
|
||||||
|
|
||||||
#### Esempio: virtualizzazione della rete
|
|
||||||
|
|
||||||
Se considero una rete con **piu' di un controller**, la stessa rete deve essere **partizionata** (di modo che i controller non vadano in conflitto). Da una stessa rete fissa posso ottenere piu' reti virtuali logicamente separate.
|
|
||||||
|
|
||||||
### Protocollo OpenFlow
|
|
||||||
*(vedi slides)*
|
|
||||||
Utilizza TCP per lo scambio di messaggi.
|
|
||||||
|
|
||||||
#### Messaggi Controller to Switch
|
|
||||||
|
|
||||||
Funzioni di base:
|
|
||||||
* features: controllore interroga lo switch in merito a una certa feature, lo switch risponde
|
|
||||||
* configure: settare parametri di config
|
|
||||||
* modify-state: modifica di entry nella flow table
|
|
||||||
* packet-out: controllore ordina di inviare paccheto a una specifica porta di uscita dello switch
|
|
||||||
|
|
||||||
#### Messaggi Switch to Controller
|
|
||||||
|
|
||||||
Funzioni di base:
|
|
||||||
* packet-in: trasferisce il pacchetto al controllore
|
|
||||||
* flow removed: rimozione di una entry nella flow table dello switch
|
|
||||||
* port status: informa riguardo al cambiamento di stato di una interfaccia
|
|
||||||
|
|
||||||
Gli operatori di rete non devono occuparsi dei messaggi, in quanto essi sono gestiti dal NetOS, e sono comandati tramite linguaggi di alto livello (tra cui POX, una versione di NOX in Python).
|
|
||||||
Il controllore SDN e' quindi il cervello della rete, che implementa un modello **event-based** (il protocollo OpenFlow) realizzato tramite ambienti vari (NOX, POX, etc).
|
|
||||||
|
|
||||||
### Sviluppi futuri
|
|
||||||
|
|
||||||
* SDN su reti wireless/cellulari (per rendere piu' economica e flessibile la struttura mobile)
|
|
||||||
|
|
||||||
### Applicazione a Data Center
|
|
||||||
|
|
||||||
Un data center massivo richiede una struttura gerarchica di dispositivi (switch) di costi estremamente elevati e gestione complessa. Un SDN permette di costruire switch *custom-built* abbattendo costi, e gestendo unificamente la rete semplifica la gestione.
|
|
||||||
|
|
||||||
### Futuro: che fine faranno gli standard?
|
|
||||||
|
|
||||||
Supponendo che SDN prenda piede come gestione della rete, tutti gli standard che finora sono implementati nell'RFC avranno valore minore. Gli standard definiranno le interfacce, mentre il controllore implementera' le regole definite dagli amministratori di rete (e non dalle aziende costruttrici dell'hardware).
|
|
||||||
|
|
||||||
# Randomizzazione nelle reti
|
|
||||||
|
|
||||||
Introduzione volontaria di comportamenti random in una rete. Utilizzata in molti protocolli:
|
|
||||||
* multiple access Ethernet
|
|
||||||
* rimozione di sincronizzazioni indesiderate (comportamenti patologici di una rete deterministica)
|
|
||||||
* gestione attiva di una coda (router, etc)
|
|
||||||
* BitTorrent load balancing
|
|
||||||
* generic load balancing (potenza delle due scelte causali)
|
|
||||||
* routing random a due hop (per ottenere soluzioni piu' eleganti
|
|
||||||
|
|
||||||
## Randomizzazione in Ethernet
|
|
||||||
|
|
||||||
I protocolli di accesso multiplo regolano la gestione di conflitti su un canale ethernet condiviso, e fanno uso di randomizzazione in quanto le ritrasmissioni sono effettuate dopo un tempo casuale (**algoritmo di backoff esponenziale**). Sull'ethernet cablato questo non si verifica piu', ma il protocollo Wifi fa largo utilizzo di questa tecnica. *(vedi slides per schizzo di Metcalfe, inventore di ethernet)*.
|
|
||||||
|
|
||||||
Un protocollo di accesso multiplo e' quindi un **algoritmo distribuito** che regola la trasmissione su un canale ethernet, e sfrutta la capacita' di ethernet di fare sensing durante la trasmissione per identificare le collisioni (**CSMA/CD**).
|
|
||||||
*(vedi slides per CSMA/CD pseudocodice)*.
|
|
||||||
|
|
||||||
### Backoff esponenziale
|
|
||||||
|
|
||||||
1. Prima collisione (per un pacchetto): scegli k a caso in {0,1}, due valori possibili. Attesa e' `k * 512`.
|
|
||||||
2. Ogni successiva collisione raddoppio l'intervallo (2,4,8,16...,1024 valori, 10 collisioni max, kmax = 1023).
|
|
||||||
3. Una volta che il messaggio e' stato trasmesso, il contatore delle collisioni viene resettato a 0 e l'algoritmo ricomincia da (1) con un nuovo pacchetto.
|
|
||||||
|
|
||||||
Nota: diversamente da TCP, non si tiene traccia dei precedenti valori di congestione (TCP regola la congestion window in base ai valori precedenti). In ethernet, la finestra e' legata alla cautela nel trasmettere (e non all'aggressivita', come in TCP). Ethernet fa **multiplicative increase, complete decrease**, il che lo rende molto aggressivo sulla trasmissione di nuovi pacchetti.
|
|
||||||
|
|
||||||
### Analisi di CSMA/CD: Modello prestazionale
|
|
||||||
|
|
||||||
L'obbiettivo di un modello prestazionale ha l'obbiettivo di comprendere quantitativamente le prestazioni di CSMA/CD.
|
|
||||||
Supponiamo:
|
|
||||||
* Lunghezza fissa dei pacchetti
|
|
||||||
* Tempo di trasmissione dei pacchetti pari ad 1 unita' di tempo
|
|
||||||
* **throughput S**: numero di pacchetti trasmessi senza collisione (con successo) nell'unita' di tempo (da trovare). Nota: **S** avra' un valore massimo (asintotico) di 1, essendo che e' misurato su 1 unita' di tempo.
|
|
||||||
* **a (alpha)**: intervallo di propagazione end-to-end (intervallo durante il quale possono avvenire collisioni). **Intervallo di vulnerabilita'.**
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,128 +0,0 @@
|
||||||
# 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
|
|
||||||
```
|
|
||||||
|
|
@ -1,152 +0,0 @@
|
||||||
# The power of two choices (continua)
|
|
||||||
|
|
||||||
## Modello del supermarket
|
|
||||||
|
|
||||||
Il modello del supermarket e' un modello che illustra il vantaggio di scegliere 2 code a caso contro la scelta di una sola coda. Le code sono considerate code MM1.
|
|
||||||
Tra la scelta di una coda e la scelta di due code *(vedi lesson11 per equazioni)*, si nota:
|
|
||||||
|
|
||||||
* Con SQ(1), ossia con la singola coda scelta a caso, l'arrivo di clienti sulle code causa ritardi **esponenziali**
|
|
||||||
* Con SQ(2), i ritardi sono abbattuti di un fattore *log* (logaritmico)
|
|
||||||
* Con SQ(d), d>2, i ritardi sono minori ma il guadagno e' minimo rispetto a SQ(2).
|
|
||||||
|
|
||||||
### Dimostrazione del vantaggio delle due scelte
|
|
||||||
|
|
||||||
Siano:
|
|
||||||
```
|
|
||||||
lambda = rate coefficient
|
|
||||||
u = tempo di smaltimento delle code
|
|
||||||
n = totale code
|
|
||||||
d = totale code che posso scegliere (si considera 1, 2)
|
|
||||||
|
|
||||||
mi(t) = numero di code con almeno 'i' clienti al tempo 't'. // devono essere minori in SQ(2) rispetto a SQ(1)
|
|
||||||
|
|
||||||
Si(t) = mi(t) / n; //frazione di code con almeno 'i' clienti al tempo 't', o mi(t) normalizzata
|
|
||||||
|
|
||||||
```
|
|
||||||
* Supponiamo che il numero di code del sistema tenda a **infinito**. Questo fa si che il sistema abbia comportamenti **deterministici**, secondo la legge dei grandi numeri.
|
|
||||||
|
|
||||||
* Questo da luogo a un'**equazione differenziale ordinaria**, dove la randomicita' del sistema scompare:
|
|
||||||
|
|
||||||
```
|
|
||||||
d[Si(t)]/dt = lambda*(S[i-1, d](t) - S[i,d](t)) - u*(Si(t) - S[i+1](t)) // per la normalizzata
|
|
||||||
|
|
||||||
d[mi(t)]/dt = n*lambda*(S[i-1, d](t) - S[i,d](t)) - n*u*(Si(t) - S[i+1](t)) // per mi(t), basta moltiplicare la normalizzata per n
|
|
||||||
|
|
||||||
NOTA: la d all'interno dei parametri di Si e' elevamento a potenza
|
|
||||||
```
|
|
||||||
#### Dimostrazione di validita' dell'ODE
|
|
||||||
|
|
||||||
La ODE e' divisa in due termini:
|
|
||||||
|
|
||||||
* `n*u*(Si(t) - S[i+1](t))` e' il **numero di code con** `i` **clienti in attesa**, moltiplicato per `u` che e' il rate di servizio. Questo termine e' il **rate con cui la derivata sul tempo di mi(t) diminuisce.**
|
|
||||||
|
|
||||||
* `n*lambda*(S[i-1, d](t) - S[i,d](t))` rappresenta l'unico evento in cui d[mi] **aumenta**: quando un cliente nuovo si uniscea una coda che ha esattamente `i-1` clienti. (quindi mi(t)++). Questo avviene con **probabilita'**:
|
|
||||||
```
|
|
||||||
S[i-1, d](t) - S[i,d](t)
|
|
||||||
```
|
|
||||||
* Infatti, la precedente probabilita' esclude `S[i,d](t)`, che e' il caso in cui viene scelta una coda con gia' `i` clienti in attesa, che non vuole essere considerata nella differenziale relativa a `mi(t)`.
|
|
||||||
|
|
||||||
##### Risoluzione
|
|
||||||
|
|
||||||
* Consideriamo l'ODE per la differenziale normalizzata (dividendo quindi per n):
|
|
||||||
```
|
|
||||||
d[Si(t)]/dt = lambda*(S[i-1, d](t) - S[i,d](t)) - u*(Si(t) - S[i+1](t)) // per la normalizzata
|
|
||||||
```
|
|
||||||
* Consideriamo, per semplicita', `u = 1` (non e' restrittivo).
|
|
||||||
|
|
||||||
* Vogliamo quindi raggiungere un **equilibrio** (valori stazionari del sistema), ossia quelli in cui **la variazione di Si(t) e' 0** (pertanto `d[Si(t)]/dt = 0`). Questo comporta:
|
|
||||||
|
|
||||||
```
|
|
||||||
0 = lambda*(S[i-1,d] - S[i,d]) - (S[i] - S[i+1])
|
|
||||||
```
|
|
||||||
* Dove `0 <= S[i] <= 1`.
|
|
||||||
|
|
||||||
* Notiamo ora che la frazione di code con 0 clienti dentro e' 1 (**non ci sono code con meno di 0 clienti in attesa**), quindi `S[0] = 1`
|
|
||||||
|
|
||||||
* Da questo risultato, dobbiamo trovare tutti gli altri S[i], che pero' ci presentano il problema di dipendere **sia da S[i-1] sia da S[i+1].**
|
|
||||||
|
|
||||||
* Possiamo affermare:
|
|
||||||
```
|
|
||||||
S[i] = lambda*S[i-1,d] // che e' una geometrica troncata, riscrivibile come la soluzione sotto riportata.
|
|
||||||
```
|
|
||||||
|
|
||||||
* Pertanto la soluzione:
|
|
||||||
```
|
|
||||||
S[i] = lambda^((d^i-1)/(d-1))
|
|
||||||
```
|
|
||||||
|
|
||||||
* Che e' una **double-exponential decrease** (perche' l'esponenziale `d...` e' elevato a `i`). Dato che lambda e' sempre compreso tra 0 e 1 e asintotico a 1, il doppio esponenziale fa si che piu' alto e' `i`, piu' il numero di code con almeno `i` elementi e' **esponenzialmente piccolo**.
|
|
||||||
|
|
||||||
#### Considerazioni
|
|
||||||
|
|
||||||
In base alla soluzione ottenuta, la SQ(1) diventa:
|
|
||||||
```
|
|
||||||
S0 = 1
|
|
||||||
S1 = lambda
|
|
||||||
S2 = lambda^2
|
|
||||||
S3 = lambda^3
|
|
||||||
etc...
|
|
||||||
```
|
|
||||||
Quindi, SQ(1) e' un **exponential decrease**, mentre SQ(2) e' **double exponential decrease**.
|
|
||||||
|
|
||||||
## TL;DR
|
|
||||||
|
|
||||||
Per dimostrare la potenza delle due scelte, abbiamo utilizzato una **mean-field approximation** (n a infinito) per eliminare le randomicita', ottenendo una ODE che rappresenta la variazione del numero di code con `i` clienti al loro interno.
|
|
||||||
Per trovare una soluzione alla ODE, abbiamo utilizzato la soluzione di **equilibrio**, che implica la derivata nulla (il sistema non ha cambiamenti).
|
|
||||||
Notiamo quindi la presenza di una **soluzione unica**, che affermiamo risolvere l'equazione di equilibrio. Da questa approssimazione otteniamo una soluzione finale come **double exponential decrease** che e' un grado esponenziale piu' alto rispetto alla SQ(1), in cui la decrescita e' solo **exponential decrease**.
|
|
||||||
|
|
||||||
### Un'osservazione sul load balancing
|
|
||||||
|
|
||||||
Il tema del load balancing e' molto attuale, infatti per una server farm con un alto numero di server (10000, 100000...) si discute ancora di versioni migliorate della potenza delle due scelte per garantire un load balancing quando lo stato intero del sistema e' troppo grande da ottenere in real time.
|
|
||||||
|
|
||||||
**C'e' un'alternativa con bassissimo overhead** alla potenza delle due scelte, ed e' la seguente:
|
|
||||||
|
|
||||||
* Ogni server scarico viene aggiunto a una pool di server *vuoti* che gestiscono le nuove richieste in arrivo. Questo sistema funziona fintanto che ho disponibilita' di server scarichi, cosa che per un numero molto elevato di server e' molto probabile.
|
|
||||||
|
|
||||||
Questo risolve il load balancing problem in maniera semplice, ma funziona solo con un numero elevato di server. E' anche vero che con un numero minore di server, lo stato delle code in tempo reale e' facilmente ottenibile.
|
|
||||||
|
|
||||||
# Instradamento randomizzato a due hop
|
|
||||||
|
|
||||||
Analizziamo il caso in cui una rete deve essere:
|
|
||||||
* **robusta** a cambiamenti di traffico (no sovraccarico)
|
|
||||||
* **con minimo overhead** (di aggiornamenti di routing al variare del traffico)
|
|
||||||
|
|
||||||
L'obbiettivo e' quindi di trovare **i miglior hop per i pacchetti da un link in ingresso a un link in uscita**.
|
|
||||||
|
|
||||||
## Caso 1: matrice di traffico
|
|
||||||
|
|
||||||
Voglio creare una **matrice di traffico**, rappresentando un grafo pesato in forma matriciale. La matrice di traffico e' pero' difficile (se non impossibile) da stimare.
|
|
||||||
|
|
||||||
*(vedi slides per matrice esempio)*
|
|
||||||
|
|
||||||
Sappiamo pero' che un nodo chiave (i.e. nodo regionale) rappresentera' un'intera **riga** (o colonna) della matrice, costruendo quello che si chiama **nodo aggregato**. Possiamo utilizzare una tecnica chiamata Valiant load Balancing.
|
|
||||||
|
|
||||||
### Valiant Load Balancing
|
|
||||||
|
|
||||||
Ogni pacchetto che entra nella rete e':
|
|
||||||
1. inviato **a un nodo intermediario scelto a caso**
|
|
||||||
2. inviato in modo **diretto** dal nodo intermediario alla destinazione.
|
|
||||||
|
|
||||||
Pertanto il passaggio 1 non e' deterministico, mentre il secondo si. Questo funziona bene se la rete considerata (di nodi aggregati) e' **completamente connessa**, oppure l'algoritmo di valiant load balancing va mappato su una rete che non sia completamente connessa.
|
|
||||||
|
|
||||||
* Supponiamo che tutti i nodi aggregati abbiano banda `r` ai propri sottonodi, dovranno quindi avere una capacita' di `r` anche su tutti i link che collegano i nodi aggregati *(vedi slides)*, se non utilizziamo il valiant load balancing.
|
|
||||||
|
|
||||||
* Con il valiant load balancing, ottengo:
|
|
||||||
```
|
|
||||||
B(link) = 2*r / (N-1) // ciascuno dei contributi di r sul link e' al piu' r/N-1, perche' e' spalmato su N nodi
|
|
||||||
```
|
|
||||||
Dove B e' la banda richiesta da un link e N e' il numero di nodi.
|
|
||||||
|
|
||||||
#### Discussione: randomizzazione (approfondimento)
|
|
||||||
|
|
||||||
*(vedi articolo su slides)*
|
|
||||||
|
|
||||||
# Indirezione
|
|
||||||
|
|
||||||
Butler Lampson scrisse che ogni problema in CS puo' essere risolto aggiungendo un altro livello di indirezione. L'indirezione e' **il passaggio da un'entita' intermedia per raggiungere una destinazione**, che pero' potrebbe essere raggiunta direttamente.
|
|
||||||
|
|
||||||
E' un meccanismo elegante che risolve molti problemi.
|
|
||||||
|
|
||||||
## Indirezione e multicast
|
|
||||||
|
|
||||||
Il multicast e' applicazione diretta del principio di indirezione, in quanto le sorgenti dei pacchetti spediscono semplicemente al gruppo multicast, che sono l'**ente intermedio** che si occupa di smistare e distribuire i pacchetti. Le destinazioni (ricevitori) si devono semplicemente registrare al gruppo multicast (IGMP soft-state).
|
|
||||||
|
|
@ -1,165 +0,0 @@
|
||||||
# Indirezione (continua)
|
|
||||||
|
|
||||||
## Indirezione e mobilita'
|
|
||||||
|
|
||||||
Problema: nodi mobili in movimento, che si agganciano a reti diverse. Questo si applica alle reti cellulari (location update etc.) ma e' trattato negli RFC di **mobile IP**.
|
|
||||||
|
|
||||||
### Terminologia e Approcci
|
|
||||||
|
|
||||||
* **Correspondent**: colui che vuole mandare pacchetti al nodo mobile
|
|
||||||
* **Routing indiretto**: flusso dati passa attraverso un **home agent** (indirezione) prima di raggiungere il nodo mobile
|
|
||||||
* **Routing diretto**: il correspondent ottiene il **foreign address** del nodo mobile, poi gli invia i dati direttamente
|
|
||||||
|
|
||||||
Il nodo mobile ha una **home network** dove e' definito un **permanent address** che non varia nel tempo, con cui il correspondent puo' attuare il tracciamento del nodo mobile. Inoltre nel home network e' definito un **home agent** che svolge le funzioni di mobilita' quando il nodo mobile non e' all'interno della home network.
|
|
||||||
|
|
||||||
Il nodo mobile si sposta dall'home network a una **visited network**, in cui ottiene un **care-of-address**, ossia l'indirizzo nella visited network.
|
|
||||||
|
|
||||||
Ogni visited network contiene un foreign agent, che svolge le funzioni di mobilita' (il foreign agent puo' essere all'interno della macchina del nodo mobile).
|
|
||||||
|
|
||||||
Ogni nodo che si sposta dal proprio home network deve avviare un processo di **registrazione**, in cui il nodo mobile contatta il foreign agent della visited network, il quale a sua volta contatta l'home agent. I due agent si comunicano la visited network del nodo mobile, di modo che questo sia rintracciabile dall'home network.
|
|
||||||
|
|
||||||
### Routing Indiretto
|
|
||||||
|
|
||||||
* Il correspondent invia pacchetti usando il permanent address del nodo mobile come destinazione, come se il nodo mobile fosse fisso nell'home network.
|
|
||||||
|
|
||||||
* L'home agent intercetta i pacchetti del correspondent (se il nodo mobile non e' nell'home network) e li ridirige verso il foreign agent.
|
|
||||||
|
|
||||||
* Il foreing agent inoltra i pacchetti ricevuti al nodo mobile.
|
|
||||||
|
|
||||||
* Il nodo mobile puo' rispondere direttamente al correspondent.
|
|
||||||
|
|
||||||
#### Osservazioni
|
|
||||||
|
|
||||||
Con questo approccio, si ha un vantaggio di **trasparenza** per il correspondent, che comunica col permanent address all'insaputa dell'attuale posizione del nodo mobile. Se il nodo mobile si sposta ma l'home agent aggiorna il care-of-address, **le connessioni in corso possono essere mantenute**.
|
|
||||||
|
|
||||||
Si ha pero' uno svantaggio: il **routing a triangolo** e' inefficiente quando il correspondent e il nodo mobile sono vicini.
|
|
||||||
|
|
||||||
### Routing Diretto
|
|
||||||
|
|
||||||
* Correspondent richiede (e riceve) l'indirizzo foreing address del nodo mobile.
|
|
||||||
|
|
||||||
* Il correspondent procede quindi a mandare pacchetti al foreing agent, il quale li inoltra al nodo mobile.
|
|
||||||
|
|
||||||
* Il nodo mobile replica direttamente al correspondent.
|
|
||||||
|
|
||||||
|
|
||||||
#### Osservazioni
|
|
||||||
|
|
||||||
Con questo approccio, il routing e' piu' efficiente (no routing a triangolo).
|
|
||||||
|
|
||||||
Lo svantaggio e' la **perdita di trasparenza** da parte del correspondent, che ora si deve occupare di ottenere il care-of-address, aggiornarlo. Di conseguenza, se il nodo mobile si sposta, **connessioni in corso non possono essere mantenute**.
|
|
||||||
|
|
||||||
### IP Mobile
|
|
||||||
|
|
||||||
RFC 3220, descrive le caratteristiche e le problematiche del routing (indiretto) per nodi mobili.
|
|
||||||
Problematiche:
|
|
||||||
|
|
||||||
* impraticita' del routing indiretto, soprattutto nell'implementazione dell'home agent (tunnel / NAT).
|
|
||||||
* egress filtering: non sempre e' possibile mandare sorgenti da un ip che non appartiene alla propria rete (i router li droppano). Rischio spoofing.
|
|
||||||
|
|
||||||
## Costruzione di un'infrastruttura di Indirezione in Internet
|
|
||||||
|
|
||||||
Internet non e' (nativamente) appropriato per comunicazioni in cui i nodi non sono fissi e definiti (e' **unicast, ma non multicast, anycast o mobile**). Per ovviare a questo problema, e' stata proposta la III (Indirection Internet Infrastructure), con lo scopo di rendere l'indirezione un **servizio di base, o di prima classe**.
|
|
||||||
|
|
||||||
### III (o I3)
|
|
||||||
|
|
||||||
Presenta un **cambiamento del paradigma di comunicazione**: non piu' punto-punto, ma per **id del contenuto** (che puo' essere numerico, testuale, etc).
|
|
||||||
|
|
||||||
* Ogni pacchetto ha un id.
|
|
||||||
* Per ricevere il pacchetto con identificativo id, il ricevente R installa un **trigger** (ID, R) nella rete di **overlay**.
|
|
||||||
* Il sender usa l'ID per mandare i contenuti (una tuple **(ID, data)**) al trigger.
|
|
||||||
* il trigger usa (R, data), dove R e' un secondo ID per indirizzare i dati ricevuti dal sender verso il receiver.
|
|
||||||
|
|
||||||
#### Modello di servizio
|
|
||||||
|
|
||||||
API:
|
|
||||||
1. sendPacket(p);
|
|
||||||
2. insertTrigger(t);
|
|
||||||
3. removeTrigger(t); // opzionale
|
|
||||||
|
|
||||||
* Si appoggia su una rete IP (best effort).
|
|
||||||
* Host utilizzano dei **timeout** per aggiornare periodicamente i trigger. (**soft state -> robusto**)
|
|
||||||
* Affidabilita', controllo di flusso e congestione sono implementati dai nodi agli estremi e dagli overlay.
|
|
||||||
|
|
||||||
Il modello di servizio e' quindi un **publish-subscribe** a livello applicativo, che contiene una infrastruttura di overlay. Ogni trigger e' simile a una entry nella tabella di routing, che pero' e' gestita dai nodi terminali.
|
|
||||||
|
|
||||||
##### Funzionamento
|
|
||||||
|
|
||||||
Quando il receiver si muove in un'altra rete, aggiorna il suo trigger di modo che il sender, tramite il nodo di overlay, sia in grado di contattarlo in modo trasparente (non deve conoscere la rete dove si trova il receiver).
|
|
||||||
L'**anonimita'** e' un grande vantaggio di questo approccio.
|
|
||||||
|
|
||||||
* L'applicazione e' in grado di passare da unicast a multicast, basta registrare piu' triggers con il medesimo ID e la rete di overlay si occupa di mandare il messaggio a piu' receivers.
|
|
||||||
|
|
||||||
##### Anycast
|
|
||||||
|
|
||||||
Comunicazione con un nodo qualunque di un insieme di nodi (ex: piu' server che offrono lo stesso servizio, e l'utente richiede il servizio a uno qualunque di essi).
|
|
||||||
|
|
||||||
Per rendere possibile questo meccanismo, il trigger contiene lo stesso ID per ogni receiver interessato, ma anche **qualificatori anycast** che informano la rete di overlay di scegliere solo uno dei peer interessati.
|
|
||||||
|
|
||||||
#### Servizi Componibili
|
|
||||||
|
|
||||||
Si usa uno **stack di ID** per codificare operazioni successive da svolgere sui dati, senza aver bisogno di configurare percorsi tra i servizi. Questo e' possibile utilizzando piu' di un' ID all'interno del trigger, creando una serie di servizi a *cipolla* (stack di servizi).
|
|
||||||
Ogni server intermedio riceve il pacchetto con l'id, esegue il servizio, toglie l'id interessato dal servizio e lo manda al server successivo. Cosi' facendo, il pacchetto viene processato e inviato al ricevitore, senza bisogno di configurare manualmente i path dei server che forniscono i servizi.
|
|
||||||
|
|
||||||
Questa tecnica permette di processare i dati da entrambe le parti (lato mittente e lato ricevitore), e anche di processare dati in maniera diversa per ricevitori diversi.
|
|
||||||
|
|
||||||
### Conclusione
|
|
||||||
|
|
||||||
L'indirezione presenta molti vantaggi *(vedi slides)* ma anche molti problemi, soprattutto per quanto riguarda la sicurezza.
|
|
||||||
|
|
||||||
Inoltre, nel caso in cui il server volesse conoscere l'identita' dei ricevitori, potrebbe installare un trigger (IDack, S) con il quale i ricevitori possono mandare degli ACK al sender, che ha id S.
|
|
||||||
|
|
||||||
# Distributed Hash Table (DHT)
|
|
||||||
|
|
||||||
L'obbiettivo e' implementare una hash table distribuita su internet, non centralizzata sul singolo nodo. Caratteristica essenziale e' che **non sia necessario avere dettagliate informazioni sull'intera rete per gestire la DHT** (conoscenza parziale: ogni nodo e' collegato unicamente a pochi nodi vicini, e conosce solo quelli). Questo e' utile nel caso dei trigger, e infatti segue un'interfaccia simile a I3:
|
|
||||||
|
|
||||||
* insert (key,value);
|
|
||||||
* lookup (key);
|
|
||||||
|
|
||||||
I nodi di una rete contengono delle parti della hash table, presentando il problema principale:
|
|
||||||
|
|
||||||
* **Data una chiave, bisogna instradare il messaggio al nodo che contiene la chiave**.
|
|
||||||
|
|
||||||
Questa procedura deve utilizzare il minor numero possibile di hop, anche senza che ogni nodo conosca l'intera rete. (basso fanout).
|
|
||||||
|
|
||||||
*(vedi slides per grafico)*
|
|
||||||
|
|
||||||
## Struttura (obbiettivi di progetto)
|
|
||||||
|
|
||||||
Rete overlay con mappaggio flessibile di chiavi e nodi fisici, basso fanout, instradamento locale. Esempio: **Chord**
|
|
||||||
|
|
||||||
### Chord
|
|
||||||
|
|
||||||
* Spazio di identificativi a `m` bit: `2^m` IDs.
|
|
||||||
* Identificativi ordinati su **anello logico** (chord ring) modulo `2^m`.
|
|
||||||
* I peer scelgono una chiave (a caso per favorire decentralizzazione) e vengono identificati come **gestori** di un range di chiavi (di modo da dividere il keyset in piu' parti).
|
|
||||||
* le chiavi vengono mappate quindi sul **primo nodo con ID piu' grande della chiave**, chiamato **successor** della chiave.
|
|
||||||
#### Lookup base
|
|
||||||
|
|
||||||
Ogni nodo memorizza la posizione del nodo successivo (solo quello). Questo comporta un numero non ottimale di hop, ma e' semplice (instrada in circolo lungo un anello). Il tempo di instradamento e' **O(N)** (worst case), in quanto se un nodo cerca una chiave molto grande rispetto alla sua, deve circolare gran parte dell'anello.
|
|
||||||
*(vedi slides per grafico)*
|
|
||||||
|
|
||||||
#### Accelerazione dei lookup
|
|
||||||
|
|
||||||
Essendo che il lookup base e' lineare (inefficiente), posso accelerarlo utilizzando delle **finger tables**: ogni nodo le usa per conoscere (al piu') `m` entries, dove `N = 2^m`.
|
|
||||||
*(vedi slides per esempi)*
|
|
||||||
<!--La entry i-esima nella tabella contiene l'id del nodo che gestisce la -->
|
|
||||||
|
|
||||||
Otteniamo quindi che:
|
|
||||||
```
|
|
||||||
finger[i] = successor (n+2^(i-1))
|
|
||||||
```
|
|
||||||
*(vedi slides per algoritmo)*
|
|
||||||
* Ogni nodo ha conoscenza piu' accurata della parte di anello seguente a lui piu' vicina, e piu' vaga della parte piu' lontana.
|
|
||||||
|
|
||||||
Questa accelerazione permette di avere un numero di hop O(log(N))
|
|
||||||
|
|
||||||
#### Churn
|
|
||||||
|
|
||||||
Fenomeno di nodi che entrano ed escono dal sistema. Questo necessita di spostare le chiavi memorizzate altrove, aggiornare le finger table, e limitare il churn. (+ churn = + overhead)
|
|
||||||
|
|
||||||
-> **Occorre un middleware** che gestisca memorizzazione e recupero di valori.
|
|
||||||
|
|
||||||
### Osservazioni
|
|
||||||
|
|
||||||
Le DHT sono usate in bittorrent e altri protocolli per la loro natura decentralizzata e robusta (molto meno vulnerabili di server centralizzato).
|
|
||||||
|
|
@ -1,88 +0,0 @@
|
||||||
# Multiplazione
|
|
||||||
|
|
||||||
La multiplazione e' la condivisione di risorse tra utenti che usano le risorse stesse. Ha moltissime sfaccettature, che possono essere viste come **dimensioni**.
|
|
||||||
|
|
||||||
* **Granularita' del traffico utente**: **pacchetto**, **chiamata**, o **burst** *intermedio* (gruppo di pacchetti trattati come unita' singola.
|
|
||||||
* **Non disponibilita' della risorsa**: **blocco** (perdita), **accomodamento**.
|
|
||||||
* ** Tipo di multiplazione**: **garantita**, su **richiesta** (best effort), prenotazione statistica *intermedio* (garanzia su una probabilita' / percentuale)
|
|
||||||
|
|
||||||
|
|
||||||
Altre dimensioni possono includere **granularita' temporale**, oppure se la multiplazione e' condivisa tra utenti o tra una classe.
|
|
||||||
|
|
||||||
Due casi verranno studiati: **Multiplazione in Internet** (livello di pacchetto) e **Multiplazione nella rete telefonica** (livello di chiamata / canale)
|
|
||||||
|
|
||||||
Nota: Spesso questi studi sono riferiti a QoS sulle reti, che potrebbero non essere essenziali su WAN ma su molte reti locali lo sono.
|
|
||||||
|
|
||||||
## Multiplazione in Internet
|
|
||||||
|
|
||||||
A livello di pacchetto, la multiplazione e' caratterizzata dai buffer dei router (spesso FIFO) che devono adottare una politica per scegliere quali pacchetti trasmettere. Il problema e' quindi di **schedulazione (scheduling)**.
|
|
||||||
|
|
||||||
### Schedulazione di pacchetti
|
|
||||||
|
|
||||||
* FIFO: I primi pacchetti che arrivano sono trasmessi, con **drop-tail** (che scarta i pacchetti arrivati per ultimi).
|
|
||||||
* RED: vedi note precedenti.
|
|
||||||
* **Priorita' secca**: trasmissione del pacchetto in attesa nella coda, dando precedenza a quelli con **priorita' piu' alta**. *(slides per schemi e rappresentazione grafica)** Un esempio pratico e' la priorita' ai pedoni su un incrocio. Un problema di questo approccio e' lo starving dei pacchetti a bassa priorita', se i pacchetti con priorita' alta continuano ad arrivare.
|
|
||||||
* **Round robin**: come per la priorita' secca, divido i pacchetti in classi. Lo scheduler visita ciclicamente le code delle classi (che in questo caso sono trattate come separate), con il seguente approccio. Se un pacchetto e' pronto per la trasmissione, lo trasmetto e cambio coda, altrimenti salto alla coda successiva. Facendo cosi' solo un pacchetto per ogni coda e' servito. Un vantaggio e' che non distrugge o limita le risorse a disposizione dei pacchetti di *bassa priorita'*. Il limite di RR e' che uno schema di questo tipo tratta tutte le classi in maniera equa, riducendo le risorse in base al numero di classi *(k classi, C capacita': capacita' per ogni classe e' C/k)*
|
|
||||||
* **Weighted Fair Queuing** (WFQ): equivalente del *generalized processor sharing*, e' una generalizzazione del RR in cui le **classi hanno un peso**. Facendo cosi' (supponendo che peso piu' alto == servizio migliore) assegno a classi diverse risorse diverse in base alla loro priorita' (importanza). Questo permette di ripartire la banda tra varie classi **senza limitarne nessuna**, grazie al funzionamento stile RR che garantisce un servizio a ogni classe.
|
|
||||||
|
|
||||||
*Nota: in SO si tratta spesso il caso della apprehension, in cui il lavoro viene sospeso se arriva un lavoro a priorita' piu' alta. Questo in Internet non si fa, perche' non ha senso interrompere una trasmissione di pacchetti.*
|
|
||||||
|
|
||||||
*Nota II: Nella descrizione non si tiene conto della dimensione variabile dei pacchetti in Internet, che hanno (circa) dimensione massima di 1500 Byte e dimensione minima di 40 Byte (header livello 3 e 4).*
|
|
||||||
|
|
||||||
### Policing (admission control)
|
|
||||||
|
|
||||||
Regole implementate in rete a pacchetto di modo da limitare il traffico in ingresso, affinche' questo non superi i parametri dichiarati.
|
|
||||||
|
|
||||||
Criteri usati:
|
|
||||||
* **Tasso medio** (di lungo periodo): quanti pacchetti posso trasmettere nell'unita' di tempo (mediando su un lungo intervallo). Qui la questione cruciale e' la lunghezza dell'intervallo su cui si media: 100 pacchetti al secondo o 6000 al minuto hanno lo stesso tasso medio.
|
|
||||||
* **Tasso di picco**, che considera il numero di pacchetti trasmessi in un picco di traffico
|
|
||||||
* **Max Burst size**, che limita il numero massimo di pacchetti consecutivi ammissibili, senza pause in mezzo).
|
|
||||||
|
|
||||||
#### Meccanismi di policing
|
|
||||||
|
|
||||||
* **Token bucketi**: limita traffico in ingresso a specifici Burst Size e AVG rate. La tecnica utilizzata e' un *secchio bucato* che fa *cadere token*, i quali permettono di venire trasmessi al network. Il secchio e' rifornito a rate costante *r* e puo' contenere al piu' *B* tokens. I pacchetti fisici che arrivano dagli utenti devono **aspettare il token** per venire inviati. In questo modo, regolando i parametri di `r` e `B` posso effettuare del policing sulla rete, dato che:
|
|
||||||
```
|
|
||||||
su un intervallo di lunghezza t:
|
|
||||||
|
|
||||||
#PacchettiAmmessi <= r*t + B
|
|
||||||
```
|
|
||||||
Avere dei *bounds* certi (deterministici) permesse di fornire garanzie dettagliate. In combinazione con il WFQ scheduling, questo permette di **ottenere un upper bound deterministico certo sul ritardo massimo subito da un pacchetto**, garantendo il QoS.
|
|
||||||
|
|
||||||
##### Combinare WFQ e Token Bucket
|
|
||||||
|
|
||||||
Per combinare le due tecniche, e' sufficiente inserire un Token Bucket per ogni coda WFQ. Ogni bucket e' rifornito a rate `r[i]` e ha dimensione `B[i]`, regolata nella seguente maniera:
|
|
||||||
|
|
||||||
* Ho un *per-flow rate* `R`, e considero la bucket size `b` e il token rate `r`. Avro' che il ritardo massimo (delay) massimo e' `Dmax=b/R`.
|
|
||||||
|
|
||||||
### Applicazioni di Multiplazione e QoS in Internet
|
|
||||||
|
|
||||||
Le reti locali / private sono quelle in cui il QoS e' trattato in maniera specifica, spesso utilizzando VPN per garantire certi standard di QoS.
|
|
||||||
|
|
||||||
## Multiplazione in Rete Telefonica
|
|
||||||
|
|
||||||
Commutazione e Multiplazione di **chiamate** invece che pacchetti, con un sistema di **blocco** se la risorsa non e' disponibile, e multiplazione **su richiesta**.
|
|
||||||
|
|
||||||
### Struttura della rete telefonica
|
|
||||||
|
|
||||||
3 livelli gerarchici:
|
|
||||||
|
|
||||||
* **Nucleo** ad ampia scala geografica (Wide Area Core)
|
|
||||||
* **rete telefonica distrettuale**, come i Local Exchange carrier (LEC)
|
|
||||||
* **Centrale Telefonica**.
|
|
||||||
|
|
||||||
Le reti telefonice sono **completamente connesse**, dove il massimo numero di *hop* e' 2 (non c'e' bisogno di instradamenti piu' complessi). Infatti, se i due nodi (chiamante/chiamato) sono all'interno della stessa LEC, e' sufficiente 1 hop, altrimenti 2 per l'nioltro al nucleo.
|
|
||||||
|
|
||||||
### Caratteristiche notevoli dell'instradamento in rete tel.
|
|
||||||
|
|
||||||
Il comportamento di una rete telefonica e' **prevedibile**, permettendo anche di calcolare il carico sulla rete nella centrale telefonica. Per fare cio', e' sufficiente utilizzare **misure del traffico passato**, per determinare ore del giorno e periodi in cui i percorsi sono provati.
|
|
||||||
|
|
||||||
### Dynamic, Non-Hyerarchical Routing (DNHR)
|
|
||||||
|
|
||||||
Problema: l'utilizzo di 2 hop (richiedendo il doppio delle risorse di 1 hop) avviene piu' frequentemente in situazioni di sovraccarico della rete, perche' le chiamate a 2 hop **bloccano due chiamate a singolo hop**. Per risolvere questo problema, si riserva spazio sul canale per chiamate a 2 hop.
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
## Multiplazione Burst-level
|
|
||||||
|
|
||||||
Usata nella rete cellulare, basata sull'idea che **si trasmette traffico solo quando si rileva un'attivita'**. E' il caso della soppressione del silenzio nei cellulari, che causa la trasmissione della chiamata solo quando l'utente parla *(talkspurts)*.
|
|
||||||
Questa e' la causa della sensazione che si ha quando si parla al telefono e la rete sembra morta, mentre in realta' non sta rilevando una voce parlante ma solo il rumore di fondo e quindi non sta trasmettendo. Attualmente si mappa il rumore di fondo e lo si trasmette, di modo che chi parla non abbia la sensazione di *parlare con un muro*
|
|
||||||
|
|
@ -1,162 +0,0 @@
|
||||||
# Traffic Engineering
|
|
||||||
|
|
||||||
Il problema dell'ingegneria del traffico, analizzato utilizzando metodi basati su programmazione lineare e trattando implementazioni in reti reali.
|
|
||||||
Nelle reti spesso e' necessario risolvere problemi di ottimizzazione, percio' e' necessario l'utilizzo di programmazione lineare e non lineare (non vista in questo corso).
|
|
||||||
|
|
||||||
## Ripasso: programmazione lineare
|
|
||||||
|
|
||||||
I problemi di programmazione lineare si possono ridurre ad una forma standard:
|
|
||||||
```
|
|
||||||
minimize sum(i=1, N) of (c[i]*x[i]) // sommatoria da minimizzare, soggetta ai vincoli sotto elencati
|
|
||||||
|
|
||||||
subject to (vincoli) sum(j=1, n) of (a[i,j]*x[j]) which must be equal to b[i]
|
|
||||||
|
|
||||||
on conditions:
|
|
||||||
i = [1,...,m],
|
|
||||||
x >= 0,
|
|
||||||
j = [1,...,n],
|
|
||||||
n >= m,
|
|
||||||
vincoli linearmente indipendenti
|
|
||||||
```
|
|
||||||
### Riduzione alla forma standard
|
|
||||||
|
|
||||||
#### Massimizzazione
|
|
||||||
|
|
||||||
Si nota come una massimizzazione puo' essere effettuata al posto della minimizzazione semplicemente introducendo un segno negativo all'interno della sommatoria da minimizzare.
|
|
||||||
|
|
||||||
#### Variabili surplus / slack
|
|
||||||
|
|
||||||
Si nota inoltre come si possano utilizzare vincoli con disuguaglianza `a*x >= b` semplicemente riconducendo la disuguaglianza alla forma standard `a*x = b`. Per fare cio':
|
|
||||||
|
|
||||||
* Aggiungo una variabile **di surplus**
|
|
||||||
|
|
||||||
```
|
|
||||||
y[i] = variabile di surplus
|
|
||||||
```
|
|
||||||
* Sottraggo alla disuguaglianza:
|
|
||||||
|
|
||||||
```
|
|
||||||
sum(j=1, n) of (a[i,j]*x[j] - y[i]) which must be equal to b[i]
|
|
||||||
```
|
|
||||||
* Per la forma `a*x < b`, aggiungo una **variabile di slack** e la sommo alla disuguaglianza
|
|
||||||
|
|
||||||
```
|
|
||||||
sum(j=1, n) of (a[i,j]*x[j] + y[i]) which must be equal to b[i]
|
|
||||||
```
|
|
||||||
#### Variabili libere
|
|
||||||
|
|
||||||
Inoltre, una variabile `x1` e' detta **libera** se puo' assumere valori sia positivi che negativi che nulli. Questo non presenta un problema perche' **qualunque numero si puo' esprimere come la differenza di due numeri positivi e/o nulli**. Quindi `x1 = u1 - v1` dove `u1,v1 > 0`.
|
|
||||||
|
|
||||||
Posso anche sostituire a x1 la sua espressione ottenuta invertendo uno dei vincoli, il che presenta il notevole vantaggio di consumare un vincolo.
|
|
||||||
|
|
||||||
### Risoluzione
|
|
||||||
|
|
||||||
La risoluzione di un problema di programmazione lineare si puo' ottenere utilizzando **l'algoritmo del simplesso**, che e' risolvibile in tempo **polinomiale in (n,m)** (buono).
|
|
||||||
|
|
||||||
#### Esempio: percorsi ottimi con pesi assegnati (shortest-paths)
|
|
||||||
|
|
||||||
Il problema di trovare i cammini minimi in un grafo si puo' scrivere come un problema di programmazione lineare. Supponiamo le ipotesi sopra date e supponiamo inoltre di avere **i pesi dei link pre-assegnati**.
|
|
||||||
|
|
||||||
*(vedi slides per procedura risolutiva e forma standard)*
|
|
||||||
|
|
||||||
**Nota: i vincoli presentati sono conservazioni del flusso**: infatti, su un link i voglio che il flusso in entrata sia uguale a quello in uscita (flusso di uscita - flusso di entrata = 0). I vincoli restanti ( =1, =-1) sono casi particolari in cui si considera il nodo sorgente e il nodo destinazione. Dalla sorgente il traffico si divide in cammini che daranno somma totale 1 (penultimo vincolo), ma non e' presente traffico entrante (sommatoria negativa = 0). Nella destinazione, viceversa, il traffico e' solamente entrante, e quindi la somma e' -1 (sommatoria positiva = 0). I cicli non sono considerati in quanto la ricerca del cammino minimo li esclude per definizione.
|
|
||||||
|
|
||||||
Questa forma di programmazione lineare consente di utilizzare l'algoritmo del simplesso (tramite un risolutore) al posto di Dijkstra. La soluzione puo' essere interpretata come segue: *(vedi slides)*
|
|
||||||
|
|
||||||
### Forma matriciale della forma standard
|
|
||||||
|
|
||||||
Si puo' riscrivere la forma standard del problema di programmazione lineare come:
|
|
||||||
|
|
||||||
```
|
|
||||||
minimize transposed(c)*x
|
|
||||||
|
|
||||||
subject to (vincoli) A*x = b, x >= 0
|
|
||||||
```
|
|
||||||
Dove:
|
|
||||||
* x, c sono vettori colonne di dimensione n
|
|
||||||
* b e' un vettore colonna di dimensione m (`n>=m`)
|
|
||||||
* A e' una matrice di **m righe e n colonne**
|
|
||||||
* x0 si dice **ammissibile** se:
|
|
||||||
|
|
||||||
```
|
|
||||||
A*x0 = b, con x0 >= 0 // il vettore x0 soddisfa i vincoli
|
|
||||||
```
|
|
||||||
|
|
||||||
### Teorema fondamentale della Programmazione lineare
|
|
||||||
|
|
||||||
* Se esiste una soluzione ammissibile, esiste una soluzione ammissibile **di base**, dove per soluzione di base si intende **una soluzione ammissibile in cui almeno** `n-m` **variabili valgono 0**
|
|
||||||
|
|
||||||
* Se esiste una soluzione **ottima**, esiste una soluzione ottima **di base**.
|
|
||||||
|
|
||||||
L'algoritmo del simplesso esplora le soluzioni di base finche' non trova quella ottima. Questo perche' si muove come se fosse sui vertici **multidimensionali** di un *politopo* (verificare), e muovendosi migliora la propria soluzione.
|
|
||||||
|
|
||||||
### Problema duale
|
|
||||||
|
|
||||||
Forma simmetrica: ogni problema di programmazione lineare ha un **duale**, ossia **un problema simmetrico all'originale (primale)**, una sorta di *antiproblema* (minimizzazione -> massimizzazione)
|
|
||||||
|
|
||||||
Il duale si puo' quindi esprimere come:
|
|
||||||
|
|
||||||
```
|
|
||||||
maximize transposed(y)*b
|
|
||||||
|
|
||||||
subject to (vincoli) transposed(y)*A <= transposed(c), y >= 0
|
|
||||||
```
|
|
||||||
Si nota come il ruolo di `b` e `transposed(c)` sia invertito nel duale.
|
|
||||||
Risolvendo il duale di un problema (trovando quindi la soluzione ottima) si risolve anche il primale, e viceversa.
|
|
||||||
Questa strategia si applica molto bene ai problemi di traffic engineering.
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
#### Proprieta' del duale
|
|
||||||
|
|
||||||
Se uno dei due problemi ha soluzione con costo **finito**, allora lo stesso vale per il duale.
|
|
||||||
Se uno dei due problemi ha soluzione con costo **infinito**, il duale non ha soluzioni ammissibili.
|
|
||||||
|
|
||||||
Inoltre:
|
|
||||||
* Se x, y sono ammissibili, allora `transposed(c)*x >= transposed(y)*b`
|
|
||||||
* Se x, y sono ammissibili, se `transposed(c)*x = transposed(y)*b`, allora x, y sono ottime.
|
|
||||||
|
|
||||||
### Slackness complementare
|
|
||||||
|
|
||||||
Se x e y sono soluzioni ammissibili, sono soluzioni ottime **se e solo se**:
|
|
||||||
|
|
||||||
1. `x[i] > 0` implica `transposed(y)*A = c[i]`
|
|
||||||
2. `transposed(y)*A < c[i]` implica `x[i] = 0`
|
|
||||||
|
|
||||||
*(vedi slides per esempio cammini minimi)*
|
|
||||||
## Funzioni del livello di rete (3)
|
|
||||||
|
|
||||||
Tre funzioni essenziali sono assegnate al livello di rete:
|
|
||||||
1. **Determinazione del cammino** dei pacchetti (protocolli di routing)
|
|
||||||
2. **Switching interno ai router**, da interfaccia di input a interfaccia di output
|
|
||||||
3. **call setup** (necessario per alcune connessioni)
|
|
||||||
|
|
||||||
### 1 - Routing
|
|
||||||
|
|
||||||
Gli algoritmi di instradamento utilizzano un'astrazione (grafo) per rappresentare la rete. Sono divisi in *link state* (centralizzato) e *distance vector* (decentralizzato).
|
|
||||||
Il problema essenziale del routing e' la ricerca del **cammino migliore per i pacchetti dati**. In genere un'operatore e' interessato a minimizzare le risorse adoperate dalla rete, limitando il piu' possibile i casi di congestione. Questo e' ottenuto utilizzando archi pesati per rappresentare i link.
|
|
||||||
|
|
||||||
**PROBLEMA: come settare i pesi relativi ai link?**
|
|
||||||
|
|
||||||
#### Contesto del problema
|
|
||||||
|
|
||||||
Si suppone:
|
|
||||||
* Conoscenza della **topologia della rete**.
|
|
||||||
* Conoscenza della **matrice di traffico** (requisiti di banda (rate) di tutti i flussi sulla rete). Nella realta' e' possibile solo stimare la matrice di traffico (vedi **load balancing** *slides precedenti*). Quindi:
|
|
||||||
```
|
|
||||||
K = insieme di flussi sorg/dest
|
|
||||||
dk = domanda di traffico del flusso
|
|
||||||
sk = sorgente del flusso
|
|
||||||
tk = destinazione del flusso
|
|
||||||
```
|
|
||||||
I criteri di ottimizzazione sono i seguenti:
|
|
||||||
* minimizzazione dell'**utilizzazione massima** di un link
|
|
||||||
* mantenimento dell'utilizzazione del link **al di sotto di una soglia prefissata** (ex. 60%). Questo assicura che nessun router vada in congestione.
|
|
||||||
|
|
||||||
**NOTA**: il problema diventa molto piu' interessante se si considera un protocollo OSPF-like in cui i link sono pesati, e il traffico puo' essere instradato **solamente sui cammini di costo minimo** (caso reale). Questo perche' l'instradamento e' comunque vincolato dal protocollo di routing installato sui nodi fisici.
|
|
||||||
|
|
||||||
#### Strategia possibile
|
|
||||||
|
|
||||||
Il problema si presenta come un'**inversione di Dijkstra** (partire da un output desiderato (cammino) e ottenere i pesi dei singoli link).
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,93 +0,0 @@
|
||||||
# Traffic Engineering
|
|
||||||
|
|
||||||
Problema: minimizzare l'utilizzazione massima dei link.
|
|
||||||
```
|
|
||||||
topologia G = (V,E)
|
|
||||||
c[i,j] capacita' del link i,j appartenente a E
|
|
||||||
K insieme dei flussi sorg / dest
|
|
||||||
alpha massima utilizzazione dei link
|
|
||||||
```
|
|
||||||
La comunicazione tra link avviene tramite OSPF. Risolvendo questo problema, riusciamo a invertire Dijkstra e ottenere nel problema duale i **pesi** dei link che OSPF puo' utilizzare per instradare i pacchetti.
|
|
||||||
*(vedi slides per formulazione standard)*
|
|
||||||
|
|
||||||
## Risoluzione PL
|
|
||||||
|
|
||||||
Utilizzando un risolutore di PL (programmi lineari) si trova una soluzione ottimale che pero' non restituisce i pesi che OSPF richiede. Questi pesi sono **variabili duali** del problema. Inoltre, la formulazione standard tende a dare risultati troppo *spalmati* (manda pacchetti a link remoti in maniera eccessiva).
|
|
||||||
|
|
||||||
Per questi motivi, si decide di minimizzare l'utilizzo totale della rete utilizzando un **parametro di controllo** `r`, prefissato ma modificabile per ottimizzare la dispersione dei pacchetti.
|
|
||||||
|
|
||||||
### Trasformazione a Duale (forma Asimmetrica)
|
|
||||||
|
|
||||||
Utilizzando tecniche standard di programmazione lineare, otteniamo un duale che per definizione **contiene tante variabili duali quanti sono i vincoli del problema originale**. Essendo che alcuni dei vincoli (quelli nella forma `c[i,j]*alpha - sum...` sono relativi ai singoli link, da essi ottengo:
|
|
||||||
```
|
|
||||||
w[i,j] >= 0
|
|
||||||
```
|
|
||||||
Ossia una variabile duale relativa al singolo link che posso considerare un peso.
|
|
||||||
|
|
||||||
*(vedi slides per formulazione duale)*
|
|
||||||
|
|
||||||
Io posso creare un vettore contenente tutte le variabili di decisione:
|
|
||||||
```
|
|
||||||
| k = 1 | k = 2 | ...
|
|
||||||
alpha | {x1[i,j]} | {x2[i,j]} | ...
|
|
||||||
```
|
|
||||||
Dove ogni colonna corrisponde a un flusso sorg/dest.
|
|
||||||
|
|
||||||
* Posso notare inoltre che **tutte le variabili con criteri di uguaglianza nel primale diventano variabili libere nel duale**.
|
|
||||||
|
|
||||||
### Formulazione duale e Interpretazione
|
|
||||||
|
|
||||||
Ottengo due insiemi di variabili di decisione `{Uk[i]}`, `{W[i,j]}` in cui il problema si formula come: *(vedi slides)*
|
|
||||||
Per interpretare la soluzione utilizziamo la **slackness complementare**, proprieta' dei problemi di programmazione lineare. *(vedi slides)*
|
|
||||||
|
|
||||||
Il risultato e' che:
|
|
||||||
```
|
|
||||||
W[i,j] = r + w[i,j]
|
|
||||||
```
|
|
||||||
Sommando `r` alle variabili duali `w` ottengo `W`, i pesi dei link del protocollo OSPF.
|
|
||||||
|
|
||||||
## Nota sulla soluzione lineare di problemi
|
|
||||||
|
|
||||||
Molte delle volte il duale dei problemi (scrivibili nella forma di programmazione lineare) e' utile da analizzare per scoprire dettagli aggiuntivi / utili nella risoluzione del problema.
|
|
||||||
|
|
||||||
### Sguardo applicativo: estensioni / practical problems
|
|
||||||
|
|
||||||
* Il metodo descritto funziona per un vasto insieme di funzioni di costo, che portano a formulazioni in PL simili l'una all'altra. Un esempio puo' essere l'utilizzo di funzioni di costo **approssimate** (i.e. lineari a tratti) per semplificare la computazione.
|
|
||||||
|
|
||||||
#### Problemi
|
|
||||||
|
|
||||||
1. Le soluzioni sono specifiche **per i flussi**, metre **IP instrada solo in base alla destinazione**. Si puo' pero' riformulare il problema per tener conto di quel vincolo.
|
|
||||||
|
|
||||||
2. Le soluzioni potrebbero non essere compatibili con le ripartizioni eque sui cammini minimi equivalenti operata da OSPF *(link uguale peso, uguale carico)*. Tener conto di questo vincolo porta a un problema NP-hard. Questa limitazione di OSPF non e' mai stata cambiata, e questo limita molto l'utilizzo dell'approccio PL. Soluzione puo' essere **modificare routing IP**, utilizzando (ad esempio) **MPLS**, che porta su internet il concetto tipico di ATM del circuito virtuale. *(Non particolarmente utilizzato, vedi slides per approfondimento)*
|
|
||||||
|
|
||||||
##### Nota: OSPF, ripartizioni di carico su cammini equivalenti
|
|
||||||
|
|
||||||
Per evitare di randomizzare la trasmissione di uno stesso flusso su due link (che metterebbe a dura prova TCP) si puo' utilizzare la quadrupla (IP sorg/dest, PORT sorg/dest), convertirla con una funzione di hash a un valore univoco e indirizzare tutto il traffico di uno stesso hash allo stesso link. Non ottimale, ma meglio che dover gestire TCP che lamenta pacchetti persi.
|
|
||||||
|
|
||||||
## OSPF (open shortest path first)
|
|
||||||
|
|
||||||
Protocollo link state che permette costi dei link compresi tra 0 e 65535.
|
|
||||||
* Utilizza Dijstra, facendo quindi broadcast della topologia
|
|
||||||
* Permette i percorsi multipli di pari costo MA traffico diviso equamente
|
|
||||||
* Molto scalabile
|
|
||||||
* Cisco raccomanda di utilizzare `costo link = 1/(capacita' link)`
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
# TCP e controllo di congestione
|
|
||||||
|
|
||||||
Studio della strategia di TCP per effettuare controllo di congestione, tramite modelli analitici.
|
|
||||||
|
|
||||||
## Studio delle prestazioni di TCP
|
|
||||||
|
|
||||||
Per studiare le caratteristiche delle connessioni TCP e' possibile effettuare delle **simulazioni**. Queste hanno il vantaggio di implementare piuttosto fedelmente il comportamento di TCP, ma sono costosi in termini di tempo / lavoro e scalano male.
|
|
||||||
|
|
||||||
Alternative: **modelli**
|
|
||||||
|
|
||||||
* **modelli deterministici approssimati**, semplici, veloci ma assumono *steady-state* in TCP (non precise). Universalmente scalabili.
|
|
||||||
* **modelli fluidi / stocastici**, che modellano anche il comportamento transitorio di TCP ma rimangono comunque approssimazioni.
|
|
||||||
|
|
||||||
## TCP congestion control
|
|
||||||
|
|
||||||
TCP opera alla cieca sulla rete, perche' e' presente solo negli endpoint e non nei nodi. Per effettuare controlli di congestione, TCP manda prima la rete in congestione, poi si regola di conseguenza una volta determinata la potenza della rete.
|
|
||||||
*(vedi slides per ripasso congestion control)*
|
|
||||||
|
|
@ -1,199 +0,0 @@
|
||||||
# TCP - relazione throughput / probabilita' di perdita
|
|
||||||
|
|
||||||
*(continua)*
|
|
||||||
Il modello idealizzato vede l'evoluzione di TCP come crescita lineare, dimezzamento, e cosi' via *(vedi slides)*. L'obbiettivo dell'analisi e' trovare il throughput in funzione di probabilita' di perdita e RTT.
|
|
||||||
|
|
||||||
Vogliamo sommare i pacchetti tra w/2 e w, per ottenere un modello approssimato che descriva i pacchetti persi.
|
|
||||||
|
|
||||||
#### Sommatoria particolare tra w/2 e w
|
|
||||||
|
|
||||||
```
|
|
||||||
sum of i ,i ranging from a to b = (a+b) * (b - a + 1) / 2
|
|
||||||
```
|
|
||||||
Questa sommatoria puo' essere utilizzata nel caso in cui:
|
|
||||||
```
|
|
||||||
a = w/2
|
|
||||||
b = w
|
|
||||||
```
|
|
||||||
Facendo si' che la sommatoria di i con i compreso tra w/2, w sia `= (3/2*w)*(w/2 + 1)/2` *(vedi slides)*
|
|
||||||
|
|
||||||
Nota: essendo che w e' supposto essere molto grande, il termine in `w^2` e' molto maggiore del termine in `w`, quindi possiamo considerare **solo il termine quadratico**.
|
|
||||||
|
|
||||||
*(vedi slides per risultato approssimato)*
|
|
||||||
|
|
||||||
A questo punto, dobbiamo considerare anche la **probabilita di perdita**:
|
|
||||||
|
|
||||||
```
|
|
||||||
ploss = 8 / (3*w^2) ovvero w = sqrt(8/(3*ploss))
|
|
||||||
```
|
|
||||||
Che quindi significa che **il throughput e' inversamente proporzionale a RTT e ploss**. Questo risultato e' comunque ottenuto ignorando slow start, timeouts, dimensione max della finestra.
|
|
||||||
Per tener conto anche di timeouts e finestra massima, possiamo usare un modello dettagliato *(pubblicato da kurose)* che ha il nome di **PFTK** (dal nome degli autori). *(vedi slides per formula e descrizione)*.
|
|
||||||
Questo e' il modello piu' utilizzato per il throughput di TCP.
|
|
||||||
|
|
||||||
## Modello PFTK
|
|
||||||
|
|
||||||
E' un'analisi di ciclo (come l'esempio simplificato precedente) che pero' comprende anche i timeouts (eventualmente consecutivi). Quindi:
|
|
||||||
|
|
||||||
```
|
|
||||||
throughput = #pacchetti mandati in un ciclo / durata ciclo
|
|
||||||
```
|
|
||||||
Si considera una probabilita' di perdita indipendente da RTT a RTT. Questo modello e' stato verificato sperimentalmente *(vedi slides)* utilizzando strumenti come *tcpdump* per misurare timeout e pacchetti ricevuti.
|
|
||||||
|
|
||||||
Utilizzando questo modello, costruendo un grafico in scala **logaritmica** (asse x = loss frequency (probabilita' di perdita), asse y = #packets sent (pacchetti inviati)) si e' visto che il legame tra i due dataset e' una retta (in scala logaritmica).
|
|
||||||
|
|
||||||
## Analisi ad anello aperto e ad anello chiuso
|
|
||||||
|
|
||||||
Le precedenti analisi si riferiscono a **singole connessioni TCP che hanno nota probabilita' di perdita e RTT**. Questa e' definita **analisi ad anello aperto**.
|
|
||||||
|
|
||||||
Interessante e' studiare l'**analisi ad anello chiuso**, che si riferisce all'** interazione di tanti flussi TCP in rete**.
|
|
||||||
|
|
||||||
### Analisi ad anello chiuso
|
|
||||||
|
|
||||||
*(vedi slides per ripasso di gestione della coda RED)*
|
|
||||||
|
|
||||||
In una coda RED:
|
|
||||||
* la probabilita' di perdita dei pacchetti dipende dalla lunghezza media della coda
|
|
||||||
|
|
||||||
Supponiamo che nella rete ci sia **un singolo link congestionato (quindi con pacchetti in coda).**
|
|
||||||
Supponiamo inoltre che i flussi siano lunghi (difficili da trasmettere), e che ogni flusso TCP che attraversa il link subisca la stessa probabilita' di perdita. La domanda e':
|
|
||||||
* **i flussi avranno lo stesso throughput?**
|
|
||||||
|
|
||||||
La risposta e' **NO** perche' avranno RTT diverso, e come si e' visto dai grafici dei modelli, RTT piu' lunghi sono penalizzati (subiscono piu' perdite).
|
|
||||||
|
|
||||||
La soluzione di equilibrio si trova con un metodo detto **punto fisso**, con cui si ottiene:
|
|
||||||
|
|
||||||
```
|
|
||||||
sum for i of (B[i] * (p,RTT[i])) = C
|
|
||||||
```
|
|
||||||
*(vedi slides)*.
|
|
||||||
|
|
||||||
#### Singolo collo di bottiglia: flussi infiniti
|
|
||||||
|
|
||||||
Si considerino N flussi TCP con infiniti pacchetti da trasmettere. Il modello *(vedi slides)* puo' essere descritto:
|
|
||||||
|
|
||||||
```
|
|
||||||
p = p(x) // p funzione nota
|
|
||||||
RTT[i] = A[i] + x/C // A[i] e' la componente costante di propagazione per il flusso i, mentre x/C e' la velocita' // con cui il link scarica una coda di lunghezza x. (C e' la velocita')
|
|
||||||
|
|
||||||
sum for i of (B[i] * (p,RTT[i])) = C[i]
|
|
||||||
```
|
|
||||||
La soluzione al punto fisso e' trovata per x, dove x e' usata nel calcolo di RTT e p. La soluzione **esiste ed e' unica**, perche' B e' **monotona e continua rispetto a x.**
|
|
||||||
|
|
||||||
*(vedi slides per grafici di rapporto throughput stimato / misurato e probabilita' di perdita stimata / misurata)*
|
|
||||||
Dai grafici si nota che la probabilita' di perdita e' molto precisa se il modello e' PFTK, mentre la piu' semplice square root formula predice una perdita molto piu' alta (non considerando i timeout).
|
|
||||||
|
|
||||||
## Nuove versioni di TCP
|
|
||||||
|
|
||||||
Attorno agli anni '90 si e' cominciato a modellare TCP e a costruire varianti per cui il grafico throughput / probabilita' di perdita da risultati migliori. Per ottenere questo risultato, si e' mescolato un collo di bottiglia con TCPnuovo e TCPstandard. Da questi esperimenti, molte delle *nuove* versioni di TCP hanno un throughput migliore.
|
|
||||||
|
|
||||||
Questo metodo pero' e' privo di senso, *(vedi slides per esperimento descritto matematicamente)*
|
|
||||||
|
|
||||||
Infatti, supponendo due scenari: il primo in cui tutti usano la TCPnuova e il secondo in cui tutti usano la TCP standard. Essendo che entrambe le versioni sono limitate dalla stessa velocita' del link, notiamo che la nuova versione, piu' *aggressiva*, tende a generare una probabilita' di perdita piu' **alta** rispetto alla TCP standard. Questo risultato si vede facilmente fissando C (banda) sul grafico del throughput / probabilita' di perdita.
|
|
||||||
|
|
||||||
## Utilizzo di Forward Error Correction (FEC)
|
|
||||||
|
|
||||||
Se il packet loss e' alto, il throughput e' basso di conseguenza, ma si potrebbe utilizzare la FEC a livello di pacchetto per risolvere le perdite *in avanti*, e quindi ottenere un throughput migliore.
|
|
||||||
|
|
||||||
*(vedi slides per meccanismo FEC)*
|
|
||||||
|
|
||||||
Questo meccanismo permette di utilizzare una nuova probabilita' di perdita, Pfec, che dovrebbe essere migliore della p originale.
|
|
||||||
|
|
||||||
**NON e' VERO**, perche' sebbene Pfec sembri molto piu' bassa di p, non si considera nuovamente il problema della banda:
|
|
||||||
|
|
||||||
* Avendo nuovamente banda C, utilizzando la FEC **si riduce la banda disponibile**, perche' mandare pacchetti ridondanti (e quindi scartati) e' equivalente a ridurre la banda.
|
|
||||||
|
|
||||||
Questo problema ha il seguente impatto sulle prestazioni:
|
|
||||||
|
|
||||||
```
|
|
||||||
Bfec() = Bwo() = Btcp() // un unico TCP standard, nessuna versione alternativa. Bwo e' il throughput without fec
|
|
||||||
|
|
||||||
N*Bwo(p) = Cwo
|
|
||||||
|
|
||||||
N*Bfec(Pfec) = Cfec
|
|
||||||
|
|
||||||
Come risultato: Pfec > p
|
|
||||||
```
|
|
||||||
Questo vuol dire che **utilizzare FEC riduce le prestazioni**, perche' aumenta la probabilita' di perdita (dato che Cwo e' maggiore di Cfec). Nonostante sembrerebbe logico che la probabilita' di perdita diminuisca con FEC, in realta' aumenta a causa della riduzione di banda.
|
|
||||||
|
|
||||||
### Conclusioni
|
|
||||||
|
|
||||||
Alterare (incrementare) l'aggressivita' di TCP non e' utile al throughput finale.
|
|
||||||
|
|
||||||
FEC non e' utile per migliorare il throughput (sebbene abbia senso nel caso in cui un singolo nodo mandi a un link abbia grosse perdite, in quel caso senza FEC il throughput sarebbe **piu' basso della banda disponibile**). Ma nel caso di nodi multipli, FEC e' controproducente.
|
|
||||||
|
|
||||||
## Colli di bottiglia multipli: flussi infiniti
|
|
||||||
|
|
||||||
Analizzando il caso in cui ci sia **piu' di un router congestionato** con coda RED, posso modellare il comportamento di ognuno dei colli di bottiglia. *(vedi slides)*
|
|
||||||
|
|
||||||
Ottengo infatti un sistema di V equazioni e V incognite, dove V e' il numero di router congestionati. Considero inoltre N flussi TCP.
|
|
||||||
|
|
||||||
* Domanda: probabilita' di perdita di un pacchetto che attraversa due link con probabilita' di perdita differenti.
|
|
||||||
|
|
||||||
Ovvero: con quale probabilita' attraverso con successo entrambi i link? *(probabilita' complementare, o *`1-p`*)*.
|
|
||||||
Il risultato e':
|
|
||||||
|
|
||||||
```
|
|
||||||
s = 1-p
|
|
||||||
stot = s1 * s2
|
|
||||||
|
|
||||||
Il che significa:
|
|
||||||
1 - ptot = (1-p1) * (1-p2)
|
|
||||||
|
|
||||||
ptot = 1 - (1-p1)*(1-p2) = p1 + p2 - p2*p1 (probabilita' condizionata)
|
|
||||||
```
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
## Note finali
|
|
||||||
|
|
||||||
* Nella pratica, non tutto e' TCP, ma una notevole parte dei pacchetti e' UDP. UDP **non e'responsive**, quindi si considera semplicemente di sottrarre il loro rate dalla capacita' del collo di bottiglia (in realta', bisogna supporre che il loro sending rate sia esattamente quello che fanno). Nota: oggigiorno quasi tutti i servizi con gran numero di dati, per connessioni persistenti, utilizzano TCP (anche per real time / streaming).
|
|
||||||
|
|
||||||
* Nessun flusso e' veramente infinito.
|
|
||||||
|
|
||||||
* Se si considerano flussi **finiti** di TCP, l'analisi e' piu' complessa perche' divido l'analisi in flussi **pesanti** (lunghi) e flussi **leggeri** (brevi, minore trasmissione dati). Sebbene la square root formula non sia adatta a modellare flussi brevi, ci sono modelli di flussi brevi abbastanza complessi ma accurati. In generale pero' occupano una parte minore del traffico, e sono quindi visti come rumore.
|
|
||||||
|
|
||||||
* Nel calcolo del throughput, si e' ipotizzato che il tempo di trasmissione di una finestra e' **minore di RTT**, ma questo non e' vero per flussi locali, dove gli RTT sono estremamamente piccoli.
|
|
||||||
|
|
||||||
# Analisi in transitorio (dinamica) di flussi TCP
|
|
||||||
|
|
||||||
Si modella il traffico TCP come un fluido, il cui comportamento e' descritto da delle **Ordinary differential equations** (ODE), che si risolvono **numericamente** (utilizzando un risolutore che estrapoli l'andamento nel tempo).
|
|
||||||
|
|
||||||
## Ipotesi
|
|
||||||
|
|
||||||
La rete e' astratta, in una *black box*, con trasmettitori e ricevitori. Introduce:
|
|
||||||
* RTT
|
|
||||||
* perdite distribuite come Poisson(lambda = rate)
|
|
||||||
|
|
||||||
lambda e' quindi un **rate di perdite / secondo**. Dalla rete riceviamo un flusso di eventi di perdita.
|
|
||||||
|
|
||||||
Supponiamo:
|
|
||||||
```
|
|
||||||
W = dimensione media della finestra
|
|
||||||
|
|
||||||
d(W)/dt = 1/RTT - (W/2)*lambda
|
|
||||||
|
|
||||||
notiamo che per t -> infinito
|
|
||||||
|
|
||||||
W = 2/(lambda*RTT)
|
|
||||||
```
|
|
||||||
Si nota che:
|
|
||||||
|
|
||||||
* `1/RTT` e' l'**additive increase**
|
|
||||||
* `(W/2)*lambda` e' il **multiplicative decrease**
|
|
||||||
|
|
||||||
Questo permette di definire il **throughput** come `tput = W/RTT` ottenendo una misurazione estremamente precisa.
|
|
||||||
|
|
||||||
## Modello a sistema di controllo a tempo continuo
|
|
||||||
|
|
||||||
Immaginare un *rubinetto* (sorgente) che genera un flusso fluido (continuo, in funzione di t), che attraversa un collo di bottiglia e poi viene mandato a un ricevitore, che risponde con un ACK alla sorgente **con un feedback delay Tau, pari a 3/4 RTT (circa).** *(vedi slides)*
|
|
||||||
|
|
||||||
Questo sistema e' pilotato da equazioni di variazione nel tempo:
|
|
||||||
|
|
||||||
```
|
|
||||||
rate di ricezione di ACKs = lambdaACK(t) = B(t-Tau) * (1-p(t-Tau))
|
|
||||||
|
|
||||||
rate di ricezione di segnali di congestione = lambdaLoss(t) = B(t-Tau) * (p(t-Tau))
|
|
||||||
```
|
|
||||||
Ovvero il rate di ricezione di acks e' il throughput al tempo t-(feedback delay), moltiplicato per il complementare della probabilita' di perdita al tempo t-(feedback delay).
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,197 +0,0 @@
|
||||||
# Sistema di controllo in tempo continuo - TCP (continua)
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
Modellando un sistema in cui un mittente che invia un pacchetto tramite router AQM con probabilita' di perdita `p(t)`, si puo' analizzare lo scenario **singolo collo di bottiglia**, in cui supponiamo:
|
|
||||||
|
|
||||||
* singolo link congestionato di capacita' C
|
|
||||||
* N flussi TCP infiniti che attraversano il link (seguendo un path punto-punto)
|
|
||||||
|
|
||||||
*(slides per formule RTT e throughput B)*
|
|
||||||
|
|
||||||
## Router RED
|
|
||||||
|
|
||||||
Se il router congestinato e' gestito con RED, possiamo collegare la probabilita' di perdita con la lunghezza della coda. RED infatti scarta i pacchetti in arrivo in base alla lunghezza attuale della coda, calcolata con **media mobile esponenziale**.
|
|
||||||
|
|
||||||
**Ignorando timeouts e slow start**:
|
|
||||||
Possiamo quindi scrivere un'**ODE** che descriva la dimensione della finestra del router congestionato, di modo da ottenere un sistema di ODE che descriva la **lunghezza istantanea della coda**. *(slides per formule)*
|
|
||||||
|
|
||||||
Due ODE: una per la window size, una per la lughezza della coda.
|
|
||||||
|
|
||||||
### Window size
|
|
||||||
|
|
||||||
Le equazioni sono costruite sommando le componenti di *additive increase* e *multiplicative decrease*. Abbiamo due *rate*: uno che descrive la ricezione di ACKs (e quindi pacchetti non persi) che implicano additive increase, mentre il secondo rate e' dipendente da `p(t)` e indica i pacchetti persi (multiplicative decrease).
|
|
||||||
|
|
||||||
Ignorando i feedback delay, possiamo semplificare ulteriormente la ODE. *(vedi slides)*
|
|
||||||
|
|
||||||
### Lunghezza istantanea della coda
|
|
||||||
|
|
||||||
Come per la window size, anche la lughezza della coda e' pilotata da due componenti: **traffico in ingresso** e **traffico in uscita**. Il traffico in ingresso e' ottenuto **aggregando i flussi che mandano pacchetti su una stessa coda**.
|
|
||||||
|
|
||||||
|
|
||||||
## Risoluzione Equilibrio (comportamento a regime)
|
|
||||||
|
|
||||||
Il sistema di ODE e' pensato per studiare l'evoluzione nel tempo, ma e' molto utile studiare la soluzione di equilibrio (derivata == 0). Cosi' facendo, ci riconduciamo alla **sqare root formula.**
|
|
||||||
|
|
||||||
## Risoluzione transitorio
|
|
||||||
|
|
||||||
Non calcolata a mano ma con un risolutore, di seguito la descrizione del sistema ottenuto.
|
|
||||||
|
|
||||||
### Evoluzione della media mobile esponenziale
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
### Evoluzione della probabilita di perdita
|
|
||||||
|
|
||||||
*(vedi slides)* Si utilizza la **chain rule**, dove `dp/dx` e' il profilo di RED.
|
|
||||||
|
|
||||||
### Equazioni accoppiate
|
|
||||||
|
|
||||||
Ottenute tutte le equazioni di interesse, si ottengono N+2 equazioni accoppiate, che possono essere messe a sistema, per ottenere la lughezza istantanea e mediata della coda, da cui posso ottenere la probabilita' di perdita.
|
|
||||||
|
|
||||||
## Multipli colli di bottiglia
|
|
||||||
|
|
||||||
E' possibile studiare una rete fatta da multipli colli di bottiglia, creando sistemi di equazioni che descrivano i singoli router. Si puo' quindi calcolare la **probabilita di perdita totale** su un percorso e il **RTT totale**.
|
|
||||||
*(vedi slides per formule)*
|
|
||||||
|
|
||||||
## Accuratezza del modello
|
|
||||||
|
|
||||||
L'accuratezza del modello proposto e' studiata supponendo:
|
|
||||||
|
|
||||||
* Una serie di link non congestionati di capacita' elevata
|
|
||||||
* Un link congestionato con capacita' ridotta, alimentato dai link
|
|
||||||
* Simulando flussi tcp, dopo un certo tempo (30 sec) si introduce un guasto della rete in cui i flussi dimezzano. Questo permette di **studiare il transitorio dell'oggetto (router RED) a seconda delle variazioni di carico**.
|
|
||||||
* Plottando il modello fluido calcolato e il modello simulato, si nota un **accordo evidente tra i risultati misurati e quelli calcolati**.
|
|
||||||
|
|
||||||
Il risultato e':
|
|
||||||
|
|
||||||
* Il modello cattura la dimensione della finestra **media** con un accuratezza molto elevata, supponendo una popolazione **omogenea** di flussi.
|
|
||||||
|
|
||||||
## Proprieta' di scalamento del modello
|
|
||||||
*(nota: OC-12 rappresenta una banda fisica, OC-48 = OC-12 x 4*
|
|
||||||
|
|
||||||
Immaginando di moltiplicare la quantita' di flussi e le capacita' per una costante `j`, possiamo simulare una situazione di **scalamento**, la finestra media dei flussi rimane invariata:
|
|
||||||
|
|
||||||
```
|
|
||||||
Wk(t) = Wj,k(t) W = window size
|
|
||||||
|
|
||||||
Qv(t) = Qj,v(t)/j q = lunghezza coda
|
|
||||||
```
|
|
||||||
|
|
||||||
Questo permette di **garantire lo stesso throughput** sotto ipotesi di scalabilita', il che e' molto utile nel caso di sistemi troppo grandi da essere simulati. Posso quindi **simulare un sistema scalato verso il basso**, perche' so che scalando mantengo il throughput.
|
|
||||||
|
|
||||||
*Nota: se il router e' RED, e' necessario scalare anche il profilo RED.*
|
|
||||||
|
|
||||||
## Altre applicazioni
|
|
||||||
|
|
||||||
* Il modello e' estendibile al caso di **code drop tail**.
|
|
||||||
* Il modello e' utile prettamente per studiare la stabilita' e la taratura di RED.
|
|
||||||
* Il modello e' usato anche per studiare il fenomeno della congestione dal punto di vista controllistico.
|
|
||||||
|
|
||||||
### Semplificazione del sistema di ODE
|
|
||||||
|
|
||||||
Utile in futuro.
|
|
||||||
|
|
||||||
```
|
|
||||||
dW/dt = W/R (1/W - p*W/2)
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# TCP CUBIC
|
|
||||||
|
|
||||||
Implementazione di default in Linux.
|
|
||||||
|
|
||||||
* E' caratterizzato da un **fattore di decrease multiplicativo** `beta`, che ad ogni perdita diminuisce la dimensione della finestra di `beta*W`.
|
|
||||||
|
|
||||||
* In assenza di perdite, TCP CUBIC utilizza un polinomio di terzo grado per **predire l'evoluzione della finestra**:
|
|
||||||
|
|
||||||
```
|
|
||||||
W = C(t - K)^3 + Wmax
|
|
||||||
|
|
||||||
Dove:
|
|
||||||
|
|
||||||
t = tempo misurato dall'ultima perdita
|
|
||||||
K = cubicroot(Wmax*beta/C)
|
|
||||||
C = parametro limitato dalla curva cubica, dove consideriamo un decrease di beta*W ottenendo:
|
|
||||||
|
|
||||||
Wmax*(1-beta) = -C*K^3 + Wmax
|
|
||||||
=> beta*Wmax = C*K^3
|
|
||||||
|
|
||||||
Da cui si puo' ottenere C e K
|
|
||||||
|
|
||||||
L'unico parametro libero e' dato da dopo quanto tempo il valore della finestra torna a quello iniziale.
|
|
||||||
```
|
|
||||||
*(slides per plot)*
|
|
||||||
|
|
||||||
L'implementazione di TCP CUBIC e' migliore del modello *classico* a dente di sega perche', mentre nel modello classico il tempo di ritorno al valore precedente e' dipendente da W e RTT, in TCP CUBIC e' un parametro libero.
|
|
||||||
|
|
||||||
# Problematiche di TCP standard: scenario ad alte prestazioni
|
|
||||||
|
|
||||||
Considerando una singola connessione TCP standard con un throughput atteso altissimo (x Gbps), *(vedi slides)* scopriamo che TCP standard richiede una finestra media di congestione di 83333 segmenti.
|
|
||||||
|
|
||||||
Dato che la durata del dente di sega dipende dalla finestra media, otteniamo (applicando la square root formula) che la durata del dente di sega e' ~ di 1 ora e 40 minuti, a cui poi segue una nuova perdita (e quindi il ciclo ricomincia).
|
|
||||||
|
|
||||||
La quantita richiesta di tempo e' **troppa** per uno scenario ad alte prestazioni, perche' una grande quantita' di tempo e' passata con una window size sottodimensionata.
|
|
||||||
|
|
||||||
Il tempo T tra due segnali di congestione e' infatti proporzionale al throughput e RTT:
|
|
||||||
|
|
||||||
```
|
|
||||||
T = B*R^2 / c^2
|
|
||||||
```
|
|
||||||
Quindi: **throughput alto, tempo maggiore per la crescita della finestra**, rallentando le dinamiche di TCP.
|
|
||||||
|
|
||||||
**TCP non scala in scenari di altissimo throughput**.
|
|
||||||
|
|
||||||
*(vedi slides per calcoli, quella scritta a mano definita back-of-the-envelope computations*)
|
|
||||||
|
|
||||||
## Soluzione al problema
|
|
||||||
|
|
||||||
C'e' un ampio spettro di soluzioni:
|
|
||||||
|
|
||||||
* Apertura di **N connessioni TCP in parallelo**, ma richiede un middleware di divisione / riassemblaggio dei dati complicatissimo
|
|
||||||
* Uso di **MulTCP**, una singola connessione che ottiene un comportamento simile a multiple connessioni TCP virtuali. Questo implica una decrescita di `b*W`, con `b < 1/2`. L'idea e' di **rendere TCP piu' aggressivo**, limitando la decrescita del dente di sega.
|
|
||||||
|
|
||||||
Per migliorare la decrescita, si puo' calcolare la W partendo dalla ODE semplificata vista in precedenza. *(vedi slides)*
|
|
||||||
|
|
||||||
Altre soluzioni:
|
|
||||||
|
|
||||||
### Soluzioni a basso costo implementativo (cambiamenti marginali)
|
|
||||||
|
|
||||||
#### Highspeed TCP (TCP con parametri modificati)
|
|
||||||
|
|
||||||
Utilizza un additive increase, multiplicative decrease ma **gli incrementi e i decrementi dipendono dalla window size**. I cambiamenti sono segnati come parametri di una tabella, inclusa nell'implementazione di TCP.
|
|
||||||
|
|
||||||
Plottando il sending rate sul loss rate, vediamo che Highspeed TCP utilizza una pendenza modificata (0.15/p^0.82) rispetto alla pendenza di standard TCP ( 1.22/p^0.5)
|
|
||||||
|
|
||||||
Scalable TCP *(slides)* e CUBIC TCP utilizzano una pendenza ancora migliore *(vedi plot)*.
|
|
||||||
|
|
||||||
#### Scalable TCP (TCP con multiplicative increase)
|
|
||||||
|
|
||||||
L'utilizzo di multiplicative increase, multiplicative decrease:
|
|
||||||
```
|
|
||||||
W = W+a // per ogni ACK -> crescita geometrica se si considerano i RTT
|
|
||||||
W = W-b*W // per finestra di cui si rileva la perdita
|
|
||||||
```
|
|
||||||
Si nota che questo multiplicative increase, il tempo tra due segnali di perdita (aka durata del dente di sega) **non dipende piu' dal throughput**:
|
|
||||||
|
|
||||||
```
|
|
||||||
B = a/(R*b*p) => T = (b*R) / a
|
|
||||||
|
|
||||||
Questo risultato e' ottenuto a partire dall'ODE semplificata, ponendo la soluzione di equilibrio (quindi con la derivata nulla).
|
|
||||||
```
|
|
||||||
*(vedi slides per grafici di prestazioni di STCP)*
|
|
||||||
|
|
||||||
Scalable TCP e' stato creato nei primi 2000 ma non ha avuto una grossa considerazione. In compenso, **TCP CUBIC** ha utilizzato il suo stesso concetto di scalabilita'.
|
|
||||||
|
|
||||||
### TCP CUBIC: scalabilita'
|
|
||||||
|
|
||||||
Utilizzando una curva cubica, TCP CUBIC e' in grado di migliorare Scalable TCP (che invece sale esponenzialmente al punto di congestione), mantenendo comunque un **throughput proporzionale a** `1/p`.
|
|
||||||
|
|
||||||
Il miglioramento di Scalable TCP e' dovuto proprio alla stabilita' di una curva cubica (migliore fairness, migliore scalabilita') rispetto a una curva esponenziale, che si rivela molto piu' aggressiva.
|
|
||||||
|
|
||||||
### Altre soluzioni
|
|
||||||
|
|
||||||
* Protocolli di congestione **delay-based**, studiando il RTT posso regolare la finestra (TCP FAST, TCP VEGAS).
|
|
||||||
* Controllo di congestione supportato dai router: **XCP**.
|
|
||||||
|
|
@ -1,100 +0,0 @@
|
||||||
# Congestione come problema di allocazione
|
|
||||||
|
|
||||||
Lo studio del congestion avoidance come problema di ottimizzazione di allocazione di risorse. **E' un problema definito in programmazione non lineare**.
|
|
||||||
Studio di:
|
|
||||||
* Come allocare risorse (divisione di banda) di modo da ottimizzare una certa funzione / obbiettivo
|
|
||||||
La soluzione potrebbe essere non ottimale, ma la formulazione in termini di ottimizzazione puo' guidare la rete e gli utenti verso un punto di funzionamento **desiderabile**.
|
|
||||||
|
|
||||||
Le soluzioni si presentano come **algoritmi distribuiti, decentralizzati, asincroni.**
|
|
||||||
|
|
||||||
## Il modello
|
|
||||||
|
|
||||||
La rete e' vista come un insieme di link {l}, di capacita' {c[l]}.
|
|
||||||
|
|
||||||
Supponiamo che le sorgenti abbiano un routing statico (che quindi e' noto come insieme di link utilizzati). Chiamiamo `xs` il **rate** associato con la sorgente `S`.
|
|
||||||
|
|
||||||
*(slides per esempio semplice e definizioni)*
|
|
||||||
|
|
||||||
Con queste ipotesi, il problema dell'**assegnare la banda ai flussi noti**, che presenta infinite soluzioni.
|
|
||||||
|
|
||||||
### Funzioni di utilita'
|
|
||||||
|
|
||||||
Utilizziamo delle **funzioni di utilita'**: `U[s](xs)` che rappresentano il *gradimento* della sorgente al rate `xs`. Le funzioni di utilita' sono supposte **concave del tasso di sorgente** `xs`.
|
|
||||||
|
|
||||||
*Nota: concava = prendendo due punti sulla funzione, la funzione e' sempre maggiore del segmento che unisce quei due punti*.
|
|
||||||
La concavita' rappresenta il fenomeno dei **diminishing returns**. Vuol dire che in corrispondenza di un certo aumento (di banda in questo caso) i corrispondenti elementi di gradimento diventano sempre minori, quindi hanno meno impatto sul gradimento (U(x)). Questo vuol anche dire che per avere lo stesso effetto di gradimento, a rate maggiore bisogna associare incrementi maggiori.
|
|
||||||
|
|
||||||
### Massimizzare l'utilita'
|
|
||||||
|
|
||||||
Il problema si presenta quindi come **la ricerca dell'allocazione di banda che massimizza l'utilita' tra tutti i flussi dati**.
|
|
||||||
|
|
||||||
## Formulazione come problema classico (Kelly, anni '90)
|
|
||||||
|
|
||||||
```
|
|
||||||
il max su (x0,x1,x2) della sommatoria per i da (1,3) di U[i](xi)
|
|
||||||
|
|
||||||
Con vincoli:
|
|
||||||
|
|
||||||
x0 + x1 <= cA
|
|
||||||
x0 + x2 <= cB
|
|
||||||
xi >= 0
|
|
||||||
```
|
|
||||||
Si nota come i vincoli abbiano forma lineare, ma il problema e' la sommatoria di funzioni non lineari => **non lineare**.
|
|
||||||
|
|
||||||
### Programmazione non lineare
|
|
||||||
|
|
||||||
Si presentano i principi della programmazione non lineare.
|
|
||||||
|
|
||||||
#### Ottimizzazione Convessa
|
|
||||||
|
|
||||||
Esiste una classe di problemi di programmazione non lineare che possono essere risolti con relativamente poca fatica. Sono i problemi che riguardano l'ottimizzazione convessa. Nel nostro caso, la somma di funzioni concave e' una concava, e i vincoli definiscono un insieme convesso.
|
|
||||||
|
|
||||||
* All'interno di questo insieme, risulta facile trovare il punto di **massimo** di una funzione **strettamente concava**. Se la funzione e' **strettamente convessa**, risulta invece facile trovare il **minimo**.
|
|
||||||
|
|
||||||
##### Trovare il massimo di una funzione concava
|
|
||||||
|
|
||||||
Trovare il massimo di una funzione in piu' variabili e' semplice in quanto si definisce come il **gradiente = 0**. Questo pero' non considera il caso in cui il massimo si trovi sul **limite dell'insieme**, ossia quello in cui la derivata non e' definita / non e' 0 (se si considera una porzione minore della curva).
|
|
||||||
|
|
||||||
Per ovviare a questo problema, si puo' utilizzare una **funzione lagrangiana**.
|
|
||||||
|
|
||||||
##### Funzioni lagrangiane
|
|
||||||
|
|
||||||
Supponiamo di dover calcolare il massimo di una `f(x)` appartenente a un insieme convesso `C`, dovendo rispettare dei **vincoli**, che possono essere:
|
|
||||||
|
|
||||||
* Vincoli con uguaglianza `g[j](x) = 0`
|
|
||||||
* Vincoli con disuguaglianza `h[j](x) <= 0`
|
|
||||||
|
|
||||||
I vincoli sono generalmente funzioni non lineari.
|
|
||||||
Senza i vincoli, sarebbe sufficiente porre il gradiente = 0, ma con i vincoli il massimo e' spesso sul bordo dell'insieme.
|
|
||||||
Per questo, si studia una funzione in cui:
|
|
||||||
|
|
||||||
* i vincoli sono stati sostituiti all'interno della funzione obbiettivo, moltiplicati per i **moltiplicatori di Lagrange**, nella forma:
|
|
||||||
|
|
||||||
```
|
|
||||||
L (x, lambda, u) = f(x) - sommatoria per i di (lambda[i]*h[i]) // nota: porre lambda >= 0 implica il segno -
|
|
||||||
L (x, lambda, u) = f(x) + sommatoria per j di (u[j]*g[j])
|
|
||||||
```
|
|
||||||
Questo riconduce la funzione obbiettivo a una funzione senza vincoli, detta **funzione lagrangiana**, in cui la soluzione per **gradiente = 0** e' valida.
|
|
||||||
|
|
||||||
La soluzione sara' quindi:
|
|
||||||
```
|
|
||||||
per ogni valore di i, la derivata dL/dxi = 0
|
|
||||||
|
|
||||||
per ogni valore di i, lambda*hi(x) = 0 // qui lambda e' != 0 solo se il vincolo non e' saturo, ossia se il vincolo non rappresenta un punto sul bordo del problema. Si noti come queste siano condizioni di complementary slackness, dove si analizzano le variabili duali del problema.
|
|
||||||
|
|
||||||
```
|
|
||||||
### Problema di ottimizzazione (di Kelly)
|
|
||||||
|
|
||||||
E' un problema a livello di sistema: massimizzare l'utilita' totale del sistema, trattando le sorgenti in modo equo, non e' praticamente risolvibile **in maniera centralizzata**. Il problema viene pero' risolto in maniera distribuito, in cui ogni sorgente risolve un **sottoproblema** fa convergere la rete alla soluzione ottima del problema centralizzato.
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
### Problema secondario: fairness
|
|
||||||
|
|
||||||
Come assegnare la banda di modo da:
|
|
||||||
* rispettare **equita'** rispetto ai link
|
|
||||||
* non eccedere la capacita' dei link
|
|
||||||
|
|
||||||
Per ovviare al problema, si utilizza **l'allocazione di risorse alpha-fair**. *(vedi slides)*
|
|
||||||
Si definisce inoltre la **proportional fairness** *(vedi slides)* e la **max-min fairness** *(vedi slides)*
|
|
||||||
|
|
||||||
*(vedi slides su come separare un problema di ottimizzazione in algoritmi distribuiti)*
|
|
||||||
|
|
@ -1,36 +0,0 @@
|
||||||
# Ripasso - Nozioni notevoli
|
|
||||||
|
|
||||||
## Statisical Multiplexing
|
|
||||||
|
|
||||||
Utilizzando variabili **aleatorie** (*random variables*) e' possibile stimare probabilisticamente la capacita' di una rete dato il numero di utenti.
|
|
||||||
|
|
||||||
*ex: Una rete a *100Mbit/s* che ha *N* utenti connessi, ognuno attivo per circa il *10%* del tempo e richiedente *10 Mbit/s*.
|
|
||||||
Se gli utenti sono connessi a commutazione di circuito, il massimo di *N* prima che la rete si congestioni e' *10*.
|
|
||||||
Se gli utenti sono connessi a commutazione di pacchetto, il massimo di *N* non e' calcolabile in maniera deterministica, ma probabilistica. La distibuzione di utenti attivi sulla rete e' infatti una *distribuzione binomiale.
|
|
||||||
|
|
||||||
-> p ( k = k') = binomial(N,k) * p^k * (1 - p)^(N - k)
|
|
||||||
|
|
||||||
Dove:
|
|
||||||
* p : probabilita' che un utente sia attivo
|
|
||||||
* k': utenti attivi
|
|
||||||
* N : utenti totali
|
|
||||||
|
|
||||||
Si nota come la probabilita' che ci siano piu' di 10 utenti attivi contemporaneamente, secondo le precedenti ipotesi, e' inferiore allo 0.0004% -> la commutazione di pacchetto permette piu' utenti attivi sulla rete.
|
|
||||||
|
|
||||||
## Traceroute
|
|
||||||
|
|
||||||
Basato su ICMP, funziona aumentando progressivamente il TTL dei pacchetti, di modo da trovare tutti gli *HOP* in cui un pacchetto "muore" (expired).
|
|
||||||
|
|
||||||
## Forward Error Control
|
|
||||||
|
|
||||||
Metodologie per il FEC:
|
|
||||||
|
|
||||||
* Ridondanza (complessita' O(n m)): Aggiunta alla trasmissione di pacchetti ridondanti, secondo i codici Reed-Solomon. 'n' e' il numero di pacchetti originali, 'm' sono i pacchetti ridondanti aggiunti. Se il numero medio di pacchetti persi da un canale non e' noto, e' possibile generare un numero infinito di blocchi e mandarli (e riceverli) come **flusso**. Questa tecnica e' chiamata *Rateless Codes* (LT/Rapture) e ha complessita' O(n ln(1/E)). 'E' e' la densita' di pacchetti. (vedi slides)
|
|
||||||
|
|
||||||
## M/M/1
|
|
||||||
|
|
||||||
**Modello a Coda**. Analizzando il buffer di un link/router in base agli arrivi, e' possibile modellare i pacchetti in arrivo secondo una distribuzione di Poisson, ottenendo un modello a coda a ritardo divergente.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Nota: il modello M/M/1 **non considera perdite** e permette un buffer **arbitrariamente grande** (anche **infinito**).
|
|
||||||
|
|
@ -1,118 +0,0 @@
|
||||||
# Controllo di congestione come problema di ottimizzazione (continua)
|
|
||||||
|
|
||||||
*(vedi slides per esempi, formule)*
|
|
||||||
## Decentralizzazione
|
|
||||||
|
|
||||||
La soluzione completamente distribuita e' basata sul fatto che **la somma dei prezzi dei link attraversati e' uguale all'utilita'**, e quindi e' molto semplice far convergere alla soluzione ottima globale.
|
|
||||||
|
|
||||||
TCP adotta esattamente questo meccanismo:
|
|
||||||
|
|
||||||
* **risolve il problema con una sua particolare funzione di utilita', ottimizzando un sotto-problema per ogni sessione.**
|
|
||||||
|
|
||||||
Per farlo, non utilizza i moltiplicatori di Lagrange ma utilizza una funzione approssimata, arbitrariamente precisa.
|
|
||||||
La scelta e' data dal fatto che **tcp porta la rete incogngestione**, eccedendo la capacita' dei link. Pertanto per TCP non e' vero che la somma dei rate dei flussi e' strettamente minore della capacita' del link.
|
|
||||||
|
|
||||||
Si presenta dunque il metodo approssimato per la risoluzione di problemi di ottimizzazione convessa.
|
|
||||||
|
|
||||||
## Metodo della funzione barriera (o di penalita')
|
|
||||||
|
|
||||||
E' necessario **rilassare i vincoli di banda**, che pertanto risulta in una funzione globale:
|
|
||||||
|
|
||||||
```
|
|
||||||
V (x) = sum in s of (Us(xs)) - sum in l belonging to L of (gl(yl))
|
|
||||||
```
|
|
||||||
Dove gl(yl) e' detta **funzione barriera**, permette di avere dei vincoli piu' *morbidi*, utilizzando una funzione con curva simil-esponenziale al posto di una costante in y (cl).
|
|
||||||
```
|
|
||||||
gl(yl) deve quindi essere convessa, continua, differenziabile, tendente a infinito per x che tende a infinito.
|
|
||||||
```
|
|
||||||
|
|
||||||
Utilizzando una funzione tendente a infinito, non e' piu' necessario utilizzare i moltiplicatori di Lagrange, che quindi risulta in un oggetto non vincolato che puo' essere risolto in modo standard (soluzione all'equilibrio, azzerando le derivate). A seconda della ripidita' della funzione barriera, posso risolvere il problema approssimando una soluzione arbitrariamente bene.
|
|
||||||
|
|
||||||
Possiamo dire che:
|
|
||||||
|
|
||||||
* La funzione che da il prezzo di un link e' **la derivata della funzione barriera**.
|
|
||||||
|
|
||||||
```
|
|
||||||
pl(yl) = d (gl(yl)) / dy // per ogni l appartenente a L
|
|
||||||
```
|
|
||||||
Infatti, la funzione di utilita' non sara' nient'altro che la somma delle funzioni di peso dei link, posta la derivata a zero.
|
|
||||||
|
|
||||||
### Possibili scelte del prezzo dei link
|
|
||||||
|
|
||||||
Varie opzioni:
|
|
||||||
|
|
||||||
* Prezzo coincide con la probabilita' di perdita (coda drop tail, dimensione B).
|
|
||||||
* Modello M/M/1/B
|
|
||||||
* Intensita' di traffico `ro = yl/cl`
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
Alternative:
|
|
||||||
* metodo del link viruale, che assume una capacita' virtuale di modo che la funzione barriera saturi a 1 eccessa quella capacita'.
|
|
||||||
|
|
||||||
* gestione RED (random early detection), che fissa il prezzo come funzione lineare a tratti della lunghezza media della coda (crescente col carico).
|
|
||||||
|
|
||||||
**Nota:** nel caso del link virtuale, a prima impressione ottengo automaticamente la struttura della rete interessata, il che risparmia le segnalazioni tra i nodi della rete. In realta' devo considerare il problema:
|
|
||||||
|
|
||||||
#### Prezzo VS feedback probabilistico
|
|
||||||
|
|
||||||
La probabilita' di marking end-to-end non e' esattamente la probabilita' di marking teorizzata. Infatti:
|
|
||||||
* Se le probabilita' di perdita del singolo link e' piccola, il prezzo e il feedback probabilistico sono praticamente la stessa cosa. TCP infatti risolve la versione ottimizzata del problema perche' il tasso di sorgente decresce per effetto delle perdite lungo il percorso sorgente-destinazione (risolvibile con **ECN, explicit congestion notification**.
|
|
||||||
TCP interpreta quindi i prezzi come indicatori di congestione.
|
|
||||||
|
|
||||||
### Prezzo dei link come soluzione distribuita del problema duale
|
|
||||||
|
|
||||||
La funzione lagrangiana duale, vista come funzione dei prezzi incogniti, e' *(vedi slides)*.
|
|
||||||
La funzione duale richiede la **minimizzazione della funzione *su slides* al variare dei prezzi.** Si nota come in questo caso non sia presente il **duality gap**, ottenendo quindi una soluzione ottimale che e' coincidente con quella del problema primale.
|
|
||||||
Il primale e il duale sono quindi due problemi opposti (uno di massimizzazione e uno di minimizzazione) in cui trovo una soluzione coincidente muovendomi in direzioni opposte rispetto al gradiente:
|
|
||||||
* massimizzare = muovermi in direzione del gradiente (funzione a campana o `U` rovesciata)
|
|
||||||
* minimizzare = muovermi in direzione opposta al gradiente (funzione a parabola `U`)
|
|
||||||
|
|
||||||
Curiosita': ponendo k(pl) = 1 (step function che regola il controllore) la variabile pl e' esattamente la lunghezza della coda.
|
|
||||||
|
|
||||||
Questa formulazione duale e' esattamente la base teorica dell'implementazione di TCP-vegas e Fast TCP (delay-based TCP), che pero' non hanno avuto grosso successo negli ultimi tempi.
|
|
||||||
|
|
||||||
## Cosa fa veramente TCP standard?
|
|
||||||
|
|
||||||
TCP standard dimezza la finestra di congestione ottenendo la square root formula. La funzione di utilita' a cui corrisponde la square root formula e':
|
|
||||||
```
|
|
||||||
(T*xs)^2 = (2 - 2*q) / q // elevo al quadrato la square root formula
|
|
||||||
|
|
||||||
=> q*(2-(T*xs)^2) = 2
|
|
||||||
|
|
||||||
da cui q = 2/(2-(T*xs)^2) che corrisponde esattamente alla U'(x)
|
|
||||||
```
|
|
||||||
Pertanto `U(x)` e' ottenuto **integrando U'(x)**
|
|
||||||
|
|
||||||
*(vedi slides per funzione usata da TCP)* Si nota come l'uso dell'arcotangente e' esattamente compatibile alla risoluzione precedentemente studiata, ma e' stato involontario.
|
|
||||||
|
|
||||||
*(vedi slides per caso con probabilita' di perdita piccola)*
|
|
||||||
|
|
||||||
Si nota come le nuove versioni (linux, etc) hanno xs proporzionale a constant/p (CUBIC, scalable TCP) -> q proporzionale a 1/xs. U(x) = log (x), quindi **proportional fairness**.
|
|
||||||
|
|
||||||
|
|
||||||
# Content Centric Networking
|
|
||||||
|
|
||||||
*(slides per outline)*
|
|
||||||
L'Internet moderno e' costituito da moltissimi utenti affamati di contenuti (enormi volumi di dati) ma dotati di hardware e software potente ed economico. Forte mobilita', ma anche increased dependency and security threats.
|
|
||||||
|
|
||||||
Pertanto, essendo che molti elementi dell'architettura di internet sono vecchi e inadeguati, alcuni sono da migliorare:
|
|
||||||
|
|
||||||
* Delivery to IP address
|
|
||||||
* point to point delivery
|
|
||||||
* lack of built-in security
|
|
||||||
|
|
||||||
Per risolvere questo problema, CCN muove il componente universale nel Internet Protocol dai pacchetti IP al **named data**. Questo comporta un cambiamento del classico diagramma a clessidra *(vedi slides)*.
|
|
||||||
|
|
||||||
Pertanto il named data si identifica come **communication medium** su cui sono costruite le applicazioni, appoggiato a qualunque network best-effort.
|
|
||||||
|
|
||||||
**Importante e' quindi il modello Publisher-Subscriber** *(vedi slides)*.
|
|
||||||
|
|
||||||
## Struttura dell'architettura CCN
|
|
||||||
|
|
||||||
Due elementi essenziali:
|
|
||||||
|
|
||||||
* **interest packets**: sent by consumers to signal a requets of a content
|
|
||||||
* **data packet**: sent by producers / nodes that satisfy the interest in response to a consumer interest packet.
|
|
||||||
|
|
||||||
*(vedi slides per architecture representation)*
|
|
||||||
|
|
@ -1,114 +0,0 @@
|
||||||
# Architettura CCN (continua)
|
|
||||||
|
|
||||||
Punti chiave:
|
|
||||||
* Consumers inviano **interest packets**, i nodi Producers rispondono con **data packets**
|
|
||||||
* Prefissi (nomi dei contenuti) **gerarchici e dipendenti dal contesto**
|
|
||||||
* **Nonce** usati per evitare loops di Interests
|
|
||||||
|
|
||||||
*(slides per architettura CCN)*
|
|
||||||
L'architettura e' pensata per i **router**, quindi adottare la rete CCN significa **cambiare l'architettura dei router** (proposta debole).
|
|
||||||
|
|
||||||
3 strutture dati fondamentali:
|
|
||||||
* Content Store [name/content]: salva i contenuti ricevuti (**cache**)
|
|
||||||
* Pending Interest Table [prefisso/porta]: memorizza gli interessi pendenti (memorizza prefisso e porta di provenienza della richiesta)
|
|
||||||
* Forwarding Information Base [prefisso/porte]: istruzioni di forwarding dei contenuti (memorizza prefisso e porte di ricezione / invio)
|
|
||||||
|
|
||||||
Grazie a quest'architettura, e' possibile ottenere una flessibilita' ottimale per soluzioni come il multicast (che col paradigma punto-punto non sono affrontabili a pieno).
|
|
||||||
|
|
||||||
## Interessi Pendenti e "briciole"
|
|
||||||
|
|
||||||
Se due nodi hanno il contenuto, un nodo puo' decidere di inviare l'Interest a entrambi. Solo il primo data packet torna indietro, quindi si crea uno spreco di banda.
|
|
||||||
|
|
||||||
Questo e' possibile perche' i router, al momento di ritornare il contenuto, seguono lo stesso path definito dalla richiesta (un po' come se avesse lasciato delle briciole di pane). 1 interest packet = 1 data packet ritornato.
|
|
||||||
|
|
||||||
## Name prefix: struttura
|
|
||||||
|
|
||||||
Il nome dei contenuti veicola un gran numero di informazioni, seguendo uno schema **gerarchico**: *(vedi slides per albero)* si definisce il processo di gerarchia del nome come **sequencing**.
|
|
||||||
|
|
||||||
La sequenza e': *(dall'http:// al fondo dell'indirizzo)*
|
|
||||||
* Globally-routable name (dominio)
|
|
||||||
* Organizational name (path del file)
|
|
||||||
* Versioning, segmentation (convenzionale o automatico)
|
|
||||||
|
|
||||||
Comodo per passare tante informazioni in poco spazio, ma:
|
|
||||||
* Complessita' evidente del lookup di un contenuto (in pratica, l'albero e' di dimensione (altezza / profondita') non note). Per questo fare longest prefix match e' costoso
|
|
||||||
|
|
||||||
## Remarks
|
|
||||||
*(vedi slides per remarks)*
|
|
||||||
* I router mantengono **lo stato**.
|
|
||||||
* Interest is routed, not data (briciole)
|
|
||||||
* Possibili sprechi dovuti a pacchetti duplicati scartati
|
|
||||||
* Nonces
|
|
||||||
* Il salvataggio dei contenuti utilizza un replacement scheme arbitrario (favorite)
|
|
||||||
* Pending Interest: le entry della tabella hanno un **timeout**.
|
|
||||||
* CCN permette una distribuzione di dati scalabile (youtube e il video streaming ne sono un esempio)
|
|
||||||
* La realizzazione di reti AD-HOC e' molto piu' semplice: due nodi possono immediatamente comunicare tra di loro (interest packet *local friends* per entrare in comunicazione con i nodi vicini). Questo rende molto efficente lo streaming di dati su dispositivi mobile *on-the-move* (si parla di flusso dati real time), dove non si necessita piu' di handover perche' non si utilizzano piu' gli indirizzi per comunicare. *La mobilita' viene gratis*.
|
|
||||||
|
|
||||||
## TCP-like features
|
|
||||||
|
|
||||||
Il controllo di congestione e' fattibile allo stesso modo, solo che invece di ragionare con i pacchetti TCP, si ragiona con interest/data packets. La congestion window sara' quindi espressa in termini di interest packet e data packet. Simile ai segmenti TCP. Si parla di **receiver-based congestion control**.
|
|
||||||
|
|
||||||
## Other layers
|
|
||||||
|
|
||||||
### Forwarding Table (strategic layer)
|
|
||||||
|
|
||||||
Costruire la forwarding table puo' essere fatto per interfacce multiple o singole, con paradigmi *send to best* (mando al link piu' scarico) o con alternative.
|
|
||||||
Per installare le forwarding table e' necessario
|
|
||||||
|
|
||||||
### Routing (incremental deployability)
|
|
||||||
|
|
||||||
Sono possibili anche situazioni in cui ci sono router *ccn-enabled* mischiati con router IP tradizionali. Questo per facilitare l'utilizzo e l'adozione di CCN.
|
|
||||||
|
|
||||||
**Intra-domain**:
|
|
||||||
* Ip-routers: si occupano di fare forwarding dei Link-state announcements (TLV)
|
|
||||||
* CCN-routers: si occupano di due funzioni: discovery dei nodi vicini e describe di risorse connesse
|
|
||||||
* I publishers fanno advertise dei nomi (prefissi), che sono aggiunti alla FIB
|
|
||||||
|
|
||||||
Vi sono pero' situazioni non ottimali, in quanto i nodi IP **non fanno da cache**, pertando riducendo prestazioni.
|
|
||||||
|
|
||||||
**Inter-domain**:
|
|
||||||
* ISP hanno incentivi per sviluppare il CCN (costi piu' bassi, performance maggiore)
|
|
||||||
* Problema: UDP-tunneling e' necessario per collegare le *isole CCN*, ossia gli ISP che adottano CCN, attraverso l'internet IP (ISP che NON adottano CCN).
|
|
||||||
|
|
||||||
## CCN security model
|
|
||||||
|
|
||||||
Uno degli obbiettivi di CCN e' quello di migliorare la sicurezza di Internet, con l'approccio **self-certified object**.
|
|
||||||
Ciascun data packet si auto-certifica, nel senso che contiene una **signature** e delle informazioni **signed info**, cosi' che il ricevente puo' essere sicuro della sua integrita' e della sua autenticita'.
|
|
||||||
|
|
||||||
* Si associa a ogni nome una chiave, firmando i dati assieme al nome **al momento della creazione**.
|
|
||||||
* Si verifica integrita' dei dati perche' questi contengono la signature.
|
|
||||||
|
|
||||||
### Prevenzione di attacchi Interest Flooding
|
|
||||||
|
|
||||||
Per prevenire attacchi di flooding, i nodi possono monitorare **quanti interest packets dello stesso prefix sono risolti con successo**. Inoltre, i domini possono anche richiedere ai router downstream (lungo il cammino) di rallentare il numero di pacchetti che essi inviano, relativi allo stesso prefisso.
|
|
||||||
|
|
||||||
## Prestazioni
|
|
||||||
*(vedi slides per esempi di performance)*
|
|
||||||
|
|
||||||
Le prestazioni di un sistema CCN sono vantaggiose prettamente per il multicast, essendo che un utilizzo point-to-point non conviene. E' stato misurato che:
|
|
||||||
|
|
||||||
* CCNd vs ttcp (linux): CCN perde un 20% circa della banda permessa **in una connessione point-to-point** dal TCP standard, ma non e' un brutto risultato visti i vantaggi. Questo e' il caso peggiore.
|
|
||||||
|
|
||||||
* Nel caso di un multicast / uno a molti, la performance di CCNd e' decisamente migliore del ttcp, essendo che con ttcp il download time di N ricevitori e' lineare nel numero di ricevitori, mentre con CCN e' **costante**. Questo e' possibile grazie alla cache effettuata dai nodi downstream. Queste ipotesi sono valide assumendo che tutti i nodi effettuino la richiesta contemporaneamente.
|
|
||||||
|
|
||||||
## Note
|
|
||||||
|
|
||||||
* CCN migliora la performance anche nel punto-punto, prettamente per un discorso di caching lungo il percorso.
|
|
||||||
* Le massime prestazioni offerte dal CCN dovrei fare routing to nearest replica. Questo vuol dire fare routing non a casaccio ma verso il punto piu' vicino.
|
|
||||||
* Sembra incrementally deployable, ma con molte limitazioni sulla performance.
|
|
||||||
|
|
||||||
Problemi principali:
|
|
||||||
* L'architettura e' del 2009, in via di sviluppo.
|
|
||||||
* E' davvero implementabile?
|
|
||||||
* Quanto tempo serve per il prefix look up?
|
|
||||||
* I router hanno abbastanza memoria?
|
|
||||||
* Come si regolano le scelte di nomi?
|
|
||||||
|
|
||||||
Inoltre:
|
|
||||||
* Come decido con quale criterio fare caching dei contenuti? (in che nodi, quante volte, se farla o no)
|
|
||||||
* CCN e' un approccio clean-slate (parte da 0).
|
|
||||||
* Basata su successi e lezioni dell'internet di oggi
|
|
||||||
* Built-in: sicurezza, multicast, multipath
|
|
||||||
* Ha suscitato un gran numero di critiche, conferenze e ricerca.
|
|
||||||
|
|
||||||
*(vedi slides per paper SIGCOMM di critiche al CCN)*
|
|
||||||
|
|
@ -1,77 +0,0 @@
|
||||||
# Complementi di Reti
|
|
||||||
|
|
||||||
## Controllo di Congestione
|
|
||||||
|
|
||||||
Due approcci:
|
|
||||||
* **End-to-End**: i terminali / host gestiscono tutto, la rete (link/router) non fa nulla a parte scartare pacchetti in eccesso. **TCP**
|
|
||||||
* **Assistito**: I router comunicano agli endpoint e gli altri router di congestione, (settando un bit, calcolando il rate ottimale e includendolo nei pacchetti). **ATM** (esempi su slides)
|
|
||||||
|
|
||||||
### TCP - Controllo di Congestione
|
|
||||||
|
|
||||||
* End-to-End
|
|
||||||
* Window protocol: il trasmettitore utilizza una *sliding window* che scorre sui dati da trasmettere, identificando una finestra chiamata **congestion window** (congwin).
|
|
||||||
```
|
|
||||||
**congwin**
|
|
||||||
|||||||||||||||||||||||||||-||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||-||||||||||||||||||
|
|
||||||
*gia' inviati con successo* ^base (paccetti inviati, no feedback yet) ^nextseqnum (da inviare) *pacchetti futuri*
|
|
||||||
|
|
||||||
```
|
|
||||||
La dimensione della finestra di congestione e' regolata **dinamicamente** da TCP, che la regola alla massima banda possibile senza congestione.
|
|
||||||
|
|
||||||
#### Regolazione di congwin: algoritmo e procedura
|
|
||||||
|
|
||||||
Pe identificare la dimensione ottimale della finestra, TCP usa un algoritmo chiamato basato su due procedure:
|
|
||||||
|
|
||||||
* **Slow Start**: all'inizio, congwin e' aumentata esponenzialmente fino a che non si verifica una congestione. Per fare cio', TCP duplica il numero di pacchetti inviati a ogni ricezione di ACK (con successo). Quindi invia 1,2,4,8,16... pacchetti, fino a congestionare la rete. TCP identifica una congestione tramite timeout expiration (Tahoe TCP) o ricezione di 3 ACK duplicati (Reno TCP).
|
|
||||||
* **Congestion Avoidance**: Appena una congestione e' rilevata, TCP diminuisce il numero di pacchetti (Tahoe: inizia da 1, Reno: dimezza) e setta il **threshold** tra Slow Start e Congestion Avoidance alla meta` del numero di pacchetti che ha causato la congestione (congestione a 16 -> threshold a 8). Durante la fase di congestion avoidance, TCP incrementa il numero di pacchetti inviati linearmente, seguendo l'equazione:
|
|
||||||
|
|
||||||
```
|
|
||||||
congwin = congwin(old) + 1/congwin(old)
|
|
||||||
|
|
||||||
questo viene fatto per ogni pacchetto, di modo che se congwin(old) e' 4, l'incremento sara':
|
|
||||||
|
|
||||||
4 -> 4+1/4 -> 4+2/4 -> 4+3/4 -> 5
|
|
||||||
|
|
||||||
per questo motivo, e' possibile approssimare l'incremento dato dalla congestion avoidance di 1 pacchetto per ogni invio simultaneo con successo.
|
|
||||||
```
|
|
||||||
|
|
||||||
Per questo motivo, l'algoritmo utilizzato da TCP e' detto anche **Additive Increase, Multiplicative Decrease** durante la congestion avoidance.
|
|
||||||
|
|
||||||
#### TCP square root formula
|
|
||||||
|
|
||||||
E' possibile descrivere la dimensione **media** della finestra di congestione data la probabilita' di packet loss su una rete. Questo si ottiene eguagliando le formule di additive increase, multiplicative decrease in congestion avoidance:
|
|
||||||
|
|
||||||
```
|
|
||||||
E[w] = avg window size
|
|
||||||
p = loss probability
|
|
||||||
|
|
||||||
(1-p) * 1/E[w] = p * E[w]/2
|
|
||||||
|
|
||||||
Da cui, isolando E[w]:
|
|
||||||
|
|
||||||
E[w] = sqrt((2 (1-p))/p)
|
|
||||||
|
|
||||||
Che, assumendo p molto piccolo (caso reale):
|
|
||||||
|
|
||||||
E[w] = sqrt(2/p)
|
|
||||||
|
|
||||||
Dato il RTT (round trip time), e' possibile ottenere il throughput della rete:
|
|
||||||
|
|
||||||
B = throughput
|
|
||||||
Rtt = round trip time
|
|
||||||
|
|
||||||
B = E[w] / Rtt -> B = sqrt(2/p) * 1/Rtt
|
|
||||||
```
|
|
||||||
|
|
||||||
Dall'equazione del throughput e' possibile notare come esso sia inversamente proporzionale alla loss probability e al RTT.
|
|
||||||
|
|
||||||
### TCP fairness
|
|
||||||
|
|
||||||
TCP e' un protocollo fair, che quindi vuole rispettare determinate condizioni di equita':
|
|
||||||
|
|
||||||
Date K connessioni TCP sulla stessa rete,
|
|
||||||
Data una banda totale R da condividere tra le connessioni,
|
|
||||||
|
|
||||||
-> Connessioni **identiche** dovrebbero ottenere R / K banda totale.
|
|
||||||
|
|
||||||
Questo e' possibile perche' il multiplicative decrease della congestion avoidance influisce piu' sulle connessioni favorite (che quindi hanno una finestra di congestione piu' ampia).
|
|
||||||
|
|
@ -1,64 +0,0 @@
|
||||||
# Complementi Reti
|
|
||||||
|
|
||||||
## Routing (instradamento)
|
|
||||||
|
|
||||||
Algoritmi (DV e LS) usano archi pesati su grafi, con peso inversamente proporzionale alla capacita' del link.
|
|
||||||
|
|
||||||
### Intra/Inter Autonomous Systems
|
|
||||||
|
|
||||||
* Intra = inside
|
|
||||||
* Inter = between
|
|
||||||
|
|
||||||
Internet usa il BGP per l'inter-AS routing (**border gateway protocol**).
|
|
||||||
|
|
||||||
## Data Link Layer
|
|
||||||
|
|
||||||
(Vedi slides, LAN, MAC address, ARP (ping)
|
|
||||||
|
|
||||||
---
|
|
||||||
fine ripasso reti
|
|
||||||
---
|
|
||||||
|
|
||||||
# Complementi di Reti - funzioni di rete e protocolli essenziali nell'architettura di una rete
|
|
||||||
|
|
||||||
## Segnalazione
|
|
||||||
|
|
||||||
Scambio di messaggi tra entita' di rete per fornire servizi orientati alla connessione.
|
|
||||||
Puo' avvenire prima/durante/dopo la connessione (detta anche chiamata)
|
|
||||||
|
|
||||||
* Prima: instaurazione connessione
|
|
||||||
* Durante: mantenimento / modifica connessione
|
|
||||||
* Dopo: misurazione a scopo tariffazione, statistico, etc
|
|
||||||
|
|
||||||
(vedi slides per esempi)
|
|
||||||
|
|
||||||
Segnalazioni sono usate su Internet (SIP), ATM (Q.2931), reti cellulari (2g,3g,4g...), reti telefoniche (SS7).
|
|
||||||
|
|
||||||
## Rete telefonica
|
|
||||||
|
|
||||||
Creata nel 1876, attualmente infrastruttura globale, cablata. Il cavo e' il doppino di rame intrecciato, che rappresenta la linea di accesso utenti.
|
|
||||||
|
|
||||||
Scopo: comunicazione telefonica (vocale) tra utenti, utilizzando terminali semplicissimi e una rete molto complessa. I terminali sono alimentati dalla rete.
|
|
||||||
|
|
||||||
**Utente** <-> Doppino <-> **Centrale Telefonica** <-> **Dorsale a lunga distanza (fatta di backbone switch)**
|
|
||||||
|
|
||||||
Spesso un'organizzazione utilizza un Private Branch eXchange (PBX) (centralino) per risparmiare sul cablaggio dell'*ultimo miglio*, o local loop, che collega i terminali utente alla centrale (~1-10Km). Questo perche'**ogni terminale richiede una linea propria che lo colleghi a un centralino o direttamente alla centrale della zona.**
|
|
||||||
|
|
||||||
Originariamente la trasmissione telefonica era **analogica con FDM**, perche' ogni chiamata vocale occupa una banda di circa 3.5KHz. In seguito si e' adottata la tecnica della trasmissione digitale, utilizzando uno schema **PCM** (8000 campioni al secondo, 8bit => 64 Kbps)
|
|
||||||
|
|
||||||
### Rete telefonica digitale
|
|
||||||
La digitalizzazione e' stata spinta sempre piu' verso l'utente, lasciando solo i local loop analogici. Il resto della rete (centrali e grandi dorsali) utilizza uno schema TDM.
|
|
||||||
|
|
||||||
La migrazione verso il digitale e'avvenuta per gradi, a partire dagli anni '90 con gli SDN (ISDN - Integrated Services Digital Network) che sono state subito soppiantate dall'ADSL (Asymmetrical Digital Subscriber Line). La telefonia tramite IP (VoIP) e' digitale ma non basata su commutazione di circuito.
|
|
||||||
|
|
||||||
In europa si e' affermata l'ADSL, mentre stati uniti / giappone tendono a utilizzare la Cable connection (cavo coassiale).
|
|
||||||
|
|
||||||
**Oggi** si utilizza la fibra ottica nei grandi centri, che arriva fino alle abitazioni utente.
|
|
||||||
|
|
||||||
* Multiplazione Digitale (digital multiplexing): sulle dorsali telefoniche i canali sono raggruppati in bande in base alla velocita'.
|
|
||||||
|
|
||||||
#### Instradamento / Indirizzamento
|
|
||||||
|
|
||||||
Ogni utenza ha un numero assegnato in maniera gerarchica: codice nazionale, provinciale / regionale, codice PBX, utenza.
|
|
||||||
L'instradamento avveniva prima tramite operatori, poi tramite strumenti elettromeccanici (meccanismi che collegavano un circuito fisico mentre l'utente digitava il numero). Oggi, telefonia digitale -> servizi implementati **al di sopra** della rete di trasporto fisico (rete telefonica intelligente).
|
|
||||||
|
|
||||||
|
|
@ -1,141 +0,0 @@
|
||||||
# Rete telefonica
|
|
||||||
|
|
||||||
## Rete telefonica intelligente
|
|
||||||
|
|
||||||
La rete telefonica digitale offre vari servizi aggiuntivi alla semplice rete analogica. (vedi slides)
|
|
||||||
Questo e' stato possibile grazie alla creazione di una rete di controllo **separata** dalla rete di trasporto dati (voce in questo caso).
|
|
||||||
* Data plane: trasporto voce a commutazione di circuito
|
|
||||||
* Control plane: rete separata (**segnalazione out-of-band**) **a commutazione di pacchetto** dedicata a messaggi di controllo, che forma il sistema di segnalazione numero 7 (**SS7**). Questo e' utilizzato sia dalla rete telefonica analogica sia da quella cellulare. Gli elementi di controllo (nodi) della rete di controllo sono **ridondanti**, perche' un guasto della rete di controllo e' molto piu' grave di un guasto del Data Plane.
|
|
||||||
|
|
||||||
### segnalazione out-of-band (SS7)
|
|
||||||
|
|
||||||
Vantaggi:
|
|
||||||
* maggiore velocita'
|
|
||||||
* segnalazione possibile in qualunque momento (non solo all'inizio / fine della connessione)
|
|
||||||
* le segnalazioni sono possibili tra qualunque coppia di commutatori
|
|
||||||
* **sicurezza**: gli utenti non hanno accesso al Control plane. Prima di questa separazione, avvenivano fenomeni di **phreaking** (anni 70-80), che facevano hijacking dei messaggi di controllo tra nodi a piacere (anche a lunga distanza, molto costose). *(vedi: episodio blue boxes)*
|
|
||||||
* commutazione di pacchetto (a differenza del Data plane) che ha un suo stack di protocolli (diversi da quelli di Internet). E' uno standard internazionale che permette di avere un'ottima interoperabilita'.
|
|
||||||
*(vedi slides per acronimi)*
|
|
||||||
|
|
||||||
#### Acronimi (non importanti ai fini dell'esame)
|
|
||||||
|
|
||||||
* SSP (signaling switching point): Nodi vicini all'utente finale, inviano e ricevono messaggi di segnalazione (basso carico)
|
|
||||||
* SCP (signaling control point): Nodi che contengono l'intelligenza della rete di controllo. Quindi l'accesso agli SCP avviene solo quando il servizio non e' una semplice chiamata, ma un servizio aggiuntivo (numero verde...) *(vedi slides)*
|
|
||||||
* STP (signaling transfer point): si occupano del routing di messaggi.
|
|
||||||
|
|
||||||
*(vedi slides per esempio di procedura di chiamata)*
|
|
||||||
|
|
||||||
# ATM
|
|
||||||
|
|
||||||
Architettura standard ad alta velocita' (fino a 622Mbps, anche oltre). **B-ISDN** (Broadband Integrated Service Digital Network). Questo e' entrato in concorrenza con TCP/IP, che poi si e' evoluto nel diventare Internet globale (deprecando ATM definitivamente). Era orientata al transporto end-to-end integrato di voce, dati e video.
|
|
||||||
|
|
||||||
## Caratteristiche
|
|
||||||
|
|
||||||
* **Circuiti virtuali permanenti**, fissi o dinamici (allocati a richiesta).
|
|
||||||
* **Commutazione di pacchetto** a velocita' fissa, detti "celle" (53 bytes), sui circuiti virtuali.
|
|
||||||
* Rispetto dei requisiti di QoS di voce, video (in contrasto con il best effort di Internet). Negli anni '90 la QoS era un argomento molto trattato, soprattutto perche' Internet non aveva ancora le capacita' odierne.
|
|
||||||
|
|
||||||
### Circuiti virtuali (VC)
|
|
||||||
|
|
||||||
Caratteristiche:
|
|
||||||
* Instaurazione / Terminazione della connessione prima e dopo il flusso dati (costoso)
|
|
||||||
* Ogni cella contiene l'identificativo del VC (che **non e' l'id della destinazione, come e' IP**) che cambiano da circuito a circuito (complesso)
|
|
||||||
* Ogni switch sul percorso sorgente-destinazione **deve** mantenere uno stato per ogni connessione attiva.
|
|
||||||
* Risorse di link / switch possono essere allocate a un VC, per ottenere prestazioni simili a un circuito.
|
|
||||||
|
|
||||||
#### Permanent VCs
|
|
||||||
|
|
||||||
Connessioni a lunga durata e canali permanenti tra due endpoint.
|
|
||||||
|
|
||||||
#### Switched VCs (VC commutati)
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
### Celle
|
|
||||||
|
|
||||||
Ogni cella e' composta di 53 Bytes:
|
|
||||||
* 5 di controllo
|
|
||||||
* 48 di dati
|
|
||||||
|
|
||||||
Il motivo e' la cancellazione dell'eco (soprattutto negli USA dove le distanze erano maggiori).
|
|
||||||
|
|
||||||
### VC Forwarding table
|
|
||||||
|
|
||||||
L'instradamento avviene usando gli ID dei VC, che in una forwarding table viene memorizzato e associato a un link (e un circuito) in uscita. *(vedi slides)*
|
|
||||||
|
|
||||||
### Segnalazione ATM (Stateful)
|
|
||||||
|
|
||||||
Con la connessione era necessario effettuare numerose segnalazioni, che permettevano:
|
|
||||||
* punto-punto e multicast (punto-multipunto) (**multicast su IP non e' possibile**)
|
|
||||||
* requisiti di banda simm/asimm
|
|
||||||
* QoS
|
|
||||||
* Controllo e recupero degli errori
|
|
||||||
|
|
||||||
Le segnalazioni di ATM sono dette **hard-state**, cioe' gestita da timers (10 lato utente, 10 lato rete) tutti atti a mantenere e controllare lo stato della connessione. Lo stato e' la forwarding table dei router, che e' necessaria a far transitare i pacchetti da un nodo all'altro. Lo stato riguarda anche le regole di QoS.
|
|
||||||
|
|
||||||
### Problematiche
|
|
||||||
|
|
||||||
* La rottura di un link su ATM richiede la riscrittura di tutte le forwarding tables dei link del circuito.
|
|
||||||
* Crash di un nodo utente (mittente, destinatario) durante la connessione, quindi senza che la rete se ne accorga. Con un circuito virtuale, le risorse sono attive (sprecate).
|
|
||||||
|
|
||||||
# Reti Cellulari (wireless)
|
|
||||||
|
|
||||||
## Richiami sulle reti wireless
|
|
||||||
|
|
||||||
Punti chiave:
|
|
||||||
* Mobilita' dei nodi di comunicazione
|
|
||||||
* Limitate risorse energetiche dei dispositivi utente
|
|
||||||
* Errori e Bit Error Rate (BER) molto maggiore rispetto alla trasmissione via cavo
|
|
||||||
* Natura broadcast del mezzo radio (il multicast e' gratuito, il che puo' essere un pro ma anche un contro: alta possibilita' di interferenza)
|
|
||||||
|
|
||||||
### Reti a infrastruttura fissa
|
|
||||||
|
|
||||||
Tutti i nodi comunicano su Internet tramite un **access point**, di solito gateway o router. (reti cellulari, wifi con infrastruttura (locali))
|
|
||||||
Molto utilizzate per la comodita' e la facilita' della gestione. Le reti cellulari sono a infrastruttura fissa.
|
|
||||||
|
|
||||||
### Reti a infrastruttura ad-hoc
|
|
||||||
|
|
||||||
Tutti i nodi comunicano tra loro senza un'infrastruttura fissa. La rete "magliata" deve quindi organizzarsi e gestirsi da se. Esistono reti ad hoc in cui un nodo fa comunque da **access point**.
|
|
||||||
Poco utilizzate, a parte per applicazioni militari o reti di emergenza.
|
|
||||||
|
|
||||||
### Problematiche delle reti wireless
|
|
||||||
|
|
||||||
#### Portata trasmissiva / interferenza
|
|
||||||
|
|
||||||
* La portata trasmissiva e' la massima distanza a cui si riceve correttamente l'informazione trasmessa.
|
|
||||||
Il segnale si attenua molto con la distanza, con la presenza di edifici/interferenze (citta' soprattutto).
|
|
||||||
|
|
||||||
* L'interference range e' di solito **maggiore** della portata trasmissiva: anche se non riesco a trasmettere i dati correttamente, posso comunque disturbare altri dispositivi piu' lontani. L'interferenza e' la somma di tutti i singoli disturbi generati dai dispositivi all'interno dell'interference range.
|
|
||||||
Interferenze dovute a vari rumori (onde em, forni a microonde, motori a scoppio...)
|
|
||||||
|
|
||||||
##### Signal to noise (interference) Ratio (SNR / SNIR)
|
|
||||||
|
|
||||||
Il signal to noise ratio e':
|
|
||||||
|
|
||||||
```
|
|
||||||
SNR = S/(sum(Ii)+N) dove la somma e' la somma di tutte le i interferenze (Ii) e N e' un rumore di fondo.
|
|
||||||
|
|
||||||
```
|
|
||||||
Il SNR e' misurato in dB (SNRdB = 10log10(SNR)) o in dBm (decibel per metro).
|
|
||||||
|
|
||||||
#### Path Loss
|
|
||||||
|
|
||||||
La perdita di potenza del segnale dovuta alla distanza (vedi portata trasmissiva). Nello spazio libero l'intensita' del segnale si attenua rispetto al quadrato della distanza.
|
|
||||||
|
|
||||||
#### Propagazione su piu' cammini
|
|
||||||
|
|
||||||
Una parte delle onde si riflette su oggetti, terreno, compiendo cammini di diversa distanza tra trasmittente e ricevente (se arrivano con un phase shift, si puo' creare un'interferenza distruttiva o **fading**).
|
|
||||||
|
|
||||||
### Tecniche di accesso multiplo
|
|
||||||
|
|
||||||
Il canale wireless e' condiviso da piu' utenti / dispositivi. Varie tecniche spartiscono il canale (FDMA, TDMA, CDMA, SDMA o space division multiple access, utilizza il fading del segnale per condividere il canale).
|
|
||||||
|
|
||||||
Molto importante e' anche il CDMA (code division multiple access) *(vedi slides)* che codificano i segnali (spesso con codici ortogonali) e permettono al ricevitore di recuperare i dati correttamente per ogni trasmissione. Questo funziona perche' il prodotto scalare tra un codice e un'altro ortogonale da 0.
|
|
||||||
|
|
||||||
* 2G utilizza un misto tra FDMA e TDMA (divide sia sulle frequenze che sui tempi).
|
|
||||||
* Le reti cellulari ora utilizzano molto SDMA, che grazie alle grandi distanze permette di utilizzare stesse frequenze in punti opportunamente distanti.
|
|
||||||
|
|
||||||
## Rete Cellulare: Definizioni
|
|
||||||
|
|
||||||
* Rete con copertura geografica divisa in **celle fisse**, adiacenti e/o sovrapposte, che suddividono il territorio.
|
|
||||||
* Un utente si puo' muovere da una cella a un'altra mentre utilizza il servizio cellulare, che e' possibile grazie all'**handover (o handoff)**, che presuppone che la rete si comporti in modo trasparente e l'utente non si accorga di nulla. Questo e' molto complesso nel caso di chiamate o trasferimenti di grandi files, che presuppongono un servizio continuativo.
|
|
||||||
|
|
||||||
|
|
@ -1,120 +0,0 @@
|
||||||
# Reti Cellulari
|
|
||||||
|
|
||||||
## Principi generali
|
|
||||||
|
|
||||||
### Copertura cellulare
|
|
||||||
|
|
||||||
Vari approcci:
|
|
||||||
* Idealmente, ogni antenna e' omnidirezionale, posta al centro di celle esagonali.
|
|
||||||
* Caso migliore (**sectoring**): 3 antenne nello stesso sito, ognuna irradia 120 gradi. Questo permette di installare meno antenne (inteso: meno siti diversi)
|
|
||||||
|
|
||||||
Nella realta', le celle non sono disposte geometricamente (dipende dalla conformazione de territorio).
|
|
||||||
Con l'aumento della richiesta di rate, le celle devono diventare piu' piccole (quasi dedicate ai singoli), di modo da garantire QoS.
|
|
||||||
|
|
||||||
### SDMA (Space Division Multiple Access)
|
|
||||||
|
|
||||||
Si basa sul riutilizzo spaziale di frequenze su celle abbastanza distanti tra loro, di modo da non creare interferenza *(vedi slides per disegno)*.
|
|
||||||
|
|
||||||
Ogni gruppo di celle che utilizzano tutte le frequenze (suddivise su ogni cella in *canali*) si chiama **cluster**. Questo schema puo' essere facilmente replicato su un territorio vasto.
|
|
||||||
|
|
||||||
* B = larghezza di banda di un canale.
|
|
||||||
* S = spettro a disposizione
|
|
||||||
* N = S/B e' il numero di canali a disposizione
|
|
||||||
|
|
||||||
Questo permette di ottenere i cluster:
|
|
||||||
```
|
|
||||||
N canali (suddivisioni di freq)
|
|
||||||
G gruppi (di k = N/G canali ciascuno)
|
|
||||||
```
|
|
||||||
Quindi un cluster e' l'insieme delle G celle che usano tutti gli N canali.
|
|
||||||
(Vedi slides per spiegazione grafica di disposizione cluster)
|
|
||||||
|
|
||||||
La definizione dipende dalla formula di Carnot (lato di un triangolo dati gli altri due e l'angolo compreso).
|
|
||||||
|
|
||||||
* le dimensioni della cella sono disegnate in base a quanta capacita' e' richiesta, ma:
|
|
||||||
**cella piccola = maggiore capacita' = maggior costo (piu' infrastruttura)**
|
|
||||||
|
|
||||||
(vedi slides, importante per esame)
|
|
||||||
|
|
||||||
#### Adattabilita' delle celle
|
|
||||||
|
|
||||||
* Spesso le celle sono adattabili alle richieste di traffico: una zona ad **alta densita'** richiedera' celle piu' fitte, mentre una zona a bassa densita' avra' bisogno di celle piu' grandi.
|
|
||||||
* Un'altra tecnica e' l'utilizzo di **macrocelle e microcelle**, in cui le macrocelle e le microcelle sono sovrapposte, le microcelle sono utilizzate per alte richieste di traffico.
|
|
||||||
* Nel caso delle vie di comunicazione (autostrade, ferrovia) richiedono celle con copertura piu' allungata e stretta, per favorire il traffico concentrato lungo la via.
|
|
||||||
|
|
||||||
## Architettura di rete
|
|
||||||
|
|
||||||
3 componenti formano la **rete operatore**:
|
|
||||||
|
|
||||||
* **MT**: terminale mobile (utente)
|
|
||||||
* **BS**: base station (stazione radio base)
|
|
||||||
* **MSC**: commutatori
|
|
||||||
|
|
||||||
Il collegamento MT-BS e' radio, mentre il collegamento BS-MSC e' cablato.
|
|
||||||
|
|
||||||
### Gestione della mobilita'
|
|
||||||
|
|
||||||
4 concetti:
|
|
||||||
* Roaming
|
|
||||||
* Locatio Updating
|
|
||||||
* Handover
|
|
||||||
* Paging
|
|
||||||
|
|
||||||
#### Roaming
|
|
||||||
|
|
||||||
Possibilita' che l'utente ha di spostarsi senza uscire dalla rete. Si tratta della **rintracciabilita'** dell'utente.
|
|
||||||
* Il sistema deve memorizzare in una base di dati la posizione degli utenti per poterli rintracciare.
|
|
||||||
* Per localizzare un utente si divide il territorio in aree dette **location areas** (insiemi di celle, meno costoso che inseguire all'utente a livello di cella).
|
|
||||||
|
|
||||||
#### Location Updating
|
|
||||||
|
|
||||||
Aggiornamento di posizione dell'utente, si basa sull'invio del LAI (location area id).
|
|
||||||
Ogni cella diffonde il proprio LAI su un canale di controllo.
|
|
||||||
|
|
||||||
* Il terminale mobile riceve un LAI diverso dal precedente e richiede al sistema una procedura di location updating. Questa procedura e' sostanzialmente l'update di un database.
|
|
||||||
* il location update e' effettuato ogni X minuti per aggiornare e garantire la presenza dei dispositivi.
|
|
||||||
|
|
||||||
#### Paging
|
|
||||||
|
|
||||||
Il sistema avvisa un terminale mobile di una chiamata in arrivo, inviando un messaggio di paging all'interno della LA in cui e' localizzato l'utente.
|
|
||||||
|
|
||||||
Il paging e' **costoso** per la rete, per questo se un terminale va offline avvisa la rete, cosi' che il paging inutile non venga effettuato. Se un terminale si rompe e non risponde, la rete effettua il paging ma dopo un certo periodo di tempo va in timeout.
|
|
||||||
|
|
||||||
#### Handover
|
|
||||||
|
|
||||||
E' simile al location update, ma considera il caso in cui l'utente ha una comunicazione / trasferimento dati in corso e cambia cella.
|
|
||||||
Handover puo' essere:
|
|
||||||
* Intra <-> inter cell (avviene all'interno della cella o tra celle diverse) *nota: intra implica il cambio di canale*
|
|
||||||
* soft: canale di destinazione e provenienza sono attivi nello stesso momento
|
|
||||||
* hard: uno solo dei due canali e' attivo nello stesso tempo
|
|
||||||
* forward: la segnalazione avviene durante la BS di arrivo
|
|
||||||
* backward: la segnalazione avviene durante la BS di partenza
|
|
||||||
|
|
||||||
##### Classificazione di Handover
|
|
||||||
|
|
||||||
L'handover, al contrario del location update, e' **deciso dalla rete**.
|
|
||||||
La decisione e' presa sulla base della qualita' (in SIR) trasmessa alla BS dal MT su un canale di controllo.
|
|
||||||
|
|
||||||
#### Registrazione
|
|
||||||
|
|
||||||
Il collegamento di un terminale implica una fase di autenticazione, basata sulla SIM del dispositivo.
|
|
||||||
|
|
||||||
## Architettura GSM
|
|
||||||
|
|
||||||
*(vedi slides per foto)*
|
|
||||||
* MS = MT
|
|
||||||
* BTS = ricevente antenna (base tranceiver station)
|
|
||||||
* BSC = controller antenna (base station controller)
|
|
||||||
* GMSC = gateway tra nodi (altre reti)
|
|
||||||
* VLR = visitors location register (attualmente nell'MSC)
|
|
||||||
* MSC = commutatore
|
|
||||||
* HLR = hole location register (contiene informazioni statiche degli utenti registrati sull'operatore e un puntatore a un VLR relativo alla posizione dell'utente)
|
|
||||||
* EIR = Database riguardante le componenti hardware (equipment information/identity register)
|
|
||||||
* AuC = auth center
|
|
||||||
* OMC = centro di controllo della rete (monitoraggio di performance, picchi, etc)
|
|
||||||
|
|
||||||
### Codificatore BSC
|
|
||||||
|
|
||||||
Un canale PCM da 2 Mb/s viene usato per mandare 4 canali GSM da 13 kb/s. (molto piu' basso dei 64 del pcm originale)
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,154 +0,0 @@
|
||||||
# GSM
|
|
||||||
|
|
||||||
## Aree del gsm
|
|
||||||
|
|
||||||
* Ogni *MSC* ha sotto di se varie **location areas**, ossia le arree in cui gli utenti vengono localizzati.
|
|
||||||
Queste sono dette MSC/VLR service areas.
|
|
||||||
* PLMN Service area: le aree di servizio degli operatori telefonici.
|
|
||||||
*(slides per grafico aree)*
|
|
||||||
|
|
||||||
### MSC - Mobile Switching Centre
|
|
||||||
|
|
||||||
* Alloca risorse e crea connessioni con i nodi (MS).
|
|
||||||
* GMSC (gateway msc) e' anche punto di partenza per la ricerca delle MS nella rete cellulare. I GMSC sono utilizzati per instradare le chiamate, le chiamate esterne sono instradate per prima cosa dal GSMC dell'operatore. -> **GSMC = entry point**.
|
|
||||||
|
|
||||||
### HLR - Home Location Register
|
|
||||||
|
|
||||||
Memorizza le informazioni riguardanti riguardo agli utenti iscritti. Tra queste:
|
|
||||||
* **IMSI: international mobile subscriber identity** - utilizzato per instradare chiamate, e' interno alla rete, univoco e associato all'operatore. Questo perche' il numero di telefono e' portabile tra operatori, l'IMSI no.
|
|
||||||
* Codice sim card
|
|
||||||
|
|
||||||
L'HLR memorizza anche informazioni volatili:
|
|
||||||
* L'indirizzo del VLR presso cui l'utente puo' essere reperito (cambia quando l'area di servizio MSC/VLR cambia)
|
|
||||||
* Parametri temporanei per crittografia e identificazione
|
|
||||||
|
|
||||||
### VLR - Visitor location Register
|
|
||||||
|
|
||||||
(*vedi slides*)
|
|
||||||
* TMSI: identificatore temporaneo (aggiornato ogni location update) che viene utilizzato al posto dell'IMSI per questioni di sicurezza (IMSI e' dato sensibile). Il TMSI viene mandato al terminale mobile crittografato, e memorizzato nella sim.
|
|
||||||
|
|
||||||
### EIR - Equipment Identity Register
|
|
||||||
|
|
||||||
Registro di terminali utente, divisa in white list (terminali autorizzati), gray list (terminali sospetti / difettosi), black list (terminali rubati / non autorizzati).
|
|
||||||
|
|
||||||
### AUC - Authentication center
|
|
||||||
|
|
||||||
Genera chiavi crittografiche per autenticare gli utenti.
|
|
||||||
|
|
||||||
### OMC - Operation and Mantainance Center
|
|
||||||
|
|
||||||
Centro di controllo che gestisce tariffazione, traffico, carico, errori sulla rete. Effettua operazioni dinamiche di reallocazioni di celle (picchi di traffico), manutenzione del sistema.
|
|
||||||
|
|
||||||
## Architettura del GSM (2G)
|
|
||||||
|
|
||||||
Gsm vuol dire essenzialmente **voce**. IMPORTANTE: **Indirect Routing**
|
|
||||||
|
|
||||||
4 parti:
|
|
||||||
* **Terminali** che si collegano via radio alle base stations (BTS)
|
|
||||||
* **BTS** che si collegano al relativo MSC
|
|
||||||
* **MSC** che si collega al relativo **GMSC**, e tramite questo si instrada nella rete pubblica.
|
|
||||||
*(slide 39: instradamento chiamate nel GSM)*
|
|
||||||
|
|
||||||
### GSM: handoff
|
|
||||||
|
|
||||||
#### MSC in comune
|
|
||||||
|
|
||||||
L'**handoff** e' il passaggio da una base station ad un'altra dovuto alla mobilita' dell'utente. La difficolta' dell'handoff sta nell'evitare la perdita di connessione, perche' si verifica in un contesto di connessione attiva (chiamata in corso).
|
|
||||||
|
|
||||||
Funzionamento:
|
|
||||||
* La vecchia BTS (base station) verifica la qualita' del segnale trasmesso all'utente. Se e' troppo bassa, inizia il processo di handoff.
|
|
||||||
*(vedi slide 41 per steps)*
|
|
||||||
Concetto importante: l'allocazione delle risorse sulla nuova base station avviene **prima** che l'utente riceva l'ordine di migrare. Questo permette alla migrazione effettuata con tutte le risorse allocate, di avere un tempo ~ms (nell'ordine dei millisecondi).
|
|
||||||
|
|
||||||
#### MSC differente
|
|
||||||
|
|
||||||
Caso piu' raro: nel passaggio da una cella all'altra si attraversano i confini dell'MSC, generando una **catena di MSC**:
|
|
||||||
* L'MSC originale fa da **ancora** (anchor). *Nota: si mantiene il routing indiretto, vedi slide 42)*
|
|
||||||
* Nuove MSC si aggiungono in *catena* all'anchor, mentre il terminale si sposta. Questo processo e' costoso ma molto raro. E' anche possibile ridurre la lunghezza della catena, per ottimizzare le risorse (escludendo un msc non utilizzato dalla catena).
|
|
||||||
|
|
||||||
## Architettura dell'UMTS (3G)
|
|
||||||
|
|
||||||
Notevole e' la separazione della rete dati dalla rete voce, che permette l'instradamento dell'una all'internet pubblico, dell'altra alla rete telefonica pubblica. *(vedi slides)*
|
|
||||||
|
|
||||||
Termini chiave:
|
|
||||||
* UTRAN - **Universal Terrestrial Radio Access Network**: rete di accesso radio
|
|
||||||
* GPRS - **General Packet radio network**
|
|
||||||
|
|
||||||
*(vedi slides)*
|
|
||||||
|
|
||||||
## Architettura dell'LTE (4G)
|
|
||||||
|
|
||||||
Lte sta per **Long Term Evolution**. Raccoglie sotto di se una serie di standard pensati per durare nel tempo.
|
|
||||||
Importante e' il miglioramento tecnologico, mentre l'architettura della rete e' molto simile al 3G.
|
|
||||||
* Ancora piu' importante e' l'**integrazione voce+dati** all'interno di IP, rimuovendo quindi la separazione tipica del 3G.
|
|
||||||
* Serving gateway: si interfaccia con la rete di connessione all'utente. *(vedi slide 45)*
|
|
||||||
* Packet (data network) gateway: si interfaccia con l'internet pubblico.
|
|
||||||
* eNodeB: base station
|
|
||||||
* MME: Mobility management Entity
|
|
||||||
* HSS: Home Subscriber Server, che ha le funzionalita' di HLR
|
|
||||||
|
|
||||||
Nota: **IP Bearer**: sono tunnel portatori di pacchetti IP che connettono eNodeB - Packet Gateway con lo scopo di mantenere una certa qualita' di servizio alle diverse connessioni (dati/voce).
|
|
||||||
|
|
||||||
### Parentesi: tunneling
|
|
||||||
|
|
||||||
Il tunneling e' costruire un pacchetto IP e inserirlo in un altro pacchetto IP. Questo per forzare il pacchetto interno ad attraversare dei *tunnel*. Raggiunta la destinazione forzata, il pacchetto IP *esterno* viene rimosso e il pacchetto e' inviato alla destinazione originale.
|
|
||||||
|
|
||||||
Nel caso dell'LTE, il tunnel viene costruito dall'eNodeB, che inserisce il pacchetto costruito dal terminale mobile. Tramite PDCP, il pacchetto viene inserito e mandato al PGW, che estrae il pacchetto e lo manda sulla rete pubblica.
|
|
||||||
|
|
||||||
### QoS LTE
|
|
||||||
|
|
||||||
Due classi di servizio:
|
|
||||||
* GBR; max/min rate garantiti
|
|
||||||
* noGBR
|
|
||||||
|
|
||||||
**12 valori** di QCI, tra cui la voce ha priorita' molto alta, ma anche un alto PELR (packet error loss rate). Questo per dare priorita' al video/streaming. Il QCI con priorita' peggiore riguarda i protocolli TCP (www, email, ftp).
|
|
||||||
*(vedi slide 49)*
|
|
||||||
|
|
||||||
# Segnalazione, piano di controllo e architettura
|
|
||||||
|
|
||||||
Su varie architetture, principale argomento del corso. Fino ad ora trattata in ambito mobile, ora:
|
|
||||||
|
|
||||||
## Segnalazione in Internet
|
|
||||||
|
|
||||||
E' principalmente fatta dai protocolli di routing, che vengono utilizzati come segnali.
|
|
||||||
* Soft state (se ne parlera')
|
|
||||||
* Segnalazione host-rete: IGMP
|
|
||||||
* SIP
|
|
||||||
* SDN: software defined networking (parentesi, molto in voga come nuova filosofia del piano di controllo in Internet).
|
|
||||||
|
|
||||||
### Principi architetturali di Internet
|
|
||||||
*(vedi slides per principi architetturali di internet, Clark '88, leggi articolo su moodle)*
|
|
||||||
|
|
||||||
Punti chiave (per importanza): *(completi su slides)*
|
|
||||||
* Survivability (resistenza al guasto del singolo link/nodo, comunicazione garantita)
|
|
||||||
* Supporto a molteplici tipi di servizi
|
|
||||||
* Permettere gestione distribuita
|
|
||||||
|
|
||||||
All'inizio, l'efficenza della rete (in termini di costi) aveva bassissima priorita', come anche tariffazione e monitoraggio del traffico.
|
|
||||||
Il problema della sicurezza non e' nemmeno considerato. Non c'era il bisogno di mettere la rete in sicurezza, essendo che non c'erano use cases illeciti.
|
|
||||||
|
|
||||||
**Priorita' diverse portano ad architetture diverse.** Motivo per cui lo stesso Clark nel 2013 ha riscritto l'articolo dove queste priorita' erano definite, dando maggiore priorita' a sicurezza, convenienza economica. E' importante pero' considerare che questa nuova visione non puo' essere attuata appieno, in quanto la rete e' stata costruita e non puo' essere ricostruita da zero.
|
|
||||||
|
|
||||||
#### Sopravvivenza
|
|
||||||
|
|
||||||
Continuare ad operare anche in caso di perdita di componenti della rete. Questo implica:
|
|
||||||
* Trasparenta del guasto interno ai nodi terminali
|
|
||||||
* **fate sharing**: la morte del nodo terminale e' l'unica evenienza in cui la rete non puo' consegnare il pacchetto.
|
|
||||||
|
|
||||||
Queste decisioni hanno portato a **mantenere un solo stato, a livello di trasporto, nei nodi terminali**. Questo elimina il problema gella gestione dell'inconsistenza dello stato.
|
|
||||||
|
|
||||||
#### Tipi di servizio
|
|
||||||
|
|
||||||
Una rete IP (datagram) difficilmente supporta diversi tipi di servizio: per questo TCP e UDP astraggono il datagram, che diventa **un comune denominatore su cui servizi diversi possono essere costruiti**. La differenziazione del servizio a livello rete IP fu considerata (IP ha il campo ToS) ma mai adottata su larga scala.
|
|
||||||
|
|
||||||
#### Varieta' di reti integrate
|
|
||||||
|
|
||||||
IP ha avuto un grande successo perche' ha requisiti minimali, approccio best-effort, riesce a integrarsi su varie tecnologie (ARPANET, X.25, etc).
|
|
||||||
La situazione e' quindi IP che gestisce una varieta' di protocolli superiori (TCP e UDP) ed e' integrato in diversi protocolli Link layer (ethernet, satellite, etc).
|
|
||||||
*(vedi slide 156 per diagramma hourglass (clessidra) di IP)*
|
|
||||||
|
|
||||||
#### Altri obbiettivi
|
|
||||||
|
|
||||||
* Efficienza era obbiettivo secondario, anche ora non si tende ad ottimizzare la rete per prestazioni. Si preferisce aumentare la capacita' e la potenza.
|
|
||||||
* Basso costo per attaccare un nuovo host nella rete: non e' mai stato un punto di forza, specialmente rispetto alla connessione telefonica.
|
|
||||||
* Tariffazione: complicato se non impossibile, monitoring e' complesso e non fattibile nel caso di cifrature.
|
|
||||||
|
|
@ -1,145 +0,0 @@
|
||||||
# Piano di controllo in Internet
|
|
||||||
*(vedi slides per timeline)*
|
|
||||||
## Note storiche
|
|
||||||
|
|
||||||
### Routing
|
|
||||||
|
|
||||||
#### Intra-domain
|
|
||||||
|
|
||||||
Il routing intra domain era necessario tra gli anni 80 e 90 a causa della forte gerarchizzazione di domini separati, mentre l'inter domain non era ancora necessario.
|
|
||||||
|
|
||||||
**ARPAnet V1** utilizzava un algoritmo **distance vector** distribuito (bellman-ford). Questo algoritmo e' asincrono, ma ha vari limiti:
|
|
||||||
|
|
||||||
* approccio iterativo: convergenza lenta, tabelle inconsistenti e oscillazioni del traffico
|
|
||||||
* traffico di update interferisce con il traffico dati
|
|
||||||
|
|
||||||
Questo approccio ha dato vita a **RIP**.
|
|
||||||
|
|
||||||
**ARPAnet V2** ha quindi adottato l'approccio **link state** (dijkstra). Questo approccio ha dato vita a **OSPF**.
|
|
||||||
|
|
||||||
#### Inter-domain
|
|
||||||
|
|
||||||
Dagli anni 90 a oggi, il routing inter-domain ha guadagnato sempre maggiore importanza.
|
|
||||||
|
|
||||||
**BGP**: protocollo distance vector (like) che determina una comunicazione TCP tra router che segnalano paths verso le destinazioni.
|
|
||||||
|
|
||||||
Problematiche:
|
|
||||||
* Volume di traffico alto rispetto al previsto (1997).
|
|
||||||
* Alta percentuale di traffico ridondante / patologica / obsoleta.
|
|
||||||
* Aumento volume di traffico su link congestionati (TCP, timers mal congestionati)
|
|
||||||
* Errori di configurazione locali hanno effetti sull'intera rete (globali)
|
|
||||||
* Deadlock / Effetto black hole: router non esistente porta l'intera rete a scartare traffico.
|
|
||||||
|
|
||||||
Tutto cio' rese la gestione di BGP praticamente impossibile, anche dimostrando quanto sia deleterio basare l'instradamento dinamico sulla congestione dei link. Questo si e' rivelato sbagliato perche':
|
|
||||||
|
|
||||||
* **Oscillazioni** sui link: un link congestionato viene evitato, ma scegliendo l'altro questo viene liberato, e quindi si oscilla tra i due.
|
|
||||||
|
|
||||||
Inoltre BGP ha dimostrato che gli **errori di configurazione si propagano**, e che non e' consigliabile **mischiare pacchetti di controllo e traffico dati**.
|
|
||||||
|
|
||||||
##### La soluzione: fornire linee guida per la configurazione dei link / router, che pero' non calcola l'errore umano.
|
|
||||||
|
|
||||||
## Mantenere lo stato di una rete
|
|
||||||
|
|
||||||
Lo stato e' l'informazione memorizzata dai protocolli di rete nei nodi.
|
|
||||||
Lo stato deve essere:
|
|
||||||
* aggiornato con il mutare delle condizioni della rete
|
|
||||||
* conservato in molteplici nodi
|
|
||||||
* associato a sessioni / chiamate generate dai sistemi terminali (utenti).
|
|
||||||
|
|
||||||
Lo stato presuppone un mittente e un ricevitore:
|
|
||||||
* **mittente**: nodo interessato a creare messaggi di stato / segnalazione sullo stato ricevitore. Questo al fine di installare, mantenere e rimuovere lo stato su altri nodi.
|
|
||||||
* **ricevitore**: nodo che reagisce ai messaggi del mittente creando, mantenendo e rimuovendo lo stato.
|
|
||||||
|
|
||||||
### Hard state: definizione
|
|
||||||
|
|
||||||
Utilizzato in telefonia, ATM, TCP.
|
|
||||||
|
|
||||||
Nell'hard state, lo stato e' valido (installato) finche' non e' ricevuto un messaggio specifico.
|
|
||||||
Il ricevitore installa e rimuove lo stato alla ricezione di un setup message / teardown message mandato dal mittente.
|
|
||||||
|
|
||||||
Problematica:
|
|
||||||
* **Stati orfani**: un problema di malfunzionamento genera stati orfani, che quindi non hanno uno stato valido ma pensano che esso lo sia. Per questo sono necessari meccanismi esterni al protocollo per segnalare la perdita dello stato, che altrimenti rimane attivo a oltranza (sprecando risorse allocate e non utilizzate).
|
|
||||||
|
|
||||||
Per questo motivo, molti protocolli di rete si basano su soft state perche' e' piu' robusto, mentre hard state e' intrinsecamente fragile.
|
|
||||||
|
|
||||||
*(vedi slides per disegno)*
|
|
||||||
|
|
||||||
### Soft state: definizione
|
|
||||||
|
|
||||||
Il progetto del multicast su IP si e' sempre basato sull'approccio **soft-state** (Clark, 1988). L'idea e' che lo stato della rete (router) sia installato / gestito dai nodi. Gli utenti quindi sono responsabili dello stato della rete. Lo scopo era ottenere una segnalazione flessibile e robusta, nonche' distribuita e *organica*.
|
|
||||||
|
|
||||||
Chiappa ha ridefinito il soft-state:
|
|
||||||
* stato mantenuto probabilisticamente
|
|
||||||
* non e' necessariamente consistente in ogni elemento della rete
|
|
||||||
* gli utenti assumono la piena responsabilita' di mantenere lo stato
|
|
||||||
* la rete assume la responsabilita' di **rimuovere lo stato**.
|
|
||||||
|
|
||||||
L'approccio soft state si basa sull'assunzione che lo stato non e' valido a meno che non venga rinnovato (refresh).
|
|
||||||
Il mittente quindi invia **periodicamente** dei *refresh* messages, senza i quali assumo che lo stato non sia valido. Lo stato e' quindi aggiornato ogni refresh.
|
|
||||||
Questo tipo di segnalazione e' detta **segnalazione best-effort**.
|
|
||||||
|
|
||||||
La fase di segnalazione e' simile all'approccio hard state:
|
|
||||||
* il ricevitore installa lo stato a ricezione di un *trigger message*, ma senza aspettare ACK.
|
|
||||||
* il messaggio di teardown non e' necessario, in quanto lo stato e' rimosso allo scadere del **timeout** (che implica la mancata ricezione del trigger message).
|
|
||||||
|
|
||||||
E' utilizzato da RTP (RTCP), RSVP, IGMP.
|
|
||||||
|
|
||||||
*(vedi slides per disegno)*
|
|
||||||
|
|
||||||
Vantaggi rispetto all'hard-state:
|
|
||||||
* robustezza: migliore reazione e adattabilita' ai cambiamenti della rete.
|
|
||||||
* semplicita': evita complessita' aggiuntiva per la gestione degli errori.
|
|
||||||
|
|
||||||
|
|
||||||
### IP multicast: a love story
|
|
||||||
|
|
||||||
Il multicast a livello IP (3) ha visto vari tentativi di sviluppo, allo scopo di ridurre il carico della rete e minimizzare il consumo di risorse. Il problema ha una notevole complessita'.
|
|
||||||
|
|
||||||
1. Uno dei principali problemi e' la **gestione della massa di utenti interessati a una stessa trasmissione di pacchetti**.
|
|
||||||
2. Altro problema e' trovare il miglior modo per ramificare l'albero di trasmissione (**steiner tree**, unire un sottoinsieme di nodi di un albero minimizzando il costo delle connessioni. **NP-Completo**).
|
|
||||||
3. L'allocazione di banda (prenotazione di risorse per il flusso dati) puo' dar luogo a un carico molto pesante sulla rete, specialmente sui nodi di *smistamento* del traffico.
|
|
||||||
|
|
||||||
Soluzioni:
|
|
||||||
|
|
||||||
1. astrazione del gruppo Multicast: riservare gli IP di un determinato gruppo come multicast, e lasciare che gli host dichiarino i loro interessi a partecipare al gruppo multicase (**IGMP** a livello locale). Sono stati riservati gli IP di classe D (2^28 IP) che pero' sono circa 256 milioni, troppo pochi ad oggi. Quindi:
|
|
||||||
|
|
||||||
* Livello locale: IGMP, l'host informa il **multicast router** locale che e' interessato a far parte del multicast. Il router inoltre invia *Query* periodiche, aspettandosi risposta positiva dai membri del gruppo. Questo protocollo e' quindi soft-state.
|
|
||||||
* WAN level: il router locale interagisce con altri multicast router per ricevere il flusso di dati. Questa fase e' gestita da vari protocolli, ma **non piu' IGMP**.
|
|
||||||
|
|
||||||
2. Essendo lo steiner tree un problema np-completo, e' stato oggetto di numerosi dibattiti. Varie soluzioni:
|
|
||||||
* Approccio **source-based**: un albero diverso da ogni mittente ai ricevitori (piu' complesso, ottimale)
|
|
||||||
* Approccio **shared-tree**: l'albero e' unico per ogni membro del gruppo (piu' semplice, piu' dispendioso)
|
|
||||||
|
|
||||||
#### Multicast a singola sorgente
|
|
||||||
|
|
||||||
Il modello originale di multicast IP e' difficile da implementare, ma molte applicazioni richiedono una singola sorgente.
|
|
||||||
Si utilizza quindi **PIM-SSM**, che utilizza la coppia di indirizzi (sorgente, gruppo) non richiedendo quindi indirizzi multicast allocati. Costruisce alberi source-based.
|
|
||||||
|
|
||||||
<!--## Segnalazione in Internet (obbiettivo QoS)-->
|
|
||||||
|
|
||||||
### RSVP (Resource Reservation Protocol)
|
|
||||||
|
|
||||||
L'obbiettivo e' permettere agli utenti di comunicare i propri requisiti alla rete in modo efficiente e robusto. Ormai e' in disuso, ma era pensato per il **multicast di IP**. RSVP e' basato su soft-state, ha sostituito l'Internet Signaling Protocol.
|
|
||||||
|
|
||||||
Requisiti:
|
|
||||||
* permettere **ricevitori eterogenei** (flussi a rate diversi)
|
|
||||||
* sorgenti possono avere diverse applicazioni con diversi requisiti di risorse.
|
|
||||||
* appoggiarsi ai protocolli di routing esistenti (non occuparsi quindi della costruzione dell'albero).
|
|
||||||
* modularita'
|
|
||||||
* overhead del controllo a crescita **al piu' lineare**
|
|
||||||
|
|
||||||
Non si occupa di:
|
|
||||||
* dividere le risorse (non garantisce banda su percorso / link), ma offre un sistema per comunicare i requisiti di risorsa
|
|
||||||
* instradare (non fa routing)
|
|
||||||
* inoltrare i pacchetti (non si occupa della gestione dei dati)
|
|
||||||
|
|
||||||
#### Funzionamento: alto livello
|
|
||||||
|
|
||||||
* mittenti e ricevitori entrano a far parte del gruppo multicast (IGMP), ma i mittenti non devono iscriversi al gruppo. Questo e' gestito da IGMP, esterno a RSVP.
|
|
||||||
* **path messages**: messaggi mittente-rete che segnalano ai router della presenza dei trasmettitori
|
|
||||||
* **reservation messages**: messaggi per riservare le risorse del mittente, mandati dagli utenti.
|
|
||||||
|
|
||||||
*(vedi slides per struttura di path message, reservation message)*
|
|
||||||
*(vedi slides per disegno / funzionamento grafico)*
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,119 +0,0 @@
|
||||||
# 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).
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
|
@ -1,6 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<classpath>
|
|
||||||
<classpathentry kind="src" path="src"/>
|
|
||||||
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/JVM 1.5.0"/>
|
|
||||||
<classpathentry kind="output" path="bin"/>
|
|
||||||
</classpath>
|
|
||||||
|
|
@ -1,17 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<projectDescription>
|
|
||||||
<name>DNDemo2</name>
|
|
||||||
<comment></comment>
|
|
||||||
<projects>
|
|
||||||
</projects>
|
|
||||||
<buildSpec>
|
|
||||||
<buildCommand>
|
|
||||||
<name>org.eclipse.jdt.core.javabuilder</name>
|
|
||||||
<arguments>
|
|
||||||
</arguments>
|
|
||||||
</buildCommand>
|
|
||||||
</buildSpec>
|
|
||||||
<natures>
|
|
||||||
<nature>org.eclipse.jdt.core.javanature</nature>
|
|
||||||
</natures>
|
|
||||||
</projectDescription>
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
#Thu Dec 29 12:44:00 CET 2005
|
|
||||||
eclipse.preferences.version=1
|
|
||||||
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
|
|
||||||
org.eclipse.jdt.core.compiler.compliance=1.5
|
|
||||||
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
|
|
||||||
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
|
|
||||||
org.eclipse.jdt.core.compiler.source=1.5
|
|
||||||
|
|
@ -1,36 +0,0 @@
|
||||||
(c) Copyright 2005, Ian Clarke, Oskar Sandberg
|
|
||||||
Released under the GNU General Public License Version 2
|
|
||||||
|
|
||||||
Requirements
|
|
||||||
------------
|
|
||||||
Needs Java 1.5 or later
|
|
||||||
|
|
||||||
Instructions
|
|
||||||
------------
|
|
||||||
From this directory:
|
|
||||||
|
|
||||||
$ java -cp bin Main <seed>
|
|
||||||
|
|
||||||
Seed can be any integer and it will be used as the seed for the random
|
|
||||||
number generator. We used 8011 in our talk.
|
|
||||||
|
|
||||||
The display shows a network where nodes have been assigned locations in
|
|
||||||
2D space. At the bottom a histogram of connection lengths is shown.
|
|
||||||
|
|
||||||
Once it starts, hit any key to advance onto the next stage. The stages are
|
|
||||||
as follows:
|
|
||||||
|
|
||||||
1. Display an ideal small world network (according to Kleinberg's proof).
|
|
||||||
Note that nodes are actually positioned on a grid, but are offset
|
|
||||||
randomly by a few pixels to make connections easier to see.
|
|
||||||
|
|
||||||
2. Show a route between two nodes
|
|
||||||
|
|
||||||
3. Randomize the network
|
|
||||||
|
|
||||||
4. Show an attempted route between two nodes
|
|
||||||
|
|
||||||
5. Show our algorithm "restoring" the network, one node and its connections
|
|
||||||
are highlighted in green
|
|
||||||
|
|
||||||
6. Show a route between two nodes
|
|
||||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -1,424 +0,0 @@
|
||||||
import java.awt.BasicStroke;
|
|
||||||
import java.awt.Color;
|
|
||||||
import java.awt.Graphics;
|
|
||||||
import java.awt.Graphics2D;
|
|
||||||
import java.awt.event.KeyEvent;
|
|
||||||
import java.awt.event.KeyListener;
|
|
||||||
import java.util.HashSet;
|
|
||||||
import java.util.LinkedList;
|
|
||||||
import java.util.Random;
|
|
||||||
|
|
||||||
import javax.swing.JFrame;
|
|
||||||
|
|
||||||
public class Main {
|
|
||||||
static int XSZ = 15, YSZ = 15;
|
|
||||||
|
|
||||||
static int step = 0;
|
|
||||||
|
|
||||||
static int NL = 5;
|
|
||||||
|
|
||||||
static int HTL = 50;
|
|
||||||
|
|
||||||
static JFrame jframe = new JFrame() {
|
|
||||||
public void JFrame() {
|
|
||||||
this.setTitle("Freenet Demo");
|
|
||||||
}
|
|
||||||
|
|
||||||
@Override
|
|
||||||
public void paint(Graphics g) {
|
|
||||||
Graphics2D g2d = (Graphics2D) g;
|
|
||||||
this.setBackground(Color.BLACK);
|
|
||||||
drawGrid(g2d);
|
|
||||||
}
|
|
||||||
};
|
|
||||||
|
|
||||||
static Node[] nodes = new Node[XSZ * YSZ];
|
|
||||||
|
|
||||||
static Random rand;
|
|
||||||
|
|
||||||
static LinkedList<Node> route = null;
|
|
||||||
|
|
||||||
static int[] linkLenHist = null;
|
|
||||||
|
|
||||||
static Thread cThread;
|
|
||||||
|
|
||||||
static char lastKeyPressed;
|
|
||||||
|
|
||||||
static HashSet<Node> highlightedNodes = new HashSet<Node>();
|
|
||||||
|
|
||||||
static boolean highlightLinks = false;
|
|
||||||
|
|
||||||
static String epsFile;
|
|
||||||
|
|
||||||
public static void main(String[] args) {
|
|
||||||
int seed = args.length > 0 ? Integer.parseInt(args[0]) : (int) (System.currentTimeMillis() % 10000);
|
|
||||||
System.out.println("Using seed: " + seed);
|
|
||||||
epsFile = args.length < 2 ? null : args[1];
|
|
||||||
rand = new Random(seed);
|
|
||||||
|
|
||||||
cThread = new Thread() {
|
|
||||||
public void run() {
|
|
||||||
Main.cThreadRun();
|
|
||||||
}
|
|
||||||
};
|
|
||||||
cThread.start();
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static char waitForKeyPress() {
|
|
||||||
synchronized (cThread) {
|
|
||||||
try {
|
|
||||||
cThread.wait();
|
|
||||||
} catch (InterruptedException e) {
|
|
||||||
}
|
|
||||||
}
|
|
||||||
return lastKeyPressed;
|
|
||||||
}
|
|
||||||
|
|
||||||
public static void cThreadRun() {
|
|
||||||
createKleinbergGrid();
|
|
||||||
updateHist();
|
|
||||||
createFrame();
|
|
||||||
if (epsFile != null) {
|
|
||||||
drawEps(1);
|
|
||||||
}
|
|
||||||
waitForKeyPress();
|
|
||||||
Node node1 = nodes[0];
|
|
||||||
Node node2 = nodes[XSZ * YSZ - 1];
|
|
||||||
route = greedyRoute(node1, node2);//(nodes[0], nodes[XSZ * YSZ - 1]);
|
|
||||||
if (epsFile != null) {
|
|
||||||
drawEps(2);
|
|
||||||
}
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
shuffleGrid();
|
|
||||||
updateHist();
|
|
||||||
route = null;
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
//highlightedNodes.add(nodes[0]);
|
|
||||||
//highlightedNodes.add(nodes[XSZ * YSZ - 1]);
|
|
||||||
//highlightedNodes.clear();
|
|
||||||
route = greedyRoute(node1, node2);//(findNode(0,0), findNode(XSZ - 1,YSZ - 1));
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
route = null;
|
|
||||||
// while (true) {
|
|
||||||
// Node[] swN = findSwitch();
|
|
||||||
// highlightedNodes.add(swN[0]);
|
|
||||||
// highlightedNodes.add(swN[1]);
|
|
||||||
// jframe.repaint();
|
|
||||||
// char k = waitForKeyPress();
|
|
||||||
// if (k != ' ') {
|
|
||||||
// break;
|
|
||||||
// }
|
|
||||||
// doSwitch(swN[0], swN[1]);
|
|
||||||
// updateHist();
|
|
||||||
// jframe.repaint();
|
|
||||||
// k = waitForKeyPress();
|
|
||||||
// if (k != ' ') {
|
|
||||||
// break;
|
|
||||||
// }
|
|
||||||
// highlightedNodes.clear();
|
|
||||||
// }
|
|
||||||
|
|
||||||
highlightedNodes.add(nodes[0]);
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
|
|
||||||
for (int x = 0; x < 10 * XSZ * YSZ; x++) {
|
|
||||||
Node[] sw = findSwitch();
|
|
||||||
doSwitch(sw[0], sw[1]);
|
|
||||||
if (x % 10 == 0) {
|
|
||||||
updateHist();
|
|
||||||
jframe.repaint();
|
|
||||||
}
|
|
||||||
try {
|
|
||||||
Thread.sleep(20);
|
|
||||||
} catch (InterruptedException e) {
|
|
||||||
}
|
|
||||||
double logSum = 0;
|
|
||||||
for (Node n : nodes) {
|
|
||||||
logSum += n.logSum(n.xPos, n.yPos);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
updateHist();
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
highlightedNodes.clear();
|
|
||||||
updateHist();
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
route = greedyRoute(node1,node2);//greedyRoute(findNode(0,0), findNode(XSZ - 1, YSZ - 1));
|
|
||||||
|
|
||||||
jframe.repaint();
|
|
||||||
waitForKeyPress();
|
|
||||||
}
|
|
||||||
|
|
||||||
public static void keyPress() {
|
|
||||||
synchronized (cThread) {
|
|
||||||
cThread.notify();
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void createFrame() {
|
|
||||||
jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
|
|
||||||
jframe.addKeyListener(new KeyListener() {
|
|
||||||
|
|
||||||
public void keyTyped(KeyEvent arg0) {
|
|
||||||
lastKeyPressed = arg0.getKeyChar();
|
|
||||||
keyPress();
|
|
||||||
}
|
|
||||||
|
|
||||||
public void keyPressed(KeyEvent arg0) {
|
|
||||||
}
|
|
||||||
|
|
||||||
public void keyReleased(KeyEvent arg0) {
|
|
||||||
}
|
|
||||||
});
|
|
||||||
jframe.setSize(640, 480);
|
|
||||||
jframe.setVisible(true);
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static Node findNode(int x, int y) {
|
|
||||||
for (Node n : nodes)
|
|
||||||
if (n.xPos == x && n.yPos == y)
|
|
||||||
return n;
|
|
||||||
return null;
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void createKleinbergGrid() {
|
|
||||||
|
|
||||||
for (int x = 0; x < XSZ; x++) {
|
|
||||||
for (int y = 0; y < YSZ; y++) {
|
|
||||||
Node n = new Node(x, y);
|
|
||||||
nodes[x * YSZ + y] = n;
|
|
||||||
|
|
||||||
}
|
|
||||||
}
|
|
||||||
for (Node n : nodes) {
|
|
||||||
int xp, yp;
|
|
||||||
for (int i = 0; i < NL; i++) {
|
|
||||||
Node m;
|
|
||||||
do {
|
|
||||||
do {
|
|
||||||
int s = (int) Math.floor(Math.pow(Math.min(XSZ, YSZ),
|
|
||||||
rand.nextFloat()));
|
|
||||||
int xs = rand.nextInt(s + 1);
|
|
||||||
int ys = s - xs;
|
|
||||||
int xd = 2 * rand.nextInt(2) - 1;
|
|
||||||
int yd = 2 * rand.nextInt(2) - 1;
|
|
||||||
|
|
||||||
xp = n.xPos + xd * xs;
|
|
||||||
yp = n.yPos + yd * ys;
|
|
||||||
} while (0 > xp || xp >= XSZ || 0 > yp || yp >= YSZ);
|
|
||||||
|
|
||||||
m = nodes[xp * YSZ + yp];
|
|
||||||
|
|
||||||
} while (n.isNeighbor(m));
|
|
||||||
|
|
||||||
if (!(n.addNeighbor(m) && m.addNeighbor(n))) {
|
|
||||||
System.err.println("COULDNT ADD NEIGHBOR!");
|
|
||||||
System.exit(1);
|
|
||||||
}
|
|
||||||
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void shuffleGrid() {
|
|
||||||
for (Node n : nodes) {
|
|
||||||
Node m = nodes[rand.nextInt(nodes.length)];
|
|
||||||
int x = n.xPos;
|
|
||||||
int y = n.yPos;
|
|
||||||
n.xPos = m.xPos;
|
|
||||||
n.yPos = m.yPos;
|
|
||||||
m.xPos = x;
|
|
||||||
m.yPos = y;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static Node[] findSwitch() {
|
|
||||||
double p;
|
|
||||||
Node n, m;
|
|
||||||
int st = 0;
|
|
||||||
do {
|
|
||||||
n = nodes[rand.nextInt(nodes.length)];
|
|
||||||
m = nodes[rand.nextInt(nodes.length)];
|
|
||||||
|
|
||||||
p = Math.exp(-2.0
|
|
||||||
* (n.logSum(m.xPos, m.yPos) + m.logSum(n.xPos, n.yPos)
|
|
||||||
- n.logSum(n.xPos, n.yPos) - m.logSum(m.xPos,
|
|
||||||
m.yPos)));
|
|
||||||
if (++st > 10000)
|
|
||||||
return null;
|
|
||||||
} while (rand.nextDouble() > p);
|
|
||||||
return new Node[] { n, m };
|
|
||||||
|
|
||||||
}
|
|
||||||
|
|
||||||
public static void doSwitch(Node n, Node m) {
|
|
||||||
int x = n.xPos;
|
|
||||||
int y = n.yPos;
|
|
||||||
n.xPos = m.xPos;
|
|
||||||
n.yPos = m.yPos;
|
|
||||||
m.xPos = x;
|
|
||||||
m.yPos = y;
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void drawEps(int n) {
|
|
||||||
//Graphics2D gr = new EpsGraphics2D();
|
|
||||||
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void drawGrid(Graphics2D g) {
|
|
||||||
g.clearRect(0, 0, jframe.getWidth(), jframe.getHeight());
|
|
||||||
for (int i = 0; i < nodes.length; i++) {
|
|
||||||
nodes[i].draw(g, false);
|
|
||||||
}
|
|
||||||
for (Node n : highlightedNodes) {
|
|
||||||
n.draw(g, true);
|
|
||||||
}
|
|
||||||
if (route != null) {
|
|
||||||
g.setColor(Color.RED);
|
|
||||||
g.setStroke(new BasicStroke(2f));
|
|
||||||
Node p = null;
|
|
||||||
for (Node c : route) {
|
|
||||||
if (p != null) {
|
|
||||||
g.drawLine(p.axPos(), p.ayPos(), c.axPos(), c.ayPos());
|
|
||||||
}
|
|
||||||
p = c;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
int maxHVal = 0;
|
|
||||||
for (int x = 0; x < linkLenHist.length; x++) {
|
|
||||||
if (maxHVal < linkLenHist[x])
|
|
||||||
maxHVal = linkLenHist[x];
|
|
||||||
}
|
|
||||||
for (int x = 1; x < linkLenHist.length; x++) {
|
|
||||||
float dist = 0.5f + (0.5f / (float) x);
|
|
||||||
g.setColor(new Color(dist, dist, dist));
|
|
||||||
g.fillRect(x * (jframe.getWidth() / linkLenHist.length), (jframe
|
|
||||||
.getHeight() - (100 * linkLenHist[x]) / maxHVal), jframe
|
|
||||||
.getWidth()
|
|
||||||
/ linkLenHist.length, (100 * linkLenHist[x]) / maxHVal);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static int distance(Node a, Node b) {
|
|
||||||
return Math.abs(a.xPos - b.xPos) + Math.abs(a.yPos - b.yPos);
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static void updateHist() {
|
|
||||||
linkLenHist = new int[XSZ + YSZ];
|
|
||||||
for (Node n : nodes) {
|
|
||||||
if (n != null) {
|
|
||||||
for (Node nn : n.links) {
|
|
||||||
if (nn != null)
|
|
||||||
linkLenHist[distance(n, nn)]++;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
protected static LinkedList<Node> greedyRoute(Node start, Node end) {
|
|
||||||
Node current = start;
|
|
||||||
LinkedList<Node> hist = new LinkedList<Node>();
|
|
||||||
while (!current.equals(end) && hist.size() < HTL) {
|
|
||||||
hist.addLast(current);
|
|
||||||
int dist = Integer.MAX_VALUE;
|
|
||||||
Node next = null;
|
|
||||||
for (Node n : current.links) {
|
|
||||||
|
|
||||||
if (n == null || hist.contains(n))
|
|
||||||
continue;
|
|
||||||
if (distance(n, end) < dist) {
|
|
||||||
next = n;
|
|
||||||
dist = distance(n, end);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
if (next == null)
|
|
||||||
break;
|
|
||||||
current = next;
|
|
||||||
}
|
|
||||||
hist.addLast(end);
|
|
||||||
return hist;
|
|
||||||
}
|
|
||||||
|
|
||||||
static class Node {
|
|
||||||
int xPos, yPos;
|
|
||||||
|
|
||||||
float roXpos = rand.nextFloat() / 2 - 0.25f,
|
|
||||||
roYpos = rand.nextFloat() / 2 - 0.25f;
|
|
||||||
|
|
||||||
Node[] links = new Node[NL * 10];
|
|
||||||
|
|
||||||
int nl = 0;
|
|
||||||
|
|
||||||
// Node[] inLinks = new Node[NL * 50]; // this can never break!
|
|
||||||
|
|
||||||
public Node(int pos, int pos2) {
|
|
||||||
super();
|
|
||||||
xPos = pos;
|
|
||||||
yPos = pos2;
|
|
||||||
}
|
|
||||||
|
|
||||||
public int axPos() {
|
|
||||||
return (int) ((xPos + roXpos + 1) * (jframe.getWidth() / (XSZ + 1)));
|
|
||||||
}
|
|
||||||
|
|
||||||
public int ayPos() {
|
|
||||||
return (int) ((yPos + roYpos + 1) * ((jframe.getHeight() - 100) / (YSZ + 1)));
|
|
||||||
}
|
|
||||||
|
|
||||||
public boolean addNeighbor(Node n) {
|
|
||||||
if (isNeighbor(n))
|
|
||||||
return false;
|
|
||||||
links[nl] = n;
|
|
||||||
nl++;
|
|
||||||
return true;
|
|
||||||
}
|
|
||||||
|
|
||||||
public boolean isNeighbor(Node n) {
|
|
||||||
for (int i = 0; i < nl; i++) {
|
|
||||||
if (links[i] == n)
|
|
||||||
return true;
|
|
||||||
}
|
|
||||||
return false;
|
|
||||||
}
|
|
||||||
|
|
||||||
public double logSum(int x, int y) {
|
|
||||||
double sum = 0;
|
|
||||||
for (int i = 0; i < nl; i++) {
|
|
||||||
Node n = links[i];
|
|
||||||
if (n.xPos == x && n.yPos == y) {
|
|
||||||
sum += Math.log(Math.abs(x - xPos) + Math.abs(y - yPos));
|
|
||||||
} else {
|
|
||||||
sum += Math
|
|
||||||
.log(Math.abs(x - n.xPos) + Math.abs(y - n.yPos));
|
|
||||||
}
|
|
||||||
}
|
|
||||||
return sum;
|
|
||||||
}
|
|
||||||
|
|
||||||
public void draw(Graphics2D g, boolean useHL) {
|
|
||||||
boolean highlight = highlightedNodes.contains(this) && useHL;
|
|
||||||
g.setColor(highlight ? Color.GREEN : Color.WHITE);
|
|
||||||
if (highlight) {
|
|
||||||
g.setStroke(new BasicStroke(2.5f));
|
|
||||||
} else {
|
|
||||||
g.setStroke(new BasicStroke(0.5f));
|
|
||||||
}
|
|
||||||
g.drawOval(axPos() - (highlight ? 4 : 2), ayPos()
|
|
||||||
- (highlight ? 4 : 2), (highlight ? 8 : 4), (highlight ? 8
|
|
||||||
: 4));
|
|
||||||
for (Node link : links) {
|
|
||||||
if (link != null) {
|
|
||||||
float dist = 0.5f + (0.5f / (float) (distance(this, link)));
|
|
||||||
g.setColor(highlight ? Color.GREEN : new Color(dist, dist, dist));
|
|
||||||
g.drawLine(axPos(), ayPos(), link.axPos(), link.ayPos());
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
Binary file not shown.
|
|
@ -1,82 +0,0 @@
|
||||||
*** Note: this talk was held in Berlin, December 2005, at the very beginning of the implementation of Darknet. It describes the algorithm behind the small-network approach which is used in the Friend-To-Friend part of the network. Currently Freenet is divided in Opennet and Darknet, the former in which one connects to peers chosen by the network, the latter in which a peer is allowed to connect only to the peers that are considered as trusted. Trust is usually established by exchanging cryptographical information between two nodes on a secure channel, whithout involving a TTP since centralization is unwanted.**
|
|
||||||
|
|
||||||
[more info](https://freenetproject.org/pages/documentation.html#understand)
|
|
||||||
|
|
||||||
# Freenet P2P network, Darknet implementation
|
|
||||||
|
|
||||||
Light P2P network: freenet, gnutella, DHT. Ability to communicate with anybody.
|
|
||||||
|
|
||||||
Dark P2P network: Waste. Only trusted connection are allowed to communicate with each other (*friend to friend network*)
|
|
||||||
|
|
||||||
## The small world phenomenon
|
|
||||||
|
|
||||||
How does a p2p network (freenet, dht) find information in a scalable, decentralized way? The small world phenomenon. Similar to the *six degree of separations* between humans, because human acquaintances form a **small world network**. Basically, information is shared (or sent, requested) only through **acquaintances**, trusted relationships.
|
|
||||||
|
|
||||||
This is a **routing algorithm in every way**: in fact, it is extremely robust since it resists to malicious attempt to *break* the routing (i.e. sending information to someone that is not known / trusted). If this happens, the routing algorithm simply **restarts**.
|
|
||||||
|
|
||||||
Problem: even though short paths exists, that does not mean that it is easy / immediate to **find** them. In the case of people, any person wanting to route a letter uses the additional information about its acquaintances to send the letter to the proper peer. In a network, this can be translated to a concept of **similarity** between the nodes / peers (**closeness**).
|
|
||||||
|
|
||||||
Similar peers are **more likely to be connected to each other**. The routing algorithm translates to:
|
|
||||||
|
|
||||||
* **Which peer do I know that is closer **(more similar)** to the peer I'm trying to reach?** [**Greedy routing**]
|
|
||||||
|
|
||||||
## The Dark Network
|
|
||||||
|
|
||||||
A dark network such as freenet's **DarkNet** *(note that freenet is divided between Opennet and Darknet)* requires a routiing algorithm similar to the small world network one described above.
|
|
||||||
To do that, there must be a way of accessing information on the network. In the old freenet, every address is accessible to anybody. Just like for the Internet, there must be a routing way. In the Internet, there's the hyerarchical system of IP addresses, planned, assinged properly, but in freenet every address and information is not organized but chaotically distributed, not existing an entity that manages the assignment of addresses (that would mean centralization).
|
|
||||||
The ability to send a message on a network from two arbitrarely distant nodes is essential.
|
|
||||||
|
|
||||||
Jon Kleinberg in 2000 explained how small world networks can be navigable. He explained that, in order for the small world phenomenon to occour, there must be an essential property:
|
|
||||||
|
|
||||||
* **The effectiveness of routing in small world network depends on the proportion of connections that have different length with respect to the position of the nodes.** In small worlds, this means that there are connections of different lengths that can be seen as nodes **closer or further**. We could take long steps, but usually short steps are preferred, since **once we get close to somebody, there's a higher chance of them knowing the person that they are near.** Kleinberg stated that, for this to be working properly:
|
|
||||||
|
|
||||||
* **The proportions of connections with a certain length should be inverse to its length.**. In this case, a simple *greedy* routing algorithm performs in O((log(n))^2) steps.
|
|
||||||
|
|
||||||
This means: few long connections, and many short ones, and the longer the connection the less likely to occour.
|
|
||||||
|
|
||||||
## Application of greedy routing
|
|
||||||
|
|
||||||
How to respond to the question: **which node is closer to the one I need to send the message to?**
|
|
||||||
This question cannot usually be answered algorithmically, and in real life people usually process a lot of information to decide the optimal solution. With nodes in a network, especially if the anonimity of the users must be preserved, one cannot decide which node is best on the base of the position and the *acquaintances* of any node.
|
|
||||||
Instead, the network is used to decide, based on the Kleinberg's model.
|
|
||||||
|
|
||||||
* Each node is assigned a **numerical identity** and is then placed in a grid, by respecting the principle of Kleinberg that states that there should be as fewer long connections as possible. This is a form of **reverse engineering** of the nodes' positions based on the connections in the network.
|
|
||||||
|
|
||||||
This must happen in a distributed, decentralized way (otherwise someone would obtain info on all the nodes, and that is unwanted). The algorithm is explained below.
|
|
||||||
|
|
||||||
### The algorithm (method)
|
|
||||||
|
|
||||||
1. A new node joins the network and chooses a position randomly.
|
|
||||||
2. Then it switches position with other nodes, so as to minimize the **product of the edge distances**. Note that this product represtent the **closeness** of the peers in the social space, which is embedded in their numerical identity.
|
|
||||||
|
|
||||||
In the network that is generated this way, the greedy routing algorithm works very well, allowing a peer to connect to any other in a (relatively small), finite number of steps. This unfortunately does not confirm anything regarding the **position** of the nodes with respect to each other. In fact, the nodes know who is connected to who, but there's no information regarding the closeness of a node to each other.
|
|
||||||
|
|
||||||
*(see graphical demonstration)*
|
|
||||||
|
|
||||||
The graphical demonstration shows that a greedy routing algorithm works **if and only if the nodes which are closer are likely (mean: have more probability) to know each other.** To achieve this result, the process of rearranging the nodes is compulsory.
|
|
||||||
|
|
||||||
The algorithm for node rearrangement is **fully decentralized** and implemented inside freenet. The algorithm takes a network of randomly connected nodes and gives as a result the small-world network in which the length between the nodes is inversely proportional to the number of nodes of that lenght. (that is, there are more short paths than long paths).
|
|
||||||
|
|
||||||
*(simulazione)*
|
|
||||||
|
|
||||||
## Practical concern
|
|
||||||
|
|
||||||
The algorithm described is implemented in freenet and the difficulties of getting the theory to work practically is a great deal of trouble. Problems are:
|
|
||||||
|
|
||||||
* Prevent malicious behavior (peers trying to abuse / destroy the network)
|
|
||||||
* Ensuring ease of use (especially since freenet works best if there are more people using it).
|
|
||||||
* Storing data (which is actually done on the user's hard drive).
|
|
||||||
|
|
||||||
### Prevent malicious behavior
|
|
||||||
|
|
||||||
If one could choose his identity, he could influence which data is sent / received from his node. This poses the treat of **centralization** of some nodes regarding some pieces of information. Defense against this kind of attack is not 100% ensured *(CHECK)*
|
|
||||||
|
|
||||||
Other treats are manipulation of other peers' nodes and of the routing algorithm itself. *(CHECK)*
|
|
||||||
|
|
||||||
### Ensure ease of use
|
|
||||||
|
|
||||||
* One of the best ways is to leave the program running in background, to mantain a connection. This is not always feasible *(CHECK)*.
|
|
||||||
* Peer introduction is one of the most difficult aspects: exchanging cryptographic information between nodes to ensure trust is a complicate and delicate process. To ease this aspect, a copy-paste approach can be used, or email messages, or whatever communication channel one sees as secure. The easier way would be a TTP, but again **centralization is unwanted**. *(CHECK)*
|
|
||||||
* NAT/Firewalls are complex enemies of P2P networks, but that could be circumvented (expecially with UDP hole-punching (same as for Skype, Dijjer). Note that this technique requires a third party, but that could be represented by **any node in the network that's not behind firewalls or NAT.**
|
|
||||||
|
|
||||||
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
|
|
@ -1,471 +0,0 @@
|
||||||
<!--DIRECTIVES-->
|
|
||||||
<!--
|
|
||||||
$theme: gaia
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# Freenet
|
|
||||||
---
|
|
||||||
|
|
||||||
<!--page_number: true-->
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
|
|
||||||
## Cos'è Freenet?
|
|
||||||
|
|
||||||
Freenet è una **rete peer-to-peer decentralizzata**, progettata per:
|
|
||||||
* Resistere alla censura
|
|
||||||
* Proteggere l'**anonimato**
|
|
||||||
* Rispettare la libertà di espressione
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Cenni Storici
|
|
||||||
|
|
||||||
* Fondazione: **paper** di Ian Clarke, 2001
|
|
||||||
|
|
||||||
Il paper contiene le basi del protocollo Freenet, tuttora in sviluppo continuo.
|
|
||||||
|
|
||||||
Dal 2008 [**Freenet 0.7**] è divisa in **Opennet** e **Darknet**, supporta l'implementazione **open source** di JDK [**OpenJDK**] e supporta sia su TCP che su UDP a livello di trasporto.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Punti Chiave
|
|
||||||
|
|
||||||
* Anonimato per **produttori e consumatori** di informazioni
|
|
||||||
* **Resistenza** a tentativi di terze parti di **negare accesso** ai contenuti
|
|
||||||
* Proteggere l' **anonimità dei dati salvati nei nodi**
|
|
||||||
* Implementare **archiviazione e routing** in maniera **dinamica** ed **efficiente**
|
|
||||||
* **Decentralizzare** tutte le funzioni della rete
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: default
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
# Architettura
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
|
|
||||||
## Freenet = Rete di Nodi
|
|
||||||
|
|
||||||
Freenet è un network P2P **adattivo**, costituito da nodi che effettuano richieste ad altri nodi per salvare e ottenere **data files**.
|
|
||||||
* Tutti i nodi sono **uguali** e comunicano **solo con i nodi prossimi**
|
|
||||||
* Ogni nodo mantiene uno **spazio di archiviazione locale** che **condivide** con gli altri nodi
|
|
||||||
* I data files sono indicizzati da **chiavi indipendenti dalla localizzazione** *[location-independent keys]*
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Indirizzi
|
|
||||||
|
|
||||||
Gli indirizzi dei nodi sono composti da:
|
|
||||||
|
|
||||||
* Metodo di trasporto
|
|
||||||
* Identificatore di trasporto specifico *[IP + porta]*
|
|
||||||
|
|
||||||
Anonimato e modifica di indirizzi si ottengono con le **Address Resolution Keys** (o **Updatable Subspace Keys**), contenenti l'**indirizzo corrente** del nodo.
|
|
||||||
Le ARK permettono di superare alcuni firewalls, NAT e blocchi su IP.
|
|
||||||
|
|
||||||
USK@<...key...>/path/to/webpage
|
|
||||||
---
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Richieste
|
|
||||||
|
|
||||||
* Richiesta = **payload di un self-contained message**
|
|
||||||
* Richiesta = **Ricerca di una chiave**
|
|
||||||
corrispondente al data file da ottenere tra i nodi della rete. *[Key-Based Routing]*
|
|
||||||
|
|
||||||
La procedura di richiesta avviene come una
|
|
||||||
**catena di proxy requests** divisa in step.
|
|
||||||
|
|
||||||
Ogni nodo **decide dove indirizzare la richiesta** durante lo step successivo.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Struttura di un messaggio
|
|
||||||
|
|
||||||
* **ID** pseudo-unico e **casuale**, che permette ai nodi di evitare i loop di richieste.
|
|
||||||
* Numero di **Hops-To-Live** *[HTL]*, simili al Time-To-Live di IP ma basati sul numero di hop. Servono ad **evitare catene di richieste infinite**.
|
|
||||||
* **Profondità**, incrementata ad ogni hop.
|
|
||||||
* **Payload** della richiesta / risposta.
|
|
||||||
|
|
||||||
Il processo di passaggio delle richieste continua finchè la richiesta non è soddisfatta o gli HTL si esauriscono.
|
|
||||||
|
|
||||||
---
|
|
||||||
## Struttura di un messaggio
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!--
|
|
||||||
template: default
|
|
||||||
-->
|
|
||||||
|
|
||||||
# Key-Based
|
|
||||||
# Routing
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
## Chiavi e Ricerche
|
|
||||||
|
|
||||||
In Freenet, i files sono identificati da **chiavi binarie**:
|
|
||||||
|
|
||||||
* **Keyword-Signed-Key** *[KSK]*
|
|
||||||
* **Signed-Subspace-Key** *[SSK]*
|
|
||||||
* **Content-Hash-Key** *[CHK]*
|
|
||||||
|
|
||||||
Le chiavi sono ottenute utilizzando funzioni di hash tra cui *DSA* e *SHA*.
|
|
||||||
|
|
||||||
---
|
|
||||||
## Keyword Signed Key
|
|
||||||
|
|
||||||
La chiave più basica utilizzata da Freenet, derivata da **una stringa di testo scelta dall'utente** al momento del **file upload** in rete.
|
|
||||||
|
|
||||||
La stringa è usata come input per ottenere una **coppia di chiavi asimmetriche**, di cui:
|
|
||||||
|
|
||||||
* La **pubblica** viene passata alla funzione di hash, ottenendo la **file key**
|
|
||||||
* La **privata** è utilizzata per firmare il file, provvedendo un **minimo controllo di integrità**.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### KSK
|
|
||||||
#### Analisi
|
|
||||||
|
|
||||||
* Un sistema simile è soggetto a **dictionary attacks** contro la chiave privata, dato che **ogni nodo può ottenere una lista di stringhe descrittive**.
|
|
||||||
|
|
||||||
Per questo il file è anche cifrato utilizzando la stringa descrittiva come chiave.
|
|
||||||
|
|
||||||
* Le chiavi KSK **non sono uniche**, per questo motivo **sono state abbandonate** in funzione delle SSK.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Signed Subspace Key
|
|
||||||
|
|
||||||
Evoluzione di KSK.
|
|
||||||
|
|
||||||
* Abilita i **personal namespaces**, identificati da una **coppia di chiavi asimmetriche**
|
|
||||||
* Stringa descrittiva e chiave pubblica del namespace sono passate alla funzione di hash **indipendentemente**
|
|
||||||
* Sui due hash ottenuti: **bit-by-bit XOR** -> **file key**
|
|
||||||
* La chiave privata è utilizzata per firmare il file
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
### SSK
|
|
||||||
#### Analisi
|
|
||||||
|
|
||||||
* Migliora KSK in quanto **la file key è generata da una coppia di chiavi casuali**
|
|
||||||
|
|
||||||
Per ottenere un file, un nodo deve conoscere:
|
|
||||||
* Stringa descrittiva
|
|
||||||
* Public Subspace Key
|
|
||||||
|
|
||||||
In aggiunta, ogni utente ha un **namespace** unico e gestibile.
|
|
||||||
|
|
||||||
---
|
|
||||||
## Content Hask Key
|
|
||||||
|
|
||||||
Hash diretto del file, ottenendo una
|
|
||||||
**file key pseudo-unica**.
|
|
||||||
|
|
||||||
I file sono successivamente cifrati con una ***encryption key*** generata casualmente.
|
|
||||||
|
|
||||||
Per ottenere il file sono necessarie sia la file key che l'*encryption key*, che **non è mai salvata col file** ma solo pubblicata con la sua file key.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Updatable Subspace Key
|
|
||||||
|
|
||||||
Le chiavi CHK sono utilizzate **in parallelo** con le SSK, per implementare l'**indirezione**:
|
|
||||||
|
|
||||||
* Inserire il file sotto la sua CHK
|
|
||||||
* Inserire la CHK in un **file indiretto** contenuto in una SSK
|
|
||||||
* La **file key** è ottenuta in due step.
|
|
||||||
|
|
||||||
Questo permette l'**update** dei files caricati, mantenendo la stessa SSK.
|
|
||||||
|
|
||||||
CHK + SSK = USK
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!--
|
|
||||||
template: default
|
|
||||||
-->
|
|
||||||
|
|
||||||
# Decentralized
|
|
||||||
# Data
|
|
||||||
# Storage
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
|
|
||||||
## Gestione dei dati salvati
|
|
||||||
|
|
||||||
**Ogni nodo della rete condivide spazio locale**.
|
|
||||||
|
|
||||||
* Gestito come una **cache LRU**
|
|
||||||
*[Least Recently Used cache]*
|
|
||||||
* Contiene **dati** e **routing table** del nodo
|
|
||||||
* L'utente **non ha accesso diretto** ai file contenuti nel suo spazio locale *[data encryption]*
|
|
||||||
* La quantità di spazio condiviso è configurabile dall'utente
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## LRU Cache
|
|
||||||
|
|
||||||
La **Least Recently Used** cache ordina i dati contenuti in base all'**ordine temporale decrescente** di ricevimento delle **richieste**. *[insert,retrieve,update]*
|
|
||||||
|
|
||||||
Questo significa che:
|
|
||||||
* I files **più richiesti** sono in cima alla coda.
|
|
||||||
* Se la capacità non è sufficiente per contenere un nuovo file, i file usati **meno recentemente** sono cancellati.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### LRU Cache - Esempio
|
|
||||||
|
|
||||||
La sequenza di accesso è *A,B,C,D,E,F*.
|
|
||||||
Il **rank** *[priorità]* dei files è il numero in parentesi.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### LRU Cache: Note
|
|
||||||
|
|
||||||
* La cancellazione dei files utilizzati meno recentemente potrebbe rendere alcuni dati **non disponibili**
|
|
||||||
|
|
||||||
Per questo **le entry nella routing table** corrispondenti ai dati cancellati rimangono anche dopo la cancellazione.
|
|
||||||
|
|
||||||
* Il meccanismo di ***scadenza*** dei dati causa l'**aggiornamento** dei files vecchi, rimpiazzandoli con le nuove versioni in automatico.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Data Encryption
|
|
||||||
|
|
||||||
È necessario che gli operatori dei nodi **non possano accedere** ai dati contenuti nello spazio locale.
|
|
||||||
|
|
||||||
Questo è garantito dalla **cifratura** dei files.
|
|
||||||
|
|
||||||
* I files sono divisi in **blocchi** distribuiti a diversi nodi
|
|
||||||
* È possibile conoscere la **file key** ma non la **encryption key** a priori
|
|
||||||
|
|
||||||
Questo consente la **plausible deniability** per gli operatori dei nodi.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ottenere un File
|
|
||||||
|
|
||||||
Utente manda la **file key** al proprio nodo. Ogni nodo, ricevuta una richiesta, controlla se la chiave è presente nel suo spazio locale.
|
|
||||||
|
|
||||||
* **No**: *forward* della richiesta al nodo contenente
|
|
||||||
**la chiave più vicina a quella cercata** della sua forwarding table
|
|
||||||
* **Sì**: **success**, file mandato ai nodi upstream, ognuno dei quali fa **caching** di esso.
|
|
||||||
* **HTL expired**: **failure** propagato verso l'upstream, la ricerca si ferma
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ottenere un file
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ottenere un file: Note
|
|
||||||
|
|
||||||
* Una richiesta successiva per lo stesso file **può essere soddisfatta dai nodi che hanno fatto caching**
|
|
||||||
* La forwarding table non deve diventare un elenco di file sorgenti:
|
|
||||||
Ogni nodo può decidere **arbitrariamente** di proclamarsi sorgente
|
|
||||||
* Se un nodo non può soddisfare una richiesta: messaggio di **failure** nella reply, il nodo upstream proverà con il secondo nodo più vicino *[backtracking]*
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ottenere un file: Note
|
|
||||||
|
|
||||||
* La qualità del routing **migliora nel tempo**, dato che i nodi si specializzano nel localizzare
|
|
||||||
**set di chiavi simili**, e salvarli in **cluster**
|
|
||||||
* Il meccanismo **replica in maniera trasparente dati popolari** vicino ai nodi che li richiedono
|
|
||||||
* Un nodo che risponde con successo a più richieste riesce a scoprire una **maggiore parte della rete** (ma gli altri nodi non lo contattano più facilmente)
|
|
||||||
|
|
||||||
---
|
|
||||||
## Ottenere un file
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
# Small World
|
|
||||||
# Network
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
|
|
||||||
## Opennet e Darknet
|
|
||||||
|
|
||||||
Si può discriminare tra 2 tipi di reti P2P:
|
|
||||||
|
|
||||||
* **Light**: comunicazione con qualunque nodo
|
|
||||||
*[Gnutella, Distributed Hash Tables, Opennet]*
|
|
||||||
|
|
||||||
* **Dark**: comunicazione sono con nodi **fidati** il cui indirizzo è conosciuto a priori.
|
|
||||||
*[Friend-to-friend network: Waste, Darknet]*
|
|
||||||
|
|
||||||
Freenet è diviso in **Opennet** e **Darknet**, implementazioni light P2P e dark P2P del protocollo.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
## Il fenomeno del mondo piccolo
|
|
||||||
|
|
||||||
Identifica un network i cui nodi condividono le informazioni **solo con altri nodi conosciuti**. *[fidati]*
|
|
||||||
|
|
||||||
Simile al principio dei **sei gradi di separazione** tra esseri umani, ma:
|
|
||||||
|
|
||||||
* In una rete di nodi la conoscenza è tradotta come vicinanza o similarità *[closeness]*.
|
|
||||||
|
|
||||||
**In uno Small World Network, peer simili hanno maggiore probabilità di essere connessi**.
|
|
||||||
|
|
||||||
---
|
|
||||||
## SWN Routing
|
|
||||||
|
|
||||||
* Peer vicini hanno maggiore probabilità di essere connessi
|
|
||||||
|
|
||||||
* Applicazione del **Greedy Routing:** è possibile comunicare con qualunque peer mandando i messaggi **al peer più vicino**, ogni step.
|
|
||||||
|
|
||||||
Questo principio è utilizzato sia da DHT che da Freenet per fare routing dei pacchetti.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Il principio di Kleinberg
|
|
||||||
|
|
||||||
*L'efficacia del routing negli Small World Network dipende dalla proporzione tra le connessioni che hanno diversa lunghezza e la posizione dei nodi.* *[John Kleinberg, 2000]*
|
|
||||||
|
|
||||||
Significa:
|
|
||||||
**Il numero di connessioni con determinata lunghezza deve essere inversamente proporzionale alla lunghezza delle stesse**.
|
|
||||||
|
|
||||||
Permette:
|
|
||||||
Complessità dell'algoritmo greedy $O(\log^2N)$
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Posizione e Closeness
|
|
||||||
|
|
||||||
La posizione dei nodi **non può essere determinata direttamente** in un network anonimo come Darknet.
|
|
||||||
|
|
||||||
* Non si conoscono gli **indirizzi** dei nodi
|
|
||||||
* Non si conoscono le ***trusted connections*** dei nodi
|
|
||||||
* Le informazioni contenute dai nodi sono distribuite **caoticamente**, non essendoci un'autorità che assegna gli indirizzi.
|
|
||||||
|
|
||||||
Come si determina **quale nodo è più vicino al peer che devo contattare?**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ottimizzazione del Network
|
|
||||||
|
|
||||||
|
|
||||||
* Assegnare ID numerici **unici** e **casuali** ai nodi
|
|
||||||
* Posizionarli **casualmente** in un grafo, connettendoli alle loro ***trusted connections***
|
|
||||||
|
|
||||||
È un **reverse engineering** delle posizioni dei nodi in base alla loro connessioni. Fatto ciò:
|
|
||||||
|
|
||||||
* Ogni nodo **scambia la propria posizione con gli altri**, di modo da **minimizzare il prodotto delle lunghezze** degli edge del grafo *[connessioni]*
|
|
||||||
|
|
||||||
**La rete determina la miglior posizione dei nodi.**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SWN: Conclusioni
|
|
||||||
|
|
||||||
* La rete ottimizza le posizioni dei nodi di modo da minimizzare la lunghezza delle connessioni
|
|
||||||
* La rete così generata permette di raggiungere **qualunque peer** in un numero ragionevole di steps
|
|
||||||
* La **vicinanza** tra peer è il **prodotto della lunghezza degli edge del grafo**
|
|
||||||
* L'algoritmo di routing Greedy funziona **se e solo se i nodi vicini hanno più probabilità di conoscersi**. Questo rende l'ottimizzazione del network necessaria.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SWN: Simulazione
|
|
||||||
|
|
||||||
Si è simulata uno Small World Network con 3 algoritmi di ricerca:
|
|
||||||
|
|
||||||
* **Random** tra i nodi *[Random]*
|
|
||||||
* **Ideal Greedy Routing** (Kleinberg), i nodi sono già disposti in maniera ottima *[Good]*
|
|
||||||
* **Restored Greedy Routing**, i nodi sono riordinati da Darknet (2000 iterazioni per nodo). *[Restored]*
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
*Numero di ricerche **successful** in $log_2^2N$ steps*.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
*La lunghezza media delle **successful routes***.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!--
|
|
||||||
template: default
|
|
||||||
-->
|
|
||||||
|
|
||||||
# Conclusioni
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: invert
|
|
||||||
-->
|
|
||||||
## Confronto di protocolli P2P
|
|
||||||
|
|
||||||
Freenet non è l'unico protocollo che tenta di proteggere l'anonimato dei suoi utenti.
|
|
||||||
|
|
||||||
A livello di userbase e maturità di progetto, si notano:
|
|
||||||
|
|
||||||
* **Tor**, basato sull'**Onion routing**
|
|
||||||
* **I2P**, basato sul **Garlic routing**
|
|
||||||
(variante dell'Onion routing)
|
|
||||||
|
|
||||||
Entrambi si identificano piu' come **proxy** che come rete decentralizzata, a differenza di Freenet.
|
|
||||||
|
|
||||||
---
|
|
||||||
## Freenet e Tor
|
|
||||||
|
|
||||||
||Freenet|Tor|
|
|
||||||
|:-:|:-:|:-|
|
|
||||||
|**Protocollo decentralizzato** |Sì |No\* |
|
|
||||||
|**Accesso a Internet (proxy)** |No |Sì|
|
|
||||||
|**Accesso a webserver anonimi** |No |Sì |
|
|
||||||
|**Salvataggio distribuito dei dati** |Sì |No |
|
|
||||||
|**Impossibilità di rimuovere i dati** |Sì |No |
|
|
||||||
|**È stato bloccato con successo** |No\*\*|Sì |
|
|
||||||
|
|
||||||
|
|
||||||
\* Tor necessita di una *directory authority* che gestisca gli *hidden services [webserver anonimi]*.
|
|
||||||
\*\* Relativo a Darknet
|
|
||||||
|
|
||||||
---
|
|
||||||
<!--
|
|
||||||
template: default
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
# Grazie per l'attenzione
|
|
||||||
|
|
||||||
|
|
||||||
Binary file not shown.
|
|
@ -1,353 +0,0 @@
|
||||||
@freenetlogo.png
|
|
||||||
|
|
||||||
Cos'è Freenet?
|
|
||||||
|
|
||||||
Freenet:
|
|
||||||
• Rete peer-to-peer decentralizzata
|
|
||||||
• Protocollo di rete
|
|
||||||
|
|
||||||
Perchè Freenet?
|
|
||||||
• Rispettare la libertà di espressione
|
|
||||||
• Resistere alla censura
|
|
||||||
• Proteggere l'anonimato
|
|
||||||
|
|
||||||
# --- cenni storici, decidere se tenere tutto o tagliare
|
|
||||||
|
|
||||||
Cenni Storici
|
|
||||||
|
|
||||||
• Ideata da Ian Clarke nel 1999
|
|
||||||
• Fondazione nel 2001, paper di Clarke
|
|
||||||
• Nel paper, le basi di Freenet
|
|
||||||
|
|
||||||
Anonimato
|
|
||||||
→ Decentralizzazione
|
|
||||||
|
|
||||||
Idea:
|
|
||||||
• Dividere i dati in blocchi
|
|
||||||
• Cifrarli
|
|
||||||
• Distribuirli a tutti nodi della rete
|
|
||||||
|
|
||||||
Risultato:
|
|
||||||
• Nodi formano una cache distribuita
|
|
||||||
• Impossibile il client-server
|
|
||||||
|
|
||||||
Dal 2001: sviluppo continuo
|
|
||||||
• Cross-Platform
|
|
||||||
• Implementazione in Java
|
|
||||||
• Necessita solo di una JVM
|
|
||||||
|
|
||||||
2008: Freenet 0.7
|
|
||||||
• Riscrittura estensiva
|
|
||||||
• Opennet
|
|
||||||
• Darknet
|
|
||||||
# espandere il punto su TCP, magari togliere da qui e parlarne alla fine
|
|
||||||
• Supporta TCP e UDP
|
|
||||||
|
|
||||||
Stato attuale:
|
|
||||||
• FProxy: interfaccia web
|
|
||||||
• Supporto a OpenJDK
|
|
||||||
|
|
||||||
# --- Fine cenni storici, inizio architettura
|
|
||||||
|
|
||||||
Architettura
|
|
||||||
|
|
||||||
Freenet
|
|
||||||
→ Rete di nodi
|
|
||||||
|
|
||||||
Tutti i nodi sono uguali
|
|
||||||
• No gerarchie
|
|
||||||
• No central points of failure
|
|
||||||
|
|
||||||
Contenuti:
|
|
||||||
associati a chiavi
|
|
||||||
→ Key Based Routing
|
|
||||||
|
|
||||||
Storage:
|
|
||||||
condiviso in rete
|
|
||||||
→ Decentralized Storage
|
|
||||||
|
|
||||||
Comunicazione:
|
|
||||||
solo con nodi vicini
|
|
||||||
→ Small World Network
|
|
||||||
|
|
||||||
# --- KBR
|
|
||||||
Key
|
|
||||||
Based
|
|
||||||
Routing
|
|
||||||
|
|
||||||
Tre tipi di chiavi:
|
|
||||||
• KSK (Keyword Signed Key)
|
|
||||||
• SSK (Subspace Signed Key)
|
|
||||||
• CHK (Content Hash Key)
|
|
||||||
|
|
||||||
Le chiavi sono ottenute
|
|
||||||
applicando hash functions
|
|
||||||
(DSA, SHA256)
|
|
||||||
|
|
||||||
KSK non più utilizzata
|
|
||||||
(poco sicura)
|
|
||||||
|
|
||||||
SSK (DSA):
|
|
||||||
• Chiave asimmetrica (Pub/Priv)
|
|
||||||
• Indentifica un namespace
|
|
||||||
|
|
||||||
Un namespace
|
|
||||||
→ Un utente
|
|
||||||
|
|
||||||
Files associati a:
|
|
||||||
• Stringa descrittiva
|
|
||||||
• Namespace dell'uploader
|
|
||||||
|
|
||||||
SSK:
|
|
||||||
Sequenza di cifratura
|
|
||||||
1. Hash (pubkey)
|
|
||||||
2. Hash (descrizione)
|
|
||||||
3. XOR tra i due hash,
|
|
||||||
4. Hash (result)
|
|
||||||
5. Firma del file (chiave privata)
|
|
||||||
→ Risultato: File Key
|
|
||||||
|
|
||||||
CHK (SHA256):
|
|
||||||
• Hash diretto del file
|
|
||||||
• Chiave pseudo-unica
|
|
||||||
• Utili per file statici
|
|
||||||
(pdf, mp3, ...)
|
|
||||||
|
|
||||||
Upload
|
|
||||||
di Files
|
|
||||||
|
|
||||||
Un utente rende pubbliche:
|
|
||||||
• Stringa descrittiva
|
|
||||||
• Public namespace key
|
|
||||||
|
|
||||||
File caricati
|
|
||||||
→ Immutabili
|
|
||||||
|
|
||||||
Update tramite indirezione:
|
|
||||||
→ Sia CHK che SSK
|
|
||||||
|
|
||||||
Indirezione:
|
|
||||||
• File inserito sotto CHK
|
|
||||||
• CHK salvata in un file indiretto
|
|
||||||
• File indiretto inserito sotto SSK
|
|
||||||
|
|
||||||
Indirezione:
|
|
||||||
Ottenere un file
|
|
||||||
|
|
||||||
Il file viene ottenuto in due step:
|
|
||||||
1. SSK → CHK
|
|
||||||
2. CHK → File
|
|
||||||
|
|
||||||
Routing
|
|
||||||
|
|
||||||
Routing Table:
|
|
||||||
(Forwarding Table)
|
|
||||||
• Salvata in ogni nodo
|
|
||||||
• Associa chiavi e nodi
|
|
||||||
• Permette routing dinamico
|
|
||||||
|
|
||||||
Richieste
|
|
||||||
|
|
||||||
Una richiesta e' formata da:
|
|
||||||
• Hops-To-Live (HTL)
|
|
||||||
• ID pseudo-unico, casuale
|
|
||||||
|
|
||||||
Passaggio delle richieste:
|
|
||||||
catena di Proxy Requests
|
|
||||||
|
|
||||||
Ogni nodo decide
|
|
||||||
dove indirizzare la richiesta
|
|
||||||
(simile a IP)
|
|
||||||
|
|
||||||
Invio di una richiesta:
|
|
||||||
(utente)
|
|
||||||
1. Ottieni File Key
|
|
||||||
2. Invia richiesta al nodo
|
|
||||||
|
|
||||||
Ricezione di una richiesta:
|
|
||||||
(nodo)
|
|
||||||
1. File presente in storage?
|
|
||||||
Si: ritorna risultato all'upstream
|
|
||||||
No: forward della richiesta
|
|
||||||
|
|
||||||
Request Forwarding
|
|
||||||
• Richiesta mandata
|
|
||||||
al nodo piu' vicino
|
|
||||||
a quello cercato
|
|
||||||
|
|
||||||
Vicinanza:
|
|
||||||
• Distanza lessicografica
|
|
||||||
dalla File Key cercata
|
|
||||||
|
|
||||||
@./friends-nodes.png
|
|
||||||
|
|
||||||
Nodo piu' vicino
|
|
||||||
→ Nodo contenente
|
|
||||||
la chiave piu' vicina
|
|
||||||
a quella cercata
|
|
||||||
|
|
||||||
Risultato di una richiesta:
|
|
||||||
• Data not found / HTL expired
|
|
||||||
→ failure
|
|
||||||
• Data found
|
|
||||||
→ success
|
|
||||||
→ data cached
|
|
||||||
(per ogni nodo)
|
|
||||||
|
|
||||||
Il risultato e' restituito
|
|
||||||
lungo la catena di nodi
|
|
||||||
che ha mandato la richiesta
|
|
||||||
(Upstream)
|
|
||||||
|
|
||||||
@./requestseq.png
|
|
||||||
|
|
||||||
# -------------------------- Routing Adattivo
|
|
||||||
Analisi:
|
|
||||||
Routing Adattivo
|
|
||||||
|
|
||||||
Routing Adattivo:
|
|
||||||
• Richieste per
|
|
||||||
chiavi vicine
|
|
||||||
mandate verso
|
|
||||||
stessi nodi
|
|
||||||
|
|
||||||
Routing Adattivo:
|
|
||||||
• Replica trasparente
|
|
||||||
di dati piu' richiesti
|
|
||||||
|
|
||||||
Routing adattivo:
|
|
||||||
• Favorisce i nodi
|
|
||||||
che rispondono con successo
|
|
||||||
a piu' richieste,
|
|
||||||
guadagnando entry
|
|
||||||
nella Forwarding Table
|
|
||||||
|
|
||||||
Routing adattivo:
|
|
||||||
• Si creano link diretti
|
|
||||||
alle sorgenti dei dati
|
|
||||||
|
|
||||||
# ----------------------- DDS
|
|
||||||
Decentralized
|
|
||||||
Data
|
|
||||||
Storage
|
|
||||||
|
|
||||||
Ogni nodo
|
|
||||||
condivide
|
|
||||||
spazio locale
|
|
||||||
|
|
||||||
Lo spazio condiviso
|
|
||||||
e' dedicato esclusivamente
|
|
||||||
al data storage
|
|
||||||
|
|
||||||
Local storage
|
|
||||||
→ LRU Cache
|
|
||||||
(Least Recently Used)
|
|
||||||
|
|
||||||
LRU Cache:
|
|
||||||
• Ordina i dati salvati
|
|
||||||
in maniera decrescente
|
|
||||||
in base al ricevimento
|
|
||||||
delle richieste
|
|
||||||
|
|
||||||
Significa:
|
|
||||||
• I file piu' richiesti
|
|
||||||
in cima alla lista
|
|
||||||
|
|
||||||
Problema:
|
|
||||||
Come gestire una cache piena?
|
|
||||||
|
|
||||||
Soluzione:
|
|
||||||
• Drop-Tail approach
|
|
||||||
|
|
||||||
Drop-Tail:
|
|
||||||
• Files meno richiesti
|
|
||||||
eliminati dallo storage,
|
|
||||||
• Entry corrispondenti
|
|
||||||
rimangono nella
|
|
||||||
Forwarding Table
|
|
||||||
|
|
||||||
Mantenere le entry
|
|
||||||
→ Evitare la perdita
|
|
||||||
di file poco richiesti
|
|
||||||
(Probabilita' che vengano
|
|
||||||
salvati in cache di nuovo)
|
|
||||||
|
|
||||||
Vantaggi:
|
|
||||||
• Performance migliora
|
|
||||||
nel tempo
|
|
||||||
• Update di files
|
|
||||||
trasparente
|
|
||||||
|
|
||||||
File Update:
|
|
||||||
• Files "vecchi" rimpiazzati da
|
|
||||||
files aggiornati in automatico
|
|
||||||
• Files "vecchi" ma ancora in uso
|
|
||||||
sono preservati dalle richieste
|
|
||||||
|
|
||||||
Data
|
|
||||||
Encryption
|
|
||||||
|
|
||||||
Necessita':
|
|
||||||
• Operatori di nodi
|
|
||||||
non devono conoscere
|
|
||||||
i dati salvati
|
|
||||||
|
|
||||||
Soluzione:
|
|
||||||
File Encryption
|
|
||||||
|
|
||||||
File Encryption:
|
|
||||||
• Utilizza chiavi (SSK, CHK)
|
|
||||||
• Utente puo' conoscere solo la File Key
|
|
||||||
(Invertire l'hash e' complesso)
|
|
||||||
• Dictionary attack puo' avere successo
|
|
||||||
ma e' estremamente costoso
|
|
||||||
|
|
||||||
Freenet:
|
|
||||||
Protocollo
|
|
||||||
|
|
||||||
Protocollo:
|
|
||||||
• P2P adattivo
|
|
||||||
(rete di nodi)
|
|
||||||
• Packet-oriented
|
|
||||||
• Self-contained
|
|
||||||
messages
|
|
||||||
|
|
||||||
Ogni messaggio
|
|
||||||
contiene un ID
|
|
||||||
della transazione
|
|
||||||
→ Insert, request
|
|
||||||
sono tracciabili
|
|
||||||
|
|
||||||
Trasporto:
|
|
||||||
Grande flessibilita',
|
|
||||||
principalmente:
|
|
||||||
• TCP
|
|
||||||
• UDP
|
|
||||||
|
|
||||||
I nodi che utilizzano
|
|
||||||
connessioni persistenti
|
|
||||||
(TCP)
|
|
||||||
possono mandare
|
|
||||||
piu' di un messaggio
|
|
||||||
sulla stessa connessione
|
|
||||||
|
|
||||||
Naming Prefix:
|
|
||||||
Utilizza ARK
|
|
||||||
(Address Resolution Keys)
|
|
||||||
• Chiavi SSK
|
|
||||||
aggiornate all'indirizzo
|
|
||||||
corrente del nodo
|
|
||||||
(semplifica la mobilita')
|
|
||||||
|
|
||||||
# ----------------------- SWN
|
|
||||||
|
|
||||||
Small
|
|
||||||
World
|
|
||||||
Network
|
|
||||||
|
|
||||||
Il mondo è piccolo
|
|
||||||
|
|
||||||
@./darknet_peers.png
|
|
||||||
|
|
||||||
|
|
||||||
?
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 954 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
|
|
@ -1,237 +0,0 @@
|
||||||
# Freenet - Seminario
|
|
||||||
|
|
||||||
* [Introduzione a Freenet](#1---introduzione-a-freenet)
|
|
||||||
* [Cenni storici](#cenni-storici)
|
|
||||||
* [Design Goals](#design-goals)
|
|
||||||
* [Architettura di Freenet](#architettura-di-freenet)
|
|
||||||
* [Modello di funzionamento](#modello-di-funzionamento)
|
|
||||||
* [Chiavi e ricerche](#chiavi-e-ricerche-2)
|
|
||||||
* [Ottenere un file](#ottenere-un-file)
|
|
||||||
* [Note riguardo al processo di ricerca di un file](#note-riguardo-al-processo-di-ricerca-di-un-file)
|
|
||||||
* [Decentralized data storage](#decentralized-data-storage-3)
|
|
||||||
* [Inserimento di dati (files)](#inserimento-di-dati-files)
|
|
||||||
* [Data management](#data-management)
|
|
||||||
* [Data encryption](#data-encryption)
|
|
||||||
* [Dettagli sul protocollo](#dettagli-sul-protocollo)
|
|
||||||
* [Small World Network](#small-world-network-4)
|
|
||||||
* [Darknet implementation](#darknet-implementation)
|
|
||||||
* [Il fenomeno del mondo piccolo (Small World Phenomenon)](#il-fenomeno-del-mondo-piccolo-small-world-phenomenon)
|
|
||||||
* [Il Dark Network](#il-dark-network)
|
|
||||||
* [Applicazione del Greedy Routing](#applicazione-del-greedy-routing)
|
|
||||||
* [L'algoritmo Greedy](#lalgoritmo-greedy)
|
|
||||||
* [Bibliografia](#bibliografia)
|
|
||||||
|
|
||||||
## Introduzione a Freenet
|
|
||||||
|
|
||||||
Freenet è una rete peer-to-peer decentralizzata, progettata per resistere alla censura. L'obbiettivo primario di Freenet è quello di costruire una rete in cui sia rispettata la libertà di parola ed espressione tramite una forte preservazione dell'anonimato.
|
|
||||||
|
|
||||||
### Cenni storici
|
|
||||||
|
|
||||||
Freenet è stato ideato da Ian Clarke nel 1999, a seguito di un progetto studentesco all'Università di Edinburgo.
|
|
||||||
Nel 2001, Clarke e altri ricercatori hanno posto le basi del progetto con un paper intitolato *"Freenet: A Distributed Anonymous Information Storage and Retrieval System"* , nel quale teorizzano un modello di anonimato in Internet ottenuto distribuendo blocchi di contenuto di piccole dimensioni, cifrati, su tutti i nodi della rete.
|
|
||||||
Da allora, il progetto Freenet è in continuo sviluppo. Freenet è scritto in Java, di modo da essere compatibile con qualunque sistema in grado di hostare una JVM.
|
|
||||||
Dal 2011, Freenet supporta OpenJDK, un'implementazione open source della piattaforma Java.
|
|
||||||
|
|
||||||
### Design Goals
|
|
||||||
|
|
||||||
Nel paper del 2001 vengono identificati 5 obbiettivi principali della rete:
|
|
||||||
* Anonimato per i produttori e i consumatori di informazioni
|
|
||||||
* Storage deniability
|
|
||||||
* Resistenza a tentativi effettuati da terze parti di negare accesso alle informazioni
|
|
||||||
* Storage e routing delle informazioni dinamici ed efficienti
|
|
||||||
* Decentralizzazione di tutte le funzioni della rete
|
|
||||||
|
|
||||||
## Architettura di Freenet
|
|
||||||
|
|
||||||
Freenet è implementato come un network peer-to-peer **adattivo**, costituito da nodi che effettuano richieste gli uni agli altri per salvare e ottenere files di dati (*data files*). I data files sono indicizzati e nominati con **chiavi indipendenti dalla localizzazione** (*location-independent keys*).
|
|
||||||
|
|
||||||
Ogni nodo mantiene il suo data storage **locale**, che rende disponibile agli altri nodi per operazioni di **reading and writing**.
|
|
||||||
Nello storage locale dei nodi è salvata una **routing table** che contiene gli indirizzi di altri nodi e le chiavi che si crede essi contengano. Questa routing table permette di fare **routing dinamico**.
|
|
||||||
|
|
||||||
### Modello di funzionamento
|
|
||||||
|
|
||||||
Il modello di funzionamento di base è che le richieste per le chiavi siano passate da nodo a nodo, tramite una catena di **proxy requests**, in cui ogni nodo decide **dove** mandare la richiesta nel successivo step. Questo modello rassomiglia il routing IP classico.
|
|
||||||
I percorsi variano a seconda delle chiavi richieste. Gli algoritmi di routing descritti nelle sezioni successive sono progettati per adattare i percorsi nel tempo, per garantire una performance ottimale.
|
|
||||||
|
|
||||||
A ogni richiesta è assegnato:
|
|
||||||
|
|
||||||
* un numero di **hops-to-live**, simili al TTL di IP, che servono per evitare catene infinite di richieste tra i nodi,
|
|
||||||
* un identificatore pseudo-unico casuale, così che i nodi possano evitare i loop, rifiutando richieste che hanno già visto. *Nota: quando questo accade, il nodo che precede sceglie semplicemente un altro nodo a cui fare forwarding*.
|
|
||||||
|
|
||||||
Il processo di passaggio delle richieste continua finchè la richiesta non è soddisfatta o gli *hops-to-live* si esauriscono. A questo punto, il risultato (*success* o *failure*) viene mandato lungo la catena di nodi mandanti (quelli che hanno passato la richiesta).
|
|
||||||
|
|
||||||
Nessun nodo è privilegiato rispetto agli altri, quindi **non esistono gerarchie o central points of failure**. Per entrare nel network, è sufficiente scoprire gli indirizzi di uno o più nodi, tramite mezzi *in-band* (Opennet) oppure *out-of-band* (Darknet), quindi cominciare a inviare richieste.
|
|
||||||
|
|
||||||
## Chiavi e ricerche
|
|
||||||
|
|
||||||
In Freenet, i files sono identificati da **chiavi binarie** (*binary file keys*), ottenute applicando una hash function come **SHA**. Si identificano **tre differenti tipi di chiavi**:
|
|
||||||
|
|
||||||
* **KSK (Keyword-Signed-Key)**: La forma più basica di chiave utilizzata in Freenet. E' derivata da una stringa di testo scelta dall'utente al momento del salvataggio del file nella rete. La stringa viene utilizzata come input per generare una coppia di chiavi **asimmetriche** pubblica/privata e la chiave pubblica viene passata alla funzione di hash per ottenere la **chiave del file** (*file key*).
|
|
||||||
La chiave privata è utilizzata per **firmare il file**, provvedendo un minimo controllo di integrità, ovvero la garanzia che un file corrisponda alla sua file key.
|
|
||||||
Si nota che un sistema simile è soggetto a **dictionary attacks** contro la firma, dato che è possibile ottenere **una lista di stringe descrittive**. Per questa e **altre ragioni (TODO)**, il file è anche crittato utilizzando la stringa descrittiva come chiave.
|
|
||||||
Per permettere ad altri peer di ottenere il file, il nodo deve rendere pubblica la stringa descrittiva. Questo rende le chiavi **keyword-signed** facili da ricordare e comunicare ai peer. Purtroppo però questo sistema non è efficace in quanto le chiavi non sono uniche (è possibile che due utenti scelgano la stessa chiave per file diversi).
|
|
||||||
|
|
||||||
* **SSK (Signed-Subspace-Key)**: E' pensata per risolvere le debolezze delle KSK. Questo tipo di chiavi abilita i **personal namespaces**, che un utente può creare generando una coppia di chiavi **asimmetriche** che identificheranno il suo namespace.
|
|
||||||
Per inserire un file, è necessario scegliere una stringa descrittiva come per le KSK, ma questa volta **la chiave pubblica del namespace e la stringa descrittiva sono hashate indipendentemente**. Tra le due viene fatto poi un bit-by-bit **XOR** e il risultato è hashato di nuovo per ottenere la chiave del file.
|
|
||||||
Come per le KSK, la chiave privata è utilizzata per firmare il file, e il file è crittato utilizzando la stringa descrittiva come chiave. Questa firma risulta però più sicura in quanto **generata da una coppia di chiavi casuali**.
|
|
||||||
Per permettere ad altri peer di ottenere il file, il nodo deve rendere pubblica la stringa descrittiva **e la sua public subspace key**. In aggiunta, il proprietario del file ora ha la possibilità di gestire il proprio namespace. Per esempio, potrebbe simulare una struttura gerarchica creando files come direttori (*directory*) contenenti hypertext che punta ad altri files. I direttori potrebbero anche puntare ricorsivamente ad altri direttori.
|
|
||||||
|
|
||||||
* **CHK (Content-Hash-Key)**: Una chiave utile per implementare **update** e **splitting** dei files. Una CHK è semplicemente derivata **hashando direttamente i contenuti del file corrispondente**, ottenendo una chiave pseudo-unica per ogni file.
|
|
||||||
I files sono anche crittati da una chiave di cifratura generata **casualmente**.
|
|
||||||
Per permettere ad altri peer di ottenere il file, il nodo deve rendere pubblica la chiave di hash del contenuto e la chiave di decifratura. Si noti come la chiave di decifratura **non è MAI salvata con il file, ma solo pubblicata con la sua file key**, per ragioni ancora da spiegare **(TODO)**.
|
|
||||||
|
|
||||||
Le chiavi CHK sono molto utili se usate in parallelo con le SSK, utilizzando un **meccanismo di indirezione**. Per salvare un file di cui si può fare un update, un utente deve prima inserirlo sotto la sua CHK.
|
|
||||||
Successivamente l'utente può inserire un file **indiretto** sotto una SSK il cui contenuto è la CHK. Questo permette ad altri peer di ottenere la chiave in due step, data la SSK.
|
|
||||||
|
|
||||||
### Ottenere un file
|
|
||||||
|
|
||||||
Per ottenere un file, un utente deve per prima cosa calcolare la sua chiave binaria (*file key*).
|
|
||||||
In seguito, l'utente deve mandare una richiesta al proprio nodo specificando **chiave e HTL**. Quando un nodo riceve una richiesta:
|
|
||||||
1. Controlla se il dato cercato è presente nel suo storage, se sì ritorna il dato lungo la catena di nodi che hanno passato la richiesta.
|
|
||||||
2. Se il dato non è presente all'interno del suo storage, il nodo passa la richiesta al nodo contenente la **chiave più vicina alla chiave richiesta** presente nel suo key database (*forwarding table*). Se questa richiesta ha successo, il nodo passa il dato indietro al richiedente in *upstream*, fa **caching** del file nel suo storage locale, e crea una nuova *entry* nella sua forwarding table associando la sorgente del dato con la chiave richiesta.
|
|
||||||
|
|
||||||
Una richiesta successiva della stessa chiave potrà essere soddisfatta dalla cache locale dei nodi per cui è passata la richiesta. Una richiesta per una chiave **simile (vicina)**, determinata come **distanza lessicografica**, è passata alla sorgente del dato precedente.
|
|
||||||
|
|
||||||
Essendo che mantenere una tabella di sorgenti dei dati è un pericolo per la sicurezza degli utenti, ogni nodo che ha fatto caching può decidere **arbitrariamente** di cambiare il suo messaggio di reply, dichiarando se stesso o un altro nodo lungo il percorso come sorgente.
|
|
||||||
|
|
||||||
Se un nodo **non è in grado di fare forwarding di una richiesta**, perché il nodo scelto non è presente o perché si verrebbe a creare un loop, allora esso tenta di mandare la richiesta al secondo nodo che ritiene più *vicino*, poi al terzo e così via. Nel caso in cui un nodo **non riesca a mandare la richiesta a nessun altro peer**, esso manda un messaggio di **failure** al suo vicino sull'upstream, che quindi proverà a mandare la richiesta alla *sua* seconda scelta e così via. In questo modo, ogni richiesta agisce come una *steepest-ascent-hill-climbing search* (cit) con **backtracking**.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Note riguardo al processo di ricerca di un file
|
|
||||||
|
|
||||||
* Se gli HTL scadono, un messaggio di failure è propagato verso l'upstream **senza provare nessun nodo successivo**. Inoltre, se gli HTL sono considerati **troppi** (un numero troppo elevato), i nodi possono decidere di limitali per ridurre il carico sulla rete.
|
|
||||||
* I nodi possono ignorare richieste pendenti dopo un certo periodo di tempo, per liberare memoria dedicata ai messaggi.
|
|
||||||
* Il meccanismo di ricerca ha una serie di implicazioni:
|
|
||||||
|
|
||||||
1. Si è visto come la **qualità del routing migliora nel tempo**, per due ragioni: I nodi tendono a specializzarsi nel localizzare set di chiavi simili, essendo che le richieste per chiavi simili sono solitamente mandate verso gli stessi nodi. Inoltre i nodi si specializzano nel salvare **cluster di files con chiavi simili**, essendo che ogni richiesta con successo comporta una serie di nodi che diventano **cache** e quindi ottengono file con chiavi simili.
|
|
||||||
2. Il meccanismo di richiesta **replica in maniera trasparente dati popolari**, creando mirrors nel sistema vicino alle località con maggiore richiesta.
|
|
||||||
3. La connettività tende a crescere e favorire i nodi che rispondono con successo a più richieste, essendo che ogni nodo che risponde con successo aggiunge una entry alla sua routing table, e pertanto riesce a scoprire **una parte maggiore della rete**. Si nota però come questo **non aiuti gli altri nodi a scoprirlo**.
|
|
||||||
4. Si creano link diretti alle sorgenti di dati, bypassando i nodi intermediari. Per questo **i nodi che fanno da sorgente con successo guadagnano entries nella routing table e saranno contattati più spesso**.
|
|
||||||
|
|
||||||
## Decentralized data storage
|
|
||||||
|
|
||||||
### Inserimento di dati (files)
|
|
||||||
L'inserimento dei files segue una strategia parallela a quella effettuata per le richieste. Per inserire un file, un utente:
|
|
||||||
* Calcola una binary file key corrispondente al file.
|
|
||||||
* Manda un messaggio di **insert** al proprio nodo, specificando la chiave proposta e un valore di HTL, che determina **il numero di nodi in cui il file sarà salvato**.
|
|
||||||
* Quando un nodo riceve una proposta di inserimento controlla il proprio storage per verificare che la chiave non sia già presente.
|
|
||||||
* Se la chiave è presente, il nodo ritorna il file precedentemente salvato come se avesse ricevuto una richiesta. In questo modo l'utente sa che è avvenuta una collisione e può riprovare con un'altra chiave.
|
|
||||||
* Se la chiave non è presente nello storage, il nodo cerca la chiave più vicina ad essa nella sua routing table, e manda la richiesta di insert al nodo corrispondente. Se si verifica una collisione, il nodo passa i dati all'upstream e di nuovo si comporta come se avesse ricevuto una richiesta (caching del file in locale + creazione di entry nella routing table).
|
|
||||||
* Se il limite di HTL è raggiunto **senza alcuna collisione**, il risultato di **all clear** è propagato indietro al nodo che ha effettuato l'inserimento. Questo è un ACK di **success**, al contrario di quanto avviene per le richieste, in cui il raggiungimento degli HTL senza collisione significa *file not found*.
|
|
||||||
* Una volta ricevuto l'**all clear**, l'utente manda il file da inserire al proprio nodo, che lo propaga lungo il percorso stabilito dalla query iniziale, salvandolo in tutti i nodi nel percorso. Ogni nodo creerà quindi una entry nella propria routing table corrispondente al file. Per evitare di salvare l'origine del file (security concern), **ogni nodo può arbitrariamente decidere di cambiare l'insert message, identificandosi come sorgente del nodo**.
|
|
||||||
* Se un nodo non può mandare la richiesta al nodo da lui scelto per malfunzionamenti (target down) oppure perché si creerebbe un *loop*, esso manda la richiesta al secondo nodo più vicino, e così via.
|
|
||||||
|
|
||||||
Questo meccanismo ha 3 effetti:
|
|
||||||
* I nuovi files inseriti sono posizionati selettivamente in nodi con chiavi vicine (simili) a quella scelta per il nuovo file. Questo rinforza il fenomeno del clustering delle chiavi.
|
|
||||||
* I nuovi nodi **possono usare gli insert come modo supplementare di annunciare la propria presenza nella rete**.
|
|
||||||
* Gli attacker non possono propagare file falsi al posto di quelli originali, anzi, ottengono l'effetto opposto, essendo che file con la stessa chiave non possono essere inseriti. (*Nota: questo è un problema delle KSK, mentre le altre chiavi hanno un meccanismo di verifica molto più forte, utilizzando i namespace dell'inserter*).
|
|
||||||
|
|
||||||
### Data management
|
|
||||||
|
|
||||||
Freenet funziona sul principio del decentralized data storage, ovvero **ogni nodo della rete condivide un certo ammontare di spazio locale, che viene dedicato esclusivamente al data storage**. I proprietari dei singoli nodi possono configurare quanto spazio dedicare alla rete.
|
|
||||||
Lo storage è gestito come una **cache LRU** (Least Recently Used), che ordina i dati salvati in base a un ordine temporale decrescente di ricevimento delle richieste (o tempo di inserimento, se non è mai stata ricevuta una richiesta).
|
|
||||||
Quando un nuovo files è inserito / salvato, se questo causa un superamento dei limiti dello storage, i file usati **meno recentemente** sono cancellati finchè non si raggiunge la disponibilità di memoria sufficiente. Questo comportamento potrebbe impattare pesantemente la disponibilità dei dati, ma è mitigato dal fatto che **le entry nella routing table relative ai file eliminati sono mantenute in memoria per un certo tempo, permettendo al nodo di ottenere nuove copie dalle sorgenti originali.**
|
|
||||||
Tecnicamente, lo storage dei nodi **non è una cache**, dato che **non c'è copia permanente dei dati che sono salvati in una cache**, come invece avviene per il caching classico (un esempio è Free Haven o Eterniti, ma anche il DNS caching, in cui i dati hanno una sorgente che li mantiene in modo permanente).
|
|
||||||
Il meccanismo di *scadenza* dei dati, che ne causa la cancellazione, ha però l'effetto vantaggioso di permettere ai nuovi dati di *aggiornare* e rimpiazzare i dati più vecchi. I documenti presenti da più tempo che però hanno valore sono preservati grazie alle richieste che ricevono, che aggiornano le entry nella cache (e quindi ricevono una posizione migliore nell'ordinamento LRU).
|
|
||||||
|
|
||||||
### Data encryption
|
|
||||||
|
|
||||||
Per ragioni politiche / legali, potrebbe essere desiderabile da parte degli operatori dei nodi di **non conoscere il contenuto del proprio storage locale**. Per questo motivo, tutti i dati salvati sono cifrati, non per renderli più sicuri (il che sarebbe impossibile, dato che chiunque effettui una richiesta è in grado di decifrare il file una volta che lo riceve).
|
|
||||||
L'obbiettivo è invece quello di **poter negare la conoscenza, da parte dei node operators, di qualunque dato salvato nel proprio storage**, dato che tutto ciò che essi conoscono *a priori* è la chiave del file, non la chiave di cifratura del file.
|
|
||||||
Le chiavi di cifratura (per il KSK e l'SSK) sono ottenibili solo **con il processo di invertimento di un hash**, mentre le chiavi di cifratura del Content Hash sono completamente scollegate.
|
|
||||||
Ovviamente **un dictionary attack rivelerebbe quali chiavi sono presenti**, ma la difficoltà e il workload di un attacco simile è sufficientemente alta da permettere una misura di sicurezza agli operatori di nodi.
|
|
||||||
|
|
||||||
|
|
||||||
### Dettagli sul protocollo
|
|
||||||
|
|
||||||
Il protocollo Freenet:
|
|
||||||
* **E' packet-oriented**
|
|
||||||
* utilizza **self-contained messages**
|
|
||||||
* Ogni messaggio include un ID della transazione, così che i nodi possano tracciare lo stato di insert e request.
|
|
||||||
|
|
||||||
Questo design permette flessibilità nella scelta del **meccanismo di trasporto**, che quindi supporta **TCP,UDP e altre tecnologie come il packet radio**. Per massimizzare l'efficienza, i nodi che utilizzano un canale **persistente** (come una connessione TCP) possono anche mandare **multipli messaggi lungo la stessa connessione**.
|
|
||||||
|
|
||||||
Gli indirizzi dei nodi consistono in un **metodo di trasporto** più un identificatore di trasporto specifico, come un'indirizzo IP e una porta, ma **nodi che cambiano indirizzo frequentemente possono utilizzare indirizzi virtuali**, salvati come **Address Resolution Keys** (ARK), che sono SSK aggiornate per contenere l'indirizzo reale corrente.
|
|
||||||
|
|
||||||
## Small World Network
|
|
||||||
|
|
||||||
### Darknet implementation
|
|
||||||
|
|
||||||
Si può discriminare tra due tipi di reti Peer-To-Peer:
|
|
||||||
|
|
||||||
* **Light** P2P network: freenet, gnutella, DHT. Permettono la comunicazione tra **qualunque nodo**.
|
|
||||||
|
|
||||||
* **Dark** P2P network: Waste. Solo i nodi **fidati**, il cui indirizzo è conosciuto *a priori*, possono comunicare (*friend to friend network*).
|
|
||||||
|
|
||||||
#### Il fenomeno del mondo piccolo (Small World Phenomenon)
|
|
||||||
|
|
||||||
Il fenomeno del *mondo piccolo* è il principio grazie al quale un network P2P è in grado di ottenere informazioni in maniera **decentralizzata e scalabile**. Il fenomeno è simile al principio dei **sei gradi di separazione** tra esseri umani, dato che **conoscenze tra esseri umani formano uno small world network**.
|
|
||||||
Quindi: **l'informazione è condivisa solo tra i conoscenti**, intesi come **relazioni fidate**.
|
|
||||||
|
|
||||||
Si nota come questo rappresenti un algoritmo di routing effettivo, dotato di grande robustezza, essendo che resiste ad attacchi intenzionati a **rompere il routing** (come l'invio di informazioni a qualcuno che non è fidato). Se questo accade, l'algoritmo di routing effettua un **restart**.
|
|
||||||
|
|
||||||
Il problema principale, stabilita l'esistenza di un percorso tra due nodi fidati, è quello di **trovare il percorso**, il che non è sempre immediato.
|
|
||||||
Nel caso di una persona che vuole mandare una lettera solo tramite conoscenze, il discriminante per stabilire a chi passare la lettera (il **next hop**) è dato da informazioni aggiuntive riguardo al conoscente.
|
|
||||||
In una rete di nodi, questo non è possibile, ma può essere tradotto in un concetto di **similarità** tra i nodi, definita come **closeness** (vicinanza).
|
|
||||||
|
|
||||||
Questo significa che **peer simili hanno maggiore probabilità di essere connessi**. La scelta che un nodo deve fare diventa quindi:
|
|
||||||
|
|
||||||
**Quale tra i peer che conosco è più vicino (quindi più simile) al peer che sto cercando di raggiungere?**
|
|
||||||
|
|
||||||
Questa scelta identifica un algoritmo di **Greedy routing**.
|
|
||||||
|
|
||||||
#### Il Dark Network
|
|
||||||
|
|
||||||
Un Dark Network, come la parte di Freenet chiamata **DarkNet** utilizza un algoritmo di greedy routing simile a quello descritto nel fenomeno del mondo piccolo.
|
|
||||||
Per ottenerelo, bisogna definire un modo di accedere alle informazioni della rete. In OpenNet, ogni indirizzo è accessibile a tutti. In Internet, c'è un sistema gerarchico di indirizzi IP, pianificati e assegnati. In Freenet, e specialmente in DarkNet, le informazioni non sono organizzate ma **distribuite caoticamente**, dato che **non esiste un'entità che si occupi di assegnare gli indirizzi di rete**. Ciononostante, l'abilità di mandare un messaggio tra due nodi distanti sulla rete è essenziale.
|
|
||||||
|
|
||||||
Jon Kleinberg nel 2000 ha spiegato come gli Small World Network possano essere navigati, definendo una proprietà essenziale che permette la riuscita dello Small World Phenomenon:
|
|
||||||
|
|
||||||
* L'efficacia del routing negli Small World Networks dipende **dalla proporzione delle connessioni che hanno diversa lunghezza, rispetto alla posizione dei nodi**.
|
|
||||||
|
|
||||||
Questo significa che connessioni di differente *lunghezza* devono essere rappresentate come nodi **più vicini o più lontani**. In una scelta tra uno step più lungo e uno più corto è preferibile quello più corto, dato che quando arriviamo più vicini a qualcuno, c'è una probabilità più alta che quel qualcuno conoscano la persona a cui entrambi sono vicini.
|
|
||||||
|
|
||||||
Per questo, si richiede:
|
|
||||||
|
|
||||||
**Il numero di condizioni con determinata lunghezza deve essere inversamente proporzionale alla lunghezza delle stesse**.
|
|
||||||
|
|
||||||
Se questo requisito è rispettato, l'algoritmo ha una complessita di `O((log(n))^2)` steps, risultando quindi molto performante.
|
|
||||||
|
|
||||||
In termini pratici, questo significa che l'ideale è avere **poche connessioni lunghe e molte corte**, sapendo che **più lunga è una connessione meno probabilità ha di venire effettuata**.
|
|
||||||
|
|
||||||
#### Applicazione del Greedy Routing
|
|
||||||
|
|
||||||
La risoluzione algoritmica alla domanda: *"Quale nodo è il più vicino a quello a cui devo mandare il messaggio?"*, non è sempre possibile senza avere una grande mole di informazioni riguardo alla rete. Freenet e in modo particolare DarkNet è incentrata sulla preservazione dell'anonimato dei suoi utenti, perciò non si hanno a disposizione la posizione dei nodi nella rete e nemmeno le *trusted connections, o "conoscenze"* di ciascun nodo.
|
|
||||||
|
|
||||||
Per queste ragioni, possiamo dire che è la rete, adottando il modello di Kleinberg, a decidere:
|
|
||||||
|
|
||||||
* Ad ogni nodo viene assegnata un'identità numerica che è posizionata in una griglia, rispettando il principio di Kleinberg che richiede poche connessioni lunghe e molte corte. Può essere visto come un *reverse engineering* delle posizioni dei nodi, basandosi sulle connessioni nella rete.
|
|
||||||
|
|
||||||
Questo però necessita una rete decentralizzata e un procedimento distribuito, altrimenti si potrebbe verificare la centralizzazione delle informazioni riguardo alla rete in un singolo nodo (o più nodi).
|
|
||||||
|
|
||||||
##### L'algoritmo Greedy
|
|
||||||
|
|
||||||
L'algoritmo riceve come input un network di nodi connessi casualmente e restituisce uno small-world network in cui le lunghezze tra i nodi sono inversamente proporzionali al numero di nodi della data lunghezza.
|
|
||||||
|
|
||||||
1. Un nuovo nodo si inserisce nella rete e sceglie una posizione a caso.
|
|
||||||
|
|
||||||
2. Il nodo scambia la propria posizione con quella degli altri nodi, di modo da **minimizzare il prodotto della lunghezza gli edge del grafo**. Questo prodotto rappresenta la **vicinanza** tra i peer nel social space, che è integrata nella loro identità numerica.
|
|
||||||
|
|
||||||
In una rete generata con questo principio, l'algoritmo greedy lavora molto bene, permettendo a un nodo di connettersi a qualunque altro in un numero **relativamente piccolo** di steps. Bisogna però considerare che ciò non rivela nulla riguardo alla **posizione** del nodo rispetto agli altri.
|
|
||||||
|
|
||||||
*(dimostrazione grafica)*
|
|
||||||
|
|
||||||
La dimostrazione grafica mostra che un algoritmo di routing Greedy funziona **se e solo se i nodi vicini hanno più probabilità di conoscersi**. Perciò il processo di riordinamento dei nodi è necessario.
|
|
||||||
|
|
||||||
L'algoritmo di riordinamento dei nodi è **interamente decentralizzato** e implementato in Freenet.
|
|
||||||
|
|
||||||
The algorithm for node rearrangement is **fully decentralized** and implemented inside freenet. *(simulazione)*
|
|
||||||
|
|
||||||
## Bibliografia
|
|
||||||
|
|
||||||
* Paper di Ian Clarke che descrive le basi di Freenet [link](https://www.cs.cornell.edu/people/egs/615/freenet.pdf)
|
|
||||||
* Slides della presentazione di Darknet a Berlino, 2005, [link](https://freenetproject.org/assets/papers/ccc-slideshow.pdf.bz2)
|
|
||||||
* Simulazione in Java della presentazione di Darknet a Berlino, 2005, [link](https://freenetproject.org/assets/papers/ccc-freenet-demo.tar.bz2)
|
|
||||||
* Paper *Distributed routing in Small World Networks*, [link](http://freenetproject.org/assets/papers/swroute.pdf)
|
|
||||||
* [Sito ufficiale Freenet](https://freenetproject.org/pages/about.html)
|
|
||||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,4 +0,0 @@
|
||||||
1. Modello TCP a tempo continuo, con equazioni differenziali per modellare W in caso di router red, slides "tcp_modelli.pdf"
|
|
||||||
2. Ripassare AQM
|
|
||||||
3. Ripassare randomizzazione
|
|
||||||
4. Ripassare indirezione
|
|
||||||
|
|
@ -1,16 +0,0 @@
|
||||||
01.clark_88.pdf
|
|
||||||
02.Design-philosopy-2013.pdf
|
|
||||||
03.segnalazione.pdf
|
|
||||||
04.Architettura_reti_cellulari.pdf
|
|
||||||
05.SDN.pdf
|
|
||||||
06.randomizzazione.pdf
|
|
||||||
07.indirezione-multiplexing.pdf
|
|
||||||
08.articolo-indirezione.pdf
|
|
||||||
09.ing-traffico.pdf
|
|
||||||
10.tcp-modelli.pdf
|
|
||||||
11.controllo-congestione.pdf
|
|
||||||
12.ccn.pdf
|
|
||||||
13.paper1-ccn.pdf
|
|
||||||
14.paper2-ccn.pdf
|
|
||||||
programma_reti
|
|
||||||
ripasso_reti.pdf
|
|
||||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 64 KiB |
|
|
@ -1,55 +0,0 @@
|
||||||
# Sicurezza Informatica come Identity Management
|
|
||||||
|
|
||||||
Ambiti della sicurezza informatica:
|
|
||||||
* Embedded (mobile, etc)
|
|
||||||
* Software (vulnerabilities, secure coding)
|
|
||||||
* IAM
|
|
||||||
* Infrastructure (firewalls, etc)
|
|
||||||
* Compliance / Risk Management
|
|
||||||
|
|
||||||
## LDAP
|
|
||||||
|
|
||||||
Database distribuito, usato per accesso e *storage* delle identita'.
|
|
||||||
|
|
||||||
## IAM (Identitiy and Access Management)
|
|
||||||
|
|
||||||
E' la componente che si occupa di verificare e memorizzare identita' utente di modo da garantire o vietare l'accesso a determinati servizi.
|
|
||||||
|
|
||||||
Concetto: **Mancanza di sicurezza = Accesso non autorizzato**.
|
|
||||||
Concetto: **Sicurezza e' gestione continuativa per mezzo di sistemi integrati su device/software**.
|
|
||||||
|
|
||||||
IAM si divide in due componenti:
|
|
||||||
* Web Applications (client+server). Trattato nel corso, LAB con Apache+Linux.
|
|
||||||
* SAP, Oracle Applications, etc (non Trattato).
|
|
||||||
|
|
||||||
### IAM: Keywords
|
|
||||||
|
|
||||||
* User Management
|
|
||||||
* Endpoint Security
|
|
||||||
* Monitoring (SOC, SIEM)
|
|
||||||
|
|
||||||
#### SOC (Security Operations Centre)
|
|
||||||
|
|
||||||
Centro automatizzato che monitora la sicurezza di sistemi target (Telecom). Fa parte delle Infrastructure.
|
|
||||||
|
|
||||||
#### SIEM (Security Incidents and Event Management)
|
|
||||||
|
|
||||||
Software utilizzato da un SOC.
|
|
||||||
|
|
||||||
|
|
||||||
### Centralita' dell'Utente Autorizzato
|
|
||||||
|
|
||||||
Un utente autorizzato e':
|
|
||||||
* Nome (Username): Identificativo, puo' avere attributi aggiunti (ex. anagrafica).
|
|
||||||
* Credenziali (Password): Informazioni aggiuntive con cui l'utente dimostra di essere se stesso.
|
|
||||||
|
|
||||||
Nota: credenziali e nome utente possono presentarsi in varie forme / metodi, ed essere multiple per ogni utente.
|
|
||||||
|
|
||||||
### Controllo di Accesso (AAA)
|
|
||||||
|
|
||||||
Le credenziali permettono di controllare l'accesso di utenti, tramite le seguenti componenti:
|
|
||||||
* Authentication
|
|
||||||
* Authorization: gestione dei permessi utente basati sull'autenticazione.
|
|
||||||
* Audit: Logging di eventi / autorizzazioni
|
|
||||||
|
|
||||||
Nota: un processo diverso dall'Authentication e' l'Identification. Questa verifica le credenziali utente senza che essi le esplicitino (es. identificazione biometrica).
|
|
||||||
|
|
@ -1,125 +0,0 @@
|
||||||
# IAM
|
|
||||||
|
|
||||||
## Authentication (continua)
|
|
||||||
|
|
||||||
Avviene in 3 modi:
|
|
||||||
* token (qualcosa che l'utente possiede)
|
|
||||||
* biometrica (qualcosa che ha (fisicamente))
|
|
||||||
* segreto (qualcosa che sa)
|
|
||||||
L'approccio preferito e' la *two factor authentication*.
|
|
||||||
|
|
||||||
### Autenticazione a token
|
|
||||||
|
|
||||||
Token e' un oggetto (carte a microprocessore, otp keys...) che l'utente utilizza per autenticarsi.
|
|
||||||
Il token utilizza un *protocollo di identificazione *per dimostrare al sistema l'identita' dell'utente.
|
|
||||||
L'identita' e' garantita dall'unicita' del token.
|
|
||||||
|
|
||||||
Vantaggi:
|
|
||||||
* Maggiore sicurezza (migliore gestione del problema del "replay" delle credenziali). Il problema del replay riguarda il riutilizzo di credenziali nel caso fossero rubate.
|
|
||||||
* Accesso ai dati e' possibile solo tramite lettori appositi: **tamper resistance** molto alta. Questo perche' i sistemi di lettura sono spesso costruiti appositamente. Sistemi chiusi: non sono *general purpose*, non sono modificabili.
|
|
||||||
* **tamper proof**: impossibile aprire un token senza distruggerlo.
|
|
||||||
* **tamper evidence**: e' facile accorgersi che il token e' stato aperto.
|
|
||||||
|
|
||||||
Svantaggi:
|
|
||||||
* perdita/furto di token invalida l'unicita' dello stesso e la validita'. La **perdita** rappresenta il rischio maggiore. Rimpiazzare i token e' lungo e costoso.
|
|
||||||
* per utilizzare un token spesso servono lettori appositi (di banda magnetica, di microprocessore)
|
|
||||||
* scomodita' di utilizzo (dover portare token per ogni autenticazione). Questo puo' impattare l'utilizzo del sistema.
|
|
||||||
|
|
||||||
#### Carta a microprocessore
|
|
||||||
|
|
||||||
Garantisce un livello di sicurezza maggiore rispetto alle carte a banda magnetica, in quanto i codici di sicurezza sono noti al sistema nel caso delle bande magnetiche.
|
|
||||||
Nel caso della carta a microprocessore, un **protocollo bidirezionale** fa si che il codice non esca mai dalla card. Questo permette al sistema di lettura e autenticazione di NON conoscere il codice segreto.
|
|
||||||
|
|
||||||
### Autenticazione biometrica
|
|
||||||
|
|
||||||
Due tipi:
|
|
||||||
* basata su caratteristiche fisiche (impronte digitali).
|
|
||||||
* basata su caratteristiche comportamentali (firma autografa su carta).
|
|
||||||
|
|
||||||
Vantaggi:
|
|
||||||
* Facile (sempre disponibile, a contrario del token)
|
|
||||||
|
|
||||||
Svantaggi:
|
|
||||||
* Meno sicura che con token e segreto
|
|
||||||
* Sensibile ad attacchi replay (riutilizzo di credenziali)
|
|
||||||
* Imprecisa: due possibilita' di errore a probabilita' alta (vedi errori frequenti)
|
|
||||||
|
|
||||||
#### Autenticazione biometrica: errori frequenti
|
|
||||||
|
|
||||||
* **FAR** (False Alarm Rate): User legittimo non riconosciuto (falso allarme) a causa dell'imprecisione del metodo di riconoscimento
|
|
||||||
* **IPR** (Impostor Pass Rate): User illecito riconosciuto come legittimo, sfruttando l'errore di imprecisione del metodo di riconoscimento
|
|
||||||
|
|
||||||
[FAR/IPR threshold](./FAR_IPRthreshold.jpg)
|
|
||||||
|
|
||||||
La soglia (threshold) e' la differenza tra la verifica memorizzata (impronta, viso, retina...) e quella sopperita per l'autenticazione. Piu' la soglia e' ridotta, meglio e', piu' e' alta, piu' frequenti sono i casi di IPR.
|
|
||||||
|
|
||||||
#### Tecnologie Biometriche
|
|
||||||
|
|
||||||
* Impronte digitali - errore 10/15%
|
|
||||||
* Riconoscimento facciale - errore elevato (>20%)
|
|
||||||
* Firma autografa
|
|
||||||
* Riconoscimento Iride - basso errore, alta scomodita'
|
|
||||||
|
|
||||||
### Autenticazione a Segreto (Password / Pin / Chiave simmetrica o asimmetrica)
|
|
||||||
|
|
||||||
Vantaggi:
|
|
||||||
* Semplicita'
|
|
||||||
* Disponibilita' (easy deployment)
|
|
||||||
* *Consumer Grade* level: utile quando l'utente non ha bisogno di un'autenticazione valida sul lungo periodo (banche, etc)
|
|
||||||
|
|
||||||
Svantaggi:
|
|
||||||
* Dimenticare il segreto e' facile
|
|
||||||
* Soggetta a **Sniffing** (intercettazione): La password trasmessa su canali non cifrati puo' essere intercettata (problema del replay)
|
|
||||||
* Soggetta a **Guessing/Cracking**: Una password / segreto puo' essere indovinata o scoperta
|
|
||||||
* Soggetta a **Phishing**: Truffa ai danni dell'utente che utilizza canali falsi per ottenere le credenziali.
|
|
||||||
|
|
||||||
#### Password Cracking
|
|
||||||
|
|
||||||
I modi principali per scoprire la password di un utente sono due, con i seguenti approcci:
|
|
||||||
|
|
||||||
* **Brute Force**: Approccio detto di *forza bruta*, si basa sui tentativi (si provano tutte le combinazioni di un dato alfabeto alfanumerico/simbolico). E' vanificato dalla lunghezza (numero di bit) della password, infatti con 10/15 caratteri si ottengono 2^80 combinazioni, non calcolabili da una macchina in tempi "umani".
|
|
||||||
* **Dictionary Based**: Approccio basato su di un dizionario, consiste nel provare una combinazione di parole conosciute e numeri, sperando nella semplicita' della password stessa. Statisticamente ha molto successo.
|
|
||||||
|
|
||||||
*Nota: bit-length di una password ed encoding*
|
|
||||||
Una password puo' essere costruita di un subset di un dato dizionario / alfabeto, ad esempio:
|
|
||||||
* ASCII: 1 char = 1 byte (molto ampio, ma contiene anche caratteri non ammessi nelle comuni password -> costoso)
|
|
||||||
* 7-bit ASCII: subset di ASCII
|
|
||||||
* **base64**: Subset a 6 bit di ASCII
|
|
||||||
|
|
||||||
#### Il problema del replay (riutilizzo)
|
|
||||||
|
|
||||||
Un utente in possesso di un segreto (password) fornisce a un sistema di controllo di accesso le credenziali, che tramite la rete le trasmette a un server di autenticazione. Che succede se il suo segreto viene intercettato, e quali sono le possibili soluzioni?
|
|
||||||
|
|
||||||
**Soluzione 1: Cifratura / Hashing**
|
|
||||||
Utilizzare una funzione di Hash **non invertibile**, quindi collision resistant.
|
|
||||||
Questo fa si che in rete non viaggi la password *in chiaro*, ma una cifratura di questa che non puo' essere collegata alle credenziali originali.
|
|
||||||
** L'hash delle credenziali pero' e' accettato dal server, che non conosce la password vera e propria. Uno sniffer puo' quindi utilizzare h(C) per autenticarsi sul server.**
|
|
||||||
|
|
||||||
**Soluzione 2: Authentication Protocol**
|
|
||||||
Se il segreto C (password) e' conosciuto sia da client che da server, non e' necessario passarlo in rete per forza, ma e' possibile utilizzare un protocollo di autenticazione, che puo' essere diverso ogni volta, per garantire l'autenticazione e vanificare lo sniffing.
|
|
||||||
Un possibile *drawback* e' che il segreto C sia memorizzato in chiaro su entrambe le macchine, il che lo rende **vulnerabile**. Per questo non si memorizza C direttamente, ma **una hash function di C** h(C).
|
|
||||||
|
|
||||||
* Un esempio possibile di memorizzazione di segreto e' dato da /etc/passwd (e tuttora /etc/shadow) su sistemi UNIX/Linux.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,98 +0,0 @@
|
||||||
# Protocollo di Autenticazione
|
|
||||||
|
|
||||||
Il protocollo di autenticazione e' utilizzato nella comunicazione client-server tramite l'utilizzo di segreti client-side e server-side, cosi' che:
|
|
||||||
* Non sia possibile effettuare attacchi replay sulla connessione
|
|
||||||
* Sia mantenuta una sessione applicativa per tutta la durata della connessione
|
|
||||||
|
|
||||||
## Come vanificare attacchi replay?
|
|
||||||
|
|
||||||
* **Credenziali temporizzate**: dopo 3/6 mesi scadono (soluzione debole)
|
|
||||||
* **Password generata da token con funzione univoca** (basata su data/ora, un hash del tempo,etc). Questo avviene sia server-side che client-side, quindi il timestamp utilizzato deve avere una precisione sufficiente per permettere a entrambe le parti di ottenere le stesse credenziali (se scadono dopo 1 ms, il server e il client potrebbero non essere sincronizzati). Inoltre, essendo che potrebbe verificarsi il caso in cui il client e il server sono sul "limite" di validita' delle credenziali, e' necessario prendere in considerazione l'intervallo di tempo precedente e successivo (server-side). La password generata ha durata media uguale a 3\*precisione del timestamp.(soluzione comunque debole per la lunga durata del timestamp)
|
|
||||||
|
|
||||||
### One-time password (OTP)
|
|
||||||
|
|
||||||
Protocollo **unidirezionale** (client->server) utilizzando un segreto condiviso (password conosciuta da entrambe le parti). Solo che invece di mandare la password, in questo caso viene mandato **h^n(password)**, ossia una funzione di hash eseguita n volte sulla password.
|
|
||||||
|
|
||||||
Essendo che la funzione di hash e' non invertibile e resistente alle collisioni, e' impossibile ritornare alla password dall'hash. Il server controlla che h^n sia corretta, poi segna n come utilizzato e quindi non piu' utilizzabile, e la volta successiva si calcolera' h^(n-1). Arrivati a n = 0, viene mandata la h^0(password), ossia la password stessa. Questa e' l'ultima autenticazione possibile prima di una nuova inizializzazione (nuova password, ricomincia). Questo sistema e' un primo esempio di protocollo di autenticazione. E' **sicuro**,ma:
|
|
||||||
|
|
||||||
* Non mantiene nessuna sessione operativa successiva all'autenticazione.
|
|
||||||
* Soggetto a session hijacking: dopo l'autenticazione, e' possibile inserirsi e prendere controllo della sessione.
|
|
||||||
|
|
||||||
Per risolvere queste problematiche, e' necessario un protocollo **bidirezionale**.
|
|
||||||
*NOTA: differenza tra chiave simmetrica e password
|
|
||||||
Non c'e' grande differenza tra password e chiave simmetrica. L'unica differenza e' lo scopo: un utente non memorizzera' mai la chiave simmetrica, mentre una password e' facilmente memorizzabile e quindi utilizzabile anche da ambienti non propri.*
|
|
||||||
|
|
||||||
### Protocollo di Needham / Schroeder
|
|
||||||
|
|
||||||
*NOTA: il libro Criptography... su Moodle lo chiama Key Distribution Scenario*
|
|
||||||
|
|
||||||
Terminologia:
|
|
||||||
* Client = Initiator (A)
|
|
||||||
* Server = Responder (B)
|
|
||||||
* Nonce = numero casuale generato da A, lungo abbastanza da non essere indovinabile (N)
|
|
||||||
|
|
||||||
Un dialogo tra Initiator e Responder fa si che essi riescano a stabilire una sessione sicura. Questo protocollo e' fatto di **5 messaggi**:
|
|
||||||
|
|
||||||
1. **Initiator si identifica** (sono A, voglio parlare con B) fornendo: nome A, nome B, Nonce (N). Manda questo messaggio in chiaro a un **key distribution center** (KDC), che e' una **trusted third party** (TTP). Il KDC utilizza una crittografia a chiave **simmetrica** (la cifratura asimmetrica non era stata ancora inventata). E' quindi necessario che A e KDC utilizzino una chiave condivisa in precedenza **[ K(A,KDC) ]**. La condivisione della chiave viene fatta in maniera "manuale", ossia esterna al protocollo. **Nota: lo stesso dialogo e' effettuato anche con B, condividendo K(B,KDC)**.
|
|
||||||
|
|
||||||
2. **Il KDC risponde ad A** con un messaggio cifrato sulla chiave K(A,KDC) condivisa in precedenza, inserendo nel messaggio:
|
|
||||||
* una nuova chiave **K(A,B)** appena generata
|
|
||||||
* il nome di B
|
|
||||||
* il Nonce
|
|
||||||
* un **ticket** (o **capability**) T, il quale e' l'encryption di [K(A,B), nome di A] sulla chiave K(B,KDC). A quando riceve questo messaggio non puo' leggere il ticket, il quale e' fatto apposta per essere utilizzato senza decifrarlo.
|
|
||||||
|
|
||||||
3. **A manda a B il ticket**, come se fosse un biglietto di accesso. Solo B puo' decifrare il ticket, grazie alla chiave condivisa K(B,KDC). B ha cosi' la certezza dell'identita' di A, perche' il ticket contiene l'identita' di A. Se un avversario intercettasse il ticket T e lo mandasse lui stesso a B, non potrebbe decifrarlo, ma potrebbe utilizzarlo come chiave d'accesso a B. Questo e' il motivo per cui ci sono i messaggi 4 e 5, che includono lo scambio di un Nonce aggiuntivo.
|
|
||||||
|
|
||||||
4. **B risponde con un messaggio cifrato con K(A,B)**, inviando nel messaggio un secondo Nonce (N2). A apre il messaggio, legge N2, lo trasforma con una determinata funzione e lo ricifra con la stessa chiave K(A,B).
|
|
||||||
|
|
||||||
5. **A manda a B la nuova cifratura di N2**.
|
|
||||||
|
|
||||||
Il protocollo finisce qui, e tutti i messaggi successivi saranno cifrati con K(A,B).
|
|
||||||
|
|
||||||
#### Note riguardo al protocollo
|
|
||||||
|
|
||||||
Il "cuore" del protocollo sono i messaggi 1,2,3, che fanno parte dell'autenticazione. Gli ultimi due **inizializzano la sessione**. Infatti, dopo il messaggio 3, **B sa chi e' A ed entrambi condividono una chiave**.
|
|
||||||
|
|
||||||
* Session hijacking e' quindi impossibile, in quanto i primi 3 messaggi sono leggibili solo da A (grazie a K(A,KDC).
|
|
||||||
* Il messaggio deve essere **ben formato** per garantire la sicurezza del protocollo.
|
|
||||||
* Non c'e' initialization tra A e B, ma solo tra A e KDC e B e KDC.
|
|
||||||
* I messaggi 4 e 5 hanno lo scopo di dimostrare che la sessione e' attiva e soprattutto di **autenticare B verso A**, effettuando una cosiddetta **Mutual Authentication**. Se A non rispondesse al messaggio 4 con il messaggio 5, A dimostra di essere **vivo**, non solo un avversario che effettua un replay (che non sarebbe in grado di decifrare il messaggio 4).
|
|
||||||
* il Ticket viene anche chiamato capability, ossia un oggetto che non dimostra un'autenticazione ma garantisce l'accesso a un determinato servizio.
|
|
||||||
|
|
||||||
#### Rapporto chiave / utente
|
|
||||||
|
|
||||||
Senza una TTP, ogni utente che vuole parlare con altri N utenti ha bisogno di N chiavi. Su un gruppo di N utenti, le chiavi simmetriche sono N+(N-1)+(N-2)... che risulta essere N(N-1)/2, O(N^2).
|
|
||||||
Questo **non e' gestibile** su una grande quantita' di utenti.
|
|
||||||
* Con unt TTP (come KDC) ogni utente ha bisogno di solo una chiave, quindi il numero di chiavi aumenta in modo lineare per ogni utente aggiunto. Molto piu' gestibile.
|
|
||||||
|
|
||||||
#### Session Keys / Master Keys
|
|
||||||
|
|
||||||
In un protocollo di autenticazione come il NS, i dati cifrati si "appoggiano" (sono cifrati con) delle Session Keys, generate al momento. Queste chiavi si appoggiano a delle Master Keys, che di solito sono chiavi "fisiche" condivise in precedenza. Per questo, il collegamento essenziale (e durevole) e' quello che collega l'utente al KDC. Ogni utente deve recarsi a un KDC per ottenere la Master Key, ma questo e' poco pratico.
|
|
||||||
|
|
||||||
* Spesso esiste piu' di un KDC, di modo da essere piu' accessibile agli utenti.
|
|
||||||
|
|
||||||
##### Esercizio: KDC gerarchico
|
|
||||||
|
|
||||||
Immaginare un KDC centrale e vari KDC periferici. Come posso estendere la struttura dei KDC gerarchicamente?
|
|
||||||
|
|
||||||
(suggerimento: replicare il protocollo tra il KDC centrale e i periferici)
|
|
||||||
In questo modo gli utenti A,B,C possono autenticarsi sul loro KDC periferico. Cosa succede se due utenti sotto due KDC periferici differenti si vogliono parlare?
|
|
||||||
|
|
||||||
|
|
||||||
### Lifetime of an Applicative Session (durata di una sessione applicativa)
|
|
||||||
|
|
||||||
*NOTA: la pila ISO/OSI definisce il livello di presentazione come quello in cui encoding e crittografia sono gestiti, non quello applicativo.*
|
|
||||||
|
|
||||||
La durata di una sessione applicativa non e' definita: di solito e' la durata tra il login e il logout dell'utente.
|
|
||||||
La durata di una Session Key invece e' spesso minore della durata della sessione, infatti puo' essere rinnovata piu' volte durante la stessa sessione.
|
|
||||||
La durata di una Master Key varia da alcuni mesi ad alcuni anni, essendo che e' poco pratico e *time consuming* ottenerne una nuova.
|
|
||||||
|
|
||||||
## Schema di controllo delle chiavi trasparente
|
|
||||||
|
|
||||||
*(vedi libro, figura 7.10)*
|
|
||||||
Due utenti A,B implementano la pila ISO/OSI.
|
|
||||||
* A livello applicativo, A vuole mandare un messaggio 'm' a B. Il livello applicativo ignora la presenza di un TTP (KDC).
|
|
||||||
* A livello di presentazione (o livello di sessione) sia A che B hanno una Master Key [K(A,KDC), K(B,KDC)]. Quando A vuole mandare un messaggio a B, il livello di sessione di A comincia mandando il messaggio (1) del protocollo al KDC. Il KDC risponde con il messaggio (2), facendo si' che nel livello di sessione si ottenga la chiave condivisa K(A,B). A manda quindi il messaggio (3) a B, utilizzando il ticket. A questo seguono i messaggi (4,5) tra A e B, e solo successivamente il livello applicativo e' autorizzato a mandare un messaggio a B.
|
|
||||||
|
|
||||||
* **Il livello di sessione e' quindi trasparente rispetto al livello applicativo**.
|
|
||||||
|
|
||||||
|
|
@ -1,144 +0,0 @@
|
||||||
# Lo scope di una chiave (segreto)
|
|
||||||
|
|
||||||
Spesso l'utilizzo di una chiave va ristretto ad un ambito specifico (firmare un programma, stabilire una connessione ssl, accedere a dei servizi, etc).
|
|
||||||
|
|
||||||
### Esempio: chiave DES
|
|
||||||
|
|
||||||
Una chiave DES e' formata da 56 + 8 bit (64), di cui i 56 sono divisi in 8 gruppi da 7 e ad ogni gruppo viene aggiunto l'ottavo bit. Di questi 8 bit, sono 3 sono utilizzati, mentre i restanti 5 sono *reserved* (per uso futuro).
|
|
||||||
|
|
||||||
I 3 bit hanno il seguente valore:
|
|
||||||
* Il primo e' detto **Session Master**.
|
|
||||||
* Il secondo e' una encryption flag (1 se la chiave si puo' usare come encryption key).
|
|
||||||
* Il terzo e' una decryption flag.
|
|
||||||
|
|
||||||
Questo e' un utilizzo piuttosto triviale (anni 80), ma allora era sufficiente.
|
|
||||||
|
|
||||||
### Esempio: certificati simmetrici
|
|
||||||
|
|
||||||
3 componenti principali:
|
|
||||||
* **Master** key
|
|
||||||
* **Session** key
|
|
||||||
* **Control vector**: un vettore che e' hashato con un algoritmo digest alla stessa lunghezza della master key.
|
|
||||||
|
|
||||||
La somma del digest del control vector e della master key e' considerata una chiave singola, mentre la session key e' considerata *dati*. Questo viene inserito in un algoritmo di cifratura ottenendo una **encrypted session key**.
|
|
||||||
|
|
||||||
Per decifrare la session key, e' sufficiente utilizzare la precedente chiave (master+vector) con un decryption algorithm per ottenere la chiave decrittata.
|
|
||||||
|
|
||||||
E' importante notare come il segreto in questo approccio sia il control vector: se questo e' sbagliato, non e' possibile cifrare o decifrare la chiave, anche se la master key e' corretta.
|
|
||||||
|
|
||||||
## Challenge-Response
|
|
||||||
|
|
||||||
I protocolli di tipo Challenge-Response sono basati su di una sfida che, una volta lanciata, ottiene una risposta. Questa potrebbe essere sempre diversa, rendendo i protocolli molto resistenti ad attacchi replay.
|
|
||||||
|
|
||||||
## Contesto: Chiave pubblica
|
|
||||||
|
|
||||||
Nel caso della chiave pubblica, non c'e' piu' la necessita' di dialogo singolo con i peer che si ha con la chiave simmetrica. Una chiave pubblica e' condivisa tra tutti i peer che vogliono parlare con un singolo (che si occupa di distribuire la chiave). Questo semplifica l'autenticazione, ma presenta vari svantaggi:
|
|
||||||
|
|
||||||
1. Ogni soggetto che vuole permettere l'autenticazione a vari peer dovra' distribuire la propria chiave pubblica a tutti i peer. Questo limita i soggetti che ricevono la chiave: molti non possono riceverla *direttamente* (fisicamente). Se la chiave viene distribuita con un mezzo (es: email) che e' sensibile al *man in the middle*, e' possibile che un attacker utilizzi una sostituzione di chiavi per falsificare i messaggi tra il soggetto e il peer.
|
|
||||||
|
|
||||||
* Soluzione: **public key directory**. La chiave non e' distribuita ma **memorizzata** in una directory, che e' solitamente una **TTP** (trusted third party). Ogni soggetto memorizza la propria chiave, che quindi e' facilmente ritrovabile dai peer interessati. Vantaggi: la chiave e' memorizzata solo una volta (e non N volte per N soggetti). Questo approccio e' piu' sicuro ma comunque vulnerabile al MITM.
|
|
||||||
|
|
||||||
### Soluzione 2: public key authority (Needham / Schroeder a chiave pubblica o asimmetrico).
|
|
||||||
La chiave e' gestita da un'authority, con i seguenti passaggi:
|
|
||||||
|
|
||||||
* Il peer A informa l'authority di voler parlare con B, mandando una R(B) *richiesta*, e un timestamp t1.
|
|
||||||
* L'authority risponde con la chiave pubblica di B, la richiesta e il timestamp ripetuti, tutto cifrato con la **chiave pubblica dell'authority** (condivisa a priori). L'authority deve quindi conoscere le chiavi pubbliche di A,B,etc, e le ottiene **fisicamente** per evitare il MITM.
|
|
||||||
* Se anche B effettua la stessa richiesta all'authority, entrambi i peer ottengono le chiavi dei rispettivi compagni.
|
|
||||||
* Una volta che entrambi i peer hanno una public key, la comunicazione viene effettuata con:
|
|
||||||
```
|
|
||||||
1. A->B: Ekb(IDa, N1) dove Ekb e il messaggio cifrato con la pubkey di B, IDa e' l'identificativo di A, e un Nonce N1
|
|
||||||
2. B->A: Eka(N1, N2) dove B risponde con un Nonce successivo al nonce N1
|
|
||||||
3. A->B: Ekb(K2) A risponde ripetendo il Nonce ricevuto.
|
|
||||||
```
|
|
||||||
Le precedenti comunicazioni possono avvenire su una rete insicura come internet, perche' sono cifrati da chiavi pubbliche.Questo protocollo e' **sicuro ma scomodo** (in quanto la richiesta alla TTP va fatta ogniqualvolta che i peer entrano in contatto), e quindi si utilizza un diverso tipo di TTP: la **certification authority**.
|
|
||||||
|
|
||||||
## Certification authority
|
|
||||||
|
|
||||||
La Certification authority e' una TTP che non fornisce una chiave pubblica ma un **certificato di chiave pubblica**.
|
|
||||||
|
|
||||||
Steps:
|
|
||||||
1. A manda alla CA il proprio ID e la propria chiave pubblica, **al di fuori della rete**, su un canale sicuro.
|
|
||||||
2. CA verifica l'identita di A e spesso anche la conoscenza della chiave privata corrispondente alla pubblica fornita (tramite challenge-response). Questo e' un processo one-time (teoricamente). Risponde tramite la rete con un **certificato** unico ad A. Questo puo' essere mandato tramite la rete in quanto esso e' **chiuso, non modificabile, non segreto**. Il certificato contiene **l'IDa, la chiave pubblica di A, un timestamp, e altre informazioni importanti riguardanti A.**
|
|
||||||
Il certificato e' reso non modificabile tramite **la firma della CA**.
|
|
||||||
|
|
||||||
```
|
|
||||||
CertA = SigCA{ IDa, K+a, ts, ... } = I, Ekca(H(I)) dove I e' l'informazione, abbinata a una cifratura con la chiave di CA dell'hash delle informazioni stesse (detta firma).
|
|
||||||
|
|
||||||
Un'informazione firmata e' quindi Info+Firma.
|
|
||||||
```
|
|
||||||
|
|
||||||
3. Una volta che B ha ottenuto il proprio certificato (one time process), A e B possono comunicare semplicemente scambiandosi i certificati. Il MITM non e' piu' effettivo perche' **cambiare qualunque parte del certificato ne invalida la firma**, che e' prodotta con la chiave della CA.
|
|
||||||
|
|
||||||
Questo sistema e' sicuro e pratico (dato che ottenere il certificato e' un one-time process).
|
|
||||||
|
|
||||||
### CA: creazione di una sessione
|
|
||||||
|
|
||||||
Una volta che i peer A, B hanno un proprio certificato, possono iniziare e mantenere una sessione.
|
|
||||||
|
|
||||||
#### Soluzione 1
|
|
||||||
|
|
||||||
1. A manda a B il proprio ID
|
|
||||||
2. B risponde ad A con una chiave di sessione cifrata con la chiave pubblica di A. (per renderlo meno vulnerabile, B puo' rispondere con `Eks(M), MACks(M)` dove MAC e' un'autenticazione (firma) della chiave di sessione.
|
|
||||||
|
|
||||||
I messaggi successivi sono cifrati e autenticati con la session key.
|
|
||||||
Questo approccio ha il difetto che un attacker puo' mandare sequenze random di bit per ottenere una risposta. (chiave fasulla).
|
|
||||||
|
|
||||||
Un altro rischio e' che il MITM faccia da ponte tra A e B, falsificando i messaggi. Questo presuppone che C (MITM) sia in grado di ottenere una sessione da B.
|
|
||||||
|
|
||||||
#### Soluzione 2
|
|
||||||
|
|
||||||
1. A manda a B il proprio ID e un Nonce N1, cifrati con la chiave pubblica di B.
|
|
||||||
2. B risponde con un nonce N2 successivo a N1 e con N1 stesso, cifrando con la chiave pubblica di A.
|
|
||||||
3. A risponde a B ripetendo N2 cifrato con la chiave pubblica di B.
|
|
||||||
4. Uno dei due peer, non importa quale, genera la chiave di sessione Ks e la invia cifrata con la pubkey dell'altro peer, mandando anche un'autenticazione (una firma `Sig(Ks)` con la propria chiave privata).
|
|
||||||
|
|
||||||
**SSL/TLS** e' un'evoluzione di questo protocollo.
|
|
||||||
*(leggi cap 13.1/13.2 del libro)*
|
|
||||||
|
|
||||||
# Kerberos
|
|
||||||
|
|
||||||
Kerberos e' un'evoluzione di Needham / Schroeder a chiave simmetrica. E' un progetto MIT di inizio anni '90, diventando uno dei sistemi di autenticazione di Microsoft. Lo scopo originale di Kerberos era fornire un'autenticazione affidabile in rete **locale**, dove quindi lo **sniffing** e' un problema frequente.
|
|
||||||
|
|
||||||
L'idea e' quella di utilizzare un servizio di autenticazione centralizzato.
|
|
||||||
|
|
||||||
## Schema di funzionamento
|
|
||||||
|
|
||||||
Consideriamo un servizio V (online) e un client C. La maniera piu' triviale di gestire l'autenticazione sarebbe una password che mandata a V permetta l'accesso, ma cio' e' scomodo e non scalabile.
|
|
||||||
|
|
||||||
Per questo motivo si introduce un **authentication server AS**, che gestisca l'accesso ai servizi. Procedura:
|
|
||||||
|
|
||||||
1. C manda ad AS `IDc, IDv, Pc` dove Pc e' la password del client
|
|
||||||
2. AS risponde a C con un **ticket**, cioe' un messaggio cifrato con una chiave condivisa tra AS e V (ma non C: come un biglietto di accesso a V, C non ha bisogno di coonscere il contenuto del ticket).
|
|
||||||
3. C manda a V `IDc, ticket`, che V verifica, garantendo a C l'accesso al servizio.
|
|
||||||
|
|
||||||
* Il **ticket** contiene:
|
|
||||||
```
|
|
||||||
ticket = Ek[AS,V] (IDc, MACc, IDv) dove MAC e' il mac address di C (nota: allora il MAC address non era falsificabile)
|
|
||||||
```
|
|
||||||
#### Pros
|
|
||||||
* Centralizzazione delle password di accesso ad AS
|
|
||||||
* ticket **chiuso**, quindi pratico perche' facilmente mandabile in rete
|
|
||||||
|
|
||||||
#### Cons (vulnerabilita')
|
|
||||||
* replay del ticket e' possibile (per riutilizzare un ticket, un attacker puo' falsificare il suo MAC address e mandare l'IDc, facilmente ottenibile tramite sniffing di (1)).
|
|
||||||
* rischio di intercettazione delle password e' alto.
|
|
||||||
|
|
||||||
##### Soluzione alle vulnerabilita': Kerberos v2
|
|
||||||
|
|
||||||
Oltre all'AS, viene introdotto il **Ticket granting service**, una quarta entita' che si occupa dell'emissione del ticket.
|
|
||||||
|
|
||||||
Procedura:
|
|
||||||
1. C manda ad A `IDc, IDtgs` richiedendo di utilizzare il TGS.
|
|
||||||
2. AS risponde con `Ek[C,AS](ticketTGS)` mandando un ticket cifrato con una chiave condivisa tra C e AS. Questo evita di mandare la password in rete, ma permette a C di ottenere un ticket per TGS. IL ticketTGS e':
|
|
||||||
```
|
|
||||||
ticketTGS = Ek[AS, TGS] (IDc, MACc, IDtgs, ts1, lifetime1) dove MACc e' il mac address del client, e il ts1 e' un timestamp
|
|
||||||
```
|
|
||||||
Il client ottiene il ticketTGS ma non puo' leggerlo.
|
|
||||||
|
|
||||||
3. C manda al TGS il ticketTGS, il quale lo decifra.
|
|
||||||
4. TGS manda a C il **ticketV**, che e' simile al ticketTGS come struttura:
|
|
||||||
```
|
|
||||||
ticketV = Ek[TGS, V] (IDc,IDv, ts2, lifetime2)
|
|
||||||
```
|
|
||||||
|
|
||||||
Questa versione di Kerberos introduce dei **lifetime** per evitare il replay di ticket (che pero' e' comunque possibile durante il periodo di validita' del ticket, che non puo' essere troppo breve per non introdurre scadenze prima dell'utilizzo.
|
|
||||||
|
|
@ -1,47 +0,0 @@
|
||||||
# Kerberos v4
|
|
||||||
|
|
||||||
Introduce un terzo elemento (**Ticket Granting Service**). E' attualmente usato da Microsoft, sviluppato dall'MIT, ottimo per reti locali. L'utilizzo estensivo di Timestamps rende vano il replay attack. L'utilizzo di messaggi **authenticator**, assicurano l'identita' del client. Complesso.
|
|
||||||
|
|
||||||
## Funzionamento
|
|
||||||
|
|
||||||
E' un dialogo tra 4 soggetti: **Client, Authentication Service, Ticket Granting Service, Server**. Ogni soggetto condivide alcune chiavi con gli altri soggetti (non tutti) che sono generate *manualmente*, in maniera sicura. Il Ticket Granting Service e' utilizzato per generare ticket che permettano l'accesso al server.
|
|
||||||
|
|
||||||
```
|
|
||||||
V = servizio richiesto (server)
|
|
||||||
LT = lifetime
|
|
||||||
T = timestamp
|
|
||||||
```
|
|
||||||
Sequenza:
|
|
||||||
|
|
||||||
1. C manda ad AS `(IDc, IDtgs, T1)`
|
|
||||||
|
|
||||||
2. L'AS risponde con `(E[kc,as](Kc,tgs, IDtgs, T2, LT2, ticket[tgs]))`
|
|
||||||
* il ticket[tgs] e' `E[Kc,tgs] (Kc,tgs, IDc, MACc, T2, LT2, IDtgs)`
|
|
||||||
|
|
||||||
3. C manda al TGS `(IDv, ticket[tgs], authenticator[c])`
|
|
||||||
* authenticator[c] e' `E[Kc,tgs] (IDc, MACc, T3)`. E' usato per dimostrare l'identita' di C.
|
|
||||||
|
|
||||||
4. Il TGS risponde con `E[ktgs,v] (Kc,v, IDv, T4, ticket[v])`.
|
|
||||||
* il ticket[v] e' `E[Ktgs,v] (Kc,v, IDc, MACc, T5, LT5, IDv)`.
|
|
||||||
|
|
||||||
5. C a questo punto comunica direttamente con V, mandando `(IDc, ticket[v], authenticator2[c])`.
|
|
||||||
* authenticator[c] e' `E[Kc,v] (IDc, MACc, T6)`. E' usato per dimostrare l'identita' di C.
|
|
||||||
|
|
||||||
6. V risponde con `E[kc,v] (T5 + 1)`
|
|
||||||
* il T5 viene restituito modificato (una qualunque funzione va bene, basta che C e V ne siano a conoscenza).
|
|
||||||
|
|
||||||
# Autenticazione con chiave asimmetrica (SSL/TLS)
|
|
||||||
|
|
||||||
In applicativi in cui non e' possibile condividere chiavi simmetriche a priori (ecommerce, banking) e' necessario un protocollo a chiavi asimmetriche.
|
|
||||||
|
|
||||||
### Digressione: autenticazione HTTP
|
|
||||||
|
|
||||||
Il protocollo HTTP utilizza una catena di servizi: **Client/Browser, Proxy/Tunnel **(un numero vario)**, Gateway **(traduce richieste)**, Server**.
|
|
||||||
|
|
||||||
#### Autenticazione in HTTP
|
|
||||||
|
|
||||||
Vari metodi, in ordine di sicurezza:
|
|
||||||
* keep-alive: non un vero e proprio sistema di sessione, semplicemente un timeout e un numero di richieste/risposte massimo per mantenere aperta una connessione.
|
|
||||||
|
|
||||||
* Cookie / URL rewriting
|
|
||||||
* SSL / TLS
|
|
||||||
|
|
@ -1,9 +0,0 @@
|
||||||
# Webserver security and Access Control
|
|
||||||
|
|
||||||
Laboratorio di sicurezza II.
|
|
||||||
|
|
||||||
## Guidelines
|
|
||||||
|
|
||||||
* LAMP: Linux, Apache, MySql, PHP
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,18 +0,0 @@
|
||||||
Corso di Sicurezza II
|
|
||||||
|
|
||||||
Argomenti previsti per il corrente anno accademico
|
|
||||||
|
|
||||||
Vedi slide e materiale salvato qui di seguito
|
|
||||||
|
|
||||||
Inoltre si vedano i libri di testo;
|
|
||||||
1) William Stallings: Cryptography and Network security, IV edition
|
|
||||||
Capitoli 7.3, 10.1, 13, 14, 15, 16.6, 17, 18.3, appendice A
|
|
||||||
2) Brian Arkills: LDAP directories explained, Independent Technology Guides
|
|
||||||
|
|
||||||
e, per consultazione:
|
|
||||||
3) Williamson, Yip, Sharoni & Spaulding: Identity Management - a primer, MC press
|
|
||||||
4) Bertino & Takahashi: Identity Management - concepts, technology and systems, Artech house
|
|
||||||
|
|
||||||
Esami: e' previsto un esame orale, con due modalita' possibili:
|
|
||||||
- studenti frequentanti: slide riportate sotto e argomenti affrontati a lezione e soluzione di tutti gli esercizi di laboratorio.
|
|
||||||
- studenti non frequentanti: studio completo dei testi 1), 2) e 3) sopra elencati, limitatamente ai capitoli sopra indicati. E' inoltre prevista la scrittura di una relazione su un argomento legato alla sicurezza ICT, da concordarsi con il docente. La relazione sara' presentata in sede di esame.
|
|
||||||
93
anno2/YearI/MCAD/esercizi2019/bomboloni_monitor.marco
Normal file
93
anno2/YearI/MCAD/esercizi2019/bomboloni_monitor.marco
Normal file
|
|
@ -0,0 +1,93 @@
|
||||||
|
monitor Vassoio{
|
||||||
|
int b = 0;
|
||||||
|
timer_scaduto = false;
|
||||||
|
condition servi;
|
||||||
|
condition friggi;
|
||||||
|
|
||||||
|
public int servi(){
|
||||||
|
if (b == 0 || timer_scaduto){
|
||||||
|
wait(servi);
|
||||||
|
}
|
||||||
|
servi --;
|
||||||
|
return b;
|
||||||
|
}
|
||||||
|
|
||||||
|
public int friggi(){
|
||||||
|
if(!(b == 0 && timer_scaduto))
|
||||||
|
wait(friggi);
|
||||||
|
return b;
|
||||||
|
}
|
||||||
|
|
||||||
|
public void riempi(){
|
||||||
|
b = 30;
|
||||||
|
timer_scaduto = false;
|
||||||
|
signal(servi);
|
||||||
|
}
|
||||||
|
|
||||||
|
public void butta(){
|
||||||
|
timer_scaduto = true;
|
||||||
|
signal(friggi);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
monitor Alarm{
|
||||||
|
int now = 0;
|
||||||
|
int alarm = -1;
|
||||||
|
condition waiting;
|
||||||
|
|
||||||
|
public void tick(){
|
||||||
|
now++;
|
||||||
|
if(alarm != -1 && alarm <= now){
|
||||||
|
alarm = -1;
|
||||||
|
signal(waiting);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
public void waittimer(){
|
||||||
|
wait(waiting);
|
||||||
|
}
|
||||||
|
|
||||||
|
public void settimer(int s){
|
||||||
|
alarm = now + s;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Vassoio v;
|
||||||
|
Alarm a;
|
||||||
|
|
||||||
|
Process Mario{
|
||||||
|
int b;
|
||||||
|
while(true){
|
||||||
|
b = v.friggi();
|
||||||
|
if(b > 0)
|
||||||
|
<butta>;
|
||||||
|
<friggi>;
|
||||||
|
a.settimer(60);
|
||||||
|
v.riempi();
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Process Piero{
|
||||||
|
int b;
|
||||||
|
while(true){
|
||||||
|
<aspetta cliente>;
|
||||||
|
b = v.servi();
|
||||||
|
<servi>;
|
||||||
|
if (b == 0)
|
||||||
|
a.settimer(0);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Process Rosa{
|
||||||
|
while(true){
|
||||||
|
a.waittimer();
|
||||||
|
v.butta();
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Process Clock{
|
||||||
|
while(true){
|
||||||
|
<aspetta un secondo>;
|
||||||
|
a.tick();
|
||||||
|
}
|
||||||
|
}
|
||||||
BIN
anno2/YearI/MCAD/esercizi2019/invarianti19.pdf
Normal file
BIN
anno2/YearI/MCAD/esercizi2019/invarianti19.pdf
Normal file
Binary file not shown.
|
Before Width: | Height: | Size: 112 KiB After Width: | Height: | Size: 112 KiB |
|
Before Width: | Height: | Size: 89 KiB After Width: | Height: | Size: 89 KiB |
|
Before Width: | Height: | Size: 112 KiB After Width: | Height: | Size: 112 KiB |
|
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 107 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue