TRANSZPORT PROTOKOLLOK VIZSGÁLATA EMULAB KÖRNYEZETBEN

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék Sajtos Róbert Imre TRANSZPORT PROTOKOLLOK VIZSGÁLATA EMULAB KÖRNYEZETBEN Szakdolgozat KONZULENS Dr. Molnár Sándor Móczár Zoltán BUDAPEST, 2013

Tartalomjegyzék Kivonat... 5 Abstract... 6 1 Bevezetés... 7 2 Nagysebességű transzport protokollok... 9 2.1 TCP: Torlódásszabályozást alkalmazó protokollok... 9 2.1.1 TCP Reno... 10 2.1.2 BIC TCP... 11 2.1.3 CUBIC TCP... 12 2.2 DFCP: Torlódásszabályozást nem alkalmazó protokoll... 13 2.2.1 DFCP működése... 14 2.2.2 A DFCP fontosabb paraméterei... 18 3 Emulab hálózatemulációs környezet... 19 3.1 Emulab felépítése... 19 3.2 Emulab működése... 20 3.3 Emulab környezetben létrehozott példa topológiák... 23 3.3.1 Egyszerű kapcsolat létrehozása... 23 3.3.2 Nem ideális link létrehozása... 24 3.3.3 Delay node explicit létrehozása... 25 4 Tesztkörnyezet kialakítása és a mérések megtervezése... 27 4.1 Célkitűzések... 27 4.2 Tesztkörnyezet kialakítása... 27 4.2.1 Kliens vagy szerver node... 27 4.2.2 Dummynet node... 28 4.3 Mérési forgatókönyvek... 29 4.3.1 Küldő-fogadó pár... 29 4.3.2 Két küldő-fogadó pár... 31 4.4 Méréseknél felhasznált számítógépek hardver tulajdonságai... 31 4.5 Felhasznált eszközök... 32 4.5.1 Client5 és server5... 32 4.5.2 Iperf alkalmazás... 37 4.5.3 Dummynet és ipfw... 38 5 Mérési eredmények... 41

5.1 Küldő-fogadó páron végzett mérések... 41 5.1.1 Késleltetés hatásának vizsgálata... 42 5.1.2 Csomagvesztés hatásának vizsgálata... 43 5.1.3 Késleltetés hatásának vizsgálata fix csomagvesztés mellett... 44 5.1.4 Konvergencia idő vizsgálata... 45 5.2 Két küldő-fogadó pár... 46 5.2.1 Késleltetés hatása versengő folyamok esetén... 47 5.2.2 Versengő folyamok átviteli sebessége... 49 6 Összefoglalás... 51 Köszönetnyilvánítás... 53 Ábrajegyzék... 54 Táblázatok jegyzéke... 55 Irodalomjegyzék... 56

HALLGATÓI NYILATKOZAT Alulírott Sajtos Róbert Imre, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2013. 12. 16..... Sajtos Róbert Imre

Kivonat A számítógépek és azok hálózata mára mindennapjaink részévé váltak, ezért az adatok továbbítása jelentős feladat. Az Internet megalkotásakor létrejött protokollok mára elavultak, több újabb algoritmust is kifejlesztettek, de még mindig nem sikerült egy univerzálisan jól működő változatot alkotni. Az Internet változatossága és a már meglévő protokollok sokszínűsége miatt a torlódásszabályozás igazságosságának teljesítése és az kapacitások lehető legjobb kihasználása komoly feladatok elé állítják a fejlesztőket. Egy újabb elgondolás szerint ne használjunk torlódásszabályozást, hanem maximális sebességgel küldjük adatainkat. Így biztosan ki lesz használva az elérhető kapacitás, a hálózati eszközökben alkalmazott igazságos ütemezők pedig igazságossá teszik a hálózat használatát. A fellépő csomagvesztések ellen a protokoll hibajavító kódolással védekezik, így nem szükséges az újraküldés sem, a hirtelen fellépő csomagvesztéseket is el tudja viselni. Ezt az elgondolást a DFCP (Digital Fountain based Communication Protocol) valósítja meg, melynek a teljesítményét a szakdolgozatomban vizsgálom meg. A tesztelést Emulab hálózatemulációs, tesztelési célokra létrehozott környezetben végeztem el, olyan elterjedt protokollokkal összevetve a fejlesztés alatt álló protokoll eredményeit, mint a TCP Reno és a Cubic TCP. A vizsgálataim alatt különböző topológiákon a linkek sávszélességét, csomagvesztését, késleltetését változtattam, így teremtettem megfelelő tesztelési körülményeket. Az eredmények biztatóak, a DFCP a mai vezeték nélküli felhasználói világban egy lehetséges megoldás lehet.

Abstract The computers and computer networks have become a great part of our lives, so transmitting the data is a major task. The initial Internet protocols have become outdated, several new algorithms have been developed, but still failed to create an universally well-functioning version. Due to the diversity of Internet and existing protocols to have a fair congestion control and have the best utilization of the capacities are significant challenges to the developers. According to a new idea, it can be a possible solution if we do not use any congestion control and send data at a maximal rate. Thus the available capacity of the network devices will be fully utilized, and fair schedulers in the network nodes can provide fairness among competing flows. Against the occurring packet loss the protocol uses erasure coding, so resending packets is not needed, the protocol can recover from bursty packet losses. This idea is implemented in DFCP (Digital Fountain based Communication Protocol), which performance is examined in my thesis. The tests were performed in Emulab, which is a network emulation testbed for testing, where I have compared DFCP to the most common TCP versions, TCP Reno and Cubic TCP. During my experimentation on various topologies, I changed the bandwidth, packet loss and delay of links to create the appropriate test conditions. The results are encouraging, DFCP can be a possible solution in today s wireless world. 6

1 Bevezetés A számítógépes hálózatok és azok használata életünk részévé vált, napjainkat már szinte el se tudjuk képzelni nélkülük. A számítógépek adatcseréjének legnagyobb színtere az Internet, melynek legalapvetőbb protokolljai a TCP/IP (Transmisson Control Protocol/Internet Protocol) protokollkészlet és az UDP (User Datagram Protocol). A TCP/IP az Internet születése óta jelenlevő protokollok, számos fejlesztésen estek már át, a kezdeti egyszerű igényeket tökéletesen kielégítették, de mostanra már a feladatok kezdenek túlnőni rajtuk, a hálózati berendezések gyorsulásával és a felhasználói igények változásával. A TCP pont-pont összeköttetést használva a két számítógép között, az adatfolyam megbízható és sorrendhelyes megvalósítását teszi lehetővé. A kezdeti TCP protokollok nem működnek hatékonyan a jelenlegi gyors hálózatokon, ezért több fejlesztés is történik és újabb algoritmusok jelennek meg. Így az Internet egyre kevésbé homogén, egyre sokszínűbb lesz, még több feladatot állítva a szakemberek elé. A TCP torlódásszabályozást alkalmaz, ennek a mechanizmusnak a javításával próbálják a szakemberek az adatátvitel hatékonyságát javítani, de nem sikerült eddig egy minden körülmény között jól teljesítő protokollt létrehozni. Az algoritmusok sokszínűsége miatt az egyes protokollok elnyomhatják egyes társaikat, nem tud megvalósulni egy teljesen igazságos kihasználtság, kiszolgálás. A TCP további hátránya, hogy a sorozatos csomagvesztéseknél a teljesítménye nagymértékben lecsökken, egyes protokollok gyorsabban vissza tudnak állni a kapcsolat javulása után, míg másoknak ez többszörös időbe is kerülhet. A vezeték nélküli hálózatoknál fordulhat leggyakrabban elő a csomagvesztés, napjainkban pedig egyre több a vezeték nélküli kapcsolatot használó eszközünk, így a probléma egyre kézzelfoghatóbb, megoldása egyre szükségesebbé válik. Egy másik megközelítés a torlódásszabályozás elhagyását javasolja, amely szerint az adatküldés maximális sebességgel történik, az esetlegesen elveszett csomagokat pedig hibajavító kódolás segítségével tudjuk visszaállítani. Ezt az irányzatot valósítja meg a DFCP (Digital Fountain based Communication Protocol), amelynél közös erőforrások igazságos kihasználtságát a routerekben történő csomageldobás biztosítja. Láthatjuk, hogy a TCP két nagy hibáját, az igazságtalanságot (unfairness) és a csomagvesztések okozta teljesítményromlást is kiküszöböli a DFCP. 7

