Core-stateless Fair Queueing

1. Core-statelessFair Queueing Egy skálázható architectúra fair sávszélesség elosztás közelítésére nagysebességű hálózatokon

2. Bevezetés Há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.

3. Bevezetés Az 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 EarlyDrop (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: • A fair kiosztásos módszer fontos szerepet töltenek be a torlódáskezelésben • A komplexitásuk a legnagyobb akadály az alkalmazhatósgukhoz.

4. 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

5. Algoritmusok A – Fluid model Vegyü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.

6. Algoritmusok B - packet A következő feladat hogy az előző algoritmust kiterjesszük olyanná ami közelebb áll a valósághoz: • Csomagokban vannak az adatok • Van bufferelés • A 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

7. Beérkezési sebesség becslése Az 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

8. Fair elosztási sebesség becslése A 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ása • Ha A(t)<= C - nincs torlódás - akkor

9. Fair elosztási sebesség becslése Ha 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

10. Buffer kezelés A 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.

11. Címke újraírás A 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

12. Súlyozott CSFQ Az 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.

13. Implementálási komplexitás Coreroutereken: időben (figyelembe véve a folyamok számát) és méretben is változatlan komplexitású. Edgeroutereken: • Besorolás egy folyamba • Frissíteni a fair elosztási sebesség becslését • Újrabecsülni a folyam sebességét • Megcimké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 edgerouterek nem nagy sebességű gerinc linkeken vannak akkor nem okoznak akkora gondot.

14. Szimulációk FIFO(FirstInFirst Out): • Kiszolgálás fifo sorrendben • Bufferelés egyszerű drop-tail módszerrel RED (Random EarlyDetection): • 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 EarlyDrop): • 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: • Sok csomagja lett eldobva eddig • 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

15. Paraméterek • Minden kimenő link késleltetési ideje: 1ms • Buffer: 64KB • CSFQ buffer határ: 16KB • RED, FRED első határ: 16KB • RED, FRED második határ: 32KB • Folyam sebesség becsléshez konstans: K = 100ms • Fair elosztási sebesség becsléshez konstans: K = 200ms • Az első router az útvonalon edge, az összes többi core.

16. 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ást • DRR: kiemelkedően hatékony • CSFQ, FRED-2: nem tökéletes, de eléggé fair elosztást ért el

17. 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

18. 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.

19. 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.

20. 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.

21. 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

22. Egyéb tesztek • ON-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

24. Kiértékelés • A 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)