Supporting Real-Time Applications in an ISPN: Architecture and Mechanism
description
Transcript of Supporting Real-Time Applications in an ISPN: Architecture and Mechanism
![Page 1: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/1.jpg)
Supporting Real-Time Applications in an ISPN: Architecture and Mechanism
Siska AttilaELTE 2009
David D. Clark
Laboratory for Computer ScienceMassachusetts Institute of Technology
Scott ShenkerLixia Zhang
Palo Alto Research CenterXerox Corporation
![Page 2: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/2.jpg)
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
![Page 3: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/3.jpg)
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.
![Page 4: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/4.jpg)
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).
![Page 5: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/5.jpg)
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ánsAdaptív + toleráns
![Page 6: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/6.jpg)
Szolgáltatási kötelezettségekMi 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).
![Page 7: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/7.jpg)
Ü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.
![Page 8: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/8.jpg)
Ütemezési algoritmusok: garantált szolgáltatás (2/3)
WFQ ütemező algoritmus:
Vegyük adatfolyamok egy halmazát.
rα: az α folyam órajeletiα: 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 α folyambanE
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.
![Page 9: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/9.jpg)
Ü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.
![Page 10: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/10.jpg)
Ü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
![Page 11: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/11.jpg)
Ütemezési algoritmusok:adaptív szolgáltatás (2/3)
Másik elképzelés: prioritásos megosztásAz 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
![Page 12: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/12.jpg)
Ü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.
![Page 13: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/13.jpg)
Ü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!
![Page 14: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/14.jpg)
Ü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.
![Page 15: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/15.jpg)
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ányA szolgáltatás az első hopnál ellenőrzi, hogy a kliens tartja-e a
megadott forgalomjellemzőket; a szabálysértő csomagokat eldobja.
![Page 16: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/16.jpg)
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é.
![Page 17: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/17.jpg)
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örDelay-EDD: csúcsráta korlát + átlagos rátára vonatkozó feltételMARS: 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.
![Page 18: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/18.jpg)
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 jitterHátrány: magasabb átlagos késés
![Page 19: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/19.jpg)
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
![Page 20: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/20.jpg)
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)
![Page 21: Supporting Real-Time Applications in an ISPN: Architecture and Mechanism](https://reader035.fdocuments.net/reader035/viewer/2022062519/568156f1550346895dc4968e/html5/thumbnails/21.jpg)
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)