Természetesen ezek elméleti síkon remek elgondolások, ezért a protokollal való tesztelések elengedhetetlenek a várt elképzelések igazolására. Szakdolgozatom következő részében bemutatom a TCP torlódásszabályozás irányelveit, a Reno, BIC és CUBIC algoritmusait, majd a DFCP működését, fontosabb paramétereit mutatom részletesebben be. Ezek után az Emulab hálózat emulációs környezetet ismertetem meg az olvasóval és példákkal illusztrálom használatát. A mérések célkitűzései, főbb beállításai és a mérési topológiák, felhasznált eszközök ismertetése után az elvégzett eredményeket fogom bemutatni és értelmezni. Végül összefoglalom a szakdolgozatom során szerzett tapasztalataimat. 8

2 Nagysebességű transzport protokollok 2.1 TCP: Torlódásszabályozást alkalmazó protokollok A TCP [1], az IP-vel [2] együtt az Internet, számítógépes hálózatok fő protokolljai, működésük létfontosságú. A TCP az OSI modellben a 4. szinten a szállítási rétegben foglal helyet. A TCP pont-pont összeköttetésben valósítja meg a két számítógép között az adatfolyam megbízható és sorrendhelyes átvitelét. Ezt a vevő oldalán minden beérkezett csomag után nyugtázással jelzi a küldő felé, így a sorrendhelyesség megvalósul, ha hiba volt, akkor a hibás sorszámtól újraküldi a csomagokat. Ezek a legalapvetőbb tulajdonságai a protokollnak[3]. További feladata a torlódásszabályozás is [4]. Ha egy router, switch egyéb hálózati eszköz leterhelődik, nem tudja olyan gyorsan a feladatát elvégezni, mint ahogy érkeznek hozzá a csomagok, akkor azokat vagy sokkal később dolgozza fel, vagy rosszabb esetben el is dobhat néhányat. Az ilyen helyzetek kialakulását úgy tudjuk előre megjósolni, hogy a körülfordulási idő (RTT) kezd megnőni, később pedig a csomagok is kezdenek elveszni. Ezek alapján két nagy csoportja van a torlódásszabályozási módszereknek, a csomagvesztés illetve a késleltetés alapú, továbbá ezek keveréke a hibridek, valamint létezik explicit és mérés alapú típus is. A késleltetés alapú protokollok az RTT szerint mérik fel a kapcsolatot és ennek függvényében a sorban állási idő változtatásával hatnak a torlódás mértékére. Ezt a módszert használja a TCP Vegas [5], Fast TCP [6] és a TCP-Africa [7] is. A csomagvesztést figyelő módszerek egy könnyen detektálható, inkrementális sorozatot felügyelnek. Ez a megoldás egyszerűbb, de kevésbé hatékony, mert nem tud felkészülni arra, hogy csomagvesztés lehetséges. Csomagvesztés után nagyobb mértékben veszi vissza teljesítményét, mint mondjuk a késleltetés alapúnál, ahol az RTT növekedésével csökkenti adását. Csomagvesztés alapú protokollok például a TCP Reno [8], BIC TCP (Binary Increase Congestion control) [9], CUBIC TCP [10], HSTCP (HighSpeed TCP) [11], Scalable TCP [12]. Hibrid protokollok a késleltetés és a csomagvesztés alapú módszerek előnyeit próbálják megtartani, hátrányaikat pedig kiküszöbölni. Az egyik ilyen Microsoft által fejlesztett protokoll a Compound TCP [13], továbbá TCP-Illionis [14]. Explicit protokoll az XCP (explicit Control Protocol) [15] amely a hálózatból 9

nyert adatok alapján végzi a torlódásszabályozást. Végül a Westwood [16] és a továbbfejlesztett változata a Westwood+ [17] mérés alapú módszerek, a hálózatban felhasználható sávszélességet monitorozzák, adási teljesítményüket az alapján szabályozzák. Azt, hogy melyik a legjobb, az Internet és hálózatok folyamatos változása miatt nem lehet egyértelműen megmondani, de a viselkedésüket meg lehet figyelni, erre ad kiváló lehetőséget az Emulab [22]. 2.1.1 TCP Reno A TCP Reno egy csomagvesztés alapú algoritmus, amely a torlódási ablakának (cwnd, congestion window) megfelelő nyugtázatlan csomagot enged meg a folyamában. Minél nagyobb a torlódási ablak mérete, annál több nyugtázatlan csomag lehet a hálózatban, így annál gyorsabban is képes az adatokat átvinni, kevesebbet kell várnia. Az algoritmusnak két fő fázisa van. Az első a Slow Start, ekkor még nincs adatunk a hálózatról, így exponenciális ablaknöveléssel felderítjük azt az első csomagvesztésig vagy egy küszöbértékig. Ezután átlépünk a torlódás elkerülés (Congestion Avoidance) fázisba. Itt AIMD (Additive Increase Multiplicative Decrease) módszerrel szabályozzuk a torlódási ablakot, tehát az ablaknövelés lépésekben történik, a csökkentés pedig nagyobb mértékben. A fentieken kívül az algoritmus további két fontos fázisát különböztetjük meg, a gyors újraküldést és a gyors javítást. Gyors újraküldés (Fast retransmit) az, amikor egy csomagra háromszor érkezik nyugta, de van még olyan nyugta, ami nem érkezett meg hozzá, akkor megfelezi a torlódási ablak és a lassú indítási küszöb méretét. Ezután gyors javítás (Fast Recovery) fázisban vagyunk, újraküldi az elveszett csomagot, megvárjuk rá a nyugtát és visszatérünk a torlódás elkerülés fázisba, igyekszünk visszatérni a már elért ablakmérethez. Ha a nyugta nem érkezik meg, akkor slow start fázis kezdődik el. A szelektív nyugtázás (SACK, Selective Acknowledgment) [18] egy újabb lépés volt a Reno javításában, amivel a fogadónak nem szükséges sorrendhelyesen nyugtázni a csomagokat, így a hirtelen csomagvesztések nem jelentenek akkora gondot, nem esik vissza annyira az ablakméret. A TCP Reno működése a 2.1.1 ábrán látható [19]. 10

