Nei disegni degli utilizzatori medi la rete è una nuvola: qualcosa che sta in mezzo e funziona. Il corso comincia proprio smontando quella nuvola, perché oggi essa non rappresenta più soltanto la connettività, ma anche i contenuti: è il cloud computing ad avere spostato dentro la rete una parte crescente di ciò che prima stava sui terminali.
Sotto la nuvola c'è invece un oggetto molto concreto: una rete è fatta di nodi e interconnessioni, cioè di switch Ethernet, access point Wi-Fi e router IP. Ciascuno di questi apparati è a sua volta un intreccio di tre dimensioni che il corso non separerà mai del tutto: hardware, software e comunicazioni. È una precisazione che sembra ovvia, ma ha una conseguenza pesante: se un apparato è hardware, allora ha risorse finite, e se ha risorse finite prima o poi qualcuno dovrà aspettare il proprio turno. Tutta la prima metà del corso nasce da qui.
L'esempio guida è il più banale possibile: l'accesso a una pagina web. Un browser su un PC dotato di scheda di rete, una LAN, un router/modem d'accesso, Internet, un router remoto, un'altra LAN, e infine il web server. Sette oggetti diversi, quattro tecnologie diverse, e un utente che vede solo una pagina che compare.
Ciò che rende possibile quel dialogo è l'organizzazione dei protocolli in strati (layer). Ogni strato risolve un problema e uno solo, e offre allo strato superiore un servizio che nasconde il problema risolto. Nella pila di Internet, procedendo dal basso:
La figura contiene un dettaglio che vale l'intero capitolo: più si sale nella pila, più lungo è il tratto di rete che il protocollo attraversa senza essere toccato. Ethernet vive dentro una LAN; PPP vive su un collegamento geografico; IP arriva da un capo all'altro passando per i router; TCP e HTTP esistono soltanto nei due host terminali. Un router non ha TCP, e questo spiega perché il controllo di congestione del TCP non potrà mai chiedere alla rete come sta: dovrà dedurlo.
Problema da risolvere: connettività locale. È il livello che permette a due apparati direttamente collegati di scambiarsi trame. Cambia tecnologia a ogni tratta: Ethernet dentro la LAN, PPP su un collegamento geografico. Lo switch Ethernet inoltra a questo livello e non guarda oltre.
Problema da risolvere: connettività globale. IP è l'unico protocollo presente in tutti i nodi del percorso, host e router. Fornisce un servizio di trasferimento pacchetti semplice, connectionless e non affidabile: è esattamente questa scelta che rende necessario tutto ciò che il TCP fa sopra di esso.
Problema da risolvere: trasferimento affidabile dei dati end-to-end. Vive solo nei due host terminali. È il livello del corso: qui stanno TCP, il controllo di flusso e il controllo di congestione.
Problema da risolvere: dialogo trasparente tra le applicazioni. HTTP è l'esempio classico; le slide segnalano la sua evoluzione fino a HTTP/3, che per aggirare i limiti del TCP abbandona il TCP stesso e poggia su UDP tramite QUIC. Il cerchio si chiuderà nel capitolo sul controllo di congestione.
Alla domanda «ma cosa c'è in mezzo?» le slide rispondono con dei traceroute verso www.ucla.edu, che rivelano una gerarchia di reti che l'utente non sospetta: GARR (la rete italiana della ricerca), GÉANT (la rete europea della ricerca) e Internet2 (la rete della ricerca statunitense). Il percorso non è una linea, è una catena di domini amministrativi distinti.
Il secondo fatto, ancora più istruttivo, è che il comportamento della rete cambia nel tempo: eseguendo lo stesso traceroute a distanza di poco si vedono, alla stessa riga, nodi diversi. Sono percorsi multipli usati in load balancing. La rete non è un circuito fisso, è un insieme di decisioni prese pacchetto per pacchetto.
Il terzo fatto riguarda i contenuti, che si spostano verso l'utente. Le misure riportate confrontano due nomi quasi identici da tre punti di osservazione diversi:
| Punto di misura | apnic.net | www.apnic.net |
|---|---|---|
| Prima misura | 25 hop, ~330 ms RTT | 10 hop, ~6 ms RTT |
| Server CloudLab Utah (USA) | 16 hop, ~220 ms RTT | 6 hop, <1 ms RTT |
| Università UFABC (Brasile) | 19 hop, ~344 ms RTT | 8 hop, ~30 ms RTT |
Il dominio è lo stesso, ma www.apnic.net è servito da una Content Delivery Network: copie del contenuto sono replicate su cache server geograficamente distribuiti, e ciascun utente viene servito da quella più vicina. Da qui la differenza di un ordine di grandezza nel round-trip time.
Percorsi multipli, cloud e CDN esistono per una ragione sola: il ritardo. E il ritardo, come vedremo, non dipende solo dalla distanza fisica ma anche dallo stato di riempimento delle code lungo il percorso. È il filo che tiene insieme la teoria del teletraffico e il TCP.
L'esperimento proposto a lezione sceglie due host reali — una postazione di laboratorio a Cesena e un server a Bologna — e procede in quattro passi:
ping il round-trip time (RTT) fra i due host;traceroute il percorso seguito e ragionare sulla distanza attraversata;iperf un flusso di traffico e misurare il throughput massimo ottenibile;Il passo 2 introduce il primo conto quantitativo del corso: dalla distanza e dalla velocità della luce nella fibra ottica si ricava il tempo di propagazione, che è un limite inferiore invalicabile. Il passo 4 introduce invece il fenomeno che il corso studierà per intero: caricando la rete, il RTT aumenta. Non perché la luce rallenti, ma perché i pacchetti cominciano ad accodarsi.
Il ritardo end-to-end di un pacchetto è la somma di componenti di natura diversa. Le prime due sono deterministiche e calcolabili; la terza è aleatoria ed è l'oggetto della teoria del teletraffico.
Per ogni pacchetto IP in ingresso, un router deve svolgere tre operazioni:
Anche quando queste operazioni sono realizzate in hardware per aumentarne la velocità, il router ha bisogno di tempo per eseguirle, e quindi deve conservare il pacchetto in una memoria prima di inoltrarlo. È il principio dello store and forward, ed è l'atto di nascita della coda: se serve memoria, serve una disciplina che decida chi esce prima.
Messi in rete, i router di Internet formano dunque una rete di code. Da questa constatazione discendono i due fatti che il corso userà come punto di partenza:
Immaginiamo, come caso ideale, che i buffer siano infiniti. Allora nessun pacchetto viene mai scartato: all'aumentare del carico offerto il throughput cresce finché la capacità non è saturata, e da lì in poi resta costante mentre il ritardo cresce senza limite, perché le code si allungano indefinitamente. È un sistema che non perde nulla ma che, oltre un certo punto, diventa inutilizzabile.
Nel caso reale i buffer sono finiti, e la storia cambia. Quando la congestione diventa significativa, alcuni pacchetti vengono scartati per buffer overflow. Questo ha spesso come effetto la ritrasmissione dei pacchetti persi da parte dei livelli superiori. E le ritrasmissioni sono traffico nuovo, che si somma a quello che aveva già saturato la rete: si rischia di causare un ulteriore aumento del carico se non si interviene in qualche modo. Quel modo si chiama congestion control.
Le slide organizzano il problema della valutazione delle prestazioni di rete su tre assi. Vale la pena impararli così come sono, perché l'intero corso è una passeggiata lungo la terza colonna.
| Cosa valutare | Come valutare | Dove valutare |
|---|---|---|
| throughput e utilizzazione della capacità | analisi | singola interfaccia (layer 2, accesso al canale) |
| ritardo e sua variabilità (jitter) | simulazione | singolo nodo (layer 2 o 3, sistema a coda) |
| perdita di dati o rifiuto di un servizio | esperimento su sistema reale o emulato | rete (layer 2 o 3, rete di code, quality of service) |
| trasporto (layer 4, controllo di congestione end-to-end) | ||
| utente finale (layer 7, quality of experience) |
Il programma dichiarato nelle slide introduttive si articola in tre blocchi.
| Blocco | Contenuti |
|---|---|
| Teletraffico | Introduzione alla teoria del teletraffico e sistemi a coda; cenni su catene di Markov e sistemi di nascita e morte; sistemi a coda Markoviani e formule di Erlang; applicazioni all'analisi, al dimensionamento e alla pianificazione di nodi di reti a commutazione di pacchetto e di circuito. |
| Trasporto e controllo end-to-end | Richiami sul protocollo TCP; il controllo di flusso nel TCP e il controllo di congestione; modelli per l'analisi delle prestazioni della connessione TCP. |
| Virtualizzazione e reti definite via software | Principi della «softwarizzazione» delle reti di telecomunicazioni; implicazioni della separazione fra piano di controllo e piano dati; problematiche relative alla virtualizzazione delle funzioni di rete. |
Questo sito ricostruisce i primi due blocchi, per i quali sono disponibili le slide e gli esercizi. Il terzo blocco (virtualizzazione e SDN) è dichiarato nel programma ma non è coperto dai materiali su cui questa ricostruzione è basata: per quella parte fai riferimento direttamente alle dispense su Virtuale.
Le slide proiettate a lezione e le eventuali altre dispense sono disponibili su Virtuale. Per approfondimenti le slide indicano tre testi:
L'esame finale è una prova scritta con esercizi. Non è un orale a domande di teoria: la teoria serve a risolvere i quesiti numerici. Il capitolo 14 ricostruisce la struttura tipica del compito a partire dagli esempi con soluzione distribuiti dal docente.
Data Link: connettività locale, cioè far dialogare due apparati direttamente collegati (Ethernet, PPP). Network: connettività globale fra host attraverso uno o più router (IP). Transport: trasferimento affidabile dei dati end-to-end fra i due host terminali (TCP, UDP). Application: dialogo trasparente fra i processi applicativi (HTTP). Solo IP e i livelli superiori attraversano l'intero percorso; il data link cambia tecnologia a ogni tratta.
Perché per ogni pacchetto in ingresso deve verificare la correttezza dell'intestazione IP, eseguire il routing table lookup e attendere che l'interfaccia di uscita sia libera. Anche se queste operazioni sono svolte in hardware, richiedono tempo: il pacchetto va quindi conservato in memoria. È il meccanismo store and forward, e da esso nasce inevitabilmente la coda.
Perché le altre componenti del ritardo sono sostanzialmente deterministiche: il tempo di propagazione dipende dalla distanza e dalla velocità della luce nel mezzo, il tempo di trasmissione dipende dalla lunghezza del pacchetto e dalla bit rate. Il tempo di attesa in coda, invece, dipende da quanti altri pacchetti si trovano nel nodo in quel momento, che è una grandezza aleatoria. Il jitter è essenzialmente varianza del tempo di coda.
Non si ha nessuna perdita, ma il throughput si stabilizza al valore della capacità e il ritardo cresce senza limite, perché la coda si allunga indefinitamente. È un sistema formalmente senza perdite ma praticamente inutilizzabile: nessuna applicazione interattiva tollera un ritardo illimitato.
Perché la perdita per buffer overflow innesca la ritrasmissione dei pacchetti persi da parte dei livelli superiori. Quelle ritrasmissioni sono carico aggiuntivo che si somma al carico che aveva già saturato la rete, in un ciclo che si autoalimenta. Per questo serve un meccanismo che, riconosciuta la congestione, riduca il ritmo della sorgente: il controllo di congestione.
Una Content Delivery Network replica i contenuti dell'origin server su cache server geograficamente distribuiti, in modo da servire ogni utente dal nodo più vicino. Le misure riportate a lezione mostrano che, dallo stesso punto di osservazione, apnic.net richiede 25 hop e ~330 ms mentre www.apnic.net ne richiede 10 e ~6 ms: stesso dominio, contenuto diverso di posizione.
Perché la rete usa percorsi multipli in load balancing: pacchetti diversi dello stesso flusso, o flussi diversi, possono essere instradati su cammini alternativi verso la stessa destinazione. Il comportamento della rete cambia nel tempo, e questo è uno dei motivi per cui il RTT è una variabile aleatoria e non una costante.
A livello di singolo nodo (layer 2 o 3) si studia un sistema a coda: arrivi, servitori, spazio di attesa, probabilità di blocco. A livello di trasporto (layer 4) si studia il controllo di congestione end-to-end, cioè come la sorgente adatta il proprio ritmo osservando ciò che le ritorna dalla destinazione. I due punti di vista sono complementari: il primo dice quanto ritardo produce la rete, il secondo dice come la sorgente reagisce a quel ritardo.
Perché TCP esiste soltanto nei due host terminali: i router attraversati implementano IP e il data link, non il livello di trasporto. Non esiste quindi, nella pila classica, un canale con cui la rete comunichi al TCP il proprio stato. La sorgente deve dedurre la congestione osservando i tempi e gli acknowledgment: è un controllo di tipo implicito.
1) Teletraffico: sistemi a coda, catene di Markov e processi di nascita e morte, formule di Erlang, dimensionamento di nodi di reti a pacchetto e a circuito. 2) Trasporto e controllo end-to-end: TCP, controllo di flusso e di congestione, modelli di prestazione. 3) Virtualizzazione e reti definite via software: softwarizzazione, separazione fra piano di controllo e piano dati, virtualizzazione delle funzioni di rete.