CAPITOLO 3 MODELLIZZAZIONE DI XCP ATTRAVERSO SIMULINK E STATEFLOW

Transcript

1 CAPITOLO 3 MODELLIZZAZIONE DI XCP ATTRAVERSO SIMULINK E STATEFLOW 3.1 Uso di Simulink per modellare un generico flusso XCP Simulink è un simulatore del pacchetto MATLAB utile per la modellazione, la simulazione e l analisi di sistemi dinamici. Esso supporta sia sistemi lineari che sistemi non lineari a tempo continuo, a tempo discreto o a tempo ibrido dei due. I sistemi possono anche essere multirates, cioè campionati o aggiornati a rates differenti. Per la modellazione, Simulink è supportato da un interfaccia grafica (GUI) che consente la costruzione di modelli attraverso schemi a blocchi, utilizzando principalmente il mouse. Inoltre ha una vasta libreria di blocchi riguardo componenti lineari e non lineari, sorgenti di segnale e blocchi di giunzione con la possibilità di personalizzare o addirittura creare dei blocchi propri a seconda delle esigenze. Fig. 3.1: libreria di Simulink 31

2 I modelli sono disposti in maniera gerarchica e si possono visualizzare sistemi di livello inferiore attraverso il doppio click del tasto sinistro del mouse sul blocco interessato, scendendo così di livello in livello fino ad arrivare al livello più dettagliato del sistema. Dopo aver definito il modello, esso può essere simulato scegliendo un metodo di integrazione, o attraverso il menu di Simulink o attraverso l inserimento di comandi nella finestra dei comandi di MATLAB. Fig. 3.2: menu di Simulink Fig. 3.3: finestra dei comandi di MATLAB L utilizzo del menu di Simulink è conveniente per lavori interattivi, mentre l approccio con comandi di linea è utile quando si vogliono avviare simulazioni a gruppi. Attraverso il blocco scope è possibile visualizzare il risultato della simulazione mentre quest ultima è in 32

3 fase di run. Infine, i risultati della simulazione possono essere visualizzati attraverso il blocco To Workspace, come spiegato più avanti. Fig. 3.4: blocchi Scope e To Workspace Nel caso in questione, il sistema da rappresentare è una rete a commutazione di pacchetto la quale può essere descritta come una serie di nodi connessi tra loro da link di comunicazione. In questi nodi i pacchetti, immessi dalle sorgenti con un certo rate, vengono bufferizzati con un meccanismo di store and forward, che comporta l accodamento di ogni pacchetto in una coda FIFO all interno del nodo, in attesa di essere trasmesso sul link di comunicazione verso la sua destinazione. Ogni nodo consiste di una serie di code di input, nelle quali vengono memorizzati i pacchetti in arrivo, e di una serie di code di output, nelle quali vengono memorizzati i pacchetti in uscita. Si assume che la capacità di elaborazione di ogni nodo sia maggiore della totale capacità di trasmissione dei link in entrata, quindi la congestione potrà essere causata solo dalla capacità di trasmissione. Ogni link è infatti caratterizzato da una capacità di trasmissione che verrà misurata in pacchetti/s e da un ritardo di propagazione t d. Già Van Jacobson [V. Jacobson88] aveva affermato che una rete simile fosse approssimabile con un sistema lineare di guadagni, ritardi e integratori. Verrà usato proprio questo tipo di approccio per modellare la nostra rete. In particolare, verrà usata la teoria di controllo classica, caratterizzata dall impiego di funzioni di trasferimento per descrivere il sistema da controllare e il controllore stesso. La rete verrà costruita usando integratori per modellare i buffer dei nodi della rete e del receiver e ritardi per modellare i link di propagazione. L avvio di Simulink avviene tramite il pulsante dalla barra degli strumenti di Matlab: Figura 3.5: Icona di accesso a Simulink Consideriamo ora un singolo flusso XCP: il numero di pacchetti del suddetto flusso memorizzati nel generico buffer i lungo il path da sorgente a destinazione è dato dalla seguente equazione: 33