2.1.1. ábra TCP Reno működése 2004-ben a Reno gyors újraküldési algoritmusát javították, így azokban a rendszerekben is, ahol nem volt támogatott a szelektív nyugtázás, a többszörös hibák is javíthatóak lettek. A New Reno alacsony csomagvesztés esetén azonosan teljesít az alap Renoval szemben, viszont magas csomagvesztés esetén jelentősen jobban teljesít az újabb algoritmus. A Reno ugyan nem késleltetés alapú algoritmus, de fent áll nála az RTT unfairness probléma, ahol is a kisebb körülfordulási idővel rendelkező folyamok elnyomják a nagyobb RTT kapcsolatokat, nagyobb különbség esetén akár ki is éheztethetik azokat. 2.1.2 BIC TCP A BIC TCP a Linux kernel 2.6.8 verziójától a 2.6.18-as verziójáig az elsődleges torlódásszabályozási protokoll. A BIC TCP ablakméret növelése két fázisból áll, a bináris keresésű (Binary Search) és az additív (Additive Increase). Az algoritmusban használt főbb változók a következőek: W max, maximális ablakméret ( dinamikus), W min, minimális ablakméret (dinamikus), S max, maximális növelés (fix), S min minimális csökkentés (fix), β, ablakcsökkentési szorzótényező (fix). Van még előre beállított paraméter, a Low_window, ezen ablakméret alatt a hagyományos TCP (TCP Reno) szerint folyik a torlódásvezérlés, ezt a küszöböt átlépve pedig a BIC szerint. Csomagvesztés esetén β-val csökkenti az ablakméretet az algoritmus, W max a csomagvesztéskor fennálló ablakméret, a W min pedig a csökkentés utáni ablakméret lesz. A két érték (W max és W min ) átlaga lesz az az ablakméret (target_win), amelyet a 11

módszer újra el szeretne érni, és még biztonságosnak ítél. Ha a cél érték és az aktuális W min különbsége nagyobb mint az S max, akkor csak S max lesz az ablaknövelés mértéke, ami lineáris növekedést eredményez (Additive Increase), elkerülve a túl nagy ablakméret növelést csomagvesztés után, esetleges újabb torlódást előidézve. A W min minden egyes ablaknövelés után növekszik, egészen egy esetleges csökkentésig, amikor is a vesztés előtti utolsó ablakméret a W max lesz, az új érték pedig a W min. Amikor már az ablaknövelés kisebb, mint az S min belépünk a bináris keresés fázisba. Ez a folyamat addig tart, amíg el nem érjük a W max ot. A 2.1.2-es ábrán látható [10], hogy eddig logaritmikus a BIC protokoll ablaknövelési függvénye, az ezt követő fázis, ha természetesen nem történik csomagvesztés, a maximum keresés (Max Probing) pedig kezdetben exponenciális, majd gyors additív növekedés lesz, lineáris függvényt eredményezve. A fenti ablaknövelési módszerekkel a BIC TCP jó skálázhatósági képességgel és TCP barátságossággal bír. Kis RTT mellett a nagyobb RTT-vel szembeni folyamokkal előnye van, illetve alacsonyabb sávszélességnél kissé agresszíven viselkedik. Az ablaknövelési algoritmusai összetettek, ezért megvalósítása nehézkes lehet. Ezeket a problémákat próbálja orvosolni a következő fejezetben bemutatott CUBIC algoritmus. 2.1.2. ábra BIC ablaknövelési függvénye 2.1.3 CUBIC TCP A CUBIC TCP Linux rendszerekben 2006, azaz a 2.6.19-es kernel verziótól az elsődleges torlódásvezérlő módszer. A CUBIC a BIC továbbfejlesztett kevésbé agresszív változata, amit az alábbi, egyszerű, 2.1.3 függvény ír le. ( ) (2.1.3) 12

A képletben a C egy skálázó tényező, a t az utolsó ablakcsökkentés óta eltelt idő, Wmax az utolsó ablakcsökkentés előtti ablakméret, végül, ahol a csomagvesztésnél bekövetkezett ablakcsökkentéshez használt szorzó konstans. A 2.1.3 ábrán a CUBIC ablaknövelési folyamatát láthatjuk [10]. A függvény jellegéből adódóan egy konkáv és egy konvex részre bontódik. A konkáv résznél (Steady State behaviour) gyorsan eléri az utoljára történt csomagvesztéskor fennálló ablakméretet. Majd a konvex résznél (Max Probing) több sávszélességhez igyekszik jutni, ezért először kis lépésekben, majd egyre nagyobb ütemben végzi az ablakméret növelést. Az algoritmus sok időt tölt el a működési mód határához közel, ami elősegíti a hálózat stabilizálódását mielőtt a CUBIC további sávszélességet szeretne magához venni. 2.1.3. ábra CUBIC ablaknövelési függvénye A fő különbség a CUBIC és a Reno között, hogy a CUBIC nem függ a nyugták gyors fogadadásától, hogy növelje az ablakméretét, csak a t paramétertől, tehát az utolsó ablakcsökkentés óta eltelt időtől függ. Ezzel szemben a már említett Reno kis RTT értákek mellett nagyon gyorsan növeli ablakméretét, tehát látható, hogy a CUBIC képes megvalósítani RTT fairness-t. 2.2 DFCP: Torlódásszabályozást nem alkalmazó protokoll A TCP már jó ideje a számítógépes hálózatok egyik legalapvetőbb protokollja, torlódásszabályozási algoritmusai a kezdetektől folyamatos fejlesztés tárgyát képezik, számos módszer el is készült, de még mindig nincs teljesen optimális torlódásvezérlése, ami az Internet sokszínűsége miatt megfelelő lenne minden helyzetben. A használt 13

algoritmusok változatossága miatt, az egyes folyamok nem egyenlően osztoznak a kapacitásokon, egyes protokollok túl agresszívak is lehetnek, kiéheztethetik a barátságosabb folyamokat, tehát az a különböző protokollok közötti igazságos sávszélesség megosztás (inter-protocol fairness) nem megoldott probléma. Egy másik megközelítés, hogy nem használunk torlódásvezérlést, a végpontok maximális sebességgel küldik az adatokat, a sávszélesség igazságos elosztása a routerekben történik igazságos ütemezőkkel, például a DRR (Deficit Round Robin) segítségével. Így börsztös csomagvesztések lépnek fel, amelyek ellen hibajavító kódolással védekezünk, az elveszett csomagok tartalmát pedig vissza tudjuk állítani a maradék fogadott csomagból. Ezt a módszert valósítja meg a DFCP (Digital Fountain based Communication Protocol), melyet a BME Távközlési és Médiainformatikai Tanszékén (TMIT) a Nagysebességű Hálózatok Laboratóriumban (HSN Lab) Dr. Molnár Sándor által vezetett kutatócsoport tervezett és fejlesztettek ki. A DFCP-t a következőekben bemutatom, először általánosan, majd az egyes részekre külön kitérve. A protokollt teljes részletességgel bemutató dokumentum adatai az irodalomjegyzékben megtalálhatók [20] [21] [27] [28]. 2.2.1 DFCP működése Az előző részben már megemlítettem a protokoll alapelvét, tehát a végpontok maximális sebességgel, hibajavító kódolással küldik az adatokat, csomagvesztés esetén nincs a TCP-ben ismert újraküldés, az elveszett csomag tartalma helyreállítható. A DFCP fő eleme a kódolás megvalósítása, amely jelen esetben a szökőkút kódolás egyik változatával, Raptor kódolással van megoldva, ahol a kódolás és dekódolás is lineáris időben tud megtörténni. Ennél az implementációnál, ha van egy adott k hosszúságú üzenetünk, és szükséges egy valós szám, akkor egy végtelen hosszúságú szimbólumsorozatot állíthatunk elő. A sorozat bármely ( ) része elég, hogy sikerrel járjunk a dekódolással, megkapjuk az eredeti sorozatot. A Raptor kódolás és dekódolás elvégzéséhez csak a szimbólumok másolása és a kizáró vagy művelet szükséges, tehát nem komplex, erőforrás kímélő megvalósítás. Láthattuk a kódoló működési elvét, most nézzük meg az adatküldés fontosabb részeit. Az első lépés az adatátvitelhez a kapcsolat felépítése az adó és a vevő között, hasonlóan a TCP protokollhoz. A kapcsolat felépítése közben bizonyos méretű tárolók kerülnek lefoglalásra mindkét félnél, a továbbítandó és továbbított adatok kódolására- 14

