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

21
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 Shenker Lixia Zhang Palo Alto Research Center Xerox Corporation

description

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 ShenkerLixia Zhang Palo Alto Research Center Xerox Corporation. Az ISPN fogalma, célja - PowerPoint PPT Presentation

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

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

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

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

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

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

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

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

Ü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

Ü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

Ü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

Ü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

Ü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

Ü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

Ü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

Ü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

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

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

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

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

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

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

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)