PRE-ORDER DEFICIT ROUND ROBIN

PRE-ORDER DEFICIT ROUND ROBIN

Bandini Alessio, Fontanelli Giacomo, Gemignani Francesco, Ghionzoli Samuele

Architetture Avanzate di Networking e Sistemi WirelessA.A. 2006/2007

1

OUTLINEAlgoritmo PDRR.Simulazioni di progetto:

Analisi delle prestazioni del PDRR e confronto con le misure effettuate con l'algoritmo DRR nei seguenti scenari:

1. Scenario di default: variazione del numero di nodi da 2 a 10.

2. Variable Forwarding Rate: numero di nodi pari a 5 e variazione del rate di invio del tagged flow tra 200 e 1000 Kbps.

3. Variable Packet Size: numero di nodi pari a 5 e variazione della lunghezza dei pacchetti del tagged flow tra 200 e 1500 bytes.

Valutazione delle misure in condizioni di rete sovraccarica e non.

Conclusioni.

2

ALGORITMO PDRR

3

LIMITI DEL DEFICIT ROUND ROBIN

Ipotesi:Flussi con pacchetti di dimensione fissa (200, 400, 100, 500)Flussi heavily-backloggedQuantum impostato a 400 per ogni flussoI primi pacchetti di ogni flusso arrivano allo stesso istante

4

LIMITI DEL DEFICIT ROUND ROBIN

1. I pacchetti 1, 4 e 6 non rispettano l’ordine di uscita tipico di un modello fluido.

2. I pacchetti 6, 7, 8 e 9 vengono inviati in un singolo burst.3. Elevato tempo di attesa del pacchetto B.

5

SOLUZIONI PROPOSTE

Incremento del QuantumVantaggio: minor tempo di attesa per il pacchetto B.Svantaggio: aumento generale del delay.

Riduzione del QuantumVantaggio: miglior approssimazione del modello a fluido.Svantaggio: aumento della complessità e conseguente aumento del delay.

Pre-Order queueing

6

PRE-ORDER QUEUEING

L’idea di base è:

“ Riordinare la sequenza di trasmissione dei pacchetti risultante dal DRR, e quindi permettere ad ogni flusso di utilizzare il

proprio Quantum in parti più piccole durante tutto il round. ”

PRE-ORDER DEFICIT ROUND ROBIN (PDRR)

7

ARCHITETTURA PDRR

•Assegnamento del Quantum e funzionamento a round identici al DRR.•Distribuzione dei pacchetti in code di priorità.•Preemption. 8

Calcola in quale coda di priorità deve essere inserito il pacchetto.

ARCHITETTURA PDRRCLASSIFIER

⎣ ⎦⎥⎥⎦

⎥

⎢⎢⎣

⎢−=

⎥⎥⎦

⎥

⎢⎢⎣

⎢−=−=

i

mi

i

mim

imi PQG

nterDeficitCouZ

QuantumZnterDeficitCou

ZZQAZp**

ZQuantum

ygranularitqueuepriorityPQG

esimoiflussodelQuantumQuantumqueueing.orderprenelesimompacchettodel

ntol'inserimedopoesimo,iflussodelCounterDeficitnterDeficitCoupriorità.dicodedinumeroZ

QuantumnterDeficitCou

tyAvailabiliQuantumQA

esimo.iflussodelesimompacchettodelprioritàp

ii

i

mi

i

mim

i

mi

==

−=−−

−==

==

−−=

.

9

DRR:Quantum e buffer distinti per flusso.Mantenimento ActiveList.

IMPLEMENTAZIONE PDRRCLASSIFIER:Calcolo delle priorità.Inserimento nelle code di priorità.

PRIORITY QUEUEING:Implementazione con min-heap.Implementazione per flusso e non per

pacchetto.Numero di nodi pari al numero di flussi

attivi.Complessità ~O(Nlog(N))Riordinamento all’interno di una stessa

coda di priorità secondo la sequenza di visita dei flussi attivi.

10

SIMULAZIONE DI VERIFICASCENARIO DI ESEMPIO

11

SIMULAZIONE DI VERIFICAMODELLO TCL

12

La sequenza di uscita è la stessa riportata nell’articolo degli autori.La sequenza di uscita si ripete con periodicità.Ordinamento all’interno della coda di priorità.

13

Quantum del flusso 4 impostato a 2000.

