Budapesti Muszaki és Gazdasági Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Telematikai Tanszék
ATM VC and VP shaping Szaszkó Sándor
Konzulensek:
Baumann Ferenc, BME
Juhász Imre, Telia Prosoft AB.
Stockholm, 2001
Tartalomjegyzék TARTALOMJEGYZÉK ............................................................................II ÁBRAJEGYZÉK.........................................................................................IV TÁBLÁZATJEGYZÉK.............................................................................. V 1.
BEVEZETÉS..........................................................................................1 1.1.
A diplomamunka témája .................................................................2
1.2.
A dolgozat szerkezete.......................................................................2
2. ALAPGONDOLATOK DSL-ROL ÉS FORGALOMFORMÁZÁSRÓL ...........................................................................3 2.1.
DSL....................................................................................................3
2.1.1. Muködése ......................................................................................3 2.1.2. A DSL típusai................................................................................4 2.2. Forgalomformázás ...........................................................................5 2.2.1. Forgalmi osztályok........................................................................5 2.3. Forgalomformázás modellje és megvalósítása..............................6 2.3.1. Leaky és token bucket...................................................................6 2.3.2. GCRA (Generic Cell Rate Algorithm) .........................................8 2.4. Cella- és csomageldobás ..................................................................8
3.
AZ ADSL FELHASZNÁLÓK......................................................... 10 3.1.
Forgalommal kapcsolatos tendenciák az Interneten..................10
3.1.1. Az Ames Internet Exchange megfigyelése .................................12 3.1.2. UDP/TCP arány ..........................................................................13 3.1.3. TCP alkalmazások.......................................................................15 3.1.4. UDP alkalmazások ......................................................................17 3.1.5. Csomaghossz szerinti eloszlás ....................................................19 3.2. Rövid áttekintés a TCP-rol ...........................................................21 3.2.1. Streaming és sebességadaptivitás................................................21 3.2.2. Csúszó ablak protokoll................................................................22 3.2.3. Nagyméretu ablak opció (Window scale option) ........................23 3.2.4. Buta ablak szindróma..................................................................24 3.3. TCP forgalomanalízis ....................................................................25 3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5.
A mérés célja...............................................................................25 Mérési elrendezés........................................................................26 Mérés menete ..............................................................................29 Mérési eredmények .....................................................................29 Összegzés....................................................................................32 II
4.
ÁLLANDÓ SEBESSÉGRE FORMÁZOTT FORGALOM ..... 33 4.1.
Forgalomformázás VP-n ...............................................................33
4.1.1. Milyen forgalmi osztályt válaszunk? ..........................................34 4.1.2. Követelmények ...........................................................................34 4.1.3. VP forgalomformázás megfeleloségi vizsgálata.........................35 4.1.4. PCR meghatározása ...................................................................36 4.1.5. CDV meghatározása ...................................................................37 4.2. Forgalomformázás VC-n...............................................................38 4.2.1. 4.2.2. 4.2.3. 4.2.4.
5.
CBR és UBR+ .............................................................................38 PCR meghatározása ....................................................................39 CDV meghatározása ...................................................................40 Elonyök és hátrányok..................................................................40
VÁLTOZÓ SEBESSÉGRE FORMÁZOTT FORGALOM ..... 42 5.1.
VBR forgalmi osztályon létesített TCP kapcsolat elemzése.......42
5.1.1. A tanulmány célja .......................................................................43 5.1.2. A mérés összeállítása és menete .................................................43 5.1.3. Eredmények ................................................................................44 5.2. VBR forgalomformázás VC-n ......................................................46 5.2.1. MBS megválasztása ....................................................................46 5.2.2. PCR megválasztása .....................................................................47 5.2.3. Elonyök és hátrányok..................................................................49 5.3. Az SMS túlterheléses viselkedésének vizsgálata .........................51 5.3.1. 5.3.2. 5.3.3.
6.
7.
A mérés célja...............................................................................52 A mérés összeállítása és menete .................................................52 Eredmények ................................................................................53
BUFFER MÉRET KEZELÉSE ...................................................... 56 6.1.
A mérés célja...................................................................................56
6.2.
Mérés összeállítása és menete........................................................56
6.3.
Eredmények....................................................................................57
6.4.
Összefoglalás...................................................................................59
ÖSSZEFOGLALÁS ........................................................................... 60
KÖSZÖNETNYILVÁNÍTÁS .................................................................. 61 A FÜGGELÉK............................................................................................ 62 B FÜGGELÉK............................................................................................ 63 IRODALOMJEGYZÉK ........................................................................... 64
III
Ábrajegyzék 2-1. ábra DSL redszerfelépítés.......................................................................................4 2-2. ábra Leaky bucket...................................................................................................6 2-3. ábra Token bucket...................................................................................................7 2-4. ábra Azonos értéku két verziója a GRCA-nak .......................................................9 3-1. ábra A megfigyelt link helye a NASA-Ames és MAE-West között. ...................13 3-2. ábra A két legfobb protokoll csomagjainak részesedése ......................................15 3-3. ábra IPSEC részesedés..........................................................................................16 3-4. ábra FTP arány......................................................................................................17 3-5. ábra A RealAudio részesedése..............................................................................19 3-6. ábra Csomagméretek szerinti összesített eloszlás 2000 februárban.....................20 3-7. ábra TCP csúszó ablak..........................................................................................23 3-8. ábra Sávszélesség számítás...................................................................................23 3-9. ábra A TCP forgalomanalízis mérési elrendezése ................................................27 3-10. ábra Letöltés Finnországból Linuxxal ................................................................30 3-11. ábra Letöltés WIN2000-rel Dániából .................................................................31 3-12. ábra Letöltés nagytávolságból ............................................................................31 4-1. ábra VP forgalomformázási mérés összeállítása ..................................................35 4-2. ábra VP forgalomformázás, SMS1 és SMS2 eredményei....................................36 4-3. ábra Csomag hosszúság eloszlási modell .............................................................40 4-4. ábra AAL5 snap csomagolás többlete (overheadje) .............................................40 5-1. ábra [SAno97]-ben használt mérési elrendezés ....................................................44 5-2. ábra SCR és MBS elméleti becslése .....................................................................45 5-3. ábra MBS függése a TCP kapcsolatok számától..................................................46 5-4. ábra Elérheto átviteli sebesség a távolság függvényében lakóöve zetben............48 5-5. ábra Buffer igény UBR+ és VBR esetén..............................................................50 5-6. ábra SMS1 túlterhelési vizsgálat ..........................................................................52 5-7. ábra MBS és BT közti összefüggés ......................................................................52 5-8. ábra Egy elofizeto csomagjainak érkezési sebessége ...........................................54 5-9. ábra Egy elofizeto celláinak érkezési sebessége ...................................................55 6-1. ábra Buffer méret mérés összeállítása ..................................................................56 6-2. ábra SMS1 bufferméret.........................................................................................58 6-3. ábra SMS2 bufferolt csomagok az felhasználószám függésében.........................58 6-4. ábra SMS2 Felhasználónkénti bufferméret ..........................................................59
IV
Táblázatjegyzék 3-1. táblázat Elso 10 legelterjedtebb protokoll 2000 februári vizsgálat alapján..........13 3-2. táblázat A 6 legjelentosebb TCP alkalmazáskategória 2000 február és 1998 áprilisa között........................................................................................................16 3-3. táblázat A 25 legjelentosebb UDP alkalmazáskategória 2000 februárjában........18 3-4. táblázat Minta az feldolgozott adatokra................................................................29 3-5. táblázat Késletetett nyugta a WIN200-tol ............................................................31 3-6. táblázat Max. bust méret operációsrendszerek szerint .........................................32 5-1. táblázat Méréssel kapott MBS és SCR értékek ....................................................45 5-2. táblázat DSLAM buffer méretek ..........................................................................49 6-1. táblázat SMS1 felhasználónkénti bufferméret......................................................57
V
1. Bevezetés Nem csak az Internetezok száma, de az egy felhasználó által átlagosan az Interneten lebonyolított adatforgalom is nagy ütemben növekszik, az újabb és újabb szolgáltatások egyre nagyobb sávszélességet igényelnek. Ennek nem csak az az oka, hogy
az
intelligensebb
alkalmazás
többletszolgáltatáshoz
több
adat
mozgatása
szükséges, de az is, hogy a fejlesztési ido és a költség csökkentése miatt nagyobb a továbbított információ redundanciája. A XXI. század elejének kihívása: nagysebességu Internet kapcsolattal ellátni a háztartásokat is, mert a ma elterjedt, maximum 56 kbps-os (ISDN, esetén 128 kbpsos) modemes kapcsolat már nem képes kiszolgálni egy teljes értéku Internet hozzáférési pontot.* Ennek megvalósításában egyértelmuen oroszlánrészt kap a DSL (Digital Subscriber Line) technológia, amely a 3-4 km-nél rövidebb telefonvezetékkel rendelkezo elofizetoknek akár 8, de legalább 0,5 Mbps-os adatkapcsolatot képes biztosítani újabb vezetékek kihúzása nélkül. Az DSL a nagyobb sávszélesség mellett a garantált minoségu szolgáltatásokat is elérhetové teszi. Az elofizeto és a DSL szolgáltató egy központi kapcsolója között valójában ATM kapcsolat van és amint ez jól tudjuk, az IP hálózattal ellentétben az ATM képes biztosítani garantált minoségu szolgáltatást nagy hálózatok esetén is. Valójában –mivel az ATM használata az elofizetoi végpontoknál nem elterjedt– az ATM-t teljesen elfedik az DSL modemben és az Internet-ATM hálózat határán végzett csomagolással, de a szolgáltatónak így is megvan a lehetosége, hogy az ATM nyújtotta
minoségi
szolgáltatásokat
kihasználja
a
forgalom
karakterisztikájának
kialakításánál. Jelenleg a Telia foleg tallózásra szánja a nem régen bevezetett, 0,5 és 2 Mbpsos XDSL szolgáltatását. Az Internet és ATM hálózat határán elhelyezkedo SMS-ben (Subscriber Managment System) történik a forgalomformázás, mind az elofizetoi kapcsolatonkénti formázás, mind az SMS, DSLAM közti, sok elofizeto forgalmát összefogó kapcsolat formázása.
*
A fejlodés ütemét érzékelteti, csupán tíz éve annak, hogy az USA egyik nagy egyetemének, a
Kalifornia Egyetemnek egyetlen 56 kbps-os kapcsolata volt az Internethez.
1
1.1.
A diplomamunka témája
Ennek a dolgozatnak a célja az elofizetonkénti (VC), illetve az agreragált folyam szerinti (VP) forgalomformázás beállításainak meghatározása. A formázást illeszteni kell a várható forgalomhoz és a Telia által használt eszközök lehetoségeihez. Meg kell vizsgálni a kétféle formázás egymásra hatását, illetve az ATM hálózat elso kapcsolójában
muködo,
a
forgalom
paramétereit
ellenorzo
vizsgálat
(UPS)
kritériumainak való megfeleloséget. Az általános célok és feltételek alapján elméletileg kialakított megoldások méréssel történo ellenorzése is a kituzött célok között van és ugyan csak ilyen mérésekkel fogunk választ adni olyan kérdésekre, amelyek elméleti alapon nem eldönthetoek.
1.2. A
A dolgozat szerkezete második
fejezetben
egy
rövid
áttekintést
fogunk
látni
az
DSL
technológiáról, majd megismerkedünk a forgalomformázás alapjaival, céljával. A harmadik fejezetben a mai Internet forgalom kerül nagyító alá, abból a célból, hogy meghatározzuk milyen forgalom várható a DSL elofizetoi kapcsolaton. Eloször
gerinchálózati
statisztikák
elemzésébol
következtetünk
a
domináns
protokollra, majd saját mérésekkel vizsgáljuk meg a burstösséget. A negyedik fejezet olyan forgalomformázási módszereket tárgyal, amelyek állandó sebességre igazítják a forgalmat. Ebben a fejezetben tárgyaljuk a VP kapcsán felvetodo összes kérdést. Az ötödik fejezet a változó sebességre történo formázásnak szentelodik. Mivel a VBR-nrt kifejezetten a tallózás jellegu forgalmak forgalmi osztálya, ezért itt felhasználjuk a forgalomról szerzett összes információt. A hatodik fejezetben a forgalom terhelés pontosabb tervezhetosége és az eszközök értékelése miatt a bufferok méretét, muködését mérjük ki. Végül
a
hetedik
fejezetben
újra
kiemelem
a
dolgozatból
fontosabb
eredményeit, leszuröm a tanulságokat.
2
2. Alapgondolatok DSL-rol és forgalomformázásról 2.1.
DSL
Az DSL technológia története az 1980-as években kezdodött. A Bellcore egyik katatója, Joseph Lechleider ismerte fel az aszimmetrikus kapcsolat létjogosultságát. Kezdetben csak videó adások szállítására szánták az akkor még ADSL-nek (Asymmetric DSL) nevezett megoldást. 1993-ban a Stanfor egyetemen 256 alcsatornára választották szét a jelet és az addigiaknál sokkal jobb eredményt sikerült így elérni. Ez a megoldás lett az ADSL elso szabványosított verziója. Innentol kezdve nagyon sok laboratórium próbált még jobb, vagy éppen egy adott környezethez jól illeszkedo DSL megoldást fejleszteni. Ezekbol egy kis összefoglaló a 2.1.2. fejezetben található. Valójában a piacon csak 1998-tól van érezheto szerepe a DSL-nek, a terjedése ma igen intenzív, foleg Európában mivel itt kevésbé van elterjedve a kábeles Internet hálózat. Néhányan a DSL-nek is nagy szerepet tulajdonítanak az Európa informatikai felzárkózásában az USA-hoz.
2.1.1.
Muködése
A DSL a hagyományos telefonhálózathoz kiépített sodortérpárt használja fizikai közegnek. Ez nagymértékben egyszerusíti a hálózat építést, de azt sem nehéz belátni, hogy egy olyan vezetéken, amelyet 4 kHz-es jel átvitelére terveztek, nehéz feladat Mbps-os sebességet elérni. Emiatt aztán az elérheto sebesség erosen függ a vezeték hosszától, ahogy ezt az 5-4. ábrán is láthatjuk. A telefonvonalon 0-4 kHz, illetve ISDN esetén 0-10 kHz tartományban helyezkednek a telefonos szolgáltatások. A felfelé meno adatok 25-160 kHz közé esnek, míg lefelé 240 kHz-1,5 MHz-es tartomány használják, de a VDSL (Very high data rate DSL) 10 Mhz-ig is felmegy. A 2-1. ábrán látható két splitter egy-egy alulátereszto szurovel válasza le a jelet a vonalról.
3
Splitter
Splitter Telefon
Telefonközpont Modem ATM hálózat DSLAM PC
Internet SMS
2-1. ábra DSL redszerfelépítés
A valóságban a splitter be van építve a modembe és nem is feltétlenül szükséges szakértelem az üzembe helyezéshez. A DSLAM (Digital Subscriber Line Access Multiplexer) összegyujti az elofizetok forgalmát és ATM hálózaton keresztül továbbítja a gerinchálózatba. A DSLAM tartja karban a fizikai kapcsolatot, figyeli a hibákat és kapcsolatfelvételkor dönthet a sebességrol. Az
SMS
(Subscriber
Management
System)
feladata
az
elofizetok
adatkapcsolati és hálózati réteg szintjén történo menedzselése, ez akár még a belogoltatásig is terjedhet. Valójában egy olyan routerként üzemel, amelyben minden elofizetonek
van
egy
virtuális
interfésze,
tehát
szétválogatja
a
csomagokat
elofizetonként és megformázás után továbbítja a DSLAM fele. Mivel a kimeno fizikai interfész ATM, így az eszközök inkább az ATM-be való becsomagolás után végzik a formázást, amiben az a nehézség, hogy a nem továbbítható cellákat úgy kell eldobni, hogy azok mindig egy csomagot alkossanak. (lásd. 2.4. fejezet)
2.1.2.
A DSL típusai
Az xDSL összefoglaló neve egy igen színes szabványcsaládnak, amelynek néhány tagját a követezokben ismertetjük.
4
Az ADSL-t még a történelmi bevezetoben említettük. A fo hangsúly az aszimmetrián van, míg az elofizeto 6,1 Mbps-mal vehet maximum 640 kbps-mal adhat. CDSL (Consumer DSL) a Rockwell cég olcsó ajánlata mindazoknak, akik megelégszenek 1 Mbps-mal. Az eszköz az teszi olcsóvá, hogy nincs szükség splitterre az elofizeto oldalán. A RADSL-t (Rate-Adaptive DSL) egy software cég fejlesztette és képes alkalmazkodni az adott elofizeto vonalminoségéhez, hozzá igazítva a sebességet. Az elérheto sebesség 2 Mbps le- és 1 Mbps felfele. VDSL (Very high data rate DSL) „nagy sebességu ATM kapcsolat a szomszédba”, ugyanis 300 m távolságig használható, de ott 51-54 Mbps-os átvitelre képes.
2.2.
Forgalomformázás
Forgalom
formázás
az
is
amikor
a
modempoolban
lévo
számítógép
kapcsolatot teremt a nagysebességu Internet link és a telefonvonal végén internetezo elofizeto között. A megérkezo burstöket egy bufferban gyujti és a vonali sebességen továbbítja, ha a buffer túlcsordul akkor az adat elveszik. Akkor vetodik fel eloször a forgalomformázás feladata, amikor az elofizetonek olyan fizikai kapcsolata van, amit jelenleg még nem tud, vagy akar kihasználni, tehát a link sebességnél kisebb sebességu szolgáltatást vásárol. Az ilyen esetben kötött szerzodés
betartásához
már
szükséges
a
küldendo
forgalom
valamilyenfajta
ütemezése. Ezt az ütemezést nem muszáj úgy végezni, ahogyan egy vonal természeténél fogva megformázza a forgalmat. Szem elott tartva a hálózat és a felhasználó érdekeit, illetve a forgalom típusát különbözo megoldások lesznek optimálisak.
2.2.1.
Forgalmi osztályok
A forgalmi osztályokat, amelyek a formázás módját is meghatározzák a különbözo forgalom típusokhoz, alkalmazásokhoz illesztette az ATM Fórum. A szolgáltató ezek megfelelo arányú keverésével, illetve az árak alakításával védi az érdekeit, az elofizeto pedig választhat a kialakított lehetoségekbol. CBR (Constant Bit Rate) például a tömörítetlen videófolyam osztálya, az adott sávszélesség (PCR Peak Cell Rate) mindig rendelkezésre áll, a késleltetés és a
5
késleltetés ingadozás (CDV Cell Delay Variation) is garantált. Ez a forgalom úgy érzi, mintha egy PCR kapacitású linken egyedül lenne. VBR-nrt (Variable Bit Rate- non realtime) a nem valósideju számítógép hálózatok forgalmához illeszkedik, mint például a böngészés. Az átvitel itt is garantált, de a CDV nem. VBR-rt (Varibale Bit Rate- realtime) ideális tömörítet videó és hang hordozására. Annyiban különbözik a VBR-nrt-tol, hogy a CDV is garantált, ami valójában kisebb bufferméretet kell jelentsen az eszközökben. Az UBR (Unspecified Bit Rate) best effort jellegu szolgáltatás. Akkor mehet be a hálózatba az adat, ha van hely számára. „Semmit sem garantálunk, de olcsón adjuk.” A késleltetésre nem érzékeny felhasználók osztálya. ABR (Available Bit Rate) az UBR testvére, annyiban nyújt többet, hogy az intelligenciával
rendelkezo
végfelhasználónak
a
hálózat
információt
ad
szabad
sávszélesség nagyságáról, így annak adata sokkal valószínubben átjut a hálózaton.
2.3. 2.3.1.
Forgalomformázás modellje és megvalósítása Leaky és token bucket
A lyukas vödör algoritmust lényegében már a neve is érthetové teszi. A vödör mérete egyenlo a buffer méretével, lyuk mérete pedig azt adja meg, mekkora sebességgel távozhat az adat a bufferból (lásd. 2-2. ábra). Az SCR formázása egyszeru laeky bucket szerint történik. A beérkezo adat egy adott méretu bufferban tárolódik és onnan PCR sebességgel távozika. Ha a buffer
Adat „Vödör”
2-2. ábra Leaky bucket
túlcsordul adatvesztés lép fel. A buffer konkrét méretét gyártó válasza meg, CBR esetén ez kicsi szokott lenni a kis késletetés és a késleltetés ingadozás betartása miatt.
6
Különbözo okok miatt a „lyukon” nem tud állandó sebességgel kifolyni az adat, ennek a sebességingadozásnak a mértékét határozza meg a CDVT.
A token bucket algoritmus a leaky bucket egy tovább fejlesztett változata, a bufferból való távozásnak van egy plusz feltétele. Van egy tokenpool amelybe a tokenek állandó sebességgel érkeznek, de ? -nál több nem tárolódhat. Az adat bufferból csak akkor enged ki a regulátor csomagot, ha ki tud venni hozzá a tokenpool egy tokent és emellett a „kifolyási sebesség” max. PCR lehet.
2-3. ábra Token bucket
A token bucket burstös forgalom formázásához lett kitalálva, amikor is az adatok csomókban jönnek és ezeket a csomókat gyorsabban kell továbbítani, de hosszabb idore nézve a forgalom sebessége nem haladhat meg egy kisebb értéket. Ez a célja a VBR osztályoknak is. Az SCR a tokenek keletkezésének sebessége, a PCR a „lyuk” mérete, a CDVT a PCR-tol való max. eltérést adja meg. Az MBS egy kicsit bonyolultabban adódik, határesetben (ha PCR >>SCR) egyenlo ? -val, máskor: MBS ? ? ? (1 ?
SCR ) PCR
A VBR-nrt és rt között csak az adat buffer méretében és a prioritásban van különbség.
7
2.3.2.
GCRA (Generic Cell Rate Algorithm)
GCRA, más néven virtuális idozíto algoritmus, hasonló muködést mutat, mint a leaky bucket algoritmus, de ennek az eszközben történo implementálása sokkal hatékonyabb. Annyiban több az elozo fejezetben leírt algoritmusoknál, hogy kezeli a CDVT-t. A GCRA(I, L)-nak két paramétere van, a növekmény (I incerement) és a határ (L limit), mindketto ido mértékegységu. A GCRA(1/PCR, CDVT)-t egyszer lefuttatva a folyamon leaky bucketként, míg másodjára GCRA(1/SCR, BT)-t lefuttatva token bucketként muködik, vagyis a CBR, illetve az VBR aktuális paramétereit ellenorzi. Az algoritmusnak 2-4. ábrán leírt muködései a forgalom konformitásának ellenorzésére
vannak
kifejlesztve.
Ha
ütemezésre,
vagyis
formázásra
akarjuk
használni, akkor a nem konform cellákat át kell ütemezni és tárolni kell a bufferben, eldobás csak akkor következik be, ha túlcsordul a buffer. Ha token bucketen keresztül értelmezzük a GCRA muködését, akkor azt találjuk, hogy a GRCA „csal”, ugyanis nulla idopillanatban teli tokenpoolal indul. Ennek gyakorlati jelenosége nincs, de az algoritmus értelmezésénél nehézségeket okozhat.
2.4.
Cella- és csomageldobás
Az ATM forgalom menedzsmentje cellákban gondolkodik, aminek csak elonyei vannak, mindaddig amíg az eszköz nem szándékozik cellát eldobni. Egy csomag akár 32 cella is lehet és ebbol pusztán egynek az elvesztése is már értéktelenné teszi a maradék 31-et. Szélsoséges esetben ez azt jelenti, hogy ha az eszköz 1%-át dobja el a csomagoknak buta módon, akkor a csomagok ? 30% fog elveszni. Erre a problémára két megoldást is kifejlesztettek az ATM világában. A kevésbé hatékony a PPD (Partial Packet Discard), amely, ha egy cellát el kell dobni, akkor eldobja az összes ugyanahhoz a csomaghoz tartozó cellát az utolsó kivételével. Ennek meghagyására azért van szükség, mert e nélkül nem lehetne felismerni a következo csomag kezdetét. Az EPD (Early Packet Discard) annyiban intelligensebb az elozonél, hogy elore gondolkodik, és ha egy csomag bármely celláját el kell dobnia, akkor az égész csomagot eldobja. 8
EPDés PPD nagy hátránya, hogy az ATM kapcsolónak negyedik rétegig bele kell néznie az a forgalomba, ami nagymértékben növeli az eroforrás igényt. ta(k)-kor megérkezik a k. cella
X' = X - (ta(k) – LCT) TAT < ta(k)
Igen
? Nem
Nem Konform Cella
X' < 0 ?
TAT = ta(k)
Igen
Nem
Igen TAT > ta(k) + L
X' = 0
? Nem Konform Cella
Nem
Igen
TAT = TAT + I Konform Cella
X' > L ? Nem
X = X' + I LCT = ta(k) Konform Cella
VIRTUÁLIS ÜTEMEZO
FOLYAMATOS ÁLLAPOTÚ
ALGORITMUS
LEAKY BUCKET ALGORITMUS
TAT
Szabványos megérkezési ido Theoretical Arrival Time
ta(k)
Cella valós érkezési ideje Time of arrival of a cell I L
Az elso cella megérkezésekor TAT = ta(1)
X
A leaky bucket száláló értéke
X'
Segéd vátozó
LCT
Last Conformance Time Az utolsó konform idopont
Növekmény (Increment) Hatát (Limit) Az elso cella megérkezésekor X = 0 and LCT = ta(k)
2-4. ábra Azonos értéku két verziója a GRCA-nak
9
3. Az ADSL felhasználók Az Internet egy egyre növekvo és állandóan változásban lévo világméretu hálózat. Egy Internet tartományokon végzett tanulmány szerint [ISIC00] .
az
Internethez csatlakoztatott számítógépek száma évente 60%-al növekszik. Az Internet adatforgalmának ugrásszeru növekedését jól jellemzi az forgalomra vonatkozó Moore törvény, amely kimondja, hogy az átvitel mennyisége minden évben megduplázódik [AOdlyzko00]. Az Interneten kínált szolgáltatások is gyorsan változnak, egy új kialakítású
portál
ugyanakkor
a
néhány “régi”
www.mtnsms.com,
hónap kedvenc
www.origo.hu)
alatt
felhasználók
portáljaink kénytelenek
is
ezreit
vonzza
(pl.
www.altavista.com,
lépéstartás
végett
magához,
idorol
idore
lecserélni szolgáltatásaik nagy részét. A fenti tények tükrében talán meglepo, hogy az Internet forgalom muszaki jellemzoi nagyléptéku skálán mérve sem változnak olyan ütemben és sebességgel, mint az Internet humán jellegzetességei. Az elso alfejezet az Internet muszaki oldalát ismerteti. Az Internet alapját legnagyobb részt a TCP/IP protokollcsalád képezi, ami szinte állandónak tekintheto. A protokollokban végrehajtott változtatások eloször RFC formájában jelennek meg, majd csak ezután valósítják meg a módosításokat az operációs rendszerekben, ami hosszú idobe is beletelhet. Fontos tényezo az UDP/TCP arány, de nem számíthatunk hirtelen változásra e téren addig, amíg az Internet csomópontok nagy részén meg nem valósul a QoS. Ettol ma még jó néhány év távolságban vagyunk. A fejezet második részében a TCP forgalmat kívánom elemezni néhány saját mérés alapján, s arra a kérdésre keresem a választ, hogy mennyire burstös a forgalom. Ez fontos információ a VBR forgalomformáló paramétereinek kiválasztásánál.
3.1.
Forgalommal kapcsolatos tendenciák az Interneten
A gerinchálózat forgalmáról két fo különbözo módszerrel lehet információt szerezni. Az egyszerubb mód az, ha kiolvassuk az értéket a router beépített számlálójáról az SNMP használatával. A lehetoségek ebben az esetben korlátozottak, csak szukös képet kapunk a forgalomról. Hasznos lehet tudni, hogy mikor és mennyire terhelt a hálózat. 10
Bovebb információkkal szolgál az a módszer, ahol egy nagysebességu linket optikai splitteren vagy tükrözött porton keresztül figyelünk analizátorral. A vizsgálat sokféle módon lefolytatható, de ez a módszer nagyon költséges, így nem is született ilyen módon túl sok tanulmány. Én egyetlen európai tanulmányt sem találtam a témában. A harmadik módszer valójában az elso ketto keveréke. A Cisco megvalósított egy Netflow nevu kapcsolási módszert, amellyel nyomon követheto a forgalom. A NetFlow kapcsolás alapját a csomagfolyamok azonosítása képezi, valamint kapcsolás végrehajtása
egy
routeren.
Kiegészíto
funkcióként
lehetoség
van
a
Netflow
adattömbök különféle paraméterekkel történo kiexportálására, amelyek magukban foglalják a forrás és cél IP-t, a portcímet, a csomagok számát, az összeg byte-okat, stb. Lásd: [Ciscoa]. A módszer segítségével könnyen és olcsón telepítheto analizátor állomás. [DPlonka99] Az folyam alapú statisztika egyrészt forgalomszimuláció, másrészt elméleti forgalmi modellek elkészítése céljából lehet fontos. A második módszerrel a folyamok nehezen azonosíthatók [KClaffy95], a módszer csak sok eroforrás felhasználásával lenne eredményre vezeto. Így nem marad más választás, mint a routeren keresztül hozzájutni a szükséges folyam alapú adatbázisokhoz.
Nagyon jó
példát ír le erre: [DPlonka00] A California Egyetemen muködo Internet adatelemzési társulás (Cooperative Association of Internet Data Analysis, CAIDA ) szakemberei többféle Internet forgalomelemzo eszközt fejlesztettek és fejlesztenek ki a kutatásaik alátámasztására, [CAIDAtools], és ezeket ingyen rendelkezésre bocsátják. Az eszközök nagyon jó lehetoséget kínálnak az Európaiak számára a forgalomelemzési mérések elindítására. Nem találtam a témában jó tanulmányt, de úgy vélem, hogy nagy szükségünk van hálózatoptimalizálásra. megfigyelték,
hogy
Például Németország
az
USA
egy
megközelítoleg
gerinchálózati akkora
forgalmat
központjában bonyolít
le
Franciaország felé az USA-n keresztül, mint magába az USA-ba [SCreary98].
3.1.1.
Az Ames Internet Exchange megfigyelése
Egy CAIDA tanulmány sok olyan kérdést taglal, amely ennek a dolgozatnak is az alapját képezi, ezért szeretném bemutatni a tanulmányt egy alfejezet erejéig. A tanulmány egy 10 hónapig tartó longitudinális vizsgálatot ír le, melynek címe:
11
“Fejlodési
tendenciák
a
nagy
kiterjedésu
IP
forgalmi
mintázatokban”
[SCreary00]. A vizsgálat a NASA Ames Internet Exchange pontján zajlott. Itt nemcsak egy nagy intézet átjárójáról van szó, hanem egy olyan átjáróról, amelyen nagyon sokféle forgalom zajlik. A terheléselemzéseket rendszerint egy egyetem exchange pontján végzik, amint az a Dave Plonka esetre is igaz [DPlonka99]. A megfigyelt kapcsolat négy OC-3 linket tartalmaz, amelyek közül az egyikre egy splittert telepítettek. A figyelorendszeren áthaladó csomagok AAL5 PDU-ról érkezo legelso ATM celláját fogták el, és írták lemezre, lásd: 3-1. Az elso cella tartalmazza az egyes csomagok elso 40 byte-ját, amely rendszerint elegendo ahhoz, hogy kivonják a TCP vagy UDP portszámot a szállítási réteg fejlécébol. Hat és nyolc közötti mintavételt végeztek egy nap, amelyek mindegyike 90 másodpercig tartott. A
nyers
mintákat
CoralReef
[CAIDAtool]
segítségével
bontották
le
táblázatokba, amelyeket késobbi elemzés céljából archiváltak. A fejlodési tendenciák felvázolásánál sok korábbi tanulmányt is figyelembe vettek.
3-1. ábra A megfigyelt link helye a NASA-Ames és MAE-West között.
3.1.2.
UDP/TCP arány
Minden protokoll másképpen jellemezheto abban a tekintetben, hogyan indítja el a forgalmat, és hogyan kezeli a torlódásokat, stb. Az alábbi fejezetekben azt
12
próbáljuk kideríteni, hogy létezik-e egy domináns protokoll, és felvázolható-e olyan tendencia, amely módosítaná ezt a dominanciát. Protocol TCP UDP GRE ICMP ESP IP in IP AH IPIP SKIP IGMP
Packets 374801201 62456731 7566415 5938044 517353 265103 74423 143502 117050 68404
Packet % 82,93% 13,82% 1,67% 1,31% 0,11% 0,06% 0,02% 0,03% 0,03% 0,02%
Bytes 1,76707E+11 9842511709 5272240819 1350011401 197216792 179257606 43454671 41707350 41633952 7729038
Bytes% 91,24% 5,08% 2,72% 0,70% 0,10% 0,09% 0,02% 0,02% 0,02% 0,00%
3-1. táblázat Elso 10 legelterjedtebb protokoll 2000 februári vizsgálat alapján
A 3-1. táblázat bemutatja azt a 10 protokollt, amelyet a 2000 februári Ames Internet eXchange (AIX) [SCreary00] vizsgálat a legfontosabb 10 protokollnak talált. Az eredmény nem meglepo, az UDP és a TCP a forgalom 96,3%-át adja, és a byte-ok tekintetében az UDP kb. 18-szor kevesebb mértékben vesz részt a forgalomban a TCP-nél. 1997 januárjában egy másik gerinchálózati linken végzett vizsgálat keretén belül a TCP és az UDP összarányát 99,3%-ban állapították meg [JApisdorf97]. A két mérési eredmény között a GRE (Generic Packet Encapsulation) növekedése jelent fo különbséget. A GRE-t többnyire stagnáló, részben elavult protokollok használják, pl. DECnet és Ethertalk (Appletalk) vagy olyan Ethernet csomagok, mint Transparent Ethernet Bridging és ARP (Address Resolution Protocol). A GRE nem növekszik tehát exponenciálisan, valójában meglehetosen lassú ütemben növekszik. A fentiekbol kifolyólag, és mivel foleg csak intézmények használják, kicsi annak a valószínusége, hogy széles körben elterjed
az ADSL felhasználói forgalomban. A fenti okok miatt
tehát indokoltnak érzem, hogy a fejezet további részében csak az UDP és a TCP vizsgálatára összpontosítsak. A 3-2. ábrán az 1999 májusa és 2000 márciusa között az AIX-on gyujtött csomagminták TCP és UDP aránya látható. Az értékek heti felbontásban láthatók, és az egyes heti értékek mediánját elso és harmadik kvartilisbeli hibaoszlopok ábrázolják. Amint látható, egy bizonyos idoszakban, 1999 késo nyarán, változás következett be ebben az arányban, ami a diákok nyári szünetére vagy más okra
13
3-2. ábra A két legfobb protokoll csomagjainak részesedése
semmiféle eltolódást a két domináns hálózati réteg protokoll használata között. Az elmúlt években az UDP alkalmazások számában történt növekedés ellenére az UDP forgalomnövekedést teljes mértékben kiegyenlíti a TCP forgalom növekedése. A 3-3. ábra az IPSEC ( IP Security) forgalom egy reprezentatív példáját mutatja, ami magában foglalja az AH
(Authentication Header) és az ESP
(Encapsulating Security Payload) forgalmat. A diagram nagyságrendi növekedést mutat a tanulmány elso 5 hónapjában, majd a forgalom növekedése hirtelen megáll, sot kis mértékben csökkenni kezd. Az újabb, divatos megoldások, alkalmazások elemzése hasonló eredményt mutat. Kezdetben a forgalmak gyors növekedését figyelhetjük meg, majd néhány hónap eltelte után ez a növekedés megáll, s stagnálni kezd. Leszögezhetjük tehát tényként, hogy az Internet forgalma az elmúlt három évben megnyolcszorozódott ugyan, de az UDP/TCP arány nem változott.
3.1.3.
TCP alkalmazások
Az elozo és mostani fejezetben azt vizsgáljuk, hogy milyen az a forgalom, amivel a formálónak meg kell birkóznia. A legfontosabb tényezo ebben a tekintetben
14
3-3. ábra IPSEC részesedés
a csomagok byteeloszlása, mert a formáló nem foglalkozik azzal, hogy hol van a csomagok közötti határ, csak abban az esetben ha túlcsordulás következik be, és el kell vetnie bizonyos részeket. A csomaghosszon alapuló forgalomeloszlás azonban fontos tényezo, amit a teljesítménymérésnél figyelembe kell venni. Protocol HTTP NNTP FTP SMTP Napster Other
Packets Packets % 243362034 67.93% 7.47% 26752698 12226194 3.41% 4.28% 15317597 7858319 2.19% 14.72% 52725321
Ames Internet Exchange
Bytes Bytes % 1.12031E+11 64.32% 12.28% 21392640422 7951905624 4.57% 3.68% 6410872072 3715838753 2.13% 13.02% 22680342414
Bytes % 75.46% 6.71% 4.29% 3.25% 10.28%
vBNS
3-2. táblázat A 6 legjelentosebb TCP alkalmazáskategória 2000 február és 1998 áprilisa között
A 3-2. táblázat felsorolja azokat az alkalmazáskategóriákat, amelyek 1%-nál nagyobb részesedéssel bírnak az összforgalomban. A jobb utolsó oszlop a Backbone Network Service (vBNS) 1998 adatain alapszik [KClaffy98] . A http (Hyper Text Transfer Protocol) dominanciája még mindig jelentos, és az is marad, mert a protokoll tömeges és interaktív átvitelre egyaránt képes. Amint az a 3-4. ábrából kiderül, az aktív FTP (File Transfer Protocol) aránya csökkent. [SCreary00] úgy véli, hogy ez a forgalom nem mozdult el a HTTP irányába, ugyanis a HTTP részesedése állandó. Ha azonban figyelmesen visszatekintünk, láthatjuk, hogy mégiscsak lezajlott a HTTP arányában egy lefelé mutató tendencia, mert
15
1997-ben is 73,5% volt a HTTP arány [JApisdorf97].
Az
én
véleményem
szerint a tanulmány ideje alatt a HTTP valójában csökkeno tendenciát mutatott, csökkenésébol
és a
az
http-be
FTP átmeno
forgalom volt az, ami ezt a tendenciát 3-4. ábra FTP arány
kiegyensúlyozta, tartotta
és
a
állandó HTTP
szinten arányt.
A NNTP (Network News Transport Protocol) aránya növekvo tendenciát mutat, 1997-ben ez az arány még csak 3% volt, 1998-ban már 6%, 2000-ben pedig 12%. Meg kell azonban itt jegyezni, hogy a méréseket ugyan gerinchálózaton végezték, de különbözo helyeken, így nem állíthatjuk bizonyossággal, hogy az NNTP aránya az elmúlt két évben megduplázódott, csak azt jelenthetjük ki teljes bizonyossággal, hogy ez az arány növekedett. A SMTP (Simple Mail Transfer Protocol) aránya állandónak tunik, ami arra utal, hogy az átlagos új felhasználók az Internet használat arányában ugyanannyi levelet írnak, mint az átlagos régi felhasználók. Összefoglalva, a HTTP csekély mértékben csökkeno tendenciáját olvashattuk ki a mérésekbol. Megjelenhetnek új alkalmazások, mint a Napster, amelyek néhány %-ot megszereznek a részesedésbol (az “egyéb” kategória ezeket az alkalmazásokat fogja össze), de az Internet világ a HTTP-n alapszik (szerverek, szolgáltatások), amiben bármiféle átalakulás csak nagyon hosszú ido alatt megy végbe.
3.1.4.
UDP alkalmazások
A UDP (User Datagram Protocol) az Internet forgalom 3-5 százalékát adja, ami nem fog jelentosen megváltozni, hacsak nem következik be változás a hálózat szerkezetében. Senki nem engedheti meg magának, hogy egy megbízhatatlan protokollt használjon garantált sávszélesség nélkül. Sok elmélet és próbálkozás született ezen a téren, de nincs egy olyan szolgáltató sem, aki garantált szolgáltatást nyújtana az Interneten keresztül. Ha lesz ilyen, újra el kell végezni ezeket a méréseket, és újra át kell gondolnunk az UDP, valamint az UDP alkalmazások helyét a protokollok között.
Protocol Packets Packets % DNS 18021984 31.34% RealAudio 4610070 8.02% Online Games 15552292 27.04% Other 19321413 33.60%
Bytes Bytes % 2036375748 22.60% 2029483625 22.53% 1362874460 15.13% 3580814562 39.74%
3-3. táblázat A 25 legjelentosebb UDP alkalmazáskategória 2000 februárjában
A 3-3. ábra azokat az alkalmazáskategóriákat mutatja, amelyek 1%-nál nagyobb
részesedéssel
bírnak.
Az
UDP
forgalom
majdnem
40%-a
kisebb
alkalmazások között oszlik meg – a TCP esetében ez az érték csak 10-13%. A fenti szám azt jelzi, hogy nagyon sok UDP alkalmazás létezik, de ezek egyike sem képes jelentos forgalomnövekedést kiváltani. Nézzük meg, melyek azok, amelyek
jelentos
mértékben hozzájárulnak az UDP forgalomhoz. A Domain Name Service (DNS) 90%-ban a gerinchálózaton zajló, szerverek közötti kommunikációt valósít meg. A kliensek többsége a Helyi hálózatról (LAN) kap DNS szolgáltatást, s a szerver csak akkor továbbítja a kérést, ha maga nem tudja a választ. Az folyam hossza nagyon rövid, 2-3 csomag, ezért nem érdemes megbízható kapcsolatot létesíteni. A DNS forgalom mértéke nagymértékben függ a mérési helytol, ennek tükrében kimondható, hogy a DNS részesedése az Interneten 1 és 2% között van, az UDP alkalmazások között pedig az aránya 18-23% körül állapítható meg, és ez az arány nem változik. A RealPlayer a jövo alkalmazása, amely a számítógépet új tulajdonsággal ruházza fel, rádióként lehet használni. A piac nem kedveli a mai minoségben megvalósított rádiózást, ami a mérési eredményekben is tükrözodik. A 3-5. ábra az 1999
augusztusa
és
szeptembere
közötti
idoszakra
hanyatlást
mutat.
Ha
visszatekintünk, láthatjuk, hogy a RealPlayer részesedése 1997-ben 1% híján ugyanannyi volt, mint három évvel késobb. Az online játékok az Internet forgalom majdnem 1% -át adják. A számítógépes játékok világa egy külön világ, a játékok kedveloi eloszeretettel fordulnak a legújabb játékok felé, így megbízható eredmények közléséhez állandóan friss adatokra van szükség. Az egyetlen online játékokról szóló tanulmány szerzoje nem ismerte az online játékvilág fenti jellemzojét, így nem tanulmányozta elég ideig a megfelelo mintát ahhoz, hogy világos tendenciát tudjon felvázolni. Úgy tunik azonban, hogy az online játékok aránya növekvoben van.
17
3-5. ábra A RealAudio részesedése
Az én véleményem szerint az online játék egy idozített bomba: ha elegendo játékosnak lesz a szokványos modem által kínáltnál gyorsabb kapcsolata, bizonyos játékok nagy sávszélességre tarthatnak igényt. Elofordulhat, hogy hirtelen a vártnál nagyobb arányban foglalja le azt magának.
3.1.5.
Csomaghossz szerinti eloszlás
A csomaghossz szerinti eloszlás az egyik legfontosabbnak számító szempont a teljesítménymérésnél. Nagyon nagy különbségek vannak egy 100 Mbps sebességu 64 byte-os és 1500 byte-os folyam között. A második esetben a routernek 23-szor több döntést kell hoznia, mint a kis csomag esetében. Az átbocsátási képességet az átlagos csomagmérethez kell igazítani, nagyon kevéssé hatékony az, ha egy aktív berendezés 100%-os átereszto képességgel muködik kis (pl. 100 byte-os) csomagok esetén. A 3-6. ábra byte-onként és csomagonként mutatja az összesített eloszlást. A teljesség kedvéért meg kell jegyezni, hogy 1500 byte-nál nagyobb csomagok is léteznek, de ezeknek a részesedési aránya nagyon kicsi, rendszerint 0,005%-nál kevesebb. Könnyebb megérteni és elemezni a csomagonkénti vonalat, a byte-onkénti vonal ido természetu, s azt mutatja, hogy egy adott csomagméret milyen gyakran fordul elo a fizikai médián. A 3-6. ábra eloszlásának fo jellemzoit az határozza meg, hogy a szokásos TCP megvalósítások hogyan darabolják fel csomagokra az adatfolyamot. A fent vizsgált forgalom megközelítoleg 85%-a TCP, és a TCP forgalom nagy részét tömeges átvitelt megvalósító alkalmazások, pl. HTTP és FTP, állítják elo. Ebbol következoen a látott 18
csomagok többségére a következo három méret egyike jellemzo: 40 byte-os csomagok (a TCP minimális csomagmérete), amelyek a TCP nyugtákat szállítják, de hasznos tehert nem; az 1500 byte-os csomagok (a maximális Ethernet hasznos teher mérete),
amelyek
útvonal
MTU
felderítést
használó
TCP
megvalósításokból
származnak; és az 552 és 576 byte-os csamagok, amelyek útvonal MTU felderítést nem használó TCP megvalósításokból származnak.
3-6. ábra Csomagméretek szerinti összesített eloszlás 2000 februárban
Statisztikai adatok a csomaghossz szerinti eloszláshoz: Középérték: 420 byte, standard eltérés: 521 byte Medián: 78 byte Százalékosztályok: 5%: 40 byte, 25%: 40 byte, 75%: 576 byte, 95%: 1500 byte
A link 9 hónappal korábbi eloszlása feltunoen hasonló képet mutatott. Az 1997-bol származó eloszlási adatokat is figyelembe véve [KClaffy98] láthatjuk, hogy az akkori adatokhoz képest is csak kis változás történt, az újabb fordulópontok 510%-kal magasabbak, ami az átlagos csomagméret lassú csökkenésére utal. Ezt sejteni lehetett abból, hogy a felhasználónkénti forgalom mennyisége növekvoben van. A változás sebességét nagyon nehéz megbecsülni, az eredmények nagyon eltéro átlagméreteket mutatnak. 1997. január 28-án például, egyetlen napon az átlag 280 és 19
350 byte között váltakozott [JApisdorf97]. A 10 hónapos tanulmányból is kitunik ez a fajta fluktuáció, jóllehet a tanulmány készítoi heti átlagokkal dolgoztak. A fentiek után nem meglepo, hogy ezekbol a paraméterekbol semmilyen hosszútávú változási tendencia nem szurheto le. Amíg a TCP a meghatározó protokoll az Interneten, nem valószínu, hogy nagyon változna a csomaghossz szerinti eloszlás, hacsak maga a TCP protokoll meg nem változik.
3.2.
Rövid áttekintés a TCP-rol
Amint az a 3-1.-es ábrán látható, a byte-forgalom 95%-a TCP. Ezért érdemes ebben a fejezetben néhány szót szentelni a TCP fo mechanizmusának leírására. Ez a fejezet fontos bevezeto a 3-3.-as fejezethez,
ahol a TCP nagyfelbontású idoskálán
szemlélt elemzése olvasható. Nem törekedhetek teljességre, hiszen a TCP egy nagyon összetett protokoll, ezért a téma néhány olyan pontját szeretném kiemelni, amelyek elengedhetetlenek a dolgozat gondolatmenetének következetessége szempontjából. Ha a témával kapcsolatban részletesebb információkat szeretne olvasni, egyrészt egy rövidebb terjedelmu, de annál jobb tanulmányt,[GHuston] , másrészt egy népszeru kiadványt [Wstevns94], illetve az RFC-ket ajánlom a figyelmébe.
3.2.1.
Streaming és sebességadaptivitás
Folyam
(Streaming):
Bár
a
TCP
csomagstruktúrát
használ
hálózati
adatátvitelre, valójában a TCP egy igazi folyam (streaming) protokoll, ahol az alkalmazás-szintu hálózati muveletek nem átlátszók. Egyes protokollok kifejezetten becsomagolják az alkalmazás-tranzakciókat; minden írási tranzakcióhoz léteznie kell egy olvasási megfelelonek. Ily módon az a logikai rekordstruktúra, amelybe az alkalmazás az adatfolyamot tördeli, megmarad az egész hálózaton keresztül. A TCP nem orzi meg az adatfolyamon megvalósított hasonló jellegu implicit struktúrákat, így nem lesznek párban az írási és olvasási muveletek sem a hálózati protokollban. Elofordulhat például, hogy egy TCP alkalmazás egymás után három adatblokkot ír a hálózati kapcsolatba, melyeket a távoli olvasó egyetlen olvasási muveletbe fog össze. A TCP szekcióban használt adatblokkok (szegmensek) méretét a szekció kezdete elott egyezteti a küldo és a fogadó. A küldo megpróbálja azt a leheto legnagyobb szegmensméretet megengedett
használni
legnagyobb
az
adatátvitelben,
szegmensméretén,
ami a
még
belül
konfigurált
van
küldo
a
fogadó
megengedett
legnagyobb szegmensméretén és a hálózati útvonal legnagyobb támogatható, nem
20
fragmentált csomagméretén, azaz a Maximáilis átviteli egységen (MTU Maximum Transfer Unit). Az útvonal MTU rendszeres idoközönként frissül annak érdekében, hogy igazodni tudjon minden olyan változáshoz, amely az aktív TCP kapcsolat ideje alatt a hálózatban történt. Sebességadaptivitás: A TCP sebességadaptív protokoll, ami azt jelenti, hogy hozzáigazítja az adatátvitel sebességét a fobb hálózati terhelési feltételekhez, és alkalmazkodik a vevo feldolgozási képességeihez. Nincsen elore meghatározott TCP adatátviteli sebesség; amennyiben a hálózat is és a vevo is rendelkezik felesleges kapacitással, a TCP adó megkísérel további adatokat fecskendezni a hálózatba, hogy kihasználja a rendelkezésre álló területet. Ennek ellenkezoje is igaz, ha torlódás van a hálózatban, a TCP adó csökkenti a küldési sebességet, amivel lehetové teszi a hálózat számára, hogy újra visszaálljon a normális állapotba. Az adaptációs funkció révén a TCP tehát megpróbálja a leheto legnagyobb adatátviteli sebességet elérni, de ügyel arra, hogy ne váltson ki folyamatos adatvesztést.
3.2.2.
Csúszó ablak protokoll
A TCP csúszó ablak protokollt használ az adatátvitel támogatására (3-7. ábra). A
vevo közli az adóval a vevonél rendelkezésre álló pufferméretet. Az adó ennek
megfelelo mennyiségu adatot vihet át, ami után megvárja, hogy a vevo újabb pufferadatokat küldjön. Ennél nagyobb mennyiségu, adótól származó adat nem lehet úton a hálózaton. Az adó az elküldött adatokat szintén pufferban tárolja, egészen addig, amíg nyugtát kap vissza a vevotol. A küldési ablak az adó puffermérete és a közölt ablakméret közül a kisebbikkel lesz egyenlo. Minden alkalommal, amikor Teljes ablak méret
Elküldött, nyugtázott adat
Elküldött, nyugtára váró adat
Azonnal küldheto adat
Vett nyugták mozgatják a hátsó élet Az adó mozgatja ezt élet adat küldéskor
Elküldésre váró adat
A vezetoélet a vevo hirdetett ablak mérete mozgatja
3-7. ábra TCP csúszó ablak
21
nyugta érkezik vissza, az ablak vége tovább mozog. Az adó puffere és a vevo ablakmérete közül a kisebbik adja az alapot az új vezeto él kiszámításához. Ha az adóablak el nem küldött adatot tartalmaz, akkor az adat azonnal elküldheto.
A hosztok TCP puffere erosen korlátozza a WAN-ok teljesítményét. A protokoll körbefordulási idoközönként egy küldo ablaknyi adat átvitelére képes. Sávszéless ég (byte/sec) ?
Ablakméret (byte) Körbefordu lási ido (sec)
3-8. ábra Sávszélesség számítás
Például 4096 byte-os küldo ablak és 600 ms-os átviteli útvonal RTT esetén a TCP szekció maximum 48 Kbps átviteli sebességre képes, függetlenül a hálózati útvonal sávszélességétol. Az átvitel maximális hatékonysággal csak akkor valósítható meg, ha az adó képes arra, hogy teljes egészében megtöltse adatokkal a hálózati útvonalat. Mivel az adó egy bizonyos adatmennyisége halad a vevo felé, és egy ugyanekkore mennyiség egy nyugta beérkezésére vár, ezért az adó puffere, valamint a vevo közölt ablakmérete sem lehet kisebb a Késleltetési sávszélességnél (Delay-Band- width).A hálózati útvonal szorzata a 3-8.-as ábra alapján számolható ki.
3.2.3.
Nagyméretu ablak opció (Window scale option)
Az opció célja a maximális ablakméret megvalósítása olyan útvonalakhoz, amelyekre nagy késleltetés a jellemzo. Az ablak méretet továbbító, a TCP fejlécben lévo 16 bites mezo legfeljebb 216
= 65535 értéket vehet fel, amely az ablakméret
65535 byte-os felso korlátját határoz meg. Ez a TCP teljesítményére nézve 64 KB per RTT-s korlátot jelent, ami akkor is érvényes, ha mindkét végrendszer tetszolegesen nagy küldési és fogadási pufferrel rendelkezik. Lehetoség van e korlát módosítására a nagyméretu ablak opciós használatával, amelynek leírása a következo tanulmányban olvasható: [VJacobson92]. Az opció lehetové teszi, hogy a hirdetett ablakméret a TCP fejlécben opcióként megadott mennyiséggel jobbra tolódjon. Az ablak mérete ily módon egy 30 bites mezore no, de csak 16 bitnyi értékes részt viszi át. Az adó és a vevo ily módon legfeljebb 230 = 1 Gbyte pufferméretet használhat, amely hatékonyan tud muködni olyan sebességek mellett, amelyek jelenleg még csak a kutatólaborokban léteznek, és a világ legtávolabbi pontjait kötik majd össze.
22
Itt kell megjegyezni, hogy létezik felderítési folyamat az MTU-ra, ami lehetové
teszi
a
maximális
szegmensméret
használatát,
ugyanakkor
semmilyen
hasonló megoldás nincs a maximális használható ablakméret felderítésére.
3.2.4.
Buta ablak szindróma
Az RFC 813 (1982) következo tanulmányban
írja le eloször a Buta ablak szindrómát (SWS). Mi a
megadott definíciót használjuk: [RBraden89]. Az SWS-t
egyrészt a vevo okozza, amely kitolja a jobb ablakélt, amikor új adatok befogadására képes pufferterület szabadul fel, illetve az adó, amely kihasználja az ablak növekedését, bármilyen kicsi volt is ez a növekmény. Ez azzal az eredménnyel jár, hogy apró adatszegmensek küldése zajlik annak ellenére, hogy az adó és a vevo rendelkezésre álló összes pufferterülete valójában nagy. A vevo egy olyan szabály segítségével kerüli el az SWS-t, amely kimondja, hogy a vevo csak akkor növelheti a hirdetett ablakméretét, ha a növekedés megfelel egy teljes szemegmensméretnek vagy a jelenlegi pufferméret felének, a ketto közül a kisebbik az érvényes.
Elterjedt az a megoldás is, amely eloírja, hogy a hirdetett
ablakméretnek meg kell felelnie legalább a Maximális szegmensméretnek (MSS). A késleltetett nyugta küldés is bevált megoldás. Az adónak lehetoség szerint addig nem szabad szegmenseket küldeni, amíg a. Egy teljes szegmenst küldhet b. Olyan szegmenst küldhet, amely legalább a felét kiteszi a vevo által meghirdetett legnagyobb ablakméretnek c. El lehet küldeni valamennyi kinnlevo szegmenst, és az adó nem vár nyugtát, vagy le van tiltva a Nagle A Nagle algoritmus eloírja, hogy egyszerre csak egy darab kis szegmens lehet kint nyugtázás nélkül. Ha az elso nyugtára várakozás közben több kis szegmens eloállítása történik, akkor ezek a szegmensek összeállnak egy nagyobb szegmenssé. A teljes méretu szegmenseket azonnal elküldi az adó, feltételezve, hogy rendelkezésre áll elegendo fogadó ablakméret. A
Nagle algoritmus hatékonyan lecsökkenti az
interaktív programok, például a Telnet által küldött csomagok számát, különösen lassú kapcsolatok felett. Sajnos a Nagle algoritmus, ahogy azt a [RBuff99] tanulmány bemutatja, bizonyos körülmények között szükségtelen késleltetések közbeiktatásával lassítja a 23
Web protokollokat. Ezért általában csak az a. és b. SWS elkerülési módszert használják a vevoben.
3.3.
TCP forgalomanalízis
A 3.1 fejezetben igen nagy mintákból kiindulva megállapítottuk, hogy egy átlagos felhasználó forgalma milyen arányban tartalmaz különbözo protokollokat, alkalmazásokat. Ebben a fejezetben a domináns TCP viselkedését tanulmányozzuk nagy felbontású idoskálán. A kérdés igen általános és így bizonyosan már sokan mások is tárgyalták, én mégis
a
saját
mérések
elvégzését
választottam,
mivel
egy
egészen
egyedi
környezetben kerestem a választ, mégpedig a ma használatos operációsrendszerek alatt futó, a Telia gerinchálózata közelében elhelyezkedo számítógép szemszögébol.
3.3.1.
A mérés célja
TCP nagyon összetett protokoll, folyamatosan „szabogatják” hozzá az aktuális követelményekhez,
tucat-számra
jelennek
meg
az
újabb
opciók,
amelyek
implementálásáról az operációsrendszer írók maguk dönthetnek. A kötelezoen beépítendo részekben is jelentos a szabadság, amit a programozók sokszor még önkényesen meg is toldanak. Ebbol a TCP-t definiáló, elso ránézésre dzsungelnek tuno RFC-halmazból emberfeletti feladat megjósolni, mikor és milyen csomagok fognak megérkezni, ha éppen kedvenc programunk legújabb verzióját akarjuk letölteni 5-20 routeren keresztül egy távoli szerverrol. Járhatóbb út nagyító alá helyezni néhány folyamot, amelyek a Világ különbözo pontjaiból erednek és egy Telia ADSL elofizetonél végzodnek. Akár az eredmények
ellenorizésének
is
tekintheto
a
folyam
idodiagramját
kialakító
mechanizmusok megtalálása. Azonkívül ez lehetoséget adhat esteleges trendek megjóslására. A mérés alapvetoen a forgalom burstösségét hívatott meghatározni abból a célból, hogy az ADSL elofizeto és az Internet között lévo, „szukíto” szerepet betölto forgalomformázó
muködését
ehhez
illeszthessük.
A
forgalomformázó eroforrás-
igényének minimalizálása úgy lehetséges, hogy megállapítjuk mi az a maximális adatmennyiség, ami a kifele meno vonal szuk keresztmetszete miatt az eszközben reked, és ezt a leheto leggyorsabban továbbítjuk csökkentve a használt buffer méretét.
24
Másrészt ez a felhasználó számára is elonyös, hiszen ami a hálózatnak drága bufferolás az neki késleltetés.
3.3.2.
Mérési elrendezés
Ahogyan már a bevezetoben is említettem, egy valós Telia ADSL elofizeto helyzetéhez teljesen hasonló összeállítást próbáltam létrehozni úgy, hogy az összes, a valós rendszerben használt elemet beépítettem a mérohálózatba. Természetesen bizonyos elemek kihagyása nem befolyásolja a mérés eredményét, de az ilyen „csonkított” mérohálózatokat általában át kell építeni, ha változik a mérés célja. Mivel a tervezés folyamán várható, hogy bizonyos paraméterek hatásának tanulmányozása hasznos lehet a tervezés késobbi szakaszában, így még ebben a fázisban megismertem és felkonfiguráltam minden eszközt.
Modem
Vonal emulátor
PC
DSLAM ATM hálózat
Internet 34 Mbps
100 Mbps
10 Mbps
Router
Router
SMS 3-9. ábra A TCP forgalomanalízis mérési elrendezése
A 3-9. ábra mutatja a mérési összeállítást. A hálózati elemeket az elofizetotol az Internet fele haladva mutatom be, majd végül térek rá a passzív szerepet játszó méroeszközre. A végfelhasználót szimbolizáló számítógépen négy operációs rendszer futott; ?? Windows NT ?? Windows 98
25
?? Windows 2000 ?? Linux Ezek lefedik a mai átlagos felhasználók dönto többségét. Nagyobb számú mérést csak Windows NT-vel és Linux-szal végeztem, mivel a másik ketto Operációsrendszer
eredményei
nem
mutattak
jelentosebb
eltérést
az
elobb
említettektol. Minden TCP/IP beállítás az alapértelmezett volt. Az ADSL modem 10 Mbps-os Ethernet interfésszel biztosította a kapcsolatot az elofizeto fele. A telefonvonalba sorosan bekapcsolt vonalemulátor a vezeték hossza és átméroje alapján csillapítást illetve késletetést adott a vonalnak. Egyéni vagy ETSI profile szerint lehettet zajt hozzáadni a vonalhoz. 500 m 0.63 mm átméroju és 2 km 0.5 mm átméroju vezeték, ETSI A zajprofile voltak az aktuális értékek. A DSLAM-nál a beállítások megegyeztek a Telia által használt beállításokkal. Interleaving-et használtunk a rövid, teljes adatvesztéssel járó hibák kiküszöbölésére. A modem és a DSLAM a kapcsolat felvételkor állapodott meg a fizikai sebességben a vonal minosége alapján. A felfele jövo adatfolyam sebessége mindig tizede a lefele menonek, amely maximum 8 000 kbps lehet. A
DSLAM
és
az
Subscriber
Managment
System
(SMS
Elofizetoi
menedzsment rendszer) között elhelyezkedo ATM hálózaton (gyk. ketto kapcsoló) 20 Mbps-os sávszélesség volt lefoglalva és a policy ki volt kapcsolva. Ez azt jelenti, hogy mivel alig volt forgalom a hálózaton, akár tartósan használhatott a kapcsolat 155 Mbps-ot. Az SMS-nek kettos feladata van, kiválasztani minden csomagnak a kimeno interfészt ? minden elofizeto egy-egy interfész ? és ATM cellákba csomagolni, illetve darabolni az Ethernet csomagokat. Ez a belépési pont az ATM hálózatba, itt történik a forgalomformázás is. Ebben a mérésben a forgalom nem volt formázva. Az IP hálózathoz az SMS egy 100 Mbps-os interfészen kapcsolódott, de ezzel a sebességgel csak a laborban lévo gépeket tudta elérni, mivel az Internet fele a labornak csak egy 10 Mbps-os kapcsolata van. Ahogyan a 3-7. ábrán is látszik, innen 34 Mbps kapcsolat vezet be a Telia gerinchálózatába 5-6 routeren keresztül. Ezen a 34 Mbps a cég dolgozói kapnak Internet hozzáférést, így munkaidon kívül nagyon kicsi a forgalom. Méréseket mindig este, vagy hétvégén végeztem, így a hozzáférési hálózaton keletkezo torlódásoktól eltekinthetünk, ennek késleltetése is csak néhány ms. Tehát tekinthetjük, úgy, hogy a vizsgált ADSL elofizeto nagyon közel volt a
26
gerinchálózathoz, hasonlóan egy valós helyzethez, amikor is az SMS csak egy router keresztül csatlakozik oda. Csak azért nem csatlakozhat közvetlenül, mert ahhoz gerinchálózati routing protokoll kellene futtatnia. Az IXIA 10000 méromuszer két ponton monitorozta a forgalmat egy-egy ethernet interfésszel. A számítógép és a modem közti kapcsolatot egy kicsi HUB-on át látta, míg az SMS a „világ” fele nézo portját egy ethernet kapcsoló monitor interfészén keresztül hallgatta. Az eszközzel lehetoség van a vett csomagok tárolására, még az is megadható, hogy milyen hosszú rész maradjon a memóriában a csomag elejébol, így sokkal több csomagról gyujtheto információ. Természetesen portonként külön tárolhatók a csomagok, így a két memória összehasonlításából a méréspontok között elveszett csomagok is pontosan kiszurhetok.
3.3.3.
Mérés menete
Nagy, néhány Mbyte-nyi file-okat töltöttem le népszeru szerverekrol. A szerverek típusában és távolságában igyekeztem minél változatosabb képet adni, de mindig elsodleges szempont volt, hogy a szerver nyújtotta szolgáltatás széles körben népszeru legyen. Például ingyenes (freeware) programok (tocows), Linux csomagok (Debian, Redhat), nagy Internet portálok bár ez utóbbin kicsit nehezebb nagy file-okat találni. Közvetlenül a letöltés megkezdése elott indítottam el az adatgyujtés az IXIA két portján amelyek minden csomag elso 40 byte-ját tárolták a memóriában. Minden alakalommal 2000 csomagnyi mintát gyujtött minden porton. A méroeszközbol az információt
szöveg
formátumban
mentettem
ki
egy
PC-re,
ahol
a
további
adatfeldolgozás történt. A tárolt 40 byte tartalmazza a TCP sorszámot, így egy kis excel programozással
összehasonlítható
a
két
ponton
meghallgatott
adatfolyam
és
kiszurheto az SMS-ben bekövetkezo csomagvesztés. Több hasznos információt is tartalmaz a méromuszerbol kinyert nyers adatfile, de nekem csak néhányra volt szükségem, így csak a csomag méretet és az idobélyeget olvastam be az excelbe, lásd táblázat 3-8. Az idobélyegekbol adódik a két csomag közti késleltetés illetve a pillanatnyi sebesség.
27
Ido (s) 1 2 3 4
00.000000000 00.444326320 00.648560840 00.650648920
Hossz Késlelte- Sebesség (byte) tés (ms) (kbps) 64 1416 444,3 25 1416 204,2 55 1416 2,1 5425
3-4. táblázat Minta az feldolgozott adatokra
3.3.4.
Mérési eredmények
Eloször nézzünk egy Finnországból Stockholmba jövo folyamot. A mérés 2000. 11. 09-én történt, a körülfordulási ido ( Round Trip Time RTT) 25 ms volt. A 38. grafikon az Internet felol jövo csomagok beérkezési idejét mutatja az SMS elotti méréspontnál. A csomagok falkában (burstökben) jönnek, 9-10 darab egyszerre. Néha egyszerre az egész csoport megérkezik anélkül, hogy szünet lenne az adásban (backto back), mint például a 2. és 3. csoport, más esetben azonban néhány csomagnyi szünet is
0
40
80 120 160 200 240 280 320 360 400 440 480 520 560 600 640 680
Ido (ms) 3-10. ábra Letöltés Finnországból Linuxxal
beékelodik a csoportba. Ennek a magyarázata valószínuleg abban lelheto, hogy valamelyik routerben idegen csomagok ékelodtek be a burstbe. Tehát a szerver valószínuleg minden burstöt back-to-back továbbít és csak a hálózat zilálja késobb szét. Keményebb dió magának a burtösségnek oka. Abban bizonyosak, hogy lehetünk ez a TCP csúszó-ablakos forgalom szabályozásával van kapcsoltban (3.2.2 fejezet). Egy lehetoség az, hogy az adó burstökben kezdett el adni, így a nyugták is burstben érkeznek mindig vissza hozzá, amelyek lehetoséget adnak a lenyugtázottal azonos mennyiségu adat küldésére. Ebben az esetben azonban ha egyszer szétkenodött idoben a burst, akkor nincs semmi oka újra „megburstösödni” a forgalomnak, ez pedig többször is bekövetkezett a 2000 csomagos mérés során. Például a 3-10. ábrán a 460 ms-nál kezdodo burst kétszer annyi ido alatt érkezett meg, mint az ot követo.
28
Úgy tunik valami miatt csak akkor hajlandó az adó adni, ha már tudomása van róla, hogy 10 csomagnyi hely van a vevoben. A vevo SWS (és más ok) miatt késleltetheti a nyugtát, de kötelessége minden 2. csomag után azonnal nyugtát küldeni. A vizsgált operációsrendszerek ezt is teszik, minden második beérkezo csomag után küldik a nyugtát az adónak. Kizárásos alapon állítható, hogy csak a szerver késleltetheti a küldést, mindaddig, amíg meg nem kapta a nyugtát mind a 10 csomagra, 15 180 byte-ra. Ezt a viselkedést az SWS elkerülési, adó oldali b. módszer (3.2.4 fejezet) használatával lehet magyarázni. Csak akkor ad, ha legalább fél TCP ablaknyi hely van a vevoben. Egy WIN2000-rel végzett mérésnél tisztán látszik, hogy a szerver megvárja az összes nyugtát az egy burstben elküldött csomagokra, mielott újra küldene. A 3-11. ábra azt mutatja, amikor a burst méret 10 csomagról 12-re növekedett. A [0, 100] és az [1800,2000] intervallumon a burstök 37 ms-onként követik egymás, az utólsó, a 10., illetve 12. csomagra azonnal küldi a vevo a nyugtát. Amikor a eloször érkezik 11 csomagnyi burst, a vevo 97 ms-ot vár ennek az utolsó csomagnak a nyugtázásával, és erre válaszként kapja meg RTT elteltével a következo adatcsokrot, lásd. 3-5. táblázat.
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Ido (ms)
3-11. ábra Letöltés WIN2000-rel Dániából Ido (ms) 173,4 174,7 175,0 176,3 274,2 275,1 295,6 296,8 297,1
Méret (byte) 1518 1518 64 1518 64 64 1518 1518 64
Irány Adat Adat Nyugta Adat Nyugta Nyugta Adat Adat Nyugta
Ido relatív (ms) 1,3 1,2 0,3 1,3 97,9 0,9 20,5 1,2 0,3
3-5. táblázat Késletetett nyugta a WIN200-tol
Nézzük mit és hogyan befolyásol a szerver távolsága. Ha a fenti esethez képest növekszik távolság a burst méret változatlan marad, de a csomagok egy kicsit jobban elterülnek idoben ami azt az elképzelést erosíti, hogy a hálózat szórja el oket és ha növekszik a távolság, nol az érintett routerek száma, jobban szét tudnak szóródni. A 3-12. ábrán két burst látható egy olyan szervertol amihez az RTT=230 ms. Sajnos az 29
ábrán nem jól kiveheto, de abszolult értékben nagyobb távolságok vannak a csomagok között, mint közelebbi szerverek esetén.
0
50
100
150
200
250
300
Ido (ms)
3-12. ábra Letöltés nagytávolságból
Ha közeli szervertol kapjuk az információt, akkor a burst méretnek csökkennie kell az ablakmérettel együtt, ugyanis a rendelkezésre álló sávszélesség (jelen esetben kb. 5 Mbps IP szinten) kihasználásához már kisebb TCP ablak méret is elegendo, lásd 4-8. ábra képletét. Mivel a vizsgált operációsrendszerek nem használtak túl nagy TCP ablakot, a még a 7-8 ms RTT-vel rendelkezo szerver is a legnagyobb bursmérettel adott. Az RTT-tol az egy burstnyi adat megérkezésének periódusideje mindig nagyobb, legalább annyival, amennyi ido szükséges a burstnek a legszukebb keresztmetszetten ? ami általában SMS és az elofizeto közti szakaszon található? való áthaladásához szükséges. A 3-6. tábla az operációs rendszerek szerint mutatja meg a mért maximális burstméretet. Op. Rendsz. Win 2000 Win 98 Win NT 4.0 Linux
Max burst (byte) 18 216 9 108 8 496 15 180
3-6. táblázat Max. bust méret operációsrendszerek szerint
Az elvégzett mérések nem tekinthetok átfogó tanulmánynak, de annyi kimondható ezek alapján, hogy egyik szerver és kliens típus sem viselkedik jelentosen eltéroen a fent leírtakhoz képest.
3.3.5.
Összegzés
A fenti mérések alapján megállapítható, hogy a legburstösebb forgalom közép és nagy távolságban lévo szerverektol kapható. Ha valóban a SWS elkerülése miatt késik a szerverek csomagküldése, akkor a burtméret elméleti maximuma fél TCP ablak, 32 kbyte, de a manapság használatos operációsrendszerek alapbeállítások mellett nem lépik túl a 18 kbyte-os határt.
30
Nagyon nehéz azt megjósolni, hogy az Internet és a kapcsolatok sebességének növekedése hogyan fog hatni a burstösségre. A Window Scale Option mindenesetre növelni fogja ezt a börtméretet, de [Sano97] szerint nem lesz lineáris az összefüggés az adó/vevo buffer és a börstméret közti kapcsolat a 64 kbyte feletti tartományban. A kisebb teljesítményu masinák egyenletesebben fogják küldeni az adatokat az egyre szélesedo kapcsolatokon.
31
4. Állandó sebességre formázott forgalom A második fejezetben láthattuk, hogy forgalmi osztálytól függoen a GRCA nullaszor, egyszer vagy kétszer fut le egy adott sorra. UBR és ABR forgalmi osztályok esetén a szabvány szerint nincs garancia a hálózat által átvitt forgalom nagyságára, ezért nincs szükség a GRCA használatára sem. A csomag elküldhetoségérol prioritásos úton dönt a hálózat. Az ABR illetve UBR felhasználók adata akkor továbbítódik, ha az összes egyéb forgalmi osztály forgalma mellett még marad hely a linken. Tehát itt nem beszélhetünk szoros értelemben vett forgalomformázásról. A Telia ilyen garancia nélküli szolgáltatás eladását egyelore nem is tervezi, úgy gondolja, hogy jól méretezett hálózat esetén megfelelo kihasználtság érheto el csak garanciát biztosító forgalmi osztályok használata esetén is. Másrészt több forgalmi osztály ütemezéséhez prioritásos sorok kezelésére van szükség, ami nem mindegyik eszközben muködik, ahogyan ezt a hatodik fejezetben mérésekkel alátámasztva is látni fogjuk. Ebben
a
fejezetben
olyan
forgalomformázási
mód(ok)hoz
keresünk
paramétereket, amelyeknél a GRCA egyszer fut le a soron. Az ilyen osztályok száma azért bizonytalan, mert a szabvány [TrafMgt99] csak a CBR-t definiálja, de számos gyártó implementálja az UBR+ -ot, ami algoritmikusan teljesen hasonlóan muködik az elobbihez. Az elso alfejezetben a VP formázását tárgyaljuk, míg a másodikban a felhasználónkénti VC formázást.
4.1.
Forgalomformázás VP-n
Az elofizetoi menedzsment rendszer és a DSLAM között az információt szállító ATM hálózatban az út sokszor igen hosszú lehet, a leggazdaságosabb nyilvános hálózaton felépíteni a kapcsolatot. Ellenben a saját hálózat használatával ebben az esetben nem csak a hálózat kihasználtságának javítása, ha nem az ATM hálózat üzemeltetojével kötött szerzodés miatt is szükséges a forgalomformázás.
32
4.1.1.
Milyen forgalmi osztályt válaszunk?
Ennek a kérdésnek a megválaszolásához két szempontot kell figyelembe venni: ?? a forgalom jellege ?? a használt eszközök képességei Egy-egy VP-n jelentos számú –
néhány tucattól több százig–elofizeto
forgalma adódik össze. Ha Poisson forrásnak tekintjük a felhasználókat, akkor a VP-n összegzett forgalom közel áll egy állandó sebességu folyamhoz. Ezen modell alapján egy CBR cso annál jobban kihasználható, mennél több felhasználó forgalma agregálódik, persze mindenesetre azonosan kicsi csomageldobási arányt elvárva. Úgy tunik az eszközgyártók is ebbol a feltételezésbol indultak ki, ugyanis a Telia laborában általam vizsgált két eszköz közül az egyik csak CBR eloírások szerint tudja formázni a forgalmat. Mivel már a ma is vannak ilyen eszközök használatban és ma is folytatódik beszerelésük, a választás a továbbiakban egyesélyes. A fentiek ellenére azt hiszem, nem szabad elhallgatni, hogy egyre elterjedtebb a Poisson modell helyett fraktális modell alkalmazása az Internet forgalom leírására. Ez annyiban másabb, hogy a felhasználók számának növekedése mellett is megtartja az összegzett forgalom a burtösségét. [WWilinger98]
4.1.2.
Követelmények
Az ATM hálózat nem tesz különbséget az egyes felhasználók forgalma között. Az oket azonosító, az ATM cella fejlécében található VC számot nem veszi figyelembe. A hálózat kapcsolói a sok elofizetot összefogó VP szám alapján kapcsolnak, sokat egyszerusítve ezzel a továbbítási táblán. Ennek is következménye az, hogy az ATM hálózat csak VP szinten szab meg követelményeket a forgalmi szerzodés szerint, ezt viszont szigorúan ellenorzi is. A police feladata, hogy az ATM hálózatba belépo forgalom paramétereit megvizsgálja, a szerzodést megszego cellákat vagy alacsony prioritással megjelölve bocsátja a hálózatba, vagy már a belépési ponton eldobja. Mindez nem csak a „bliccelés” elkerülésére történik, de a hálózat túlterhelésének kivédése miatt is. Amiatt kell kiemelt figyelmet szentelnünk ennek a police-nak, mert o csak ATM szinten vizsgája a folyamot és cellánkét dönt a megfeleloségrol, illetve dob el. A végponttól végpontig továbbított átlagos méretu IP csomagot 10-12 cella szállítja, amibol ha egy eldobódik, akkor az egész csomag hasznavehetetlen lesz. Ez azt jelenti, 33
hogy ha a police 1%-át dobja el a celláknak, akkor körülbelül 10%-a veszik el a forgalomnak IP szinten.
4.1.3. Mivel
VP forgalomformázás megfeleloségi vizsgálata a
VP
nem
megfelelo
sebességre
való
formázásának
hatása
hatványozódik ebben a dolgozatban kiemelten foglalkozom ezzel a kérdéssel. A következokben mindkét, a laborban megtalálható SMS-t megvizsgálom, hogy valóban a megadott paraméterek szerint végzik-e a forgalomformázást. Mérési összeállítás: Forgalomgenerátornak az IXIA 10000 IP eszköz egyik 100 Mbps-os portját használtam, a vételi oldalon pedig az ADTECH 400 ATM méromuszer hallgatott egy STM-1-es kapcsolatot. A tesztelt eszközben a használt IP interfészen bejövo összes forgalmat egy VP-re irányította, amely CBR-ként volt formázva: PCR
(Peak
Cell
Rate)
:
25
000
kbps
CDV (Cell Delay Variation) : 200 ? s
UTP100 Mbps IXIA IP Tester
STM 1
SMS
ADTECH 400 ATM Tester
4-1. ábra VP forgalomformázási mérés összeállítása
Mérés menete: Az IXIÁ-ból induló IP forgalmat 0-tól 100 Mbps-ig 10 Mbpsonként növeltem és az ADTECH-kel mértem az SMS-bol kijövo ATM folyam sebességét. Eredmény: A két mért eszköz, SMS1 és SMS2 a követelményeknek megfelelt mind PCR, mind CDV tekintetében. Tehát a police-t végzo eszköz nem dobhat el cellát az ATM hálózatba irányuló forgalomból. Az eredmények között olyan kicsi az eltérés, hogy az a grafikonokon nem is látható.
34
30 000
Vett (kbps)
25 000 20 000 15 000 10 000 5 000 0
0
10
20
30
40
50
60
70
80
90
100
Adott (Mbps)
4-2. ábra VP forgalomformázás, SMS1 és SMS2 eredményei
Amíg SMS2 minden eredménye csak néhány száz bps-mal marad el a 25 000 kbps-tól, addig SMS1 átlagosan 4000-5000 bps-ban vette fel a távolságot. Ez a különbség az eszközök architektúrájával magyarázható, SMS2 gyakorlatilag egy ATM kapcsolót tartalmaz, amíg SMS1 egy IP eszköz „tuningolásából” született.
4.1.4.
PCR meghatározása
Végül a CBR két paraméteréthez kell javaslatot adni. A PCR, a VP cso átméroje a benne elhelyezni kívánt ?? felhasználók számától, ?? az egyes felhasználók sávszélességétol ?? és az egyes felhasználók aktivitásától függ. A Telia egy tapasztalt forgalom elméleti szakembere, egy heti munkával becslést adott erre [KLindberger00].
O Poisson eloszlást feltételezett a források
adására és egy eloírt adatvesztési arányhoz határozta meg a VP méretét. Sajnos azonban ez az elmélet egy policert feltételez az SMS helyén. Teljesen figyelmen kívül hagyja, hogy a forgalomformázó eszköz képes égész jelentos mennyiségu adatot (kb. 1,5 MB-ot) tárolni simítva a forgalmat és csökkentve az eldobás mértékét. Ezen tulajdonság figyelembe vételével sokkal bonyolultabbá válik a modell, valószínuleg nem is adható rá egzakt megoldás. Véleményem szerint e probléma megoldása egy teljes diplomamunkát is kitehet. Praktikus megoldás a PCR meghatározására egy kezdeti becslés után folyamatos korigáció alkalmazása, hasonlóan a TCP sebesség kontroljához. Az SMS számlálóinak rendszeres ellenorzésével ki kell szurni a túlterhelt kapcsolatot és 35
növelni a cso méretét, vagy csökkenteni a VP-n elhelyezett felhasználók számát. Az adatvesztést nem jelzo linkekre érdemes új elofizetoket telepíteni az egyensúlyi pontot keresve.
4.1.5.
CDV meghatározása
Arra, hogy az eloírt idohöz képest milyen ingadozással indulnak, indulhatnak a cellák, három dolognak van hatása ?? forgalom érzékenysége a késleltetés ingadozásra ?? PCR és a link sebesség (LK, Link Rate) aránya ?? forgalom formázó processzorának teljesítménye Az elso pont kapcsán elmondhatjuk, ez a foleg HTTP-bol álló forgalom nem érzékeny a késleltetés ingadozásra. A második pontban említet PCR/LR arány miatt, akkor jelentkezik CDV ha az nem fejezheto ki 1/n alakban (ahol n egész szám). Ugyanis fizikai szinten az ATM cellák csak adott idopillanatokban indulhatnak, pl. egy 155 Mbps-os linken t=0? s 2,7? s
5,4? s … idopontokban. Ha ezen a linken egy folyamot 102 Mbps-ra
formázunk, akkor a celláknak ideális esetben is 4? s-onként kell érkezni, de a legjobb esetben is t=0? s 2,7? s 8,1? s 9,8? s 12,5? s –kor érkezhetnek, vagyis ebben az esetben mindenképpen lesz 1,3? s CDV. A nagy sebességu linkeken a cella idok hosszúsága nem esik messze a kapcsoló processzorain futó taszkok futási idejétol. E határ miatt megesik, hogy pusztán az ütemezo processz hibájából nem tud elindulni (megérkezni) a cella az eloírt idopontban. Az ilyen okból adódó apró torlódások elviselésére is lehetoséget ad a police-t végzo eszközben a CDVT. Kisebb CDV azt jelenti, hogy az eszköznek, az ütemezo processznek surubben kell „ránézni” az adott sorra, nagyobb a processzor terhelése. Nekünk tehát egy olyan CDV-t kell alkalmaznunk, amely esetén teljes terhelés mellett is az SMS processzora el tudja látni feladatát. A fenti meghatározás alapján a legpontosabb az volna, ha kimérnénk az értéket, de ez túlzottan eszköz- és költségigényes. Megbízva a gyártók ajánlásában és az eddigi tapasztalatainkban, azt mondhatjuk, az SMS jól fog muködni, ha 100 ? s körüli étéket adunk meg. Ez jóval több, mint amennyi CDV a PCR/LR szerint kialakulhat, így megfelelo, ha az SMS-ben beállított CDV 10-20%-kal kisebb, mint az ATM hálózat belépési pontjánál használt CDVT érték. 36
4.2.
Forgalomformázás VC-n
Ebben az alfejezetben azt az estet vizsgáljuk, amikor az egyes felhasználók forgalmát úgy formázzuk, hogy a GRCA algoritmust egyszer futatjuk le a soron. Eloször ismetetem a két idetartozó forgalmi osztályt, majd rávilágítok, hogy a várható forgalom ilyen módon való formázása technikai szempontból hátrányosabb a VBR formázásnál.
4.2.1.
CBR és UBR+
A 4.2 bevezetésében említett kritériumnak az ATM Traffic Managment-ben [TrafMgt99] definiált osztályok közül egy felel meg, a CBR. Ez az osztály 100%-os garanciát ad az adott sebességet nem meghaladó forgalom továbbítására, és késleltetési paraméterei is nagyon jók, a többi forgalmi osztállyal szemben mindig elsobbsége van, övé a legmagasabb prioritás. Általában a CBR felhasználóról feltételezzük, hogy folyamatosan kitölti a sávszélességét, amit le is foglalunk a linken. Így kis aktivitású felhasználók esetén nem lehetséges a linket kitölteni. Ráadásul egy off-line adatforgalom esetén – alapvetoen ilyen az itt tárgyalt ADSL elofizetoké is – teljesen felesleges a magas prioritás, eros késleltetés garancia. Vannak olyan esetek, amikor a CBR-hez hasonlóan egyeszuen csak egy felso határ beállítását várjuk el a forgalomformázástól mindenféle garancia nélkül. Például errol van szó ha egy felhasználó best effort
szolgáltatást fizet elo egy X
sávszélességre és valahol a hozzáférésben van olyan fizikai link amelyik kapacitása X. Ilyen igényhez van illesztve az eszközgyártók által kifejlesztett UBR+ forgalmi osztály, amely annyival több az UBR-nél, hogy a beállított maximális sebességnél magasabbra akkor sem engedi a felhasználót, ha egyébként még lenne a hálózatban
szabad
kapacitás.
Az
UBR+
felhasználó
celláinak
(csomagjainak)
ütemezésekor egyszer fut le a GRCA algoritmus, emiatt hasonló a CBR-rel. Ez a hasonlóság annyira kézzelfogható, hogy az SMS1-ben csak CBR forgalmiosztály használatával
elkerüljük
a
prioritásból
fakadó
különbséget,
akkor
CBR
bekonfigurálása mellett olyan lesz a forgalomformázás, mint ha UBR+ lett volna beállítva, ugyanis ebben az eszközben mindegyik forgalmi osztály azonos méretu queue-t (sort) használ. Az UBR+ megjelenése is arról tanúskodik, hogy ma még legnagyobb arányban best effort szolgáltatásokat szállítanak az ATM hálózatok. Jó példa az ATM 37
képességek
kihasználására,
hogy
bizonyos megvalósítások estén egy garantált
minimális sávszélességet is be lehet állítani az UBR+ -nak, amit az eszköz le is foglalt a linken.
4.2.2.
PCR meghatározása
A PCR megválasztásánál elso gondolatként egyszeruen csak azt mondanánk, vegyük az elofizetovel megkötött szerzodésben szereplo sávszélességet. Ez akár teljesen jogosan is tehetjük a szerzodésben nincs feltüntetve, hogy milyen szinten értjük ezt az értéket; pl. szerepelhet az, hogy „adatszolgáltatás sávszélessége: X Mbps” Ha jobban átgondoljuk a helyzetet, könnyen beláthatjuk, hogy igazából a felhasználó számára az ATM használata teljesen feleslegesnek tunik, hiszen o csak IP csomagokhoz férhet hozzá, az ATM kapcsolat csak a technológia miatt iktatódik be. Miért fizetne az elofizeto egy olyan plusz fejlécek szállításáért, amelyeket o nem is lát, elonyeit is legfeljebb közvetve tudja csak elvezni. Azt javaslom, mivel csak IP-hez fér hozzá az elofizeto, így a szerzodésben is IP sávszélesség szerepeljen, a PCR-t, illetve majd a VBR-nél (5. fejezet) a SCR-t úgy adjuk meg, hogy a szerzodében szereplo értéket megnöveljük az ATM-be történo becsomagolásból származó többlettel. A többlet három részbol adódik össze: ?? ATM fejléc (5/48=) 10,42 % ?? ALL5 farok 8 byte csomagonként ?? Kiegészítés (0-47 byte) átlagosan 23,5 byte A 3.6 ábra alapján készített 4.3 ábra azt egy modellezését adja annak, hogy „tömeg” (byte) szerint hogyan oszlanak el a csomagok.
Százalék byte szerint
Csomaghosszúság eloszlási modell 70% 60% 50% 40% 30% 20% 10% 0%
58% 32% 10%
64
576 Csomagméret (byte)
1514
4-3. ábra Csomag hosszúság eloszlási modell
38
A 64 byte-os csomagoknál a kiegészít 26 byte-tal számolom – gyk. egy csomag = két cella –, míg a további csoportoknál az átlagos 23,5 byte-tal.
2 ? 53byte (576 ? 8 ? 23,5)byte ? 110,42% ? 32% ? ? 64byte 576byte (1514 ? 8 ? 23,5)bytes ? 110,24% ? 58% ? ? 100% ? 19,21% 1514byte
10% ?
4-4. ábra AAL5 snap csomagolás többlete (overheadje)
A 4.4 –es ábrán kapott eredmény a többlet mértékére, olyan esetre vonatkozik, amikor a szimmetrikus a forgalom. A tárgyalt esetben a vizsgált irányban a nagy csomagok
aránya
nagyobb,
jellemzoen
a
felhasználó
fele
jönnek
a
nagy
adatcsomagok, visszafele pedig a 64 byte-os ACK üzenetek. Mivel egy 1514 byte-os csomag többlete csak 12,7%, ezért a 19,2%-nál kisebb értéket kell vennünk, én 1617%-ot javasolok.
4.2.3.
CDV meghatározása
Valójában az itt megfontolandó kritériumok nagyon hasonlóak a 4.1.5-ben tárgyaltakhoz. A különbség abban van, hogy ezt a forgalomformázást már
nem
ellenorzi a szállító ATM hálózat, nagyobb értékek választása sem okoz cella eldobást. Nem szabad azt sem elfelejteni, hogy a VP-t formázó algoritmus a VC-t követoen fut le, így nincs értelme kisebb CDV-t megadni, mint amit megadtunk a VP-nél. Tehát itt is a gyakorlatban bevált 100? s-ot javaslom.
4.2.4.
Elonyök és hátrányok
A 3. fejezetben megismert, igen burtsös forgalom megformázását feltéve értéklejük a VC állandó sebességre történo formázását. Tisztán csak akkor fogjuk látni a helyzetet, ha majd össze tudjuk hasonlítani a másik lehetséges formázási móddal, így néhány itt következo állítás magyarázata csak az 5. fejezetben lesz megtalálható. A formázási algoritmus viszonylag egyszeru, kicsi az eroforrás igénye, mivel a GRCA-t csak egyszer alkalmazzuk. Pusztán a formázás miatt is, az elofizetok nagyobb sebességet tudnak elérni a közelebbi szerverekrol, így inkább ezeket használják, ami a szolgáltatónak sokkal olcsóbb.
39
Mivel az SMS Internet kapcsolata sokkal gyorsabb a PCR-nél és a burstök is nagyok, ezért a „falkában” érkezo IP csomagok átlagosan sok idot fognak tölteni az SMS-ben, fogyasztva a memóriát. SMS1-ben nincs az UBR+ implementálva, így két elonytelen megoldásból kell választani. Használni VBR-nrt-t SCR=PCR paraméterekkel, de ekkor eroforrást pazarolunk, vagy használni CBR-t, mint UBR+ -ot, de ez csak addig lehetséges, amíg nem szeretnénk más forgalmi osztályt is használni, hiszen ekkor az UBR+-nak tekintett osztálynak mindenkinél nagyobb lenne a prioritása.
40
5. Változó sebességre formázott forgalom Ha a GRCA két pár paraméterrel, két alakalommal fut le a soron, akkor VBR forgalmi osztályról beszélünk. A VBR-nrt-nek és VBR-rt-nek t ugyan az a négy paramétere van. A különbség abban áll, hogy a valósideju forgalom nem késleltetheto, így ebben az esetben nagyon kicsi a buffer. Ebben a fejezetben VBR-nrt-vel foglalkozunk. Eloször egy japán kutatást ismerünk meg, amelyben a TCP forgalom formázását vizsgálták VBR forgalmi osztályt használva. A 2. alfejezetben adott környezethez illesztjük a paramétereket. Mivel nem minden kérdés tisztázható elméletileg, így a 3. alfejezetben mérésékkel vizsgáljuk meg a kapott eredményeket.
5.1.
VBR forgalmi osztályon létesített TCP kapcsolat elemzése
Az ATM technológia terjedésével párhuzamosan vált egyre érdekesebbé, hogyan viselkedik a TCP/IP, ha ATM hálózaton szállítjuk. 1994-tol kezdve jelentek meg
különbözo
tanulmányok
ebben
a
témában,
foleg
mérésekre
alapozva
eredményeiket. A legtöbb teljesítmény vizsgálat ABR és UBR forgalmi osztályt használt [KMoldeklev94],
[HSaito96], az a néhány VBR osztályon végzett
tanulmány [OBonaveture96] is foleg azzal a problémával foglalkozik, hogy mi történik, ha csak egy-egy cellát dob el a kapcsoló tekintet nélkül arra, hogy ez egy IP csomag része. Mára már alapkövetelmény olyan kapcsolók beépítése a hálózatba, amik tudják az Early Packet Discard-ot, vagyis ha szükségessé válik egy cella eldobása, akkor a kapcsoló az összes, az IP csomaghoz tartozó cellát eldobja. A KDD egy vezeto japán telekommunikációs szolgáltató, 80 vállalat szövetségébol alakult a század közepén. Jelenvan az európai és az Amerikai piacon is. fejleszto és kutató központjukban egy 5 fos csapat két publikációt készített „TCP over VBR” témában. Az elsoben ma használatos TCP implementációval felszerelt számítógépeken végeztek méréseket [SAno1997] , amíg a másodikban egy kicsit távolabbi jövobe tekintettek és a ma még nem igazán elterjed Window Scale Option 41
bekapcsolása mellett vizsgálták a gépek közötti kommunikációt [SAno98]. Sajnos ennek a diplomamunkának a terjedelme nem engedi meg, hogy a második cikket is feldolgozzuk, de annyi tanulság így elöljáróban is leszurheto, hogy az MBS, SCR paraméterek 4-10-szeres növelésre szorulnak WSO bekapcsolásakor.
5.1.1.
A tanulmány célja
Az alapkoncepció az volt, hogy olyan VBR paramétereket kell választani, amelyek esetén a formázás bekapcsolása mellett is úgy érezze a két kommunikáló gép, mintha egy terheletlen, nagysebességu hálózaton tartanák a kapcsolatot. Tehát elso lépésben egy ATM szinten kontrolálatlan forgalmat „vettek fel”, majd olyan VBR paramétereket kerestek, amelyekkel a forgalomformázás sem változtatja meg a forgalom karakterisztikáját.
5.1.2.
A mérés összeállítása és menete
Az 5-1. ábrán látható az egyszerusített mérési elrendezés. A két Sun munkaállomás gyakorlatilag egy DS3 (45Mbps) linken látja egymást. Az ATM hálózat
„méretét”
az
ADTECH
vonal
emulátor
határozta
meg,
és
passzív
üzemmódban rögzítette a HP 75000 a cellaérkezési idoket. HP ATM Line Monitor
ATM Swich DS3 (45 Mbps) ADTECH Vonal Emulátor OC3 (155 Mbps)
OC3 (155 Mbps)
SUN Munkaállomás
SUN Munkaállomás
5-1. ábra [SAno97]-ben használt mérési elrendezés
Változtatott paraméterek: RTT (Roundtrip Time) Adó/Vevo (S/R) buffer mérete
: 10ms, 160ms : 24 kbyte, 48 kbyte 42
MSS (maximum segment size) Lokális
(RTT=10ms),
illetve
nagy
: 512 byte 9148 byte
távolságú
(RTT=160ms)
kapcsolat
szimulálása mellett vizsgálták a forgalmat, egy és több TCP kapcsolat esetén. Az ATM kapcsolóban a UPC ki volt kapcsolva, a gépek rendelkezésére állt az egész fizikai sávszélesség, amit az egyik munkaállomáson futó forgalomgenerátor próbált kihasználni amennyire a TCP engedte. A vizsgált esetben gyakorlatilag csak az MBS-t és az SCR-t kellett meghatározni, ugyanis a PCR-t a vonal határozta meg, a CDV-nek a hatását pedig elhanyagolhatónak tekintették. A felvett adatfolyamot egy szimulátor program segítségével egy olyan lukas vödrön folyatták keresztül, aminek nem volt korlátozva a mélysége (mérete). Így az önkényesen megválasztott SCR-hez (itt a lyuk mérete) tartozó MBS annyi lett, mint amennyi a vödörben lévo cellák számának legnagyobb értéke.
5.1.3.
Eredmények
Az MBS és SCR így becsülheto: ? S buffer ? ? R ? * MSS ? MSS ? ? MBS ? ? cella 48byte MBS * 53 * 8bit SCR ? bps RTT 5-2. ábra SCR és MBS elméleti becslése
Vizsgáljuk meg a kapott SCR-MBS görbéket (A függelékben). Csökkentve az SCR értékét az elso szakaszon az MBS értéke alig emelkedik, e szakasz végén van egy pont, ahol a görbe közel derékszögben megindul plusz végtelen felé. Ebben a töréspontban felvett értékek az SCR és MBS minimumának tekinhetok. Az itt kapott MBS adja meg a forgalom burstösségét. A becsült és a töréspontban felvett SCR és MBS értékek RTT=160ms esetén szinte teljesen megegyeznek, RTT=10ms esetén 25-40%-kal kisebbek a becsült értéknél (5-3. ábra). Ez a nagy eltérés valószínuleg azzal magyarázható, hogy a viszonylag nagy forgalmi terhelés mellett a valódi RTT megnott, mivel a Sun csaknem „azonnal” adta a választ.
43
Mért MSS=9148byte és S/R=24kbyte MSS=512byte és S/R=24kbyte MSS=9148byte és S/R=48byte
MBS SCR MBS SCR MBS SCR
RTT=10ms RTT=160ms Becsült Mért Becsült 380 390 390 390 11,5 17 1 1 530 580 580 580 18 24 1,5 1,55 720 960 940 960 23 41,6 2,4 2,6
[MBS]=cella, [SCR]=Mbps*
5-1. táblázat Méréssel kapott MBS és SCR értékek
Több TCP kapcsolat estén az SCR lineárisan növekszik a kapcsolatok számával, ami várható is volt. Az MBS esetén viszont sejtheto a nem lineáris kapcsolat, de a becslések készítése jóval bonyolultabbnak tunik, mint az elozo estekben. A 5-3. ábra az MBS függését mutatja a kapcsolatok számától, tendenciák
MBS (cella)
leszuréséhez azonban nincs elegendo adat. 3000 2425
2000 1000
960 530
0
1445 606
1934 995
632
0 0
1 2 3 Kapcsolatok száma RTT=160ms
4
MSS=512B, S/R=24kB MSS=8148B, S/R=48kB
5-3. ábra MBS függése a TCP kapcsolatok számától
5.2.
VBR forgalomformázás VC-n
Ahogyan már a második fejezetben is láttuk, a VBR forgalmi osztálynak négy paramétere van; PCR és CDV, SCR és MBS. Ezekbol az CDV és az SCR megválasztása nem igényel részletesebb tárgyalást. A fennmaradó MBS-t alapvetoen a forgalom jellege, míg a PCR-t a fizikai lehetoségek határozzák meg. Az SCR értékét egyértelmuen a szerzodében meghatározott sebességre kell állítani, pontosabban annak 117%-ára, mivel itt ATM szintu paraméter (részletesebb indoklást lásd. 4.2.2.). A VC formázás szintjén a CDV annyira kis jelentoségu, hogy
*
A táblázatban található adatok a függelékben csatolt ábráról lettek
leolvasva, ezért néhány százalékos eltérés az eredeti értékéktol feltételezheto.
44
bizonyos eszközök esetén külön paranccsal kell megváltoztatni a gyárilag beállított értéket. Amennyiben az eszköz követeli a CDV beállítását a javasolt érték a 100? s (lásd. 4.1.5. fejezet).
5.2.1.
MBS megválasztása
[SAno1997]-ben láthattuk, hogy az 5-2. ábra elso képletében adott közelítés az MBS-re igen jó felso becslés. Az a cikk azonban csak egy operációs rendszerre terjesztette ki viszgálódásait terheletlen hálózat mellett. Az általam végzet, 3.3 fejezetben ismertett mérés eredményeket szolgáltat a legtöbb, ma széleskörben népszeru operációs rendszer által generált forgalomról, egy reális hálózat, az Internet használata mellett. A 3.3 fejezet eredményei alapján elmondható, ma 18 kbytenyi, 384 cellányi MBS alakalmas a legtöbb TCP kapcsolat burtsjeinek az átvitelére. Az 5-3. ábra azt mutatja, hogy az MBS 15%, 50%-kal növekszik ketto TCP kapcsolat esetén. Tehát 30-40%-kal kell növelni az egy kapcsolatnál tapasztalt értéket, hogy két TCP kapcsolat esetén is nagy valószínuséggel PCR-en továbbítódjanak az egy-egy bursthöz tartozó cellák. Ez esetben MBS= 500-550 cella. Nehéz választ adni arra a kérdére, hogy a bust mérete hová konvergál, ha nem használjuk a megnagyobbítot ablakok. A TCP fejléc 64 kbyte-ra korlátozza a TCP ablak méretét. Figyelve egy olyan kapcsolatot ahol a burstméret 18 kbyte volt, találtam olyan csomagot amiben a TCP ablakmérete 32 kbyte, sajnos azonban igazi protokol dekoder nem állt rendelkezésre, így megbízható méréseket nem sikerült végezni. Mindenesetre ez és az a buta ablak elkerülési módszer (csak akkor küld csomagot az adó, ha legalább fél TCP ablaknyi mennyiséget el tud küldeni) arra utal, hogy valójában a burst mérete nem 64kbyte-ban, hanem ennek felében, 32 kbyte-ban maximalizálódik. A 32 kbyte 682 cellába fér bele, ami alig több, mint a fentebb javasolt 550 cella és akkor egész biztosan beleférne minden lehetséges burst az MBS-be. Én több ok miatt sem javaslok 550-nél többet. Eloször is ez csak egy sejtés, másodszor pedig a DSLAM bufferek sem képesek ennyi cellát tárolni.
5.2.2.
PCR megválasztása
Az SMS-be 100 Mbps-on jönnek be az IP csomagok, ezt a sebességet egyértelmuen csökkenteni kell mielott a felhasználók fele továbbítjuk a csomagot. 45
Mivel a gyorsabb továbbítás kevesebb buffer használatot jelent és a felhasználónak is az az elonyös, ha minél hamarabb megkapja az egy burtshöz tartozó csomagjait ezért a maximális értéket kell megkeresni. Az elofizeto és az SMS között a szuk keretmetszete egyértelmuen a telefonvonalnál található. Sajnos az adatátvitel maximális sebessége függ a vezeték hosszától,
átmérojétol
és
zajterheltségétol.
Persze
ezek
közül a távolság a
legmeghatározóbb, így az ettol való függést be is mutatom az 5-4. ábrán. Az 5-4. ábrához hasonló összefüggések nem túl nehéz egy laborban megvizsgálni, de például arról információt szerezni, hogy az elofizetok hány százalékának van 1 km-nél rövidebb kábele, szinte lehetetlennek tunik. És akkor még meg sem említettük a kábel típusok tarkaságát. Nem marad hát máslehetoség , mint józan becslésekbe bocsátkozni, hogy az elofizetok mekkora hányada érhet el legalább például 5 Mbps-os kapcsolatot.
Max. sebesség (Mbps)
10 8 6 4 2 0 0
1000
2000
3000
4000
Távolság (m) 5-4. ábra Elérheto átviteli sebesség a távolság függvényében lakóövezetben
Mivel a telefonközpont 1 km-es környezetében közel 8 Mbps-os a kapcsolat és általában a központ környéke surubben lakot terület, így vizsgáljuk meg azt az esetet amikor a PCR=8 Mbps. Azt a problémát kell megvizsgálni, hogy mi történik azokkal a cellákkal, amelyek egy busrhöz tartozva 8 Mbps-mal megérkeznek a DSLAM-ba és onnan már csak
0,5
Mbps-mal
továbbítódhatnak
egy
adott
elofizeto
felé.
Ez
a
46
legpesszimisztikusabb eset, Telia ugyanis nem nyújt 0,5 Mbps-nál lassabb DSL szolgáltatást. A cella vesztés elkerülésének alapfeltétele ez esetben az, hogy a DSLAM-nak rendelkeznie kell legaalább: 0,5Mbps * MBS PCR hálózatában használt háromféle eszközön ezek a
MBS ?
méretu
bufferrel.
A
Telia
paraméterek már egy korábbi projekt kapcsán ki lettek mérve, és 5-2. táblázatban találhatók meg. MBS=550 cella és PCR=8 Mbps esetén a minimális bufferméret 516 cella, aminél csak alig nagyobb a DSLAM2 legnagyobb buffere. Említésre méltó, hogy ha PCR változásának kicsi a hatása a minimális bufferméretre, ha PCR=4 Mbps ? aminél kisebbet nem logikus választani? a minimális buffer méret 482 cella, vagy feltéve az 523 cellányi buffer kihasználását MBS= 597 cella. Szolgáltatás Irány Buffer DSLAM1 UBR le 8000 cella fel 1000 cella CBR le 128 cella fel 24 cella 523 cella DSLAM2 Alacsony le fel ? Közép le 300 cella fel ? Magas le 34 cella fel ? DSLAM3 UBR le 1500 cella fel 1500 cella CBR le 48 cella fel 6 cella 5-2. táblázat DSLAM buffer méretek
Az 5-2. táblázat tanulsága, ennek a burstös forgalomnak magasabb szolgáltatás osztályban való elhelyezése nem hogy javítja, de meg is ölheti a forgalmat. Ez foleg a DSLAM2 forgalmi osztályainak elnevezése esetében nem magától értetodo. Összefoglalva a fentieket, a Telia eszközeihez és a várt forgalomhoz legjobban PCR=8 Mbps MBS=384 cella illeszkednek, de sok elonnyel jár ha (részletesen lásd. 5.2.3. fejezet) MBS=550 cella
47
5.2.3.
Elonyök és hátrányok
Ahogyan az elozokben láthattuk, két különbözo mód van a VC-k formálására. Alapvetoen ezek összehasonlításából kiindulva a VBR forgalomformázásnak három elonyös és ketto hátrányos tulajdonságát emelem ki. Elméleti sebességének:
maximuma
egy
TCP
kapcsolat
átviteli
max .TCPablak . Vegyünk azt az esetet amikor ez kisebb, mint az RTT
elofizeto által vásárolt sávszélesség. A 3.3 fejezet mérései szerint a fenti képletben szereplo a RTT valójában három tényezobol áll: ?? terjedési késleltetés ?? feldolgozási ido az adónál/vevonél ?? egy burst elso utolsó byte-jának megérkezése közti ido Például a ping program RTT-je az elso két ido összegét adja meg. Az utolsó pontban szereplo idot a kapcsolatban lévo szukkeresztmetszettol függ, tehát ha a hálózatban nincs torlódás, akkor a PCR-tol. Nézzük mennyi is ez az ido ha 18 kbyte a burst: PCR 8 Mbps 2 Mbps 0,5 Mbps
ido 2,20 ms 8,79 ms 35,2 ms
Vegyünk egy olyan szervert, amelyikre a ping RTT=80 ms–ot formázással
ad. VBR
18kbyte 18kbyte ? 1751kbps , míg UBR+ esetén ? 1621kbps az átviteli 82,2ms 88,79 ms
sebesség egy 2 Mbps-os elofizeto esetén, vagyis a VBR 8%-kal gyorsabb. Az burtshöz tartozó csomagok beérkezési (pl. 100 Mbps) és kimeneteli sebessége között egy nagyságrendnyi a különbség, ezért a mindenképpen jelentos mennyiségu buffer kapacitásra van szükség. Könnyen belátható, hogy amikor a leheto legnagyobb sebességgel küldjük tovább az egy burst csomagjait, akkor kisebb a bufferigény. Az 5-5. ábra jól szemlélteti, hogy egy 2 Mbps-mal letöltést végzo felhasználó UBR+ esetén négyszer annyi buffert használ el az SMS-ben, mint VCR esetén. Az elofizeto második TCP kapcsolat is komfortosan érzi magát. Az 5-5. ábrán egy TCP kapcsolat kihasználja a felhasználó elofizetett sávszélességét, ha azonban ezt két kapcsolat teszi meg, akkor a két burst egymáshoz közelebb is érkezhet (akár
48
Bufferelt Adat (kbyte)
20 15
VBR UBR+
10 5 0 0
20
40
Ido
60
80
5-5. ábra Buffer igény UBR+ és VBR esetén
azonos idopontban is, de ennek nagyon kicsi a valószínusége).
Az 5-3. ábra azt
mutatja, hogy az egy kapcsolathoz szükségesnél nagyobb MBS=550 cella esetén a második kapcsolat is úgy érzi magát, mintha egy PCR kapacitású kapcsolaton lenne. Habár
a
mai
Internet
architektúrájában
nem
alkalmas
a
valósideju
alkalmazások kiszolgálására, mégis egyre több ilyen próbálkozás van, gondolok itt az Internet rádiókra, valósideju játékokra. A VBR forgalomformázás valójában segíti az ilyen, általában kis sebességu folyamokat. Egy 20 kbps-os rádióadás esetén az 5-3. ábráról is leolvasható, VBR esetén a csak a 0-10 intervallumban érkezo csomagoknak kell várni, míg az UBR+-os elofizeto csak a 0, 40, 80, stb. idopontokban kaphatja meg a valósideju csomagjait, vagyis az átlagos késleltetés, de még inkább a késleltetés ingadozás sokkal nagyobb. A VBR forgalomformázás hátránya, hogy az ATM kapcsolaton is burstös marad a forgalom. Nem nehéz belátni, ha ugyan az az adatmennyiség „falkákban” kerül rá egy fizikai kapcsolatra, akkor a fizikai kihasználtsága kisebb lesz, vagyis több sávszélességet kellhet lefoglalni az ATM hálózatban. Itt kell megemlítenünk, hogy ezt többlet sávszélesség megfeleloen sok elofizetoi kapcsolat agregációja esetén nem jelentos. Nem véletlenül van a fenti bekezdésben feltételes mód, ha a szolgáltató túl drágának találja az ATM hálózatban a VBR okozta többlet igényt lefoglalni, akkor megteheti azt is, hogy csak az UBR+-hoz is szükséges sávszélességet veszi igénybe. A nap nagy részében ekkor is az elozoekben leírt módon fog viselkedni a forgalomformázás, csak a néhány forgalmas órában lép fel túlterhelés. Ekkor fordulhat elo az a probléma, hogy az SMS-nek meg kell csorbítania minden aktuálisan forgalmazó elofizetonek a sávszélességét.
49
Midig vannak olyan elofizetok, akiknek az adott pillanatban PCR-rel illetve SCR-re van joguk adni. A probléma akkor áll fenn ha az SMS mindenkitol megvon sávszélességet, vagyis gyakorlatilag az SCR és az PCR értékét is csökkenti azonos arányban. Ez azért probléma, mert az SCR-nyi sávszélesség a szerzodés alapján garantált, míg a PCR csökkentésével a szolgáltató semmilyen „ígéretet” nem szeg meg.
5.3.
Az SMS túlterheléses viselkedésének vizsgálata
Az elozo alfejezet utolsó bekezdésében leírt probléma kezelését a VP formázó megvalósítása határozza meg. Az ATM Fórum ezt nem szabályozza, de nyilvánvalóan az a logikusabb megoldás, hogy csak a PCR csökken, akkor is ha ez együttmuködést igényel a VC formázóval. Ez az együttmuködés bonyolítja az eszközt és abban az esetben nem is oldható meg, ha a VP és a VC formázó két független eszközben van. Az SMS2 esetében a nagy volumenu VC formázás egy IP router jellegu eszközben van, ami az ATM cellákba csomagolást is elvégzi, de a VP megformázására csak az eszköz közepébe beépítet ATM kapcsoló képes, aminek viszont kevés a teljesítménye ahhoz, hogy az összes VC-t is megformázza. Tehát a kétféle formázást két saját operációsrendszerrel rendelkezo eszköz végzi, a VP formázó nem tudja melyik VC forgalmaz az adott pillanatban PCR-rel, így túlterhelés esetén minden kapcsolatnak csökkenti a sávszélességét. SMS1-ben egy processzor foglalkozik az összes ütemezési, forgalomformázási feladattal, így a választ arra, hogy csökkenti-e az SCR-t is csak mérés útján lehet megadni.
5.3.1.
A mérés célja
A mérés célja megállapítani, ha a VP formázásnak át kell ütemezni a VC formázás által már ütemezett cellákat, akkor tesz-e különbséget az éppen SCR-rel és PCR-rel adó folyamok között.
5.3.2.
A mérés összeállítása és menete
Hasonlóan a 4.1.3.-hoz az IXIA 10000 generált IP csomagokat az SMS1 részére és az ADTECH 400 monitorozta az ATM interfészen kijövo forgalmat. (lásd. 5-6. ábra) Az IP kapcsolat egy 100 Mbps-os Ethertnet linken, míg az ATM egy 155 Mbps-os STM-1 linken volt realizálva.
50
UTP100 Mbps IXIA IP Tester
STM 1
SMS1
ADTECH 400 ATM Tester
5-6. ábra SMS1 túlterhelési vizsgálat
Az SMS1-ben az 50 bekonfigurált felhasználó mindegyike VBR-nrt forgalmi osztállyal volt formázva. Az eszközben az MBS-t csak közvetett módon, BT-ként lehet megadni, melynek az értéke [0,10000] ? s intervallumban kell legyen. PCR ? ? MBS ? ?1 ? BT * PCR ? SCR ?? ? 5-7. ábra MBS és BT közti összefüggés
Az elozoekben javasolt PCR=8 Mbps, CDV=100 ? s és egy szokásos SCR=2 Mbps paraméterek mellett a maximális BT=10000 ? s-mal MBS sokkal kisebb, mint a beállítandó 550 cella; csupán 64 cella (5-7. ábra képlete szerint). PCR=8 000 kbps CDV=100 ? s SCR=2 000 kbps BT=10 000 ? s (? MBS=64 cella) Szerencsére ez nem probléma valószínuleg nem okoz túl sok fennakadást, ugyanis az SMS1 gyártójának mérnöke rendszeresen látogatja a Teliát és ha megalapozott, mérésekkel bizonyított hiányosságot mutatunk neki, akkor azt egy pár héten belül kijavítják a fejlesztok. Amiatt, hogy hasonló arányban legyenek VC kapcsolatok, amelyek éppen PCR-rel, illetve SCR-rel adnak a vártól eltéro, 6 kbyte-os burstben generáltam a forgalmat. Körforgásszeruen küldött az IXIA 4 db 1500 byte-os csomagot mindenegyes elofizeto IP címére. Az SMS1-be 100 Mbps sebességgel megérkezo burstbol 4*32=128 cella lett, és ezekbol MBS-nyinek, 64-nek PCR-en kellett volna továbbítódnia. Az adási sebesség 7297 csomag/s volt ami ATM szinten 96 619 kbps-ot jelent. CBR típusú forgalomformázás volt a VP-n: PCR=100 000 kbps
CDV=100 ? s
51
5.3.3.
Eredmények
AZ SMS1 egyértelmuen csak a PCR-t csökkenti, tehát az SCR-rel forgalmazó elofizetok nem fognak a PCR-rel adók miatt éhezni. Már az 5-8. grafikon is jól mutatja, hogy a burst elso fele kevesebb, mint 8 Mbps-on továbbítódott ? néhol csak 6 volt ez az érték? amíg a 3. csomag mindig legalább 2 Mbps-on érkezet a monitorba. A negyedik csomag azért lett ábrázolva olyan alacsony sebességgel, mert a monitor csak a csomag megérkezésének idopontját képes rögzíteni, tehát a pillanatnyi sebesség kiszámításához két csomag érkezési idejének különbségét használtam fel, amely tartalmazza az adásszüneteket is. 10000
Átviteli sebesség (kbps)
8000
6000
4000
2000
0 0
100
200
300
400
500
Ido (ms)
5-8. ábra Egy elofizeto csomagjainak érkezési sebessége
Az 5-9. grafikonjáról leolvasható: a felvett 2300 cellából 7 db volt ami kevesebb, mint 2 Mbps-on érkezett. Abban az idoszakban amikor az elofizetonek joga volt PCR-rel forgalmazni, akkor a rendelkezésre álló kapacitástól függoen volt a sebesség 5-8 Mbps. Érdekes, hogy voltak csomagok, amik gyorsabbak voltak 8 Mbpsnál, de ez
nem rendellenes muködésnek az eredménye. Az SMS-nek joga van az
eloírt idonél surubben küldeni cellákat a CDV keretein belül. A B függelékben olyan grafikonok találhatók, amelyek esetén maximális volt a CDV, minden más adat pedig azonos volt a fent leírtakkal. Találhatók cellák amik közvetlenül egymás után mentek a 155 Mbps-os linken, de egy olyan csomag sincs
52
amelyik túllépte volna a PCR-t, viszont átlagosan hamarabb továbbítódtak a csomagok, mint kisebb CDV esetén. 10 000
Átviteli sebesség (kbps)
8 000
6 000
4 000
2 000
0 0
50 000
100 000
150 000
200 000
250 000
300 000
350 000
400 000
450 000
500 000
Ido (micro s)
5-9. ábra Egy elofizeto celláinak érkezési sebessége
53
6. Buffer méret kezelése A gyártók igyekeznek nagyok sok fontos információt visszatartani az eszközökrol,
mivel
a
felhasználók
kezébe
kerülo
dokumentáció
könnyen
megszerezheto a konkurencia számára is. Ezek az adatok sokszor szükségesek lennének a tervezéshez. A buffer méretének ismerete elengedhetetlen a forgalom méretezéséhez, mivel az SMS csak akkor dob el csomagot, ha már nem tudja a bufferében letárolni. Olyan esetben, amikor a bejövo forgalom nagyon butstös és sokkal nagyobb a bejövo, mint a kimeno link kapacitása, akkor gyakorlatilag az eszközben bufferelheto burstök számától függ a kimeno linken elhelyezheto felhasználók száma.
6.1.
A mérés célja
A mérés célja megállapítani az SMS-ben bufferrelheto adat mennyiségét különbözo forgalmi osztályok és csomagméretek esetén.
6.2.
Mérés összeállítása és menete
Ebben a mérésben ugyan az az eszköz, az IXIA 10000 látta el a forgalomgenerátor és analizátor szerepét, mivel így sokkal egyszerubb a küldött és vett adatok összehasonlítása.(6-1. ábra) Ez azzal a hátránnyal jár, hogy az SMS-en kétszer halad át a forgalom, mivel az ATM cellákat vissza kell alakítani IP csomagokká.
UTP100 Mbps STM 1 IXIA IP Tester SMS 6-1. ábra Buffer méret mérés összeállítása
Az
SMS-ben
200
felhasználó
volt
a
visszahurkolás
miatt
kétszer
bekonfigurálva. Az IXIA-ból beérkezo adatok felhasználói 64 kbps PCR-re voltak megformázva (VBR esetén az SCR is ennyi volt). A visszahurkolást végzo részben semmilyen plusz feladata nem volt a kicsomagoláson és a routingon kívül, így ez az alig használt eroforrás, nem befolyásolta a mérés eredményét. 54
Az IXIA-val egy-egy burstöt küldtem az SMS-be 100 Mbps-os sebességgel. Három paramétert változtattam: 1. burst mérete, minden esetben egy nagy értékrol indítottam és addig csökkentettem, amíg csak egy kicsivel volt kevesebb a visszakapott adatmennyiség. 2. elofizetok száma,(gyk. a használt IP címek száma) 1 és 200 között exponenciálisan nott 3. csomag mérete, 64 és 1518 kbyte között lineárisan vátozott A mérés úgy zajlott, hogy hirtelen (nagy sebességgel, 100 Mbps) sok adatot zúdítottam az SMS-be, amit az neki gyakorlatilag egy az egyben a bufferjában kellett eltárolnia, mivel csak nagyon lassan tudott távozni (n*64 kbps, maximum 12,5Mbps). Az IXIA-ba visszaérkezo adatok mennyiségébol levonva a még a küldés alatt az SMS-bol továbbítódott csomagok mennyiségét a bufferelt csomagok száma, illetve a buffer mérete adódik eredményül.
6.3.
Eredmények
Az SMS1-ben egy úgy kerülik el, hogy néhány felhasználó lekösse az egész buffer, hogy maximalizálták hány csomagot tarolhat egy elofizeto. Elküldött Megérkezett Bufferelt/ Felhaszná csomagok csomagok felhasználó ló (db) (db) (db) (db) 1 2 3 5 10
60 110 160 260 520
51 102 153 255 521
50 50 50 50 50
,
6-1. táblázat SMS1 felhasználónkénti bufferméret
A 6-1. táblázat a visszaérkezett csomagok számát mutatja a felhasználók számának növekedésétol függoen, olyan tartományban, ahol még a buffer fizikai mérete nem korlát. Feldolgozási okok miatt egy kártyához nem várakozhat több, mint 4000 csomag, így 200 felhasználó használatával a bufferméret „fizikai” korlátait lehetet kimérni. A 6-2 ábra a csomagméret függvényében mutatja a bufferelt csomagok számát, amibol ki lett számolva az adatmennyiség byte-ban.
55
4 000 1 500 3 000 1 000
2 000 csoma g byte
1 000
500
0
Bufferelt adat (kbytes)
Bufferelt csomagok (db)
2 000
0 0
250
500
750
1000
1250
1500
Csomag méret (byte)
6-2. ábra SMS1 bufferméret
A bufferelt csomagok számát mutatató lépcsos diagram egyértelmuen egy szoftveres megoldást ad arra, hogyan oldják az SMS1 fejlesztoi, hogy ne lépje túl a bufferelt adatmennyiség az 1500 kbyte-ot. Igen meglepo, hogy a valósideju forgalmi osztályok esetén teljesen azonos a buffer mérete, viselkedése, mint a VBR-nrt vagy UBR esetén. A CBR vagy VBR-rt forgalmi osztály bufferének sokkal kisebbnek kellene lenni, mivel a bufferolás késleltetést okoz, amit az ilyen folyamok nem viselnek el.
Az SMS2-ben nem valósították meg a fent látható lépcsos görbét, az IP
Bufferelt csomagok (db)
csomag méretétol teljesen független, hogy hány darab csomagot bufferel. 3 500 3 000 2 500 2 000 1 500 1 000 500 0 0
50
100
150
200
Felhasználók száma 6-3. ábra SMS2 bufferolt csomagok az felhasználószám függésében
56
A 6-3. ábra mérései egyértelmuen mutatatja, a maximális buffer méret (2940*1518 bytes=) 4358 kbytes. Amíg az SMS1-nél alig tértek el mért eredmények értékei és az „ideális” görbe eredményei, addig az SMS2-nél más mérések alkalmával és itt azt tapasztaltam, hogy nagyon eros másodlagos jelenségek vannak, amelyek sokszor egészen nagy eltéréseket okoznak, rontva a mérés pontosságát. A 6-4. ábrán ez jól látható, a 5 illetve 50 méréspontokban nagy valószínuséggel ilyen másodlagos jelenségek okozták az alacsony értéket. Ettol függetlenül az SMS2-rol is biztonsággal kijelentheto, hogy
Felhasználonkénti bufferelt cs. (db)
egy felhasználó 30 csomagnál többet nem tarthat az eszköz bufferében. 40 30 20 10 0 0
50
100
150
200
Felhasználók száma (db)
6-4. ábra SMS2 Felhasználónkénti bufferméret
A méréseket VBR-nrt és VBR-rt esetén végeztem el és semilyen különbséget nem tapasztaltam a buffer méretében, viselkedésében.
6.4.
Összefoglalás
Végezetül
nézzük
meg
a
mért
eredményeket,
következtetéseket
egy
táblázatban. SMS1 Max. buffer méret (byte) Felhasználónkénti limit a bufferolt csomagok számára Max. bufferelt csomagok száma
SMS2
1500 kbyte 4358 kbyte 50 csomag
30 csomag
Igen
Nem
Nem
Nem
függ-e csomag mérettol Függ-e a bufferméret a forgalmi osztálytól
57
7. Összefoglalás Ebben a dolgozatban két megoldási javaslatot adtunk a Telia ADSL elofizetoihez meno forgalom formázására. A
tervezés
elso
lépésében
megismerkedtünk
a
mai
Internet-forgalom
összetételével, paramétereivel. Gerinchálózati elemzések alapján beláttuk, a TCP egyeduralkodóként adja a hálózat terhelésének több mint 85 %-át. Saját mérések segítségével megismertük a formázás szempontjából igen fontos maximális burst méretet, melyet a TCP protokoll szerkezetével magyaráztunk. Az is világossá vált, hogy a gyors fejlodés ellenére az Internet forgalom szerkezetében, paramétereiben jelentosebb változás egyelore nem várható. Az elso megoldás-javaslat az állandó sebességre történo formázás, mint egyetlen megoldás szerepel az elofizetoket összefogó VP esetén. Mérésekkel igazoltuk, hogy a Telia ProSoft AB laborjában található két SMS mindegyike képes úgy formázni, hogy az ATM hálózat belépési pontján UPC kontrollja nem fog cellát dobni. Az elofizetokhöz hozzárendelt VC-k állandó sebességre történo formázása nem bizonyosodott a legkedvezobb megoldásnak. Bár kétségtelen, van néhány csak a szolgáltató számára kedvezo tulajdonsága, hátrányait viszont mindkét fél (szolgáltató, elofizeto) is viseli. A VBR-nrt illeszkedik az elofizetok forgalmának formázásához, azt pontosan ilyen jellegu szolgáltatáshoz fejlesztették ki. A két valóban kérdéses paraméter, a burst méret és a maximális adási sebesség, melyek meghatározásához, nem csak a forgalom-analízis eredményeit kellett felhasználni, hanem a Telia ADSL eszközeinek, vonalainak képességeit is fel kellett kutatni. Amellett, hogy a VBR formázás komfortosabb megoldás az elofizetoknek, a DSLAM –egyébként kihasználatlan– buffereit felhasználja, csökkentve az SMS buffer szükségleteit. A dolgozat végén található mérésekbol kiderül, az SMS igen nagy méretu bufferrel rendelkezik –ami nagyon hasznos a burstös forgalom formázásánál,– de ennek méretét a valósideju forgalmi osztályok esetében sem csökkentik.
58
Köszönetnyilvánítás Ez a dolgozat nem jöhetett volna létre az engem körülvevo emberek támogatása és segítsége nélkül. Szeretném hálámat ez úton is kifejezni. Mindenek
elott
szüleimnek
köszönöm,
hogy
lehetoséget
biztosítottak
tanulmányaim elvégzésére, és támogattak akkor is, ha ez néha saját céljaik módosításával járt. Elso
önálló
mérnöki
munkám
elvégzésében
nélkülözhetetlen
segítséget
nyújtott Juhász Imre, aki nagy szakmai tapasztalata átadásán kívül azért is megtett mindent, hogy megismerjem a Telia belso szerkezetét, a változások hátterében lévo okokat. Külön köszönetemet szeretném mindezekért kifejezni neki. Köszönetet szeretnék mondani néhány doktorandusnak is, név szerint Cselényi Istvánnak, Füzesi Péternek, Seres Gergonek és Varga Tamásnak. Leginkább csekélységeknek tuno dolgokban volt csak idejük segíteni, de azok igen hasznosak voltak. Legvégül, de egyáltalán nem utolsó sorban, Baumann Ferencnek fejezem ki hálám, aki immáron két éve terelget a mérnökké válás göröngyös útján, néha igen kemény, de jószándékú szavakkal.
59
A függelék
60
B függelék
61
Irodalomjegyzék [AOdlyzko00] K. G. Coffman and A. M. Odlyzko. Handbook of Massive Data Sets, J. Abello, P. M. Pardalos, and M. G. C. Resende, eds., Kluwer, 2001. To appear..............................................................................................................10 [Ciscoa] Cisco NetFlow Aggregation http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/ 120t/120t3/netflow.htm#xtocid297610 ..........................................................11 [DPlonka00] Dave Plonka: Internet Traffic Flow Size Analysis http://net.doit.wisc.edu/data/flow/size/...........................................................11 [Ghuston00] Huston, G., TCP Performance, The Internet Protocol Journal, Vol. 3, No. 2, Cisco Systems, June 2000....................................................................20 [HSaito96] H.saito, K Kawashima, H. Kitazumr, A Koike, M. Ishizuka: Performance Issues in Public ABR Service IEEE communication magazine, Vol. 34, No. 11, pp. 40-48, November 1996 .......................................................................40 [ISIC00] Internet Software Consortium http://www.isc.org/ds/WWW-200007/index.html ....10 [KClaffy95] K. C. Claffy, Hans-Werner Braun, George C. Polyzos. A parameterizable methodology for Internet traffic flow profiling, IEEE JSAC April 1996, http://wwwdev.caida.org/outreach/papers/pmi.html ...................11 [KClaffy98] K Claffy, G. Miller, and K. Thompson. the nature of the beast: recent traffic measurements from an Internet backbone, http://www.isoc.org/inet98/proceedings/6g/6g_3.htm ...................................15 [KLindberger00] Karl Lindberger: Vilken trafik man ha på en VP med en viss Kapacitet. 2000 (nincs publikálva) .................................................................34 [KMoldeklev94] Kjersti. Moldeklev, Per Guningberg: Deadlock Situation in TCP over ATM IFIP Workshop 1994....................................................................40 [OBonaveture96] Oliver Bonaveture, Espen Klovning, Andre Dathine: Is VBR a Sollution for an ATM LAN? IFIP Workshop 1996........................................40 [RBrade n89] R. Braden, Editor:RFC 1122 Requirements for Internet Hosts -Communication Layers 1989 Oktober ......................................................23 [RBuff99] Robert Buff, Arthur Goldberg Web Servers Should Turn Off Nagle to Avoid Unnecessary 200 ms Delays 1999 http://www.cs.nyu.edu/artg/index.html ..........................................................23 [SAno1997] S. Ano, T. Hasengawa, T. Kato, K. Narita, K. Hokamura: Performance Evaluation of TCP over VBR in Wide Area ATM Network, IEEE ATM’s Workshop 1997...............................................................................................40 [SAno98] S. Ano, T. Hasengawa, T. Kato, K. Narita, K. Hokamura: Performance Evaluation of TCP/IP Traffic using Window Scale Option over Wide Area ATM Network with VBR service, IEICE Trans. Vol. E81-B, NO. 11. 1998 41
62
[SCreary00] Sean McCreary and K. Claffy Trends in Wide Area IP Traffic Patterns http://www.caida.org/outreach/papers/AIX0005/...........................................12 [TrafMgt99] ATM Forum,Technical Committee Traffic Management Specification Version 4.1 March 1999 www.atmforum.com...............................................31 [VJacobson92] V. Jacobson, R. Braden, D. Borman RFC 1323 TCP Extensions for High Performance ........................................................................................22 [Wstevns94] Stevens, W. R., TCP/IP Illustrated, Volume 1, Addison-Wesley, 1994. .................20 [WWilinger98] W. Willinger, V. Paxson, and M.S. Taqqu, Self-similarity and Heavy Tails: Structural Modeling of Network Traffic Birkhauser, 1998. http://math.bu.edu/people/murad/pub/tails-w16-posted.ps ............................32
63