dekódolására. Tehát a következő lépésben, a küldő félnél a program által küldendő adatok a tárolóba kerülnek, majd ezek kódolása és a kódolt adatok elküldése következik. A küldő félnek adatot újraküldenie nem szükséges, a kódolás redundanciája miatt veszhetnek el csomagok, nyugtát vár a küldő oldal, mégpedig blokkonként. A vevő oldal megvárja, amíg elegendő adat érkezik egy blokk dekódolásához, ami ezáltal sikeresen végrehajtható. A sikeres dekódolás után a vevő oldal visszajelzést küld az adott blokkra, a küldő pedig leállítja az adott blokkhoz tartozó adatok küldését. A vevő oldalon már csak át kell adni a dekódolt adatokat a rájuk várakozó programnak, majd a kapcsolatot le kell bontani. A kapcsolat lebontása a felépítéshez hasonlóan TCP alapokon nyugszik. 2.2.1.1 A kapcsolat felépítése Az adó és vevő fél között az adatok küldése előtt még egy kapcsolatot fel kell építeni. Az adatot küldendő fél kezdeményezi a kapcsolatot egy SYN szegmenssel és SYN_SENT állapotba kerül. Ha 3 másodperc alatt nem érkezik rá SYNACK válasz a fogadó féltől, akkor még ötször küld SYN szegmenst (3 másodperces kivárásokkal, minden egyes kísérletnél a kivárási idő megduplázásával), ha mind elveszik vagy nem érkezik válasz, akkor elmarad a kapcsolat felépítés, felszabadulnak az erőforrások. A fogadó fél a SYN szegmens megérkezésekor SYN_RECV állapotba kerül, és az előbb említett SYNACK csomagot kiküldi és hasonlóan a küldő félhez, maximum ötször próbálkozhat, ha sikertelen, a kapcsolat nem jön létre. A következő lépésben a fogadó fél a visszaérkező SYNACK hatására egy ACK csomagot küld vissza és ESTABLISHED állapotba kerül. A fogadó oldal az ACK szegmens fogadása után szintén ESTABLISHED állapotba kerül. Az ACK szegmens újraküldésére nincs szükség, ugyanis ha a fogadó fél nem kapja meg időben, akkor újra SYNACK üzenetet küld ki. Ha a fogadó félhez nem érkezik ACK üzenet, akkor RST szegmenssel tudatja a küldő féllel, hogy bontja az eddig felépített kapcsolatot, ő is szabadítsa fel az erőforrásait. 2.2.1.2 A kódolás folyamata A protokoll a már említett Raptor kódolást használja, melynek logikai vázlatát a 2.2.1.1 ábrán láthatjuk [21]. Ez azt jelenti, hogy az adatok kódolása két fő lépésből áll, az első az LDPC (Low-Density Parity Check), a második az LT (Luby Transform code). 15

n k 2.2.1. ábra Raptor kódolás Az LDPC blokk előkódolóként használt, így már a kódolt forrás szimbólummennyiségnél egy kicsivel több beérkezett kódszimbólum segítségével visszafejthető a kód. Az LDPC a megkapott k bájtnyi adatból n bájtnyi adatot állít elő a kódolás végére, tehát bájt a redundáns szimbólum. A redundancia mértéke az aktuális implementációnál 2000 bájt. A kapott n bájt lesz az LDPC kódoló kimente, az LT kódolás bemenete. Az LT kódolás során az n bájtnyi adatból, egyetlen kódolt bájt jön létre. Az LT kódolás tetszőleges számú ismétlésével tetszőleges hosszú kódolt folyamot hozhatunk létre, amit el lehet küldeni. 2.2.1.3 Az adatok küldés Az adatok küldése előtt a kapcsolat felépítés fázisban meghatározott számú tárolót foglalunk le. Az adatokat ezekbe a tárolókba rakjuk bele, ha nincs szabad tároló, akkor várakozunk, ameddig az egyik ki nem ürül. Az adatküldés során csúszóablakos módszert alkalmazunk, tehát egy ablak mennyiségnyi nyugtázatlan csomag lehet a hálózaton, az ablak mérete a tárolók száma. Az adatok miután belekerültek a tárolóba, le is fut rajtuk az LDPC kódolás és elküldésére is sor kerül. A blokk küldéséhez, annyi csomagot kell kiküldeni, amennyiből dekódolható lesz a blokk. Az egyes csomagok 1420 bájtnyi LT-kódolt üzenetet hordoznak, az alapbeállításoknál 49 redundáns csomag keletkezik, tehát egy blokknál 69580 bájtot ad át a protokoll az alsóbb IP rétegnek és kerül elküldésre. A küldés után várakozás kezdődik, az adott blokk nyugtázására várunk. Ha megérkezett a nyugta, akkor felszabadíthatjuk a tárolót, a blokk küldése sikeres volt, a felszabadult tárolóba új adatot rakhatunk be, és előkészíthetjük küldésre. 16

2.2.1.4 Az adatok fogadása A vevő oldalon is az adatkapcsolat felépítéséhez hasonlóan tárolók kerülnek lefoglalásra az egyes érkező blokkokhoz. Ezeket a tárolókat használjuk a beérkező adatok tárolására, a beérkező csomagok fejlécében megtalálható, hogy a csomag melyik blokkhoz tartozik, így a megfelelő tárolóba, vagy eldobásra kerül. Három eset lehetséges, az első esetben még nincs az adott blokkból csomagunk és van szabad tárolónk, az újonnan érkező csomagot az adott blokknak újonnan kinevezett tárolójába rakjuk. Második esetben a beérkezett csomag olyan blokkhoz tartozik, amelynek már érkezett meg csomagja, így belekerül a blokkja csomagjait tartalmazó tárolóba. A harmadik esetben nincs már szabad tárolónk és az érkezett csomag egy blokk legelső tagja, így eldobásra kerül. Ha a tárolóban a dekódoláshoz szükséges elegendő mennyiségű csomag érkezett már meg, elkezdődhet a dekódolás. 2.2.1.5 A dekódolás folyamata A dekódolás akkor kezdődik el, ha a tárolóban lévő csomagokból már nagy valószínűséggel sikeresen visszafejthető a szükséges adat. Ha ez nem lehetséges, további üzenetekre várunk. A dekódolás a kódolással ellentétes sorrendben történik, tehát először az LT kódolás, majd utána az LDCP kódolás következik. Ha a dekódolás sikeres, akkor nyugtát küldünk a küldő félnek, így ő is fel tudja szabadítani az adott blokkhoz rendelt tárolót. A fogadó oldalon ezek után tovább tudjuk adni az alkalmazásnak a szükséges adatokat. 2.2.1.6 A kapcsolat lebontása A kapcsolatbontás TCP-hez hasonló, időzítőkkel ellátott, három fő lépésben történik. Az első lépésben a kapcsolat bontását kezdeményező fél, továbbiakban küldő egy FIN szegmenst küld a másik félnek és FIN_WAIT1 állapotba kerül. A küldő fél erre nyugtát vár, ha nem kapna, ötször újrapróbálkozik, és ha ezek után sem kap, akkor a kapcsolatot bontja, illetve az erőforrásokat felszabadítja. A vevő oldal a FIN üzenetre ACK-al nyugtáz és CLOSE_WAIT állapotba kerül. A küldő oldal a nyugta feldolgozása után FIN_WAIT2 állapotba kerül. A vevő oldal tehát akkor is nyugtáz, ha nem szeretné még a kapcsolatot bontani, mert az csak a következő lépésben történik meg. Amikor a vevő oldal is zárni szeretné a kapcsolatot FINACK-ot küld és LAST_ACK állapotba kerül. A FINACK üzenetet a kapcsolat bontása elején lévő FIN szegmenshez hasonlóan, akár ötször újraküldhetjük. A kezdeményező oldal ACK-al nyugtázza és TIME_WAIT 17

