Supporting Real-Time Applications in an ISPN: Architecture and Mechanism

1. Siska Attila ELTE 2009 Supporting Real-Time Applications in an ISPN: Architecture and Mechanism David D. Clark Laboratory for Computer Science Massachusetts Institute of Technology Scott Shenker Lixia Zhang Palo Alto Research Center Xerox Corporation

2. Az ISPN fogalma, célja Valósidejű alkalmazások osztályozás késedelem Szolgáltatási kötelezettségek Ütemezési algoritmusok Szolgáltatási interfész Hozzáférés-szabályozás Kapcsolódó munkák Miről lesz szó?

3. Hálózatok típusai: - csomagkapcsolt - vonalkapcsolt - (üzenetkapcsolt) Különböző célok, különböző megvalósítás... Célunk: egységes hálózat kialakítása, mely egyszerre alkalmas adat alapú és valósidejű forgalom lebonyolítására. Elképzelés: csomag alapú hálózat felkészítése valósidejű alkalmazások hatékony kezelésére. ISPN: Integrated Services Packet Network

4. Play-back alkalmazások: forrás [jel csomagokra bontása] → továbbítás a hálózaton keresztül → cél [jel visszaállítása] A hálózati továbbítás során a csomagok különböző késedelmi idővel jutnak el a célhoz. Ezt szokás jitter-nek nevezni. A jitter kiküszöböléséhez bufferelni kell a beérkezett csomagokat, és adott időbeli „csúszással” visszajátszani a rekonstruált folyamot. Kérdés: mekkora legyen a csúszás? - Ha túl rövid: nem biztos, hogy elegendő időt hagyunk a csomagok megérkezéséhez. A későn érkező csomagokat nem lehet felhasználni. - Ha túl hosszú: időkritikus (pl. interaktív) alkalmazásoknál problémát jelenthet (pl. beszélgetésnél késik a hang). Valósidejű alkalmazások (1/2)

5. A valósidejű alkalmazásokat kétféle szempont szerint csoportosíthatjuk. Rugalmasság szerint: - Merev alkalmazások: a hálózat által reklámozott késedelmi korlát alapján fix csúszási időt választanak, függetlenül a hálózat aktuális terheltségétől, lehetőségeitől. - Adaptív alkalmazások: a hálózat aktuális képességeihez folyamatosan alkalmozkodva változtatják a csúszási időt. Tűrőképesség szerint: Toleráns / intoleráns alkalmazásokat különböztethetünk meg, attól függően, hogy megengedhető-e esetenként kismértékű deformitás, kiesés a visszajátszásban. Előnyök, hátrányok... Leggyakoribb kombinációk: Merev + intoleráns Adaptív + toleráns Valósidejű alkalmazások (2/2)

6. Mi kell ahhoz, hogy a hálózati szolgáltatás meg tudjon felelni a kliens által támasztott követelményeknek? Mindenképp ismernie kell a kívánt kapcsolat forgalmának jellemzőit. A további feltételek a szolgáltatás típusától függenek: Garantált szolgáltatás: nincs további feltétel. A hálózatnak a legrosszabb esetben is garantálnia kell a zökkenőmentes kapcsolatot. Megfelelő a merev, intoleráns alkalmazások számára. Adaptív (predicted) szolgáltatás: feltételezzük, hogy a közelmúlt hálózati forgalmának jellemzőiből következtethetünk a közeljövőére is. Igyekszik minimális késlekedésű ütemezést biztosítani, cserébe kevésbé megbízható. Ideális adaptív, toleráns alkalmazások számára. Datagram szolgáltatás: semmit nem garantál, kivéve, hogy szükségtelenül nem dob el, ill. nem késleltet csomagokat (legjobb szándék [best effort] elve). Szolgáltatási kötelezettségek

7. Garantált szolgáltatás = forgalomszűrő + ütemezési algoritmus A forgalmi jellemzők leírására ún. token vödör szűrőt használunk. Két paramétere van: ráta (r) és mélység (b). A vödör r rátával tokenekkel telik meg, legfeljebb b mélységben. Amikor csomag generálódik, p db token kikerül a vödörből (p a csomagméret). A forrás megfelel a token vödör szűrőnek, ha mindig van a vödörben elegendő token, amikor egy új csomag generálódik. Ütemezési algoritmusok: garantált szolgáltatás (1/3)

