119 lines
6.4 KiB
Markdown
119 lines
6.4 KiB
Markdown
|
# Controllo di congestione come problema di ottimizzazione (continua)
|
||
|
|
|
||
|
|
*(vedi slides per esempi, formule)*
|
||
|
|
## Decentralizzazione
|
||
|
|
|
||
|
|
La soluzione completamente distribuita e' basata sul fatto che **la somma dei prezzi dei link attraversati e' uguale all'utilita'**, e quindi e' molto semplice far convergere alla soluzione ottima globale.
|
||
|
|
|
||
|
|
TCP adotta esattamente questo meccanismo:
|
||
|
|
|
||
|
|
* **risolve il problema con una sua particolare funzione di utilita', ottimizzando un sotto-problema per ogni sessione.**
|
||
|
|
|
||
|
|
Per farlo, non utilizza i moltiplicatori di Lagrange ma utilizza una funzione approssimata, arbitrariamente precisa.
|
||
|
|
La scelta e' data dal fatto che **tcp porta la rete incogngestione**, eccedendo la capacita' dei link. Pertanto per TCP non e' vero che la somma dei rate dei flussi e' strettamente minore della capacita' del link.
|
||
|
|
|
||
|
|
Si presenta dunque il metodo approssimato per la risoluzione di problemi di ottimizzazione convessa.
|
||
|
|
|
||
|
|
## Metodo della funzione barriera (o di penalita')
|
||
|
|
|
||
|
|
E' necessario **rilassare i vincoli di banda**, che pertanto risulta in una funzione globale:
|
||
|
|
|
||
|
|
```
|
||
|
|
V (x) = sum in s of (Us(xs)) - sum in l belonging to L of (gl(yl))
|
||
|
|
```
|
||
|
|
Dove gl(yl) e' detta **funzione barriera**, permette di avere dei vincoli piu' *morbidi*, utilizzando una funzione con curva simil-esponenziale al posto di una costante in y (cl).
|
||
|
|
```
|
||
|
|
gl(yl) deve quindi essere convessa, continua, differenziabile, tendente a infinito per x che tende a infinito.
|
||
|
|
```
|
||
|
|
|
||
|
|
Utilizzando una funzione tendente a infinito, non e' piu' necessario utilizzare i moltiplicatori di Lagrange, che quindi risulta in un oggetto non vincolato che puo' essere risolto in modo standard (soluzione all'equilibrio, azzerando le derivate). A seconda della ripidita' della funzione barriera, posso risolvere il problema approssimando una soluzione arbitrariamente bene.
|
||
|
|
|
||
|
|
Possiamo dire che:
|
||
|
|
|
||
|
|
* La funzione che da il prezzo di un link e' **la derivata della funzione barriera**.
|
||
|
|
|
||
|
|
```
|
||
|
|
pl(yl) = d (gl(yl)) / dy // per ogni l appartenente a L
|
||
|
|
```
|
||
|
|
Infatti, la funzione di utilita' non sara' nient'altro che la somma delle funzioni di peso dei link, posta la derivata a zero.
|
||
|
|
|
||
|
|
### Possibili scelte del prezzo dei link
|
||
|
|
|
||
|
|
Varie opzioni:
|
||
|
|
|
||
|
|
* Prezzo coincide con la probabilita' di perdita (coda drop tail, dimensione B).
|
||
|
|
* Modello M/M/1/B
|
||
|
|
* Intensita' di traffico `ro = yl/cl`
|
||
|
|
|
||
|
|
*(vedi slides)*
|
||
|
|
|
||
|
|
Alternative:
|
||
|
|
* metodo del link viruale, che assume una capacita' virtuale di modo che la funzione barriera saturi a 1 eccessa quella capacita'.
|
||
|
|
|
||
|
|
* gestione RED (random early detection), che fissa il prezzo come funzione lineare a tratti della lunghezza media della coda (crescente col carico).
|
||
|
|
|
||
|
|
**Nota:** nel caso del link virtuale, a prima impressione ottengo automaticamente la struttura della rete interessata, il che risparmia le segnalazioni tra i nodi della rete. In realta' devo considerare il problema:
|
||
|
|
|
||
|
|
#### Prezzo VS feedback probabilistico
|
||
|
|
|
||
|
|
La probabilita' di marking end-to-end non e' esattamente la probabilita' di marking teorizzata. Infatti:
|
||
|
|
* Se le probabilita' di perdita del singolo link e' piccola, il prezzo e il feedback probabilistico sono praticamente la stessa cosa. TCP infatti risolve la versione ottimizzata del problema perche' il tasso di sorgente decresce per effetto delle perdite lungo il percorso sorgente-destinazione (risolvibile con **ECN, explicit congestion notification**.
|
||
|
|
TCP interpreta quindi i prezzi come indicatori di congestione.
|
||
|
|
|
||
|
|
### Prezzo dei link come soluzione distribuita del problema duale
|
||
|
|
|
||
|
|
La funzione lagrangiana duale, vista come funzione dei prezzi incogniti, e' *(vedi slides)*.
|
||
|
|
La funzione duale richiede la **minimizzazione della funzione *su slides* al variare dei prezzi.** Si nota come in questo caso non sia presente il **duality gap**, ottenendo quindi una soluzione ottimale che e' coincidente con quella del problema primale.
|
||
|
|
Il primale e il duale sono quindi due problemi opposti (uno di massimizzazione e uno di minimizzazione) in cui trovo una soluzione coincidente muovendomi in direzioni opposte rispetto al gradiente:
|
||
|
|
* massimizzare = muovermi in direzione del gradiente (funzione a campana o `U` rovesciata)
|
||
|
|
* minimizzare = muovermi in direzione opposta al gradiente (funzione a parabola `U`)
|
||
|
|
|
||
|
|
Curiosita': ponendo k(pl) = 1 (step function che regola il controllore) la variabile pl e' esattamente la lunghezza della coda.
|
||
|
|
|
||
|
|
Questa formulazione duale e' esattamente la base teorica dell'implementazione di TCP-vegas e Fast TCP (delay-based TCP), che pero' non hanno avuto grosso successo negli ultimi tempi.
|
||
|
|
|
||
|
|
## Cosa fa veramente TCP standard?
|
||
|
|
|
||
|
|
TCP standard dimezza la finestra di congestione ottenendo la square root formula. La funzione di utilita' a cui corrisponde la square root formula e':
|
||
|
|
```
|
||
|
|
(T*xs)^2 = (2 - 2*q) / q // elevo al quadrato la square root formula
|
||
|
|
|
||
|
|
=> q*(2-(T*xs)^2) = 2
|
||
|
|
|
||
|
|
da cui q = 2/(2-(T*xs)^2) che corrisponde esattamente alla U'(x)
|
||
|
|
```
|
||
|
|
Pertanto `U(x)` e' ottenuto **integrando U'(x)**
|
||
|
|
|
||
|
|
*(vedi slides per funzione usata da TCP)* Si nota come l'uso dell'arcotangente e' esattamente compatibile alla risoluzione precedentemente studiata, ma e' stato involontario.
|
||
|
|
|
||
|
|
*(vedi slides per caso con probabilita' di perdita piccola)*
|
||
|
|
|
||
|
|
Si nota come le nuove versioni (linux, etc) hanno xs proporzionale a constant/p (CUBIC, scalable TCP) -> q proporzionale a 1/xs. U(x) = log (x), quindi **proportional fairness**.
|
||
|
|
|
||
|
|
|
||
|
|
# Content Centric Networking
|
||
|
|
|
||
|
|
*(slides per outline)*
|
||
|
|
L'Internet moderno e' costituito da moltissimi utenti affamati di contenuti (enormi volumi di dati) ma dotati di hardware e software potente ed economico. Forte mobilita', ma anche increased dependency and security threats.
|
||
|
|
|
||
|
|
Pertanto, essendo che molti elementi dell'architettura di internet sono vecchi e inadeguati, alcuni sono da migliorare:
|
||
|
|
|
||
|
|
* Delivery to IP address
|
||
|
|
* point to point delivery
|
||
|
|
* lack of built-in security
|
||
|
|
|
||
|
|
Per risolvere questo problema, CCN muove il componente universale nel Internet Protocol dai pacchetti IP al **named data**. Questo comporta un cambiamento del classico diagramma a clessidra *(vedi slides)*.
|
||
|
|
|
||
|
|
Pertanto il named data si identifica come **communication medium** su cui sono costruite le applicazioni, appoggiato a qualunque network best-effort.
|
||
|
|
|
||
|
|
**Importante e' quindi il modello Publisher-Subscriber** *(vedi slides)*.
|
||
|
|
|
||
|
|
## Struttura dell'architettura CCN
|
||
|
|
|
||
|
|
Due elementi essenziali:
|
||
|
|
|
||
|
|
* **interest packets**: sent by consumers to signal a requets of a content
|
||
|
|
* **data packet**: sent by producers / nodes that satisfy the interest in response to a consumer interest packet.
|
||
|
|
|
||
|
|
*(vedi slides per architecture representation)*
|