állapotba kerül. A kezdeményező oldal egy idő után felszabadítja az erőforrásait. A vevő oldal az ACK szegmens megérkezése után CLOSE állapotba kerül és felszabadítja az erőforrásait. 2.2.2 A DFCP fontosabb paraméterei A protokollnak öt fontosabb paramétere van, amelyek nagymértékben kihatnak a teljesítményére, ezért a tesztelésénél ezeket a paraméter értékeket szükséges egységesen beállítani, illetve hatásaikat így külön-külön állítva meg is tudjuk vizsgálni. A paraméterek a következők: nyugtázás ki-/bekapcsolása, kódolás ki-/bekapcsolása, dekódolás ki-/bekapcsolása, maximális ablakméret, redundancia mértéke. A nyugtázás kikapcsolásával az adatküldés sebessége növelhető, a dekódoláshoz szükséges megfelelő mennyiségű csomag kiküldése után felszabadítja a küldő fél a tárolóit, nem vár nyugtára. Így megszűnik a visszacsatolás (flow control), a vevőket nem védi semmi a túl gyors adóktól, csomagvesztés lehetséges. A kódolás kapcsolásával egyértelműen a kódolásnak az adatküldés teljesítményére gyakorolt hatása szemrevételezhető. Ha kikapcsoljuk a kódolást, akkor csak az első blokk lesz kódolva, ezt eltároljuk és a kapcsolat folyamán az eltárolt adatot fogjuk elküldeni. A dekódolás kapcsolásával a dekódolás hatása vizsgálható. Kikapcsolt dekódolás esetén a fogadó félnél csak a beérkezett adatmennyiség kerül rögzítésre, a beérkezett adat tartalma helyett. A maximális ablakmérettel a már említett lefoglalandó tárolók száma külön a küldő és külön a fogadó félnél, ezzel együtt a csúszóablak mérete állítható be. A redundancia mértékével azt tudjuk megadni, hogy egy blokkhoz mekkora redundancia határértéket állapítunk meg. Magas csomagvesztési rátával rendelkező linken nagyobb redundancia szükséges, hogy az elveszett csomagok esetén is maradjon megfelelő dekódolható mennyiség, a dekódolás sikeres legyen. A protokoll alapértelmezett redundancia értéke 49, ami 0%-os csomagvesztésű linkre van optimalizálva. A méréseim során, ha nem említem meg külön, akkor a nyugtázást bekapcsolt, a kódolást és dekódolást pedig kikapcsolt állapotban használom. 18

3 Emulab hálózatemulációs környezet Az Emulab [22] emulált hálózatok kialakítására és azokon kísérletek végzésére lett létrehozva. Az Emulab neve kettős, egy nyilvános intézményre és egy szoftver rendszerre is utal. Ezt az intézményt bárki ingyen használhatja, így ajtókat nyitva a hálózati kutatásokra, kísérletekre a kevésbé jól felszerelt kutatóknak, hogy így egy nagyon széleskörű tesztkörnyezetben elvégezzék a szükséges méréseket, azokat kellően kiértékelhessék, majd fejlesszék a projektjüket. 3.1 Emulab felépítése Az elsődleges Emulab környezet egy felsőoktatási intézményben, az Utah egyetemen található, de további állomások vannak még, elsősorban Észak-Amerikában a nagy egyetemeken, de ugyanúgy megtalálható Európában, Ázsiában számos helyen, illetve kisebb számmal a maradék földrészeken. Ezek az állomások nem ugyanakkorák, van ahol 724 PC (node) áll rendelkezésre és van, ahol csak néhány darab. A node-ok természetesen nem egyformák, több különböző típusú van, ahol az azonos típusokat logikailag egy-egy csoportba fogták össze, és egy közös néven lehet rájuk hivatkozni, melyekben utalnak a PC-k egymáshoz mért relatív sebességére, tulajdonságaira. Nézzük is meg az Utah-i állomás erőforrásait, amiket használni is fogunk, zárójelben a darabszámuk, illetve a w végződésű csoportok az IEEE 802.11 szabványt támogató egységeket jelzik: d820(16), d710(160), pc3000(160), pc2000(6), pc850(128), pc600(40), pc3000w(18), pc2400w(60). A node-okban különböző számú, illetve típusú Ethernet kártya van, ezek közül egy biztosítja az összeköttetést a külvilág, illetve belső szerverek felé, a hátralévő még legalább négy kártya az általunk felépített hálózatban a többi egységgel képes kommunikálni. A hálózatok kialakításához, 7db Cisco 6500, 5 db HP 5400zl és 1 db Arista 7504 típusú switch-re van szükség. A fentebb leírt eszközök topológiája a 3.1.1 ábrán látható. 19