8. WFQ ütemező algoritmus: Vegyük adatfolyamok egy halmazát. rα: az α folyam órajele tiα: az i-edik csomag generálásának időpontja δiα(t): az α folyam kiszolgált bitjeinek száma tiα és t között (t ≥ tiα) mα: küldésre váró bitek száma az α folyamban Eiα(t) = (mα(tiα) - δiα(t)) / rα: a csomag utolsó bitjének elküldéséig várhatóan eltelő idő A WFQ algoritmus t időpillanatban azt a csomagot választja ki küldésre, amelyikre minimális Eiα(t) értéke. Ütemezési algoritmusok: garantált szolgáltatás (2/3)

9. Parekh és Gallager bebizonyították, hogy a WFQ algoritmus garantált szolgáltatási minőséget biztosít (bizonyos feltételek mellett). Továbbá felső becslést adtak bármely folyam sorbanállási várakozási késedelmére, feltéve, hogy a folyam minden switch-ben azonos órajelet kap, és mindegyik switch-ben az órajelek összege nem haladja meg a link sebességét. A WFQ algoritmus megfelel az izoláció követelményének, vagyis egyetlen folyam sem lehet negatív hatással a többire, mivel garantált sávszélesség-részesedést biztosít magas terhelés mellett is. Az algoritmus azonban nem túl alkalmas adaptív szolgáltatás nyújtására, mivel ott a hangsúly az izoláció biztosítása helyett a késlekedési idő minimalizálásán van. Ütemezési algoritmusok: garantált szolgáltatás (3/3)

10. Egy egyszerű példa: vegyünk néhány klienst azonos elvárásokkal. Tegyük fel, hogy mindegyiktől egyenletesen érkeznek a csomagok, kivéve egyet, amelytől hirtelen több csomag érkezik (burst). Vessük össze a WFQ és a FIFO algoritmus viselkedését! WFQ: az egyenletes források csomagjai továbbra is az órajelüknek megfelelően továbbítódnak, a kivételes folyam azonban csak sokára ürül ki. Így itt a késés ugrásszerűen megnő, a többi folyamot azonban nem érinti. Az átlagos késés alacsony marad. FIFO: A feltornyosult csomagsorozat egyben halad tovább, némileg feltartva ezzel a többi folyamot. Az okozott késedelem azonban jóval alacsonyabb, mint a WFQ esetében. A folyamok osztoznak a jitteren, így összességében alacsonyabb késedelmi idő érhető el! WFQ → izoláció FIFO → megosztás Ütemezési algoritmusok:adaptív szolgáltatás (1/3)

11. Másik elképzelés: prioritásos megosztás Az alacsonyabb prioritású folyamok „átvállalják” a magasabb prioritásúak jitterét. Egyik irányban: megosztás (jitter átjátszása) Másik irányban: izoláció (alacsonyabb prioritású nem zavarhatja a magasabb prioritásút) → jitter shifting Ütemezési algoritmusok:adaptív szolgáltatás (2/3)

12. Probléma a FIFO-val: több linken keresztülhaladva a megosztásból adódó késések nagymértékben felhalmozódhatnak egy folyamra. Hogyan terjeszthetnénk ki a megosztást a teljes útvonalra? FIFO+ algoritmus: A folyamokat osztályokba soroljuk. Minden switchen belül, minden osztályra kiszámítjuk a csomagok átlagos várakozási idejét. Minden csomag fejlécében egy mezőhöz hozzáadjuk (kivonjuk) a csomag aktuális várakozási idejének és az osztálya átlagos várakozási idejének az eltérését. A csomagokat ez alapján rendezzük, vagyis aszerint, hogy mikor kellett volna megérkezniük, ha valóban „átlagos” kiszolgálást kapnak. Ütemezési algoritmusok:adaptív szolgáltatás (3/3)

13. Eddig: szolgáltatás-specifikus algoritmusok Önmagában egyik sem alkalmas mindhárom szolgáltatás (garantált, adaptív, datagram) hatékony nyújtására. Hozzunk létre olyan algoritmust, amelyik képes mindhárom elvárásnak megfelelni! Alapötlet: különítsük el a garantált szolgáltatást igénylő klienseket egymástól, ill. az egyéb szolgáltatásoktól. Minden garantált szolgáltatású kliens egy külön folyamot kap. Az adaptív és datagram szolgáltatásokat egy pszeudo-folyamban egyesítjük. Ezen a szinten alkalmazzunk WFQ ütemezést! Ütemezési algoritmusok:az egyesített algoritmus (1/2)

14. A pszeudo-folyamon belül a folyamokat osztályokba soroljuk, és mindegyik osztályhoz prioritást rendelünk. Az osztályokon belül FIFO+ ütemezést alkalmazunk. A datagram folyamok a legalacsonyabb prioritás-osztályhoz tartoznak. A felette lévő szintekhez küszöbértékeket rendelünk: megadjuk az osztályba tartozó folyamok csomagjainak maximális várakozási idejét. Hozzáférés-szabályozással megpróbáljuk az aktuális várakozási időket jóval a korlátok alatt tartani. Reklámozott várakozási idő: - Garantált szolgáltatás: a Parekh-Gallager korlát - Adaptív szolgáltatás: a küszöbértékek összege a hopok mentén Célszerű a datagram szolgáltatásnak legalább 10% átlagos rátát biztosítani. Ütemezési algoritmusok:az egyesített algoritmus (2/2)

