Architettura per multimedia

Transcript

1 Architettura per multimedia RTSP Layer 5 RTCP RTP Layer 4 UDP Layer 3 OSPF RTP (mixer & translator) Layer 3 Layer 2 MPLS queuing & scheduling 5 of 18 Queuing & scheduling Example: 1Mbps IP phone, FTP share a 1.5 Mbps link. bursts of FTP can congest router, cause audio loss want to give priority to audio over FTP R1 R2 N.B.: serve marcatura pkt per distinguere classi (DS-TOS byte) priorità secca può produrre starvation in FTP controllo di ammissione per traffico alta priorità isolamento tra classi di traffico 6 of 18 1

2 Politiche di accodamento First-in-first-out nessuna garanzia su ritardo Priorità classe più alta può provicare starvation nelle altre Round Robin divisione equa della bwth tra classi RR conservativa: se quando tocca ad una classe non ci sono pkt suoi, allora si passa a classe successiva Weighted Fair Queuing divisione proporzionale della banda tra classi ad ogni classe è associato un peso w i ogni classe ha banda in frazione pari a w i / (Σ j w j ) 7 of 18 Traffic shaping traffico irregolare (bursty) più difficile da controllare Variable (e.g. Mpeg) vs. Constant Bit Rate rate time customer e carrier si accordano su profilo traffico ammissibile 8 of 18 2

3 Specifica flussi caratteristica input per imformare sistema riguardo a carico generato insieme a servizio richiesto: risorse necessarie per gestione traffico admission control caratteristiche input max pkt size (B) rate medio (B/s) buffer (B) max rate (B/s) tipo servizio loss interval (microsec) [LI] loss [LS], loss rate [LS/LI] loss per burst (pkt) min. delay max jitter 9 of 18 2 processi: Leaky bucket producer genera r token/sec senza credito se non usati prima, non si possono tenere per dopo consumer: quando arriva pkt if token disponibile then invia pkt e decrementa #token disponibili else if esiste spazio in buffer then accoda pkt else pkt dropped 10 of 18 3

4 Leaky bucket in generale: token puo' equivalere a pkt (se pkt size costante) o a # byte/bit NB: cio' non significa che frammento pkt! es: src produce a 200 Mbps per 40 msec; bwth disponibile a src = 2 MBps = 16 Mbps leaky bucket t.c. r l = 16 Mbps ; C l = 8Mb traffico in ingresso al LB: 200 Mbps x sec = 8 Mb <= C l nessun dato e' dropped tempo di uscita dal leaky bucket T = 8 Mb / 16 Mb = 0.5 sec 11 of 18 Token bucket buffer dati illimitato (ideale) bucket contiene token e mantiene credito senza credito: r tasso generazione token e' maximum output rate con credito: r tasso generazione token e' mean output rate r rate time NB: dati sono sempre inviati alla piena bwth del link 12 of 18 4

5 leaky vs. token bucket LEAKY BUCKET TOKEN BUCKET dati input token generator dati input token generator bucket data transm. buffer infinito data transm. bucket to link discard to link discard 13 of 18 token bucket bucket di capacita' C t : drop token in eccesso credito consente burst limitato a breve termine, rispettando rate medio su lungo termine es: bucket pieno a t 0 ; C t = 8 Mb; r t = 16 Mbps; M t = 100 Mbps src produce a 200 Mbps per 20 msec 200 Mbps x 0.02 sec = 4 Mb traffico da smaltire 4 Mb <= C t percio' invio a peak rate durata burst = 4 Mb / 100 Mbps = 40 msec... credito residuo?! posso smaltire piu' di 4 Mb posso smaltire 4 Mb + (r t x 40 msec.) 14 of 18 5

6 token bucket es: src produce a 200 Mbps per 40 msec.; C t = 2 Mb ; r t = 16 Mbps, M t = 200 Mbps; S = durata massima burst dati inviati in S sono M t S = C t + (r t x S) S = C t /(M t - r t ) es: S = 2 Mb / (200 Mbps - 16 Mbps) = 11 msec M t S = 200 Mbps x = 2.2 Mb traffico src = 200 Mbps x sec = 8 Mb rimangono 8 Mb Mb = 5.8 Mb che invio al rate medio r t, smaltendoli in tempo T=5.8/16= 0.36 sec 15 of 18 es. token bucket (appello sett.2012) traffico generato a sorgente traffico inviato a destinazione Elena Pagani RETI di CALCOLATORI A.A. 2008/ of 18 6

7 token + leaky bucket ha senso se r T < r L < M T appiattisco il picco durata burst e' S = C T / (r L - r T ) es: r L = 80 Mbps; r T = 16 Mbps; M T = 200 Mbps; C T = 4 Mb; dati da sorgente di 8 Mb S = 4/(80-16)= sec. in cui smaltisco S x r L = 80 x = 5 Mb restano 8-5=3 Mb che smaltisco a rate r T impiegando un tempo 3/16 = sec. 17 of 18 token bucket + WFQ capacità collegamento: R ; n flussi per ogni flusso i token bucket con parametri r i e C i scheduling WFQ ; peso w i per flusso i Flusso 1: arriva burst di b 1 pacchetti se bucket pieno e b 1 C 1 token rimossi il burst passa subito nella WFQ i pkt sono serviti a tasso R w 1 / (Σ j w j ) l ultimo pkt accumula ritardo complessivo: d max = b 1 / (R w 1 / (Σ j w j ) ) WFQ quindi si può limitare ritardo, oltre a garantire banda of 18 7