163 lines
7.5 KiB
Markdown
163 lines
7.5 KiB
Markdown
|
# 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).
|
||
|
|
|
||
|
|
|