3.1.1. ábra Az Utah-i Emulab állomás topológiája Az általunk használt node operációs rendszere szabadon választható, számos előre elkészített képfájl van már, főleg Linux disztribúciók, de a Windows család néhány tagja is megtalálható. Az általunk használt PC-kre be tudunk jelentkezni és ott további program csomagokat telepíthetünk, amik szükségesek az általunk tervezett mérésekhez. A már felkonfigurált operációs rendszereinket saját képfájljainkba is lementhetjük, ezzel rengeteg időt megspórolva az elkövetkezendő méréseknél. A képfájlok nem mentődnek automatikusan a kísérlet befejeztével, csak a felhasználó utasítására, ezzel a módszerrel egy félresikerült konfiguráció után nincs szükség esetleges teljes újrakonfigurálásra. 3.2 Emulab működése Először is rendelkezni kell egy felhasználói fiókkal, ennek a megszerzésében Sonkoly Balázs segített nekem, az ő projektjébe kaptam jogosultságot. Ez után létrehozhatjuk a saját tesztkörnyezetünket, topológiánkat az elképzeléseink, szükségeink szerint. Ehhez egy.tcl (Tool Command Language)[23] fájlt kell feltöltenünk, amiben az ns2 (Network Simulator)[23] kissé módosított(otcl [23]), az Emulabot jobban támogató formátumát kell használnunk. Ebben a leírásban megadhatjuk a következő legfontosabb dolgokat: a node-okat, hogy milyen operációs rendszer legyen rajtuk, a node-ok milyen összeköttetésben legyenek, lehet LAN vagy link, ezek az összeköttetések milyen paraméterekkel rendelkezzenek (kapcsolat típusa, sebesség, 20

csomagvesztési arány, késleltetés, sorban állási típus, sor hossza/mérete). Ha feltöltjük ezt a fájlt, a rendszer elkezdi az összeállítást létrehozni (swap in), ha probléma adódik közben (hibás a leíró nyelv, nincs elég szabad kapacitás) azt kiírja, illetve email üzenetet is kapunk ugyanúgy, mint a sikeres swap in-nél, illetve, a kísérletünkön elvégzett módosítás eredményességéről. Ha minden sikeres volt, elkezdhetjük használni az összeállított hálózatunkat a megadott laboratóriumi körülmények között, ennek megbizonyodására van beépített többszintű Link test funkció is, amit a projektünk online felületén elvégezhetünk. Az első szinten a összeköttetéseket illetve a késleltetést vizsgálja, a másodikon azt, hogy a hálózat végpontjai elérik-e egymást. A harmadikon a veszteséget, a negyediken még a sávszélességet is leellenőrzi. A teszt kimenetéről nem kapunk e-mailt, az linktest online felületén maradva láthatjuk az eredményt. Egy kapcsolat lehet ideális vagy nem ideális. Akkor ideális az összeköttetés, amikor a megadott sávszélesség elérhető, illetve nincs csomagvesztés és késleltetés rajta, a többi esetben nem ideális a link. Ha nem ideális linket használunk az ns fájlunkban, akkor az Emulab egy delay node-ot iktat be, azaz lesz egy harmadik gép, ahol a kért forgalom emulálás megtörténik, továbbá még kettő ideális link, ami összeköti a három gépet a delay node-ot köztük elhelyezve. A delay node-ot ideális linken is lehet kérni, de a kísérletben felhasználható PC-k száma korlátozott, ésszerűen kell használni ezt az opciót. A kapcsolataink paramétereit, ha van delay node-unk az adott összeköttetésen, az online felületen keresztül is tudjuk módosítani, nem kell új fájlt feltölteni. Ha a kísérletet módosítanunk kell, változtatjuk az ns fájlt, akkor az Emulabban újra fel kell építeni a topológiát, és több mint 10 percbe is beletelhet, hogy újra használható legyen a környezetünk. Tehát az online felületes traffic shaping nagyon hasznos. A delay node-okon a hálózat emulálását a Dummynet [24][25] alkalmazás végzi el, ami FreeBSD rendszereken fut. Ezt a szoftvert direkt hálózat emulálásra tervezték, protokollok tesztelésének céljából. A hálózati forgalmat saját egységeibe irányítja, amiken keresztül haladva kapjuk az elvárt hálózati feltételeket. A queue, pipe, scheduler objektum megadása, egymás után fűzése az ipfw tűzfalkezelő programmal lehetséges. A queue támogatja a DropTail, RED (Random Early Detection), illetve a GRED (Gentle RED) csomageldobási típusokat. Az ütemező több algoritmust is támogat, amelyek a következőek: First In First Out (FIFO), Quick Fair Queuing (QFQ), Deficit Round Robin (DRR), Weighted Fair Queueing (WF2Q+)[26]. 21

Az aktív kísérletben a használatban lévő PC-kre bejelentkezés egyik módja a kapcsolat létrehozása SSH-n keresztül, ami Linux rendszereknél tökéletes is, illetve Remote Desktop a Windows operációs rendszereknél. A szükséges címek, nevek a számítógépekhez a kísérlet online felületén megtekinthetőek, többféleképpen elérhetőek. Például IP cím, node0.experimentname.projectname.emulab.net, pc301.emulab.net, továbbá a létrehozott topológiában megkapott IP címe is megtudható pl.: 10.1.1.2. A kísérletek betöltésénél nem biztos, hogy ugyanazt a gépet kapjuk, illetve a topológiában sem biztos, hogy ugyanazt az IP címet kapja egy node. A feltöltött ns fájlban csak számítógép családot kérhetünk, illetve az egyes node-oknak explicit is megadhatjuk az IP címét, így scriptek könnyű használatát is lehetővé téve a PC-ken. Bejelentkezés után az operációs rendszernek megfelelően telepíthetjük a további szükséges programokat, az ezekhez szükséges root jogot természetesen megkapjuk, és kezdhetjük is a kísérletünket. A kísérletünk végeztével ajánlott a használt erőforrásainkat felszabadítani (swap out), hogy mások is hozzáférhessenek, ha ez nem történik meg, akkor általában 2 óra múlva automatikusan felszabadítja azt a rendszer, ha nincsenek használva, erről előtte kapunk egy figyelmeztetést is, mert a PC-ken tárolt adataink, konfigurációs módosításaink elvesznek majd. Adataink lementésére kiválóan alkalmas az scp parancs, illetve Windows környezetet használva a WinSCP program ideális, a mérések közben létrehozott logok átvételére az Emulabos gépekről. A kísérleteket elindíthatjuk saját kezűleg, illetve batch módban is. Batch módnál beállíthatjuk, hogy mikor induljon el a hálózatunk üzembe helyezése, de hátránya ennek a lehetőségnek, hogy csak egy ilyen kísérletünk lehet, továbbá alapértelmezett esetben 15 perc üresjárat engedélyezett, ez kis mértékben módosítható, utána terminálva lesz. Normál esetben az üresjárat már említett 2 óra, egy kísérlet pedig összesen a betöltés elkészültétől számított 120 óráig lehet aktív, utána felszabadítják az erőforrásokat. Ezektől a szabályoktól eltérni kivételes esetben, előre egyeztetett módon lehet. Láthatjuk, hogy az Emulab széleskörű környezetét a hálózatok, illetve az elosztottrendszerek fejlesztői tudják leginkább kihasználni, illetve oktatási célokra is tökéletes az előzőleg említett tudományterületeken. 22

3.3 Emulab környezetben létrehozott példa topológiák Ebben a fejezetben pár egyszerű példát fogok bemutatni, elsősorban a különbséget kiemelve, hogy mikor hoz létre automatikusan delay node-ot az Emulab, és mikor nem, illetve, hogyan tudjuk explicit megadni. 3.3.1 Egyszerű kapcsolat létrehozása Ennél a példánál egy 1 gigabites linket hozok létre két számítógép között, késleltetés és csomagvesztés nélkül, melyhez az NS fájl a következő: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set n0 [$ns node] [4:] set n1 [$ns node] [5:] tb-set-node-os $n0 UBUNTU70-Step1 [6:] tb-set-node-os $n1 UBUNTU70-Step1 [7:] set l0 [$ns duplex-link $n0 $n1 1000Mb 0ms DropTail] [8:] tb-set-hardware $n0 pc3000 [9:] tb-set-hardware $n1 pc3000 [10:] tb-set-ip $n0 10.1.1.2 [11:] tb-set-ip $n1 10.1.2.2 [12:] $ns rtproto Static [13:] $ns run Az első két sor a kötelező fejléc, amelynek mindig benne kell lennie a fájlban, az NS szimulátor létrehozása, illetve a szükséges TCL fájl betöltése a feladatuk. A harmadik és negyedik sorban létrehozzuk a két számítógépet, nevet is adva nekik: n0 és n1. A következő két sorban beállítjuk a rajtuk futtatandó operációs rendszereket. Az operációs rendszerek listája az Emulab oldalán az experimentation/list ImageIDs alatt tekinthető meg. Az operációs rendszert meg lehet adni a felhasználók által adott nevükkel, vagy az Emulabos Internal ID alapján is, pl az UBUNTU70-Step1 Internal ID-ja 3685. A hetedik sorban megadjuk a kapcsolatot l0-ás néven, ami egy duplex link, n0 és n1 között 1000Mb sebességgel, 0ms késleltetéssel és DropTail sorban állási algoritmussal. Csomagvesztést abban a parancssorban nem tudunk beállítani, arra külön NS parancs szolgál, majd azt is be fogom mutatni. Az alapértelmezett csomagvesztési érték 0%. A nyolcadik-kilencedik sorban beállítjuk, hogy milyen hardvereken szeretnénk lefoglalni és használni az egyes node-jainknál. A tizenkettedik sor a számítógépeink közötti statikus útvonal választást aktiválja, mellyel bármely két gépünk el tudja érni egymást a tesztkörnyezetünkben. A tizenharmadik sor végül a szimulációt elkezdi futtatni. A fentiekben leírt elrendezés a 3.3.1. ábrán megtekinthető. 23