15. Garantált szolgáltatás: a kliensnek csak a kívánt órajelet kell megadnia. Ebből saját maga meghatározhatja a várakozási időt a legrosszabb esetben. Ha nem elég jó, magasabb órajelet kell kérnie. A forgalom jellemzőire nincs megkötés. Adaptív szolgáltatás: egyaránt szükséges a forgalomjellemzők és a kért szolgáltatási minőség meghatározása. - Forgalomjellemzők: token vödör szűrő paraméterei (r, b) - Szolgáltatási minőség: késedelmi idő és csomagvesztési arány A szolgáltatás az első hopnál ellenőrzi, hogy a kliens tartja-e a megadott forgalomjellemzőket; a szabálysértő csomagokat eldobja. Szolgáltatási interfész

16. Feladat: meghatározni, hogy egy új valósidejű folyam elvállalható-e a megfelelő szolgáltatásnyújtás veszélyeztetése nélkül. 1. kritérium: A valósidejű folyamok a rendelkezésre álló sávszélesség legfeljebb 90%-át foglalhatják le. 2. kritérium: A folyam hozzáadása ne növelje meg az adaptív folyamok várakozási idejét a hozzátartozó osztály korlátja fölé. Hozzáférés-szabályozás

17. WFQ-hoz hasonló ütemezési algoritmusok: - Delay-EDD (Earliest Due Date) - MARS (Magnet II Real-Time Scheduling Algorithm) Közös elv: „határidős” ütemezések (deadline scheduling) Eltérő forgalomszűrők: WFQ: token vödör Delay-EDD: csúcsráta korlát + átlagos rátára vonatkozó feltétel MARS: nincs explicit szűrő → nincs garantált késedelmi korlát, szimulációk alapján ad becsléseket Ezek ún. work-conserving ütemezések: a link aktív, ha van továbbításra váró csomag. Kapcsolódó munkák (1/4)

18. Léteznek non-work-conserving ütemezések is: - Stop-and-Go - HRR (Hierarchical Round Robin) - Jitter-EDD Szintén határidős ütemezések, de a link nem feltétlenül aktív várakozó csomagok esetén: a csomagok nem továbbítódhatnak „túl korán”. Előny: alacsonyabb jitter Hátrány: magasabb átlagos késés Kapcsolódó munkák (2/4)

19. A legtöbb algoritmus (pl. Delay-EDD, Jitter-EDD, HRR) csak garantált szolgáltatást támogat, vagyis izolációra törekszik. Kivételek: 1. MARS - adaptív szolgáltatás - megosztásra öszpontosít - nem támogat izolációt, ezáltal garantált szolgáltatást sem - „a priori” statisztikai korlátok, analítikus becslések vagy szimulációk alapján 2. Jacobson-Floyd - adaptív szolgáltatás a hálózati viszonyokhoz alkalmazkodva - prioritások használata megosztásra és izolációra - forgalomszűrők a teljes útvonalon, minden switch-re - osztályon belül FIFO helyett Round Robin - nem támogat garantált szolgáltatást Kapcsolódó munkák (3/4)

20. R. Guérin, L. Gün, H. Ahmadi, M. Naghshineh: Hozzáférés-szabályozás „ekvivalens kapacitások” alapján Cél: Egységes mérték létrehozása a kapcsolatok által használt effektív sávszélességre és a megfelelő linkek effektív terheltségére. Egyszerűen számolható becslést ad sávszélesség-igényre vonatkozóan mind különálló, mind multiplexált kapcsolatok számára, figyelembevéve: - statisztikai jellemzőket - a kívánt szolgáltatási minőséget (Grade-of-Service) Kapcsolódó munkák (4/4)

21. Quality of Service (QoS) Internet Engineering Task Force (IETF) két modelt definiál: 1. Integrated Services (IntServ) 2. Differentiated Services (DiffServ) IntServ: - Resource Reservation Protocol (RSVP) alapú - Két szolgáltatástípust támogat: garantált és „kontrollált terhelés” DiffServ: - Forgalmi osztályok definiálása: Class of Service (CoS) - Type of Service (ToS) jelzés az IP fejlécben - Speciális továbbítás ToS alapján: Per-Hop-Behavior (PHB) Mai állapot