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