4 t q i t = [ ui τ d i τ oi τ ] dτ dove u i t 0 modella il rate di arrivo dei dati, d i t 0 modella il depletion rate dei dati, ovvero il rate di dati in uscita, e o i t 0 modella l overflow rate dei dati, cioè i dati che vengono persi quando il buffer è pieno e l input rate supera l output rate. In Simulink il buffer verrà quindi modellato nel modo seguente: Figura 3.6: Modellizzazione di un buffer Come si può notare, il buffer del nodo è modellato usando un integratore, rappresentato dalla sua trasformata di Laplace 1. Il buffer riceve tre input, che modellano i suddetti s rate. L output dell integratore rappresenta il livello della coda all interno del buffer. L equazione dinamica del generico link i-1 di comunicazione che connette il nodo i-1 al nodo i è un ritardo puro. In particolare, essendo d i 1 t l input rate dal link al buffer i-1 e u i t l output rate verso il buffer i successivo, risulta: u i t =d i 1 t T i 1 dove T i 1 è il tempo di propagazione sul link i-1. In Simulink il link verrà quindi modellato nel modo seguente: Figura 3.7: Blocco di ritardo puro La rete completa potrà quindi essere modellata da un cascata di integratori (i nodi) e di ritardi (i link). Vediamo ora come è possibile modellare l overflow rate. Sappiamo che la capacità del buffer di un nodo della rete non è infinita. Quando i pacchetti accodati in attesa di essere trasmessi sul link più opportuno satureranno il buffer del nodo, quelli che arriveranno successivamente verranno persi. In una situazione in cui il buffer è vuoto o solo parzialmente riempito, l overflow rate sarà nullo. Appena il buffer viene saturato dai pacchetti accodati, se il rate di arrivo dei pacchetti non supera il depletion rate, ancora non si hanno perdite. Al contrario, se il rate di arrivo dovesse essere superiore alla capacità di smaltimento dei pacchetti, si avranno 34

