Upload
winka
View
59
Download
0
Embed Size (px)
DESCRIPTION
Core-stateless Fair Queueing. Egy skálázható architectúra fair sávszélesség elosztás közelítésére nagysebességű hálózatokon. Bevezetés. Hálózati torlódás okai lehetnek: hosztoktól nagy forgalom érkezik, a csomópontok képtelenek megbirkózni vele. - PowerPoint PPT Presentation
Citation preview
Egy skálázható architectúra fair sávszélesség elosztás közelítésére nagysebességű
hálózatokon
BevezetésHálózati torlódás okai lehetnek: hosztoktól nagy forgalom érkezik, a csomópontok képtelenek
megbirkózni vele. várakozó sor alakul ki egy ponton, kevés a memória az összes
beérkező üzenet befogadásához lassú processzor, adminisztratív feladatok lassú elvégzése miatt
nem kerülnek be az egyébként üresen várakozó memóriába. kis vonalkapacitás Következmény: Torlódás alakul ki, majd csomagvesztés, idővel a teljes hálózat
összeomlik.
A torlódás globális jelenség, vagyis a hálózat egészére vonatkozó módszert kell találni az átbocsátóképesség növelésének érdekében.
BevezetésAz fair sávszélesség kiosztásnak több előnye is van: Megvédik a jól viselkedő folyamokat a hibásaktól Lehetővé teszi több különböző torlódáskezelő eljárás együttes használatát
Mostanáig a fair kiosztásra: Fair queueing - folyamonkénti ütemezéses módszer Flow Random Early Drop (FRED) - folyamonkénti eldobásos módszer
Tulajdonságaik: Állapotkezelés (folyamonkénti) Buffer kezelés És/vagy folyamonkénti csomag ütemezés Ezek miatt komplexek, nem implementálhatóak költséghatékonyan
Tegyük fel:1) A fair kiosztásos módszer fontos szerepet töltenek be a torlódáskezelésben2) A komplexitásuk a legnagyobb akadály az alkalmazhatósgukhoz.
Core-stateless fair queueing
‘edge’ : folyamonkénti állapot tárolás. Megbecsülik a beérkező folyamok rangját és ez alapján cimkét helyeznek el a csomag header-jébe.
‘core’ : nem tárolnak folyamonkénti állapotot. FIFO ütemezés. A cimkék és a router összesített forgalmi becslése alapján valószínűsített eldobási algoritmussal működnek.
Egy ilyen felépítést hívunk „Core-stateless fair queueing”-nak amire igaz:
Jelentősen csökkenti az implementálási komplexitást Még mindig korrekt sávszélesség kiosztást biztosít
Algoritmusok A – Fluid modelVegyük a folyamot most egy összefüggő bitfolyamnak. Nincs bufferelés.Legyenek: C – kimenő link sebesség t - idő ri(t) – érkezési sebesség (minden folyamra pontosan ismertnek
tekintjük) α(t) – minden folyamra azonos kimenő sebesség (fair elosztási
sebesség)a max-min elosztási módszer alapján minden folyam min(ri(t),α(t)) sebességet kap.
A(t) = összes beérkezési sebesség.Ha A(t) > C akkor α(t) egy egyedi megoldása az
egyenletnek itt ha akkor minden továbbítva lesz, egyébként csak α(t).
Ha A(t) <= C akkor nem dobunk el semmit és Ez egy egyszerű valószínűségi továbbító algoritmus lesz ami fair
elosztást ér el.Minden bejövő folyam eséllyel lesz eldobva.
n
ii tr
1)(
n
ii ttr
1))(),(min(
)(max)( trt ii)()( ttri
)(
)(1,0max
tr
t
i
Algoritmusok B - packetA következő feladat hogy az előző algoritmust
kiterjesszük olyanná ami közelebb áll a valósághoz:
Csomagokban vannak az adatokVan bufferelésA beérkező sebességet nem ismerjük előre
Még mindig a beérkezéskor eldobó sémát alkalmazunk annyi különbséggel,hogy most csomagokkal tesszük.
Mivel a sebesség becslés magában foglalja a csomag méretet, az eldobási valószínűség nem függ tőle, csak a bejövő és a fair elosztási sebességtől.
Ezt a kettőt még ki kell számolni
Beérkezési sebesség becsléseAz edge routereken egy folyam sebességének
becslésére exponenciális mozgóátlag számítást használunk.
az i folyam k-adik csomagjának érkezési ideje az i folyam k-adik csomagjának hossza
Minden i folyam sebességére a becslés képlete:
Ahol és K egy konstans
kitkil
oldiKT
ki
kiKTnew
i reT
ler
ki
ki
,//1
1 ki
ki
ki ttT
Fair elosztási sebesség becsléseA sebesség amivel az algoritmus elfogadja a csomagokat [
] a fair elosztási sebesség jelenlegi becslésének függvénye [ ].
Ez a függvény függ attól,hogy a link túlterhelt-e:Ha A(t) >C – torlódás - akkor az megoldásaHa A(t)<= C - nincs torlódás - akkor
)(ˆ t )(ˆ tF
n
ii ttrtF
1)(ˆ),(min)(ˆ
)(ˆ t
)(max)(ˆ 1 trt ini
CtF )(
Fair elosztási sebesség becsléseHa ismerjük a beérkező sebességeket, Ki tudnánk számolni
közvetlenül a képletből is, de hogy elkerüljük az állapot tárolást, csak aggregált adatokra támaszkodva számítunk.
Legyenek: - a becsült fair elosztási sebesség - a becsült összesített beérkező sebesség - a becsült elfogadott sebesség T - csomagérkezési időköz
Az utóbbi kettőt minden csomag beérkezésekor frissítjük exponenciális átlag számítással
Hogy kiszűrjük a kerekítésből származó becslési pontatlanságokat, az időt Kc időintervallumokra osztjuk és -t csak ezek végén frissítjük a link terheltségétől függően
A
F
oldKTKT
new AeT
leA ˆ1ˆ //
F
Coldnew ˆˆˆ
Buffer kezelésA fair elosztási sebesség becslésének célja az elfogadott sebesség és a
sávszélesség közelítése, mi van ha ez a sebesség eléri a sávszélességet?
Okok: becslési pontatlanságok Az frissítések közötti töltési különbségek az algoritmus valószínűségi természete
Normál esetben a buffer el tudja tárolni a csomagokat, de néha el kell dobni őket. Mivel a drop-tail ellenkezik az algoritmus céljaival és néha beszámíthatatlan tulajdonságai vannak, így ennek a hatásait limitálni kell.
Bevezetünk egy egyszerű heurisztikát: Minden buffer túlcsordulásnál leveszünk egy kis (előre fixen
meghatározott) százalékot az ból. Nem többet mint 25%, hogy elkerüljük a túlkorrigálást. Feltesszük, hogy a link ami ‘nem zsúfolttá’ válik az ellenőrzéskor, a
buffer egy előre meghatározott határértékéig az is marad.
Címke újraírásA cimkékben lévő becsült sebesség pontatlanná
válhat(például mert a csomag belefutott egy túlterhelt linkbe a
szigeten belül)
minden routeren finomítani kell )(,min tLL oldnew
Súlyozott CSFQAz algoritmus kiterjeszthető úgy, hogy folyamonként
súlyozható legyen. Legyen az i folyam súlya.
Ekkor ha A(t) > C az
Az eldobási valószínűség pedig így módosul
A folyékony modellben ez azt jelenti, hogy a értéke ugyanaz lesz minden folyamra. A cimkékbe pedig kerül a sima ri(t) helyett.
Fontos, hogy csak olyan szigeteket tudunk kezelni az algoritmusunkkal melyeken belül egy folyamnak minden routeren ugyanaz a súlya, de még ezzel a megkötéssel is értékes módszer.
i
i
ir
)(t Ctr
tn
ii
ii
1
)(),(min
i
i trt
)()(1,0
i
i tr
)(
Implementálási komplexitásCore routereken:
időben (figyelembe véve a folyamok számát) és méretben is változatlan komplexitású.
Edge routereken:Besorolás egy folyambaFrissíteni a fair elosztási sebesség becslésétÚjrabecsülni a folyam sebességétMegcimkézni a csomagot
bár ezeket minden csomagra meg kell csinálnia, a besorolás kivételével mind könnyen implementálhatóak ma már. A besorolás algoritmusai viszont ma is aktív kutatás alatt állnak, de ha az edge routerek nem nagy sebességű gerinc linkeken vannak akkor nem okoznak akkora gondot.
SzimulációkFIFO(First In First Out): Kiszolgálás fifo sorrendben Bufferelés egyszerű drop-tail módszerrelRED (Random Early Detection): Kiszolgálás Fifo sorrendben Bufferelés valószínűségi eldobás két határértékkel. (Első alatt nem dob semmit, a
második felett mindent, a kettő közt a telitettséggel lineárisan nő az eldobás esélye.)FRED (Fair Random Early Drop): Kiszolgálás: fair queueing Állapot tárolás minden folyamhoz aminek legalább egy csomagja van a bufferben Bufferelés: az eldobás nem csak a buffer telitettségétől függ, hanem az állapottól is Eldobáskor preferálja azokat amiknek:
1. Sok csomagja lett eldobva eddig2. A sora hosszabb mint az átlagos
Két verziója van (FRED-1, FRED-2), a különbség csak annyi, hogy a második mindig biztosít egy minimális mennyiségű helyet minden folyamnak a bufferben. Mindig azt vesszük amelyik épp jobb.
DRR (Deficit Round Robin): Kiszolgálás: fair queueing Bufferelés: mikor a buffer tele a leghosszabb sorból dob el csomagot A Weighted Fair Queueing (WFQ) egy hatékony implementálása
ParaméterekMinden kimenő link késleltetési ideje: 1msBuffer: 64KBCSFQ buffer határ: 16KBRED, FRED első határ: 16KBRED, FRED második határ: 32KBFolyam sebesség becsléshez konstans: K = 100msFair elosztási sebesség becsléshez konstans: K =
200msAz első router az útvonalon edge, az összes többi
core.
Egy torlódott link
Teszt 1: 32 CBR folyam ahol minden i folyam (i + 1)es adatmennyiséget
küld. 10mp időintervallum.Eredmény: FIFO,RED,FRED-1: nem ért el fair elosztástDRR: kiemelkedően hatékonyCSFQ, FRED-2: nem tökéletes, de eléggé fair elosztást ért el
Egy torlódott link
Teszt 2: • 1 CBR folyam ami 10Mbps el küld + 30 TCP folyam. • 10mp időintervallum.Eredmény: • Csak a DRR és a CSFQ volt képes hatékonyan beépíteni a CBR
folyamot.• FRED: a CBR közel 6x annyit sávszélességet (1,8Mbps) kapott
mint ami fair• FIFI, RED: rossz teljesítmény közel 8Mbps-t adott a CBR-nek
Egy torlódott link
Teszt 3 (30 darab teszt): • 1 TCP folyam + 1..30 CBR folyam. Minden CBR a fair
kétszeresével küld.• 10mp időintervallum.Eredmény: • A DRR 22 CBR-ig jó, utána folyamatosan romló teljesítményt ad.• A CSFQ jobban teljesít mint a DRR ha sok a folyam.• A CSFQ végig hasonló vagy jobb teljesítményt ad mint a FRED.
Több torlódott link
•CBR0 kivételével az összes CBR 2Mbps –el küld így az összes link torlódik.•Majd megpróbálunk az így torlódott routereken átküldeni 1-1 CBR illetve TCP folyamot amik a saját fair elosztási sebességükön (0.909Mbps) adnak.
Több torlódott link
Teszt 1: • 1 CBR folyam. Eredmény: • CSFQ, FRED elég jól teljesít de elmaradnak a DRR-től• FIFO, RED minél több torlódott linken megy át annál
rosszabb.
Több torlódott link
Teszt 2: • 1 TCP folyam. Eredmény: • CSFQ, DRR: elég hatékonynak bizonyulnak.• FRED: jelentősen rosszabb náluk de még mindig jobb mint
FIFO, RED• Folyamok különböző end-to-end torlódás kezelő
algoritmusokkal mindig különböző átviteli sebességet érnek el, még ha a
Egyéb tesztekON-OFF folyamok:
DRR,CSFQ, FRED megint jól elosztotta a sávszélességet.
TCP folyamok - 0.1ms késleltetési idő( web forgalomhoz hasonló)átlagos idő és eltérés
RLM (Receiver-driven Layered Multicast) folyamok
KiértékelésA legtöbb feltétel mellett elfogadható fair
sávszélesség elosztás közelítést ér el.
A jelenleg leginkább használt (FIFO, RED) módszereket messze felülmúlja.
Sőt minden helyzetben a FRED-hez hasonló eredményt ér el, miközben jelentősen fairebben osztja a sávszélességet.
Még bőven fejleszthető és javítható (pl: a bufferkezelő-algoritmusa, szeretnék közelíteni a RED eljáráséhoz)