n0 l0 n1 Sávszélesség: 1000 Mb/s Késleltetés: 0ms Csomagvesztés: 0% 3.3.1. ábra Egyszerű kapcsolat topológiája Emulabban 3.3.2 Nem ideális link létrehozása Ennél a példánál egy 1 gigabites nem ideális linket hozok létre két számítógép között, késleltetéssel és csomagvesztéssel, melyhez az NS fájl a következő: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set n0 [$ns node] [4:] set n1 [$ns node] [5:] tb-set-node-os $n0 UBUNTU70-Step1 [6:] tb-set-node-os $n1 UBUNTU70-Step1 [7:] set l0 [$ns duplex-link $n0 $n1 1000Mb 50ms DropTail] [8:] tb-set-link_loss $l0 0.05 [9:] tb-set-hardware $n0 pc3000 [10:] tb-set-hardware $n1 pc3000 [11:] tb-set-ip $n0 10.1.1.2 [12:] tb-set-ip $n1 10.1.2.2 [13:] $ns rtproto Static [14:] $ns run A 3.3.1-es fejezetben bemutatott példához képest a hetedik sorban van paraméter változás, illetve egy sor még be lett toldva a hardverszükségek megadása elé. A hetedik sorban paraméterben megadtam az 50ms késleltetést, a nyolcadik sorban pedig 5%-os csomagvesztést állítottam be a linken. A kapcsolati paraméterek emulálására az Emulab ebben az esetben beszúr egy delay node-ot, amin Dummynet alkalmazás fut. A delay node-os Dummynet segítségével a mérés során az online felületen is változtathatjuk a hálózati paramétereket, továbbá közvetlenül a node-ra bejelentkezve is. A topológia a 3.3.2 ábrán látható, az értékek a 2 node között értendők. 24

n0-delay node delay node-n1 n0 delay node Sávszélesség: 1000 Mb/s Késleltetés: 50ms Csomagvesztés: 5% n1 3.3.2. ábra Automatikus delay node beszúrás topológiája Emulabban 3.3.3 Delay node explicit létrehozása Ennél a példánál egy 1 gigabites nem ideális linket hozok létre két számítógép között, késleltetéssel és csomagvesztéssel, a delay node-ot explicit megadva, melyhez az NS fájl a következő: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set n0 [$ns node] [4:] set n1 [$ns node] [5:] set ndelay [$ns bridge] [6:] tb-set-node-os $n0 UBUNTU70-Step1 [7:] tb-set-node-os $n1 UBUNTU70-Step1 [8:] tb-set-delay-os $ndummy FBSD83-Step1 [9:] set l0 [$ns duplex-link $n0 $ndelay 1000Mb 10ms DropTail] [10:] tb-set-link_loss $l0 0.1 [11:] set l1 [$ns duplex-link $n1 $ndelay 1000Mb 20ms DropTail] [12:] tb-set-link_loss $l1 0.05 [13:] tb-set-hardware $n0 pc3000 [14:] tb-set-hardware $n1 pc3000 [15:] tb-set-ip $n0 10.1.1.2 [16:] tb-set-ip $n1 10.1.2.2 [17:] $ns rtproto Static [18:] $ns run Az ötödik sorban adom meg a delay node-ot, látható, hogy bridge-ként, nem pedig egyszerű node-ként, a rajta futó operációs rendszert a nyolcadik sorban adom meg, ami egyúttal azt is jelenti, ha lenne még több delay node-unk, azok is ezzel azonos operációs rendszert használnának. A kilenc-tizedik sorban az n0 és a ndelay közötti linket specifikálom 10ms késleltetéssel, 10%-os csomagvesztéssel. A tizenegy-tizenkettedik sorban pedig az n1 és ndelay közötti linkre 20ms késleltetést és 5%-os csomagvesztést adtam meg, mindkét linken 100Mb/s sávszélességgel. Ez a megadás akkor lehet jó, ha a köztes node-on is mérnénk esetleg, egyébként láthatjuk, hogyha csak a két végpontban figyeljük az eseményeket, az előző kettő példa teljesen tökéletes felhasználást ígér. A bemutatott elrendezés topológiája a 3.3.3 ábrán látható. 25

n0 l0 ndummy l1 n1 1000 Mb/s 10ms 10% Sávszélesség Késleltetés Csomagvesztés 1000 Mb/s 20ms 5% 3.3.3. ábra Delay node explicit megadás topológiája 26

4 Tesztkörnyezet kialakítása és a mérések megtervezése 4.1 Célkitűzések A DFCP még fejlesztés és emiatt még legfőképpen tesztelés alatt is áll. A következőkben a DFCP protokollt meghatározott topológiákon, megválasztott körülmények között fogom tesztelni. Feladatom a DFCP-t megvalósító legújabb kernel tesztelése, a korábbi mérések eredményeinek validálása, illetve új mérések elvégzése különböző szempontok szerint. A DFCP protokollt majd néhány esetben a TCP torlódásszabályozás alapját adó TCP Renoval, illetve több esetben a legelterjedtebb CUBIC algoritmussal fogom összehasonlítani. A továbbiakban bemutatom a tesztkörnyezet szükséges beállításait, a felhasznált eszközöket, illetve a méréseknél használt topológiákat. 4.2 Tesztkörnyezet kialakítása A legelső lépés a majd használni kívánt operációs rendszerek beállítása. Törekedtem arra, hogy a méréseimet lehetőleg a leghasonlóbb körülmények között hajtsam végre, ezért a kiindulási pontok szinte azonosak voltak, kivéve, hogy újabb kernelt és forgalomgeneráló alkalmazást kaptam. 4.2.1 Kliens vagy szerver node A korábbi, tanszéken végzett mérésekhez hasonlóan én is egy Ubuntu 7.04-es operációs rendszert vettem kiindulásnak, ami megtalálható az Emulab operációs rendszer képei között sok egyéb mellett. Legelsőként az új kernelt, a 2.6.26-2-1.2.5- lab28-as verziót installáltam a dpkg paranccsal, ami a megfelelő helyre mozgatta a szükséges fájlokat. Ezután már érdemes elmenteni Emulabban a node képét, és a következő betöltéskor megfigyelni, hogy az új kernellel tölt-e be az operációs rendszerünk, aminek én a UBUNTU70-Step1 nevet adtam. Ezután létrehoztam egy bash fájlt, ami a következő parancsokat tartalmazza: sysctl net.ipv4.tcp_wmem='4096 16384 3555328' sysctl net.ipv4.tcp_rmem='4096 87380 3555328' sysctl net.ipv4.tcp_mem='83328 111104 166656' sysctl net.core.wmem_default=111616 27