5 perdite: in particolare, le perdite saranno pari alla differenza tra il rate di arrivo e il depletion rate. Possiamo dire che il buffer del nodo è saturo quando il livello di coda q(t) raggiunge la capacità del buffer C. Ne deriva che: 0 q t C q t =C u t d t u t d t q t =C u t d t o t = { Per modellare l overflow rate in Simulink è stato creato un sotto sistema con due ingressi: uno di questi è il livello di coda q(t), cioè l uscita dell integratore portata in retroazione, e l altro è la differenza tra il rate di arrivo dei pacchetti u(t) e il depletion rate. E stato utilizzato un blocco If il cui ingresso è, appunto, il livello di coda q(t); i due blocchi If Action Subsystem vengono attivati entrambi dal blocco If. Quando q(t) si mantiene sotto un certo valore di soglia, che rappresenta la massima capacità del buffer (in genere è il prodotto tra la larghezza di banda e l RTT), è attivo il blocco else, e l uscita del sottosistema si mantiene nulla,in quanto l uscita di questo blocco è semplicemente una costante nulla. Ma appena q(t) raggiunge e supera la soglia, viene attivato il blocco if, e l uscita, nel caso u(t) superi d(t), diventa pari alla differenza tra i due rate. In particolare possiamo notare che l ingresso di questo blocco è proprio u(t)-d(t) e quando esso è attivo, l uscita è pari al suo ingresso nel caso sia positiva, cioè se u(t)>d(t); ciò significa che si hanno delle perdite, e questo corrisponde a verità poiché u(t)>d(t) significa che il rate di arrivo sta superando il depletion rate. Al contrario, se u(t)<d(t), cioè il rate di arrivo dei pacchetti è inferiore al depletion rate, risulta che u(t)-d(t)<0, quindi l uscita del blocco che calcola il massimo tra u(t)-d(t) e la costante nulla sarà 0: ciò significa che anche in questo caso le perdite sono nulle, in quanto pur essendo il buffer pieno, il rate di smaltimento dei pacchetti, essendo superiore al rate di arrivo, impedisce che altri pacchetti si accodino nel buffer e vengano persi. Qui di seguito possiamo vedere l intero sottosistema o(t), con l interno dei blocchi If Action Subsystem. 35

6 Figura 3.8:Modellizzazione dell Overflow Rate o(t) 36

7 Passiamo ora ad esaminare la modellizzazione del depletion rate. Se il buffer del nodo è vuoto e quindi non ci sono pacchetti in coda da smaltire, gli unici pacchetti che verranno inviati sul link d uscita saranno quelli che stanno arrivando nel nodo con il loro rate di arrivo. In questo caso il depletion rate sarà quindi pari all input rate u(t) (nel caso questo sia inferiore alla banda disponibile, altrimenti sarà proprio pari alla banda). Naturalmente, appena la coda comincerà a riempirsi, saranno i pacchetti accodati nel buffer a dover essere smaltiti, quindi il depletion rate sarà pari alla larghezza di banda disponibile. Se il buffer dovesse svuotarsi di nuovo, immediatamente d(t) tornerebbe ad inseguire il rate di arrivo. Se la banda disponibile è B (o B(t) nel caso essa non dovesse essere costante nel tempo), si può affermare che: min u t, B q t =0 B q t 0 d t = { La modellizzazione 37urino37o del depletion rate è simile a quella utilizzata per l overflow rate. Anche qui viene creato un sottosistema con due ingressi, uno dei quali è il livello di coda q(t) e l altro è il rate di arrivo dei pacchetti u(t). Il livello di coda è l ingresso del blocco If, che, a seconda del valore di q(t) renderà attivo uno dei due blocchi If Action Subsystem. Come abbiamo visto, se la coda è vuota, cioè q(t)=0, il depletion rate sarà pari ad u(t): in questo caso deve quindi essere attivato il blocco else, che computerà il minimo tra u(t) e il valore della larghezza di banda disponibile, nel caso quest ultima dovesse essere inferiore al rate di arrivo. L uscita sarà il valore assunto dal depletion rate. Nel caso la coda non dovesse essere vuota, cioè q(t)>0, d(t) deve risultare uguale alla larghezza di banda disponibile: viene in questo caso attivato l altro blocco condizionale, che semplicemente pone l uscita d(t) uguale al valore della banda. Di seguito possiamo vedere l interno del sottosistema d(t), con i relativi blocchi condizionali. 37

8 Figura 3.9: Modellizzazione del Depletion Rate d(t) 38

9 Possiamo iniziare a fornire una rappresentazione più completa della coda, aggiungendo i due sottosistemi d(t) e o(t). Figura 3.10: Inserimento dei sottosistemi o(t) e d(t) Come si può notare, l integratore è limitato dalla saturazione inferiore, posta a zero per evitare che la coda assuma valori negativi. 3.2 Calcolo dell RTT Per quanto riguarda il calcolo dell RTT, esso è pari alla somma dei ritardi di propagazione di trasmissione e ricezione del link. Inoltre si è tenuto conto anche del tempo di svuotamento della coda pari al rapporto tra la coda, q(t), e il depletion rate, d(t). Quindi in definitiva l RTT sarà: RTT =T i l q t d t Vediamo di seguito il blocco utilizzato nel sistema dove si può notare che è stata inserita una costante K che rappresenta il limite minimo del depletion rate impostato ad 1 pacchetto/s, visto che si sta parlando in pacchetti/s (in maniera da evitare divisioni per zero). 39

10 Fig. 3.11: blocco RTT 40

11 3.2.1 Calcolo dell RTT medio Come visto nel capitolo 2, il router XCP necessita di calcolare l RTT medio per stimare l intervallo di controllo e il feedback. Il calcolo viene effettuato attraverso il rapporto tra la sommatoria del prodotto di Xi per RTTi, e la sommatoria di Xi effettuate nel precedente intervallo di controllo. Chiaramente, visto che si tratta di un modello fluido, il calcolo dell RTT medio è stato effettuato attraverso un filtro passa basso del primo ordine con funzione di trasferimento pari a k RTT, dove τ = 1 τ s 4 e k dipende dal numero di connessioni effettuate (ogni flusso avrà un RTT diverso) Calcolo di X Per il calcolo di X è stato inserito un blocco che ha in ingresso i valori di cwnd (studiato nel paragrafo successivo) e RTT, e in uscita il valore X. Al suo interno effettua il rapporto dei due valori nel modo seguente: Fig. 3.12: blocco X=RTT/cwnd Come mostrato in Fig. 3.12, il rapporto è effettuato tramite il blocco dove il valore del numeratore è inserito in corrispondenza del per, e il valore del denominatore in corrispondenza del diviso. 41

12 3.3 Uso dello Stateflow Stateflow è un potente strumento di progettazione grafica per il controllo e la supervisione logica, ed è utilizzato insieme a Simulink. Esso permette di descrivere i comportamenti di sistemi complessi in maniera semplice, utilizzando la teoria della macchina a stati finiti, notazioni di diagrammi di flusso e transizioni di stato, tutti inclusi i un unico blocco. Si può affermare che Stateflow è un esempio di macchina a stati finiti. Quest ultima (FSM) è una rappresentazione di un sistema event-driven, in cui si verificano transizioni da uno stato all altro quando la condizione che definisce la transizione è vera. La macchina si può rappresentare tramite transizioni tra stati, che sono attivi a seconda dell occorrenza o meno di eventi sotto certe condizioni. Essa, quindi, può essere rappresentata graficamente da un diagramma Stateflow. La notazione dei diagrammi di flusso è essenzialmente logica, capace di rappresentare strutture di codice come cicli for e costrutti if then else senza l uso degli stati. Il blocco Stateflow si chiama Chart ed è incluso nella libreria di Simulink come segue: Fig. 3.13: blocco Chart Stateflow è costituito da un set di oggetti grafici (stati, transizioni, giunzioni etc.) e non grafici (eventi, dati e obiettivi). Uno stato descrive una modalità di un sistema event-driven. L attività o inattività dello stato cambia dinamicamente in base ad eventi e condizioni. Gli stati hanno etichette che specificano le azioni eseguite in una sequenza basata sul tipo di azione (entry, during, exit ). Gli stati possono essere paralleli (AND) o esclusivi (OR). Questi ultimi sono usati per descrivere modalità che sono mutuamente esclusive. Una transizione è un oggetto grafico che lega un oggetto sorgente ad un oggetto destinazione. Un etichetta descrive le circostanze sotto le quali il sistema si sposta da uno stato all altro. 42

13 Gli oggetti data sono usati per memorizzare valori numerici nel diagramma Stateflow. Essi sono creati e modificati usando lo Stateflow Explorer e possono essere: Locali al diagramma Stateflow Un input al diagramma Stateflow dal suo modello Simulink Un output dal diagramma Stateflow al suo modello Simulink Ci sono anche altri tipi di dati, ma non li menzioniamo perché non vengono utilizzati nella modellizzazione successiva. Una condizione è un espressione booleana che specifica che una transizione avviene quando la condizione specificata è vera. Ogni macchina Stateflow ha la sua gerarchia di oggetti: la macchina è il livello più alto. Vediamo ora come è stato possibile in Simulink regolare un sender generico XCP tramite il feedback calcolato dal router. Come abbiamo visto, il router XCP effettua vari calcoli per poter regolare il throughput del sender. Quindi, prima di tutto è stato implementato il sender, selezionando l oggetto Chart e inserendolo in un blocco chiamato sender. Il sender XCP deve regolare la propria cwnd a seconda del feedback ricevuto, e inoltre deve inviare al router XCP il throughput desiderato. Il blocco sender è il seguente: Fig. 3.14: blocco sender contenente l oggetto Chart Cliccando due volte sull oggetto Chart si accede al suo interno. Attraverso il menu Add si possono inserire i dati che, per quanto riguarda il sender, sono tre di tipo input from Simulink e due di tipo output to Simulink. Tramite il menu Tools e selezionando l opzione Explorer, si possono gestire le variabili create come in figura seguente: 43

14 Fig. 3.15: variabili della Chart relative al sender Come possiamo notare dalla Fig. 3.15, in input sono state create le variabili banda, che rappresenta appunto la banda che verrà impostata successivamente, F, che rappresenta il feedback calcolato dal router ed infine rtt, che rappresenta l RTT visto precedentemente. Come variabili di output sono state impostate w e deltath, che sono rispettivamente la cwnd ed il Delta_Throughput calcolati dal sender stesso. Vediamo ora come si implementano i calcoli effettuati dal sender. Nella chart viene inserito, tramite il pulsante, uno stato, che viene chiamato cwnd contenente le operazioni da effettuare per il calcolo della congestion window e del Delta_Throughput. In particolare otteniamo: Fig. 3.16: operazioni effettuate dallo stato cwnd Prima di tutto, tramite la parola chiave entry, è stata inizializzata la congestion window a 1 [pacchetti/s]; successivamente, le espressioni presenti dopo la parola chiave during (indica che le operazioni durano per tutto il tempo di permanenza nello stato), rappresentano 44

15 rispettivamente la regolazione della cwnd in funzione del feedaback, e l impostazione del Delta_Throughput che è funzione della banda e dell attuale congestion window. Si nota che nel caso di w, il massimo è effettuato tra w + F * rtt e 1, dove 1 è l MSS (minimum segment size) misurato in pacchetti/s. Nel caso di deltath, si sono effettuate delle semplificazioni considerando che il throughput desiderato dal sender è proprio la banda massima, il throughput è stato approssimato come come cwnd/rtt e MSS è pari a 1 come visto precedentemente. Quindi: Delta Throughput = throughput desiderato throughput throughput RTT MSS throughput desiderato =banda cwnd throughput = rtt MSS =1 cwnd =w banda Delta Throughput = E stata inserita (obbligatoriamente), grazie al pulsante w rtt w, una transizione di default per evitare ambiguità. Passiamo all implementazione del router. Come visto nei capitoli precedenti, ci sono tre fasi in cui il router implementa i vari calcoli. Per quanto riguarda la fase di stima dell intervallo di controllo, trattandosi di un modello fluido, alcuni calcoli riguardo l RTT, l RTT medio e X sono già stati effettuati attraverso le implementazioni descritte nei paragrafi precedenti. Di conseguenza sono stati inseriti, all interno di un blocco chiamato Router, due oggetti Chart che implementano rispettivamente la fase di arrivo e la fase di partenza dei pacchetti. Il blocco Router è il seguente: Fig. 3.17: blocco Router Come si può notare in Fig. 3.17, il blocco Router ha in ingresso le seguenti variabili: 45

16 cwnd: è la congestion window. Visto che il router XCP si calcola la somma dei bytes che gli arrivano in un RTT medio (intervallo di controllo), nel nostro caso, trattandosi di pacchetti, la quantità di informazione che arriva al router in un intervallo di controllo è proprio pari alla congestion window corrente (valido per singola connessione); q: è la quantità di pacchetti presenti in coda che servirà per calcolare il feedback; rtt_m: è l RTT medio ricavato attraverso il filtro passa basso con funzione di trasferimento del primo ordine visto nel paragrafo precedente; x: è il tempo di intercorrenza tra i pacchetti come su scritto; deltath: è il Delta_Throughput calcolato dal sender; banda: è la banda che verrà impostata attraverso un altro blocco. In uscita, invece, c è solo la variabile F che rappresenta il feedback totale calcolato all interno del blocco e che sarà l ingresso del sender. Analizziamo ora la parte interna del blocco Router in cui sono presenti i due oggetti Chart. Fig.3.18: oggetti Chart interni al blocco Router Notiamo che le variabili di ingresso al blocco Router comandano in parte il primo oggetto Chart (on packet arrival) ed in parte il secondo oggetto Chart (on packet departure); l uscita (F) è gestita soltanto dal secondo blocco Chart. Inoltre ci sono alcune variabili di uscita del primo blocco che guidano l input del secondo blocco necessarie per il calcolo del feedback. Per quanto riguarda la fase di arrivo dei pacchetti (on packet arrival), nell oggetto Chart sono stati inseriti i seguenti dati: 46

17 Fig. 3.19: dati relativi al blocco della fase di arrivo dei pacchetti (on packet arrival) I primi cinque dati sono di input spiegati precedentemente; i successivi tre dati sono variabili locali e indicano: f: feedback totale corrispondente a Φ specificato nel capitolo 1; intervallo: variabile che verifica se l intervallo di controllo calcolato non va al di sotto di una certa soglia; max2: variabile ausiliaria locale che serve per il calcolo del feedback positivo. Gli ultimi cinque dati sono variabili di output che andranno a guidare il secondo blocco Chart relativo alla fase di partenza dei pacchetti: banda_m: variabile che indicherà, istante per istante, la banda media utilizzata; cn: fattore di scala del feedback negativo per pacchetto (nel nostro caso per flusso poiché è un modello fluido); cp: fattore di scala del feedback positivo per pacchetto (nel nostro caso per flusso poiché è un modello fluido); max1: rappresenta la funzione shuffled traffic (vedi paragrafo1.5.2); 47

18 max3: variabile che serve sia per il calcolo del feedback positivo per pacchetto e sia per il calcolo del feedback relativo ad ogni pacchetto calcolato nella fase successiva. L implementazione dei calcoli, nel blocco Chart, è stata effettuata inserendo un solo stato chiamato packet_arrival rappresentato in figura seguente: Fig. 3.20: stato del blocco on packet arrival I calcoli corrispondono a quelli visti nel paragrafo 2.2.2; chiaramente non sono proprio identici poiché stiamo rappresentando un modello fluido. Infatti si può notare che l RTT medio è già stato calcolato precedentemente, e inoltre: il valore input, che rappresenta la quantità di dati ricevuti dal router in un intervallo di controllo, è pari a cwnd come spiegato precedentemente; il valore sum_x, che rappresenta la sommatoria di X di ogni pacchetto in un intervallo di controllo, nel nostro caso è pari a x*cwnd. Questo perchè si sta considerando una sola sorgente e il conteggio è effettuato in pacchetti\s e non in bytes\s, percui, in un intervallo di controllo (RTT medio RTT), si ricevono un numero di pacchetti pari a cwnd e il valore di Xi sarà uguale per tutti i pacchetti che arrivano nello stesso intervallo. Quindi verranno sommate un numero n di Xi uguali dove n è pari al valore di cwnd, cioè viene sommato lo stesso valore di Xi cwnd volte. Passiamo ora alla fase di partenza dei pacchetti, rappresentata dall oggetto Chart chiamato on packet departure. I dati relativi a questo blocco sono: 48

19 Fig. 3.21: dati relativi al blocco della fase di partenza dei pacchetti (on packet departure) I primi sei dati sono variabili di input, di cui quattro (cn, cp, max1, max3) derivano dal blocco precedente, e due (deltath e x) derivano dall esterno. Per quanto riguarda le variabili locali sono: negfbk: rappresenta il feedback negativo per pacchetto; posfbk: rappresenta il feedback positivo per pacchetto. Infine, l ultimo dato è una variabile di output chiamata feedback, la quale rappresenta il feedback per pacchetto che andrà a regolare il sender. L implementazione dei calcoli è stata effettuata inserendo diversi stati nel blocco Chart in questione: 49

20 Fig. 3.22: rappresentazione degli stati del blocco on packet departure Come si può notare dalla Fig. 3.22, è stato inserito uno stato chiamato fedbk dentro un altro chiamato f, entrambi inseriti nello stato più grande chiamato packet_departure. Inoltre è stato aggiunto, all interno di packet_departure, un altro stato denominato cf il quale contiene a sua volta due stati detti f1 e f2. Selezionando il super stato packet_departure col tasto destro del mouse, e andando sulla voce decomposition è stata selezionata l opzione AND. In questo modo gli stati f e cf risultano essere tratteggiati e possono agire contemporaneamente. Lo stato cf determina i valori del feedback positivo e di quello negativo attraverso le transizioni degli stati f1 e f2; le condizioni di transizione da uno stato all altro sono: deltath <= feedback: vuol dire che il throughput desiderato dal sender è più piccolo di quello allocato dal router e quindi, ricordando le specifiche riportate nel capitolo 2, vengono ricalcolati i valori del feedback positivo e di quello negativo; deltath > feedback: in questo caso il throughput desiderato dal sender è superiore alla capacità allocata dal router, per cui i valori del feedback positivo e di quello negativo non vengono modificati. Contemporaneamente a queste transizioni di stato, lo stato f calcola il valore del feedback opportuno che sarà l uscita del blocco stesso e che verrà inviato al sender. Vediamo, di seguito, il modello completo del controllo di congestione XCP a singola connessione. 50

21 Fig. 3.23: modellizzazione del controllo di congestione XCP a singola connessione Dalla Fig. 3.23, si può notare la presenza di un blocco di colore rosso chiamato Bandwidth in cui viene settata la larghezza di banda. Infatti, nelle simulazioni effettuate sono state 51

22 utilizzate sia bande costanti e sia bande variabili (sinusoidali, a gradini ecc ) per valutare come reagisce XCP in queste condizioni. I risultati saranno commentati nel capitolo Unione di più flussi Oltre alla singola connessione, sono stati realizzati altri due modelli a doppia e a tripla connessione aggiungendo rispettivamente una e due sorgenti che, nel caso di XCP, utilizzano la stessa coda creando un bottleneck del buffer. Per quanto riguarda la connessione di due flussi, è stato aggiunto un altro sender effettuando semplicemente una copia del sender primario. Chiaramente, in questo caso, sono stati sommati gli input rate dei due flussi e il risultato è stato inviato al buffer rappresentato dagli elementi spiegati precedentemente, ovvero l overflow rate (o(t)), il depletion rate (d(t)) e l integratore che somma i pacchetti in ingresso. Per gestire meglio il sistema, sono stati creati dei sottosistemi (sender1 e sender2) che a loro volta contengono l oggetto Chart relativo al sender e il ritardo di propagazione associato al sender stesso come mostrato in figura seguente: Fig. 3.24: contenuto del blocco sender1 Stessa cosa vale per sender2. Inoltre è stato creato un altro sottosistema, chiamato buffer, contenente i blocchi relativi a o(t), d(t) e q(t) come segue: Fig. 3.25: contenuto del blocco buffer 52

23 Gli ingressi al blocco buffer sono la banda data e l input rate che è la somma degli input rates dei due flussi. Per quanto riguarda il router, sono state cambiate alcune variabili come mostrato in figura seguente: Fig. 3.26: blocco Router nel sistema a doppia connessione Analizziamo le nuove variabili di input del blocco Router: sum_cwnd: è la somma delle cwnd relative ai due flussi. Nel caso di due sorgenti, il router riceverà, in un intervallo di controllo, un flusso di bytes pari alla somma dei due flussi, e visto che si sta ragionando in pacchetti/s, il flusso di pacchetti che riceve il router in un RTT medio è proprio la somma delle due cwnd; x e x1: questi due valori rappresentano rispettivamente il tempo di interarrivo dei pacchetti relativi alla prima ed alla seconda sorgente; deltath e deltath1: sono i throughput desiderati dal primo (deltath) e dal secondo sender (deltath1); sum_x: rappresenta la somma dei valori di x e x1 che servirà per calcolare il coefficiente del feedback positivo cp spiegato nel paragrafo precedente; rtt_m: in questo caso l RTT medio è stato calcolato tramite il filtro passa basso con funzione di trasferimento pari a connessioni, e τ = k 1 dove k= poiché si tratta di due 1 τ s 2 RTT. In ingresso al filtro è inviata la somma degli RTT dei due 4 flussi ; q: quantità di pacchetti presenti in coda. Per quanto riguarda le variabili di output, si nota che ci sono due feedback (F e F1) poiché, come visto nei capitoli precedenti, mentre la porzione di feedback positivo è uguale per tutti i flussi, la porzione di feedback negativo è proporzionale al throughput di ognuno. Per questo motivo, nel blocco router, è stato aggiunto un oggetto Chart relativo alla fase di 53

24 partenza dei pacchetti (on packet departure). In questa maniera abbiamo due blocchi Chart che calcolano il feedback in relazione al valore di X del flusso interessato. Fig. 3.27: blocchi interni al sistema Router relativi alla doppia connessione I due oggetti Chart, chiamati on packet departure e on packet departure1, hanno le stesse funzioni interne, ma differiscono le variabili di controllo di input. Infatti ognuno dei due blocchi è funzione di X e del Delta_Throughput relativi al flusso interessato. In questo modo, F viene inviato al primo sender e F1 viene inviato al secondo sender. Vediamo lo schema completo del modello a doppia connessione: 54

25 Fig. 3.28: modellizzazione a doppia connessione 55

26 Si nota che sono stati aggiunti dei sommatori proprio per effettuare le somme relative all input rate, all RTT ed al valore di X. Per quanto riguarda la tripla connessione, sono state effettuate le stesse operazioni viste per la doppia connessione: prima di tutto si è creata un altra sorgente detta sender3 identica alle altre due create precedentemente avente un tempo di propagazione diverso dalle altre; successivamente sono state impostate le somme opportune attraverso i sommatori riguardo RTT, input rate e X; infine, per quanto riguarda il router, è stato creato un ulteriore blocco di Chart che calcola il feedback relativo al terzo sender chiamato on packet departure2 come in figura seguente: Fig. 3.29:blocchi interni al sistema Router relativi alla tripla connessione Si nota che il blocco on packet departure2, oltre ad aver in input le variabili calcolate nella fase di arrivo dei pacchetti (on packet arrival), dipende anche dalle variabili esterne X2 e deltath2 che rappresentano rispettivamente l intervallo di interarrivo dei pacchetti e il Delta_Throughput desiderato provenienti dal terzo flusso (visto anche nel modello a doppia connessione). Vediamo di seguito il modello completo a tripla connessione: 56

27 Fig. 3.30: modellizzazione a tripla connessione 57

28 In questo caso il filtro passa basso, utilizzato per il calcolo dell RTT medio, ha funzione di trasferimento pari a τ= k 1, dove k=, in quanto si tratta di una media di tre flussi, e 1 τ s 3 RTT come nei casi precedenti. 4 58