# 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)*