Added Piattaforme Software MOD1 lessons

Piattaforme Software per la Rete/MOD1/lesson_02.md

@@ -0,0 +1,98 @@
+# Piattaforme Software per la Rete - lesson 2
+#### Giacomo Verticale
+###### 11 March 2016
+## Modulo 1 - Endnodes
+
+__collo di bottiglia__ della velocità può essere
+- velocità del collegamento in uscita: serve link più veloce
+- in una delle funzioni dei nodi: si possono migliorare le prestazioni
+Le __astrazioni__ sono il primo nemico delle prestazioni
+Le comunicazioni ad esempio email non sono implementate direttamente sul cavo
+ ma ci sono multipli strati di astrazione, ognuno dei quali nasconde gli strati sottostanti. 
+La stessa __interfaccia__ (ad es socket) deve andare bene per applicazioni multiple
+ad esempio trasferimento di file (possibilmente lento) o pagine web (poss. veloce)
+
+Il nostro obiettivo è ottenere una velocità __wirespeed__
+
+## Endnodes
+__Struttura__: 
+- architettura a strati per *semplificare lo sviluppo*
+- sistemi di protezione
+- implementazione più generale possibile: ad es. scelgo algoritmi in base 
+al funzionamento generale e non al funzionamento in un caso specifico.
+__Scala__:
+La tabella di un pc desktop viene gestita da un algoritmo molto più semplice e meno sofisticato
+della tabella di un core router tra autonomous systems (~6 entries vs ~100'000 entries)
+
+### Architettura hardware BSD
+- Net Interface (scheda di rete che implementa lo strato ethernet)
+- I/O BUS
+- Bus Adaptor
+- System Bus
+- Memory
+- MMU + Cache
+- CPU
+La prestazione degli endnodes dipende molto dalla velocità della cache, 
+quindi si cerca di massimizzare l'utilizzo della cache. 
+Le cache in genere sono efficaci quando si ha una *località temporale* e *spaziale* tra le informazioni richieste. 
+Il caching non è sfruttabile facilmente nei sistemi di rete, ad esempio se si guarda un film in streaming, 
+non è utile mettere i pacchetti ricevuti in una cache, perchè i dati vicini non sono ancora arrivati, e
+quelli appena visti non serve mantenerli in cache. 
+Ad esempio se una macchina apre tante (~1000) connessioni TCP, non serve avere tutti i socket pronti in cache, 
+ma potrebbe essere utile copiare il descrittore del socket in cache nel momento in cui viene ricevuto un pacchetto. 
+Gli algoritmi BSD degli anni '80 non sono più adatti alle velocità (~300Mb/s) perchè sono adatti solo a velocità di (10-30Mbit/s). 
+
+### Architettura software BSD
+- Processi p1,p2,p3...
+- Kernel (coda IP)
+- Net Interface
+- Trama ethernet
+Quando la scheda di rete riceve una trama, questa viene copiata in un buffer,
+poi viene controllato il checksum, se non torna butto la trama, dopo
+viene controllato il MAC addr. se non è il mio butto la trama.
+La scheda di rete per interagire col S.O. alza un interrupt hardware
+La routine di gestione degli interrupt comunica alla scheda di mettere le trame sul buffer
+Può avvenire
+- Senza DMA: la CPU copia 1 byte per volta in RAM
+- Con DMA: la scheda di rete copia la trama direttamente in RAM
+A questo punto il pacchetto viene messo in una coda IP (nella memoria centrale)
+Del pacchetto guardo:
+- Indiritto IP destinazione, se non è il mio scarto o forwardo
+- Guardo campo protocollo (TCP o UDP)
+- Identifico socket tramite numero di porta sorg-dest (TCP) o dest (UDP)
+- Metto il pacchetto nella coda ad (es. UDP) del processo
+- Se il processo era in attesa bloccante, il processo viene cambiato a pronto
+- Quando verrà schedulato il processo va in esecuzione e legge dal socket. 
+Per un pacchetto TCP la questione è simile a parte la gestione della finestra,
+ad esempio se il pacchetto non è arrivato in ordine, non può essere consegnato
+finchè non arrivano i pacchetti mancanti.
+
+### Problemi
+__Livelock__
+Se il sistema è configurato male:
+- la scheda di rete riceve spesso pacchetti
+- il sistema operativo è troppo impegnato dagli interrupt della scheda di rete
+- il sistema non riesce a dividere i pacchetti nelle code
+- il sistema non riesce ad eseguire i processi che smaltiranno i pacchetti
+
+### Invio di un pacchetto
+Se consideriamo l'architettura hardware BSD con l'aggiunta di un disco sul bus I/O
+Ad un server può essere richiesta una pagina web tramite una richiesta HTTP GET
+- Il S.O. chiede al disco la pagina web richiesta e viene caricata in RAM (cache disco)
+- L'applicazione webserver legge dalla cache il file e lo copia nel proprio spazio utente
+- L'applicazione invoca la SEND sul socket buffer della connessione.
+- Il pacchetto viene copiato dal socket buffer alla scheda di rete
+Abbiamo 4 operazioni per ogni pacchetto, quindi la banda richiesta per ogni pacchetto viene
+amplificata di 4 volte.
+All'avvicinarsi della velocità del bus alla velocità del link aumenta 
+la latenza della trasmissione, e quindi il throughput della connessione non è determinato
+dal link ma dalla macchina che non riesce a gestire le connessioni.
+Ad esempio nei sistemi solaris l'applicazione invia i dati direttamente alla scheda di rete,
+senza passare dalla memoria, il checksum lo calcola la scheda di rete
+Anche la ricezione può essere ottimizzata facendo calcolare il checksum delle trame IP 
+in hardware alla scheda di rete. 
+Ad esempio in un datacente di Amazon vengono usate macchine virtuali che scambiano pacchetti tramite
+l'hypervisor facendo calcolare i checksum alla scheda di rete, a cui però i pacchetti non arrivano
+Quindi in questo modo si aveva un tasso di errore sui pacchetti molto alto.
+
+

Piattaforme Software per la Rete/MOD1/lesson_03.md

@@ -0,0 +1,48 @@
+# Piattaforme Software per la Rete - lesson 3
+#### Giacomo Verticale
+###### 15 March 2016
+## Demultiplexing
+
+Un __sistema finale__(endnode) implementa l'intera pila protocollare dal livello fisico a quello applicativo
+I __nodi interni__ alla rete implementano un numero ridotto di livelli (1,2,3 e a volte 4).
+
+La __demultiplazione__ è lo spacchettamento della trama di livello 2 e tirare fuori il pacchetto di livello applicativo.
+- __Layered demultiplexing__ rispetta l'astrazione della stratificazione protocollare
+è possibile ottenere un implementazione semplificata ma più efficiente
+Ad esempio nel *video streaming* si usa UDP perchè TCP introduce affidabilità e ritardo
+- __Early demultiplexing__ Nel caso UDP venga bloccato, si può mascherare UDP da TCP, in occasioni come questa si gestisce tutta la pila
+protocollare a livello kernel(modulo del kernel) o a livello applicativo.
+Può servire a:
+- Prioritizzare i pacchetti
+- Usare codice specializzato
+- Saltare la pila protocollare.
+
+C'è un problema di __sicurezza__, in quanto un processo avrebbe accesso a tutti i pacchetti che transitano nel sistema.
+Vogliamo garantire __wirespeed processing__, il collo di bottiglia deve essere il link fisico.
+Vorremmo la proprietà di __composability__: Il costo complessivo deve essere minore alla somma dei protocolli attraversati.
+
+Lo standard attuale (usato ad esempio da wireshark o tcpdump) è il meccanismo __Berkeley Packet Filter__
+è un grafo di controllo di flusso (un qualsiasi grafo diretto aciclico).
+
+Il BPF viene eseguito nel kernel in parallelo (divisione di tempo OS) e gestisce gli stessi pacchetti 
+inviati allo stack TCP/IP layered, per ogni pacchetto ricevuto il BPF controlla se corrisponde ad alcuno dei filtri
+e nel caso viene copiato nel buffer corrispondente, altrimenti viene scartato.
+
+Il buffer serve perchè il costo di portare il pacchetto a livello utente è alto, e questo aumenterebbe il tempo
+di esecuzione del filtro, abbassando le prestazioni.
+La API si chiama __pcap__, e tcpdump è il programma più diffuso per usarle.
+--- Nota:
+*rarpd* è il nonno del protocollo DHCP e non viene più usato
+BootP consente di copiare informazioni per il boot
+DHCP consente di trasferire DNS, durata del lease, ecc.. 
+Per questo è inutile eseguire rarp in kernelspace ma basta eseguirlo in userspace, e lo stesso vale per lo sviluppo 
+di nuovi protocolli.
+Il filtro viene specificato usando una sintassi BPF che viene compilata ed eseguita nella virtual machine BPF
+(Originariamente pseudo-machine) VM-BPF ha un suo set di istruzioni limitato e specifico.
+
+### BPF syntax
+### Tcpdump and wireshark
+__Tcpdump__ stampa pacchetti in stdout, e può salvare pacchetti in file pcap
+__Wireshark__ dispone di filtri aggiuntivi per riconoscere traffico a livello applicativo.
+I pacchetti salvati nel formato pcap vengono tagliati ai primi 64byte ad esempio per salvare solo gli header utili
+senza memorizzare tutto il pacchetto sprecando spazio.

Piattaforme Software per la Rete/MOD1/lesson_04.md

@@ -0,0 +1,67 @@
+# Piattaforme Software per la Rete - lesson 4
+#### Giacomo Verticale
+###### 17 March 2016
+## Exact Match Lookup
+## Bridge Ethernet
+Il primo bridge ethernet è nato per connettere due reti separate
+Il problema di usare solo un ripetitore per connettere due reti
+è che fonderei le due reti portando dalle due parti molto traffico inutile.
+
+Il __bridge__ presenta due interfacce e ha una tabella di routing
+- Se il destinatario della trama si trova nella stessa interfaccia
+da cui è arrivata la trama, questa non viene propagata
+- Se il destinatario è nell'altra interfaccia,
+la trama viene propagata
+Il bridge ha un __algoritmo di apprendimento__ con cui si annota l'interfaccia
+da cui provengono le varie trame per poter effettuare forwarding.
+
+### Requisiti prestazionali
+- Lunghezza trame ethernet = 64Byte (max=1500Byte)
+Fissata dal requisito di distanza massima della rete
+Le trame internet più diffuse sono ack (40byte+14 intestazione)
+Quindi vengono inviati 64-54Byte=10Byte inutilmente
+- Velocità del collegamento = 10Mbit/s
+- Tempo tra 2 trame = 64x8bit/10Mbit/s = 51,2us
+
+Nel tempo tra 2 trame le operazioni da fare sono:
+- (sovra)Scrivere la riga della tabella
+- Leggere la riga corrispondente
+Queste operazioni vanno fatte per 2 interfacce allo stesso tempo
+Quindi ho 4 operazioni di lookup per ogni intervallo
+Ovvero 1 lookup ogni 12,8us
+
+Di solito in questi algoritmi il limite alle prestazioni è 
+il singolo accesso a memoria, mentre le operazioni aritmetiche hanno un
+impatto trascurabile.
+
+Il primo bridge Dec aveva un tempo di accesso a memoria di 100ns
+Max numero di righe= 8000
+Soluzione: array ordinato
+Max n. accessi a memoria= log2(8000)=13
+Costo di lookup = 1,3us
+
+### Tecnologia FDDI
+è una tecnologia di rete ad anello,
+ha lunghezza minima della trama 40Byte
+Velocità= 100Mbit/s
+Tempo tra 2 trame = 3.2us
+
+Per migliorare le prestazioni si potrebbero usare memorie più veloci
+ma questo alzerebbe il prezzo sul mercato, :(
+Per questo è stato introdotto l'uso delle __tabelle hash__
+Che consistono in una funzione di hash che mappa gli input in un array con indici di n bit
+Nel caso peggiore dell'utilizzo di una hash table, tutti i mac finiscono nella stessa chiave, 
+quindi ho tempi di accesso analoghi ad una tabella
+Se ho una funzione di hash abbastanza buona da non avere collisioni, ho tempo di accesso costante
+Se inizio ad avere tante collisioni, posso cambiare la funzione di hashing
+Quello che si fa di solito è avere una famiglia di funzioni di hashing, 
+ne scelgo una a caso e valuto le prestazioni, se va male cambio la funzione e ne scelgo un'altra.
+
+Originariamente si era pensato ad un albero di 3 livelli invece ad una lista,
+questo permette di avere al massimo 7 collisioni
+Nell'implementazione del gigaswitch in caso di collisione si utilizzava una CAM ovvero una memoria
+che era in grado di fare ricerca in parallelo in hardware.
+
+MAC 48bit A(x)=a0x^47+a1x^46+...+a46x+a47 Sono i bit del mac address
+H(x)=A(x)M(x)modG(x)
+output,input,parametro che determina una specifica funzione hash

Piattaforme Software per la Rete/MOD1/lesson_05.md

@@ -0,0 +1,123 @@
+# Piattaforme Software per la Rete - lesson 5
+#### Giacomo Verticale
+###### 18 March 2016
+## Prefix Match
+
+Per ogni pacchetto viene fatto il matching nella tabella di inoltro
+In caso di ambiguità di applica la regola del __Longest prefix matching__
+Cioè data una chiave, dobbiamo trovare la riga contenente il prefisso più lungo.
+
+### Osservazioni
+Potremmo usare una cache per le voci più usate
+Il costo finale della ricerca sarà una media pesata del costo 
+per la ricerca in cache e del costo per la ricerca fuori,
+quindi è utile solo in caso di alta probabilità di usare la cache (~90-95%)
+Nei router con tabelle molto grandi, gli indirizzi utilizzati sono molto vari
+
+- 1 molti flussi contemporaneamente
+	- molti indirizzi diversi in un intervallo breve
+- 2 ~50% dei pacchetti sono TCP SYN e/o ACK ~40byte
+	- Quindi il tempo di interarrivo è all'incirca quello dei pacchetti di
+lunghezza minima, quindi ho poco tempo per risolvere gli indirizzi.
+- 3 Il costo della ricerca è dominato dal tempo di accesso in memoria
+Perchè ci sono solo operazioni aritmetiche semplici da effettuare.
+- 4 Capita di trovare prefissi di tutte le lunghezze (non solo 24)
+- 5 ~100'000 di righe 
+Con IPv6 la situazione peggiora perchè ci sono altri indirizzi e le netmask vanno da 8 a 64bit
+- 6 Aggiornamenti frequenti (ms-s) devo usare algoritmi con letture e scritture bilanciate.
+	- Ci sono algoritmi che hanno ottime prestazioni in lettura ma quelle in scrittura sono disastrose
+ce ne sono altri che hanno delle buone velocità in scrittura ma meno in lettura
+
+### Soluzione
+Una soluzione ottima che richiede budget molto elevato è tutta in hardware
+Le CAM hanno una tabella chiave-valore
+chiave = {0,1}^n
+è utile una variante: TCAM (ternary)
+chiave = {0,1,*}^n (*:wildcard)
+Gli * possono essere in qualsiasi posizione, noi li metteremo alla fine.
+La CAM può restituire al più 1 risultato, nella TCAM potrebbe succedere
+Il problema si risolve mettendo una preferenza tra le voci
+Cioè vince il prefisso più in alto, per questo è necessario ordinare
+le voci mettendo il prefisso più lungo in alto (inserimento più costoso
+rispetto ad una CAM normale usata nel Exact Matching)
+
+__Vantaggio__
+Tempo di ricerca costante in lettura
+__Svantaggi__
+- Rispetto ad una memoria normale, utilizza più transistor (10 rispetto a 1-2)
+Questo posta ad un costo più elevato per circuito (chip per area)
+Quindi consumano anche molto di più
+`In italia il primo consumatore di energia sono le ferrovie, il secondo è telecom`
+Ultimamente si utilizzano meno le TCAM e si usano invece memorie veloci 
+con algoritmi molto ottimizzati e Cisco ha ottenuto anche un algoritmo 
+con due accessi alla memoria (dinamica) per entry (e un numero fisso di accessi in cache).
+vedi successivamente multibit trie.
+Quindi le TCAM vengono usate in dispositivi di fascia media perchè per router
+troppo grossi non sono abbastanza capienti, e per router piccoli sono costose.
+
+### Algoritmo
+Supponiamo di avere una TCAM già popolata con prefissi di lunghezza decrescente
+Se dobbiamo inserire un indirizzo in mezzo ad altri ma non c'è spazio
+Inserendo un indirizzo di lunghezza 31 lo mettiamo a posto del primo di lunghezza 30
+che dobbiamo riposizionare, in questo modo avremo max 32 riposizionamenti.
+Un implementazione furba ha gli indirizzi lunghi sopra, quelli corti sotto e un buco in mezzo.
+
+### Soluzioni algoritmiche
+Algoritmi basati su:
+- __Tries__ ha prestazioni migliori ma i più efficienti sono brevettati
+- __Ricerca binaria__
+
+__Unibit trie__
+```
+Tabella di routing
+P1=101*
+P2=111*
+P3=11001*
+P4=1*
+P5=0*
+P6=10000*
+P7=100000*
+P8=100*
+P9=110*
+```
+__Nodo dell'albero__
+|Prefisso/valore|
+|---|---|
+|0|1|
+Il primo blocco è il puntatore al prossimo livello sul ramo 0
+Il secondo è il puntatore al prossimo livello sul ramo 1
+__Radice dell'albero__
+|Root|
+|---|---|
+|0-P5|1-P4|
+
+|P5|
+|---|---|
+|-|-|
+
+|P4|
+|---|---|
+|sottoalbero|s.a.|
+
+|-|
+|---|---|
+|0-P8|1-P1|
+ecc...
+Ogni livello indica la lunghezza del prefisso.
+
+__Visita dell'albero__
+Se dobbiamo cercare un indirizzo nell'albero
+iniziamo a scorrerlo dalla radice annotando l'ultimo nodo per cui passiamo
+Quando non possiamo più procedere l'ultimo nodo per cui siamo passati è la route cercata.
+
+__Tempi di accesso__
+Costo nel caso pessimo: 32 accessi in memoria
+In generale è possibile scambiare occupazione di memoria con tempo di calcolo
+Utilizzando un __multibit trie__ che ha per ogni nodo molti figli (es.4)
+Il problema dei multibit trie è che posso memorizzare solo prefissi che
+hanno lunghezza multipla intera del passo dell'albero, se ho prefissi più corti 
+devo esploderli in più nodi di lunghezza intera. (1*3bit -> 2*4bit)
+
+Se ho una tabella data, esiste un passo che ottimizza i tempi di accesso
+Però gli inserimenti sono critici perchè si sposta il punto di ottimo.
+