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)