Supporting Real-Time Applications in an ISPN: Architecture and Mechanism Siska Attila ELTE 2009 David D. Clark Laboratory for Computer Science Massachusetts.

Az előadások a következő témára: "Supporting Real-Time Applications in an ISPN: Architecture and Mechanism Siska Attila ELTE 2009 David D. Clark Laboratory for Computer Science Massachusetts."— Előadás másolata:

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

2 Miről lesz szó?  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

3 ISPN: Integrated Services Packet Network 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.

4 Valósidejű alkalmazások (1/2) 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).

5 Valósidejű alkalmazások (2/2) 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

6 Szolgáltatási kötelezettségek 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: 1.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. 2.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. 3.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).

7 Ütemezési algoritmusok: garantált szolgáltatás (1/3) 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.

8 Ütemezési algoritmusok: garantált szolgáltatás (2/3) WFQ ütemező algoritmus: Vegyük adatfolyamok egy halmazát. r α :az α folyam órajele t i α :az i-edik csomag generálásának időpontja δ i α (t): az α folyam kiszolgált bitjeinek száma t i α és t között (t ≥ t i α ) m α :küldésre váró bitek száma az α folyamban E i α (t) = (m α (t i α ) - δ 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 E i α (t) értéke.

9 Ütemezési algoritmusok: garantált szolgáltatás (3/3) 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.

10 Ütemezési algoritmusok: adaptív szolgáltatás (1/3) 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

11 Ütemezési algoritmusok: adaptív szolgáltatás (2/3) 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

12 Ütemezési algoritmusok: adaptív szolgáltatás (3/3) 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.

13 Ütemezési algoritmusok: az egyesített algoritmus (1/2) 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!

14 Ütemezési algoritmusok: az egyesített algoritmus (2/2) 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.

15 Szolgáltatási interfész 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.

16 Hozzáférés-szabályozás 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é.

17 Kapcsolódó munkák (1/4) 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.

18 Kapcsolódó munkák (2/4) 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

19 Kapcsolódó munkák (3/4) 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

20 Kapcsolódó munkák (4/4) 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)

21 Mai állapot 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)