93 lines
5.3 KiB
Markdown
93 lines
5.3 KiB
Markdown
# 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)*
|