Partenza del flusso 4 ritardata a 5.1 secondi.

2000x1x

4*500)(x4 =⇒=−

−

14

SIMULAZIONI DI PROGETTO

15

STRUMENTI E CONFIGURAZIONISTRUMENTI:

Ns2measureStat utilitiesGnuplot

IMPOSTAZIONI:Bins = 1000MinRun = 5MaxRun = 50

SCRIPT:TclShellGnuplot

METRICHE SCALARI:Valor medio del delay.Valor medio del valore assoluto del jitter.

METRICHE DISTRIBUITE:Distribuzione del delay.Distribuzione del jitter.

Tutte le metriche sono state misurate con intervallo di confidenza al 95%.

16

SIMULAZIONI DI PROGETTOScenario di default

17

SCENARIO DI DEFAULT

18

CONSIDERAZIONI INIZIALIEND-TO-END DELAY

End-to-end delay al variare del numero di code di priorità1. Delay minore per numero di code di priorità multiplo di 3.2. Delay maggiore per numero di code di priorità pari a 2. 19


1. Delay minore per numero di code di priorità multiplo di 3:

Packet Size multipla della granularità.

20


2. Delay maggiore per numero di code di priorità pari a 2:

Buona parte dei pacchetti dei K flussi di “disturbo” hanno dimensione minore di 1000 byte. Tali pacchetti sono in numero più elevato rispetto ai pacchetti del Tagged Flow.

I K flussi si riattivano più velocemente rispetto al Tagged Flow.

I pacchetti del Tagged Flow assumono priorità 2-1-2 periodicamente.

21

CONSIDERAZIONI INIZIALIVALOR MEDIO DEL VALORE ASSOLUTO DEL JITTER

Jitter al variare del numero di code di priorità1. Andamento praticamente costante dopo i primi nodi.2. Attenuazione della burstiness iniziale.3. Diminuzione globale all’aumentare delle code di priorità. 22

CONSIDERAZIONI INIZIALIVALOR MEDIO DEL VALORE ASSOLUTO DEL JITTER

1. Andamento praticamente costante dopo i primi nodi.2. Attenuazione della burstiness iniziale.3. Diminuzione globale all’aumentare delle code di priorità.

Il traffico, distribuendosi su diverse code di priorità, porta alla frammentazione di eventuali burst. All’aumentare del numero di code,

questo fenomeno è sempre più evidente, arrivando quasi a simulare un traffico CBR.

23

SCENARIO DI DEFAULTANALISI DEL DELAY - VALOR MEDIO

Andamento PDRR peggiore del DRR solo per 2 code di priorità:Più del 66% dei pacchetti del tagged flow viene inserito in 2° ed ultima coda.

24

SCENARIO DI DEFAULTANALISI DEL DELAY – DISTRIBUZIONE

DRR

PDRR con 2 code

25

SCENARIO DI DEFAULTANALISI DEL DELAY – DISTRIBUZIONE

DRR

PDRR con 3 code

26

SCENARIO DI DEFAULTANALISI DEL JITTER

L’andamento del PDRR per 2 code di priorità è il peggiore:Più del 66% dei pacchetti del tagged flow viene inserito in 2° ed ultima coda, questo comporta una maggiore irregolarità del traffico e relativo aumento del jitter.

27

SCENARIO DI DEFAULTANALISI DEL DELAY (VALOR MEDIO) – RETE SOVRACCARICA

28

Osservazione 1: incremento complessivo del delay.

Il flusso Tagged Flow è sempre l’ultimo in qualunque coda di priorità venga inserito, dal momento che è l’unico che può

diventare temporaneamente idle. Essendo i flussi k sempre backlogged il Tagged Flow subisce un ritardo maggiore.


29

Osservazione 2: prestazioni PDRR migliori del DRR.

Nel DRR il Tagged Flow occupa sempre l’ultima posizione nell’active list, e quindi deve aspettare che vengano serviti tutti i k

flussi che lo precedono, i quali sono heavily backlogged.


30

SCENARIO DI DEFAULTANALISI DEL JITTER – RETE SOVRACCARICA

31

Osservazione 1: andamento costante senza la presenza del burst iniziale tipico degli scenari precedenti.

Il Tagged Flow viene servito con cadenza costante, similmente adun tipo di traffico CBR.


32

Osservazione 2: nel PDRR, il valor medio del valor assoluto del jitter è minore del caso con rete non sovraccarica.

Avendo più pacchetti per i k flussi, è più improbabile che si formino burst, perché il traffico del Tagged Flow è distribuito su un numero

maggiore di pacchetti.


33

Osservazione 3: nel DRR, il valor medio del valor assoluto del jitter è maggiore del caso con rete non sovraccarica.


Dal momento che la sequenza di burst rimane la stessa e che il traffico generato dai k flussi aumenta, aumenta conseguentementeanche il delay medio fra due burst consecutivi.

34

SIMULAZIONI DI PROGETTOVariable Forwarding Rate

35

VARIABLE FORWARDING RATE

36

VARIABLE FORWARDING RATE ANALISI DEL DELAY - VALOR MEDIO

• Aumento del delay mano a mano che il forwarding rate del Tagged Flow tende al rete di servizio garantito tramite la scelta del Quantum (1 Mbps).

37

VARIABLE FORWARDING RATE ANALISI DEL DELAY – DISTRIBUZIONE

DRR

PDRR con 2 code

38

DRR

PDRR con 3 code

VARIABLE FORWARDING RATE ANALISI DEL DELAY – DISTRIBUZIONE

39

VARIABLE FORWARDING RATE ANALISI DEL JITTER

40

VARIABLE FORWARDING RATE ANALISI DEL DELAY (VALOR MEDIO) – RETE SOVRACCARICA

41

VARIABLE FORWARDING RATE ANALISI DEL JITTER – RETE SOVRACCARICA

42

O.24 Mbps:

Un pacchetto ogni 3 round.

0.29 Mbps: Tempo di trasmissione = 27 ms

Un pacchetto alternativamente ogni 2/3 round.

0.36 Mbps: Tempo di trasmissione = 22 ms

Un pacchetto ogni 2 round.

round urataDàPeriodicit

netrasmissio di Tempo=

VARIABLE FORWARDING RATE ANALISI DEL JITTER PDRR – RETE SOVRACCARICA

ms 1131

10*0.24Mbpsbits 8000

6 =∗=roundD

43

VARIABLE FORWARDING RATE ANALISI DEL JITTER – RETE SOVRACCARICA

44

SIMULAZIONI DI PROGETTOVariable Packet Size

45

VARIABLE PACKET SIZE

46

VARIABLE PACKET SIZE ANALISI DEL DELAY - VALOR MEDIO

47

Osservazione 1: il DRR presenta uno scalino in corrispondenza di packet size pari a 750 bytes.

Per pacchetti di dimensioni inferiori a 750 bytes, il DRR può iniviare almeno 2 pacchetti in ogni round. Ciò non è vero per

dimensioni superiori.


48

Osservazione 2: il PDRR presenta un ritardo migliore per PacketSize=k*granularity, con k=1,…, Z.

Per pacchetti di dimensioni di poco superiori a k*granularity, il delay subisce un degrado istantaneo: ciò dipende dalla priorità

associata ad ogni pacchetto del Tagged Flow.


49


Appena superate le soglie k*granularity, la coda associata al primo pacchetto di un flusso che passa da stato idle a backlogged ha priorità via

via inferiore. Poiché il Tagged Flow alterna spesso fra fasi di idle e di backlogged, subirà un delay maggiore.

50

VARIABLE PACKET SIZE ANALISI DEL DELAY – DISTRIBUZIONE

DRR

PDRR con 2 code

51

VARIABLE PACKET SIZE ANALISI DEL DELAY – DISTRIBUZIONE

DRR

PDRR con 3 code

52

VARIABLE PACKET SIZE ANALISI DEL JITTER

Il jitter del DRR, per pacchetti superiori a 750 bytes, si abbassa drasticamente. Ciò è dovuto alla riduzione del numero di burst. Per il PDRR, l’andamento generale per 3 code di priorità è migliore che per 2, perché un maggior numero di code permette di spezzare in maniera più efficiente i burst (eccetto in prossimità di 750 bytes). 53

VARIABLE PACKET SIZE ANALISI DEL DELAY (VALOR MEDIO) – RETE SOVRACCARICA

Crescita pressochè lineare.DRR: performance migliori per pacchetti di dimensioni tali da sfruttare al meglio il Quantum. PDRR: performance migliori per pacchetti di dimensioni tali da sfruttare al meglio la Granularity, che a sua volta dipende dal Quantum.

54

VARIABLE PACKET SIZE ANALISI DEL JITTER – RETE SOVRACCARICA

55

• Andamento DRR a “campana”:• La componente di jitter dovuta al traffico dei K flussi influisce

maggiormente per pacchetti di dimensioni intorno a 750 bytes.

• Andamento PDRR periodico, proporzionale al numero di code di priorità:• L’andamento DRR si ripete su ciascuna coda, ma con valori minori.• Valori minimi in concomitanza di Packet Size che permettono uno

sfruttamento ottimale della granularità.

VARIABLE PACKET SIZE ANALISI DEL JITTER – RETE SOVRACCARICA

56

750

250

=

=

PS

PS

VARIABLE PACKET SIZE ANALISI DEL JITTER DRR (DISTRIBUZIONE) – RETE SOVRACCARICA

I picchi indicano la presenza di burst:Packet Size < Quantum: mano a mano che la dimensione dei pacchetti si avvicina alla dimensione del Quantum, diminuisce la frequenza dei burst.Packet Size = Quantum: assenza di burst. 57

In un sistema DRR, e quindi anche PDRR, il numero massimo di pacchetti N inviabili durante un round è dato da:

Se N > Z, avremo più di un pacchetto accodato nella stessa coda di priorità.In uno scenario con rete sovraccarica questi pacchetti verrano serviti consecutivamente, formando un burst.

VARIABLE PACKET SIZE OSSERVAZIONI SUL JITTER CON RETE SOVRACCARICA

( ){ }PacketSizeQuantumNPacketSizeN +<Ν∈ *max |

58

VARIABLE PACKET SIZE ANALISI DEL JITTER PDRR (DISTRIBUZIONE) – RETE

SOVRACCARICA

PDRR con 2 code

PDRR con 3 code

PacketSize < 750 Bytes

N > Z

PacketSize < 500 Bytes

N > Z

59

VARIABLE PACKET SIZE ANALISI DEL JITTER PDRR (DISTRIBUZIONE) – RETE

SOVRACCARICA

Quindi per Z=8 non si formano burst (la distribuzione non ha picchi).

8200 =⇒= NPacketSizemin

60

CONCLUSIONI

61

Prestazioni eccellenti in situazioni di rete sovraccarica.

Guadagno in termini di fairness rispetto al DRR.

Maggiore complessità rispetto al DRR.

Dipendenza accentuata dalla granularità.

Prestazioni dipendenti dall’ordine di attivazione.

FINE PRESENTAZIONEGrazie dell’attenzione

62

Verifichiamo l’approssimazione del WFQ:1. Il pacchetto con il più piccolo TS tra tutti i flussi dovrebbe essere servito per primo:

2. Sostituendo , e dividendo il tutto per Quantum, si ottiene:

3. Sostituendo :

4. Teorema 1: per ogni pacchetto si ha .

5. Teorema 2: il pacchetto che ha TS più piccolo, avrà QA più grande.

6. Per il teorema 2, il sistema dovrebbe selezionare il pacchetto con QA maggiore, ma essendo il costo

computazionale troppo elevato, è stato scelto di classificare i pacchetti in code di priorità:

i

mim

imi r

LTSTS += −1

i

mi

mi

i

mi

QuantumLAcc

QuantumAcc +

=−1

mii

mi Acc*rTS =

mii

mi ounter- DeficitCnterDeficitCouAcc 0= m

ii

mi

mi

i

mi QA

QuantumLnterDeficitCou

QuantumnterDeficitCou

=−

=−1

10 , <≤ mi

mi QAP

⎣ ⎦⎥⎥⎦

⎥

⎢⎢⎣

⎢−=

⎥⎥⎦

⎥

⎢⎢⎣

⎢−=−=

i

mi

i

mim

imi PQG

nterDeficitCouZ

QuantumZ*nterDeficitCou

ZZ*QAZp

APPENDICE

Timestamp del pacchetto m-esimo del flusso i-esimo.

Rate allocato al flusso i-esimo.

Lunghezza del pacchetto m-esimo del flusso i-esimo.

Traffico in bytes accumulato fino al pacchetto m-esimo dal flusso i-esimo.==

=

==

imi

mi

mi

i

mi

rTSAcc

L

rTS

* 63

Documents

PRE-ORDER DEFICIT ROUND ROBIN