sysctl net.core.rmem_default=111616 sysctl net.core.wmem_max=131071 sysctl net.core.rmem_max=131071 ifconfig eth1 txqueuelen 50000 ifconfig eth2 txqueuelen 50000 ifconfig eth3 txqueuelen 50000 ifconfig eth4 txqueuelen 50000 A fent látható első három sor megadja a TCP kapcsolatokra a buffer minimális, alapértelmezett és maximális méretét küldésre és fogadásra is. A következő négy sor hasonlóan állítja be a buffer méretét, az alapértelmezett illetve maximális értékeket adjuk meg az összes kapcsolattípus számára. Az utolsó négy sorban a hálózati interfészek várakozási sorának hosszát állítjuk be 50000-re. Kis magyarázat az utolsó négy sorhoz, az eth0 interfész mindig a külvilághoz kapcsolódik, az nincs is benne a scriptben, de a többi interfész a belső hálózathoz tartozhat, így mindegyiket be lehel állítani 50000-re nem lesz problémánk a node elérésében és a szükséges sorhosszakat minden egyes betöltésnél, interfész vizsgálás nélkül, így is beállíthatjuk. Még a server5 és a client5 forgalom fogadó és generáló programok elengedhetetlenek a mérésekhez, ezeket egy-egy C fájlban kaptam meg, majd gcc-vel lefordíttattam őket és a mérésekhez már készen is álltak a végpont node-jaink. Mc és iperf Linuxos programokat telepítettem még munkám megkönnyítésére, illetve a hálózat gyors tesztelésére. 4.2.2 Dummynet node Ezekre a gépekre FreeBSD 8.3-as alap operációs rendszert használtam, módosítottam, FBSD83-Step1-nek neveztem el a saját képfájlomat. Ezeken a gépeken lehet majd az egyes hálózati paramétereket beállítani, emulálni. Először is a /etc/rc.conf fájlt kellett módosítani a következő sorok hozzáadásával: inetd_enable="yes" gateway_enable="yes" firewall_enable="yes" firewall_type="open" Az első két sor segítségével a node átjáróként tud viselkedni, a harmadik sor segítségével aktiváljuk az ipfw szolgáltatást, a negyedik sor pedig a tűzfalat nyitott állapotba helyezi, tehát nem lesz blokkolt csomag, a méréseknél nem fognak elveszni adatok. A /root/ipfw.rules állományba a következő sorokat helyeztem el: ipfw add 65000 allow ip from any to any kldload ipfw 28

Az első sorral a szabály listába egy mindent áteresztő szabályt rakok, itt is biztosítva, hogy ne legyen blokkolt csomagunk. A második sorral elértük, hogy az ipfw futtatásakor automatikusan induljon, nem szükséges kiadni a beírt parancsot indulásonként, az adott méréshez szükséges szabálylistákat egyből vihetjük be. hoztam létre. A fejezetcím nevét adó Dummynet programindításhoz szintén egy bash fájlt kldload dummynet sysctl net.inet.tcp.delayed_ack=0 sysctl net.inet.ip.dummynet.io_fast=1 sysctl net.inet.ip.dummynet.pipe_byte_limit=1048576000 sysctl net.inet.ip.dummynet.pipe_slot_limit=100000 sysctl net.inet.ip.dummynet.hash_size=4096 sysctl net.inet.ip.fw.one_pass=1 Az első sor elindítja a Dummynet szolgáltatást, utána sikeresen lehet alkalmazni a megadott parancsokat. A minél gyorsabb csomagátadás volt a célunk, lehetőleg sorbaállási csomagvesztés nélkül, ezeket valósítják meg a fentebbi szabályok. Ezek a szabályok konzisztensek a korábbi, tanszéken végzett teszthálózati mérésekkel. Az utolsó sorral beállíthatjuk, hogy egy adott csomag a szabálylistában rá illeszkedő szűrők közül csak a legnagyobb precedenciájút alkalmazzuk rá vagy az összes többit is. 4.3 Mérési forgatókönyvek A méréseknél kezdetben a protokollok egyenként változó hálózati paraméterek mellett voltak tesztelve, majd intra-protokoll vizsgálatokat végeztem. A mérések 60 másodpercig tartottak, az ablakméret 100 volt, a szükséges helyeken WF2Q+ ütemezést használtam, az egyes források között igazságosan elosztva a súlyokat, a hálózati paraméterek emulálásánál a módosítások csak a küldő féltől a fogadó fél felé értendőek, tehát csak egy irányban voltak alkalmazva. DFCP protokollnál nyugtázással, a kódolás és dekódolás kikapcsolásával teszteltem. 4.3.1 Egy küldő-fogadó pár Három tesztet fogok ezen a topológián elvégezni, a mérési elrendezést a 4.3.1-es ábra mutatja. Az elrendezésben a linkek (l0 és l1) 1 gigabitesek, veszteség és késleltetés mentesek, tehát ideálisak. A tesztelt protokollok a DFCP, Reno és Cubic lesznek. A hálózati emulációt majd az ndummy-n futó Dummynet alkalmazással valósítom meg. 29

n0 l0 ndummy l1 n1 4.3.1. ábra Küldő-fogadó pár topológia Az első esetben a linken 0, 5, 10, 50, 100 ms késleltetést adok meg, megfigyelve az RTT növelésekor bekövetkező hatásokat. A második esetben 0,1%, 1%, 5%, 10%, 50% csomagvesztést adok meg, megfigyelve a csomagvesztés okozta hatásokat. A kliens oldalon a csomagvesztésnek megfelelően redundanciát kell állítani, amelyet a 4.3.1 táblázat mutat be. A táblázatban megadott értékek optimális redundancia értékek, amelyek olyan minimális értékek, amit egy adott csomagvesztési ráta mellett be kell állítani ahhoz, hogy az adatküldés sikeresen megtörténjen és a vevő oldalon az adatok dekódolhatók legyenek. Csomagvesztés [%] 0,1 1 5 10 50 Redundancia 52 56 62 69 180 4.3.1. táblázat Redundancia értékek A harmadik esetben fix 0,1% csomagvesztést állítok be, a késleltetés értékei pedig 0, 5, 10, 50, 100 ms lesznek. A kliens oldalon a csomagvesztésnek megfelelően az 52 redundancia értéket állítom be. Ennél az esetnél a kismértékű csomagvesztés melletti késleltetés változás okozta hatásokat vizsgáljuk. A negyedik esetben a DFCP és CUBIC protokoll konvergencia idejét vizsgálom 10, 50, 100, 200, 500 ms késleltetési értékek mellett. Konvergencia idő alatt azt az időt értjük, amennyi idő alatt a vizsgált protokoll el tudja érni az adott hálózati körülményekhez tartozó legnagyobb adatátviteli sebességét és ezt a szintet stabilan tudja tartani. Ezekkel a mérésekkel megfigyelhető, hogy az egyes hálózati paraméterek milyen módon befolyásolják a protokollok teljesítményét. 30