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: Wmax, maximális ablakméret ( dinamikus), Wmin, minimális ablakméret (dinamikus), Smax, maximális növelés (fix), Smin 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, Wmax a csomagvesztéskor fennálló ablakméret, a Wmin pedig a csökkentés utáni ablakméret lesz. A két érték (Wmax és Wmin) á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 Wmin különbsége nagyobb mint az Smax, akkor csak Smax 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 Wmin 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 Wmax lesz, az új érték pedig a Wmin. Amikor már az ablaknövelés kisebb, mint az Smin belépünk a bináris keresés fázisba. Ez a folyamat addig tart, amíg el nem érjük a Wmax–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. (
)
12
(2.1.3)
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 elérhetőek.
a
Például
kísérlet IP
online cím,
felületén
megtekinthetőek,
többféleképpen
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
l0 n0
n1 Sávszélesség: Késleltetés: Csomagvesztés:
1000 Mb/s 0ms 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 n0
delay node-n1 delay node
n1
Sávszélesség: 1000 Mb/s Késleltetés: 50ms Csomagvesztés: 5% 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
l0
l1 nDummy
n0 1000 Mb/s 10ms 10%
Sávszélesség Késleltetés Csomagvesztés
n1 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.5lab28-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 sysctl sysctl sysctl
net.ipv4.tcp_wmem='4096 16384 3555328' net.ipv4.tcp_rmem='4096 87380 3555328' net.ipv4.tcp_mem='83328 111104 166656' 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. A fejezetcím nevét adó Dummynet programindításhoz szintén egy bash fájlt hoztam létre. 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
l0 n0
l1 nDummy
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 Redundancia
52
1
5
10
50
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
4.3.2 Két küldő-fogadó pár Az elrendezésben a linkek (l0, l1, l2, l3) 1 gigabitesek, veszteség és késleltetés mentesek, tehát ideálisak. A késleltetést az nDummyn futó Dummynet alkalmazással valósítom majd meg. Az elrendezés a 4.3.3 ábrán látható. Az első esetben n0 és n2 között fix 10 ms késleltetést állítok be, n1 és n3 között kezdetben 0 ms-ot majd 10 ms lépésközzel 100 ms-ig növelem. Intra-protokoll tesztelést hajtok végre a DFCP és CUBIC használatával, megfigyelve a késleltetés változás okozta hatásokat, és megmutatva a Jain’s indexüket is. A második esetben a mérésben DFCP és CUBIC protokollokat vizsgálok intraprotokoll tesztelést végezve, ahol mindkét folyam késleltetése 100 ms, a beállított szűkkeresztmetszetű csatorna pedig 200Mbit/s sebességű lesz. Az idő függvényében láthatjuk majd az átviteli sebességek változását.
n0
l2
l0
n2
nDummy l3
l1 n1
n3 4.3.2. ábra Két küldő-fogadó pár topológia
Ezekkel a mérésekkel láthatóvá válik az egyes folyamok egymásra hatása, amelyek az előző elrendezésben nem figyelhetőek meg.
4.4 Mérésekhez felhasznált számítógépek hardver tulajdonságai Az Emulab mérések során, ha nincs megnevezve a kért számítógép típusa, a rendszer automatikusan kioszt egy célhardvert. Ez a mérések szempontjából nem túl ideális, a kimenetek változók lehetnek hardvertől függően, ezért a méréseim során a pc3000 típust kértem a rendszertől, melynek a fontosabb paraméterei az alábbiak:
31
pc3000:
3.0 GHz 64-bit Xeon processzor, 800Mhz FSB
2GB 400Mhz DDR2 RAM
2 db 146GB 10,000 RPM SCSI merevlemez
6 db 10/100/1000 Intel hálózati interfész
4.5 Felhasznált eszközök 4.5.1 Client5 és server5 C nyelven íródott, egyszerűen konzolból, paraméterek megadásával indítható egyenként szervert vagy klienst megvalósító, adatfogadó vagy generáló programok. Használata egyszerű, először a szerver oldalon kell elindítani, ami ezután várakozik, figyeli a paraméterben megadott portot. A kliensoldalon a szerver IP címét és portját kell legfőképpen megadni és a kapcsolat felépülhet, az adatátvitel megvalósul. A szerver és a kliens oldalon az adatátvitel végeztével kiíródik az átvitt adatmennyiség, a kapcsolat futási ideje és az átlagos átviteli sebesség. A programok sok paraméterrel rendelkeznek, ezeket ismertetem és használatukra mutatok példát a következőkben. 4.5.1.1 Server5 paraméterei A server5 paraméterei, kis magyarázattal, az egyes értékek jelentésével.
-p: A használt portszám <portszám>
-w: Ablakméret nagysága
-a: Nyugtázás kapcsolása <0: be, 1: ki>
-e: Kódolás kapcsolása <0: be, 1: ki>
-d: Dekódolás kapcsolása <0: be, 1: ki>
-z: TCP típus beállítása
-f: Fájlba naplózás kapcsolása <0: ki, 1: be>
-k: Terminálra naplózás kapcsolása <0: ki, 1: be>
-x: Naplózás első x másodpercének figyelmen kívül hagyása az átviteli értékeknél <x sec>
-y, Debug funkció kapcsolása <0: ki, 1: be>
--prec: Fájlba naplózás, terminálra naplózás felbontása < sec >
32
4.5.1.2 Client5 paraméterei A client5 paraméterei, kis magyarázattal, az egyes értékek jelentésével.
-s: Szerver megadása <szerver címe vagy hosztneve>
-p: A használt portszám <portszám>
-n: Küldendő adat mérete MB-ban <méret (MBytes)>
-w: Ablakméret nagysága
-r: Redundancia mértéke
-a: Nyugtázás kapcsolása <0: be, 1: ki>
-e: Kódolás kapcsolása <0: be, 1: ki>
-m: Maximális token szám
-i: Token növelés
-t: Token generálási intervallum < sec >
-b: sávszélesség <sávszélkorlát, Kbps vagy Mbps>
-c: Küldési idő < sec >
-z: TCP típus beállítása
-f: Fájlba naplózás kapcsolása <0: ki, 1: be>
-k: Terminálra naplózás kapcsolása <0: ki, 1: be>
-x: Naplózás első x másodpercének figyelmen kívül hagyása az átviteli értékeknél <x sec>
-y, Debug funkció kapcsolása <0: ki, 1: be>
--prec: Fájlba naplózás, terminálra naplózás felbontása < sec >
4.5.1.3 Client5, server5 példák DFCP példa Először a szerver oldalon indítjuk a programot: ./server5 -p 54321 -e 1 -d 1 -a 0 -w 100 -x 15 --prec 0.1 -f 1
Az 54321-es portot használjuk, kódolást, dekódolást kikapcsolva, nyugtázást bekapcsolva, 100-as ablakmérettel, az első 15 másodpercet elvetjük a kapcsolat adatainak számolásakor, 0.1 másodpercenként, az alapértelmezett csv formátumú fájlba naplózunk. Ezután indíthatjuk a kliens oldalon is: ./client5 -s 10.1.2.2 -p 54321 -e 1 -a 0 -b 1000Mb -c 20 -w 100 --prec 5 k 1
33
Megadjuk
a
server
címét,
portját,
kódolást
kikapcsoljuk,
nyugtázást
bekapcsoljuk, 1000 Mbit/s adatsebességgel küldjük, 300 másodpercig, 100-as ablakmérettel az adatokat, másodpercenként a terminálra naplózva. A parancsot elindítva, az alábbiakban megtekinthető információk íródnak ki a terminálra. Az összes paraméter, az értékeikkel együtt, majd meg kell adni néhány karaktert, amit a forgalomgeneráló felhasznál, de egy szöveges fájl is tökéletes. Ezután elkezdődik az üzenetküldés, 5 másodpercenkénti konzolra kiírást adtam meg a paramétereknek, láthatjuk az adott időpillanatot és az adott időpillanatig kiküldött adatmennyiséget. Végül kiíródik egy összegzés, hogy mennyi idő alatt mennyi adatot küldtünk ki. Továbbá megjelenítődik a kapcsolat átlagos sávszélessége és átlagos hasznos adatküldési sebessége. Végül a program lezárja a kapcsolatot és befejeződik a futása. Client running: Server Address: 10.1.2.2 Port: 54321 Protocol: P7 Buffer size: 63536 Block number: 1 Size: 0 MB Window: 100 Send count: 49 Ack off: 0 Code off: 1 Inctokens: 514149 Maxtokens: 695800 Inttokens: 1 Bandwidth: 1000.00000 Mbps Interval: 20 Log to file: 0 Log to console: 1 Exclude: 0 Precision: 5.00000 seconds Please enter the message: asd Sending... 2.503787,272760048 7.504001,810782896 12.504467,1348805744 17.504527,1886637984 Sent 2158.0073 megabytes in
21.0005 seconds.
Total: Bandwidth (Throughput): 918.0343 Mbps Bandwidth (Goodput): 822.0802 Mbps Connection closed. Quit.
Most nézzük meg, hogy a szerver oldalon mi történik a program elindítása után és egy bejövő kapcsolati kérés esetén. A fogadóhoz hasonlóan a szervernél is először kiíródnak a paraméterek, majd figyelő állapotba kerül. Ha érkezik küldési kérés, akkor 34
elkezd a kiírt nevű fájlba naplózni, ha bekapcsoltuk a funkciót, továbbá a kapcsolódó kliens IP címét is megtudjuk. Itt konzolra nem kértünk kiíratást, így nem tudjuk, hogyan áll a fogadás menete, csak mikor a kliens végzett a küldéssel és zárja a kapcsolatot, továbbá a szerver oldal megkapott minden még a hálózatban lévő adatot, tud majd kiértékelni. Ez hasonlóan történik, mint a kliens oldalon, de itt még be lehet állítani, hogy a kiértékelésnél az általunk megadott, jelen esetben 15 másodperces időintervallumot ne vegyük figyelembe. Végül a kapcsolat lezárul, a naplófájlt is lezárja a szerver, majd tovább figyel, bejövő kapcsolatokat vár, futása nem áll le. Server running: Port: 54321 Protocol: P7 Buffer size: 63536 Window: 100 Ack off: 0 Decode off: 1 Code off: 1 Log to file: 1 Log to console: 0 Exclude: 15 Precision: 0.10000 seconds Listening.. Logging to logs_20131203113659.csv Accepted client: 10.1.1.2:55796 Connection closed by client. Received 2157.9467 megabytes in
21.0434 seconds.
Total: Bandwidth (Throughput): 916.1355 Mbps Bandwidth (Goodput): 820.3798 Mbps First 15 seconds excluded: Bandwidth (Throughput): 916.8263 Mbps Bandwidth (Goodput): 820.9983 Mbps Connection closed. Closing logfile... Listening..
A mérések során mindig a szerver oldali adatok a mérvadóak. Cubic/Reno példa A torlódásszabályozást alkalmazó módszereknél nem kell használni a DFCP sajátos paramétereit (pl. kódolás, dekódolás), a nyugtázás kapcsoló nem befolyásolja a Cubic-ot és a Reno-t. Ezek helyett a már említett –z kapcsoló után kell megnevezni a használni kívánt protokollt. Egy-egy példa a szerver és kliens oldali programindításra: ./server5 -p 23232 -z cubic -w 100 -x 15 --prec 0.1 -f 1
35
./client5 -s 10.1.2.2 -p 23232 -b 1000Mb -c 20 -z cubic -w 100 --prec 5 -k 1
A program szintén kiírja a paramétereket, lényegesen kevesebb a DFCP-s indításhoz képest. Jelentős újdonság, hogy kiírja a használni kívánt TCP verziót is. A küldendő adat megadása után a program beállítja a használt torlódásvezérlési algoritmust. A kiértékelésnél csak a goodput jelenik meg, egyéb tekintetben azonos, mint a DFCP-s küldésnél. Client running: Server Address: 10.1.2.2 Port: 23232 Protocol: TCP Buffer size: 63536 Block number: 1 Size: 0 MB TCP version: cubic Interval: 20 Log to file: 0 Log to console: 1 Exclude:0 Precision: 5.00000 seconds Please enter the message: asd net.ipv4.tcp_congestion_control = cubic Sending... 1.696214,199503040 6.701201,788418224 11.710077,1377778160 16.710098,1966312128 Sent 2356.8118 megabytes in 21.0033 seconds. Total: Bandwidth (Goodput): Connection closed. Quit.
897.6906 Mbps
A szerver oldal terminálra írása az előző magyarázatok függvényében már egyértelmű. Server running: Port: 23232 Protocol: TCP Buffer size: 63536 TCP version: cubic Log to file: 1 Log to console: 0 Exclude: 15 Precision: 0.10000 seconds net.ipv4.tcp_congestion_control = cubic Listening.. Logging to logs_20131203114943.csv Accepted client: 10.1.1.2:53245 Connection closed by client.
36
Received
2356.8118 megabytes in
Total: Bandwidth (Goodput):
21.0002 seconds.
897.8225 Mbps
First 15 seconds excluded: Bandwidth (Goodput): 897.8531 Mbps Connection closed. Closing logfile... Listening..
4.5.2 Iperf alkalmazás Említésre méltó az iperf program, amellyel ellenőrizni lehet az méréseink eredményét, esetleg a hálózatban történt változások után gyorstesztelőként is használható. Működése nagyon hasonló a már bemutatott server5 és client5 programokéhoz. Először a szerver oldalt kell elindítani és utána a kliens oldalt. A program bemutatása nem teljes körű, csak az általam használt pár paramétert mutatja be. A szerver oldalon elég a parancs neve és egy –s kapcsoló, amivel jelöljük, hogy ő lesz a fogadó fél. iperf –s –i 10
A kliens oldalon meg kell adni, hogy a küldő fél leszünk (-c), a fogadó fél címét, az időintervallumot (-t), a kimenetre hány másodpercenként írjuk ki az addig aktuális adatokat (-i), tehát a következőképpen néz ki: root@node0:~# iperf -c 10.1.2.2 -t 20 -i 5 -----------------------------------------------------------Client connecting to 10.1.2.2, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 10.1.1.2 port 52583 connected with 10.1.2.2 port 5001 [ 3] 0.0- 5.0 sec 563 MBytes 945 Mbits/sec [ 3] 5.0-10.0 sec 561 MBytes 941 Mbits/sec [ 3] 10.0-15.0 sec 562 MBytes 943 Mbits/sec [ 3] 15.0-20.0 sec 561 MBytes 941 Mbits/sec [ 3] 0.0-20.0 sec 2.19 GBytes 942 Mbits/sec
A példa futtatásnál 20 másodperces időintervallumot adtam meg, 5 másodpercenként kiírva az aktuális állapotokat. Az utolsó sornál leolvasható, hogy 2,19 GB adat ment át 942 Mbit/s átlag átviteli sebességgel. A szerver oldali kimenet lentebb látható, a két oldalon mért értékek megegyeznek. root@node1:~# iperf -s -i 10 -----------------------------------------------------------Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
37
-----------------------------------------------------------[ 4] local 10.1.2.2 port 5001 connected with 10.1.1.2 port 52583 [ 4] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec [ 4] 10.0-20.0 sec 1.10 GBytes 941 Mbits/sec [ 4] 0.0-20.0 sec 2.19 GBytes 941 Mbits/sec
További hasznos, beállítható paraméterek az iperf –h paranccsal kérdezhetőek le.
4.5.3 Dummynet és ipfw A már említett Dummynet node-okon a fejezet címét adó 2 alkalmazás segítségével tudjuk a hálózati paramétereket emulálni, erre fogok példát mutatni. A Dummynet keretrendszert ad az ipfw szabályok támogatására, a 2 alkalmazás betöltése, a Dummynetes változók beállítása után ipfw szabályokat tudunk megadni. Példákat a 3.3.2-es fejezetben található elrendezéshez adom meg, a 2 végpont közötti delay nodeon kell futtatni a megadott parancsokat. ipfw add 40 pipe 5 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 5 config bw 800Mb queue 50000 delay 20ms plr 0
Az első sorban létrehozom a 40-es szabályt, amiben az 5-ös pipe objektumot IP címeket vizsgálva, ahol a forráscím a 10.1.1.2 a célcím a 10.1.2.2. A második sorban a már létrehozott 5-ös pipe objektumot állítom be, 800 Mbit/s sávszélességre 50000-es queue mérettel, 20 ms-os késleltetéssel és a csomagvesztést 0%-ra. A pipe objektumunkat létrehozva a rá illeszkedő IP csomagok végig fognak rajta haladni. A pipe szabály létrehozásakor 40-es számot adtunk neki, ami egyben a precendenciáját is megadja, minél nagyobb az a szám, annál később kerül kiértékelésre. Részletes szabálylistát az ipfw show paranccsal tudunk lekérdezni, melynek a kimenete jelen esetben a következő: 00040 0 0 pipe 5 ip from 10.1.1.2 to 10.1.2.2 out 65000 1536 224012 allow ip from any to any 65535 0 0 deny ip from any to any
Az első sorban láthatjuk az előbbiekben létrehozott szabályunkat, mely 0 csomagon 0 bájtnyi adaton lett alkalmazva. A második sort is mi állítottuk be, még a 3.3.3-s fejezetben, tehát az összes IP csomagot átengedjük az interfészeken. Jelen esetben már 1536 IP csomagot engedett át, ami 224012 bájtnyi adatot jelent. Az utolsó szabály minden IP csomagot tilt, de mivel később helyezkedik el a mindent átengedőnél, így nem is jut hozzá csomag, nem kerül alkalmazásra. A 10.1.1.2-es gépről pingelve a 10.1.2.2-es gépet a következőket láthatjuk a kimeneten: 38
root@node0:~# ping 10.1.2.2 PING 10.1.2.2 (10.1.2.2) 56(84) bytes of data. 64 bytes from 10.1.2.2: icmp_seq=1 ttl=63 time=21.0 ms 64 bytes from 10.1.2.2: icmp_seq=2 ttl=63 time=20.0 ms 64 bytes from 10.1.2.2: icmp_seq=3 ttl=63 time=19.2 ms 64 bytes from 10.1.2.2: icmp_seq=4 ttl=63 time=19.6 ms 64 bytes from 10.1.2.2: icmp_seq=5 ttl=63 time=19.0 ms 64 bytes from 10.1.2.2: icmp_seq=6 ttl=63 time=19.3 ms --- 10.1.2.2 ping statistics --6 packets transmitted, 6 received, 0% packet loss, time 5024ms rtt min/avg/max/mdev = 19.008/19.713/21.000/0.678 ms
Jól látható, hogy az egyes csomagok 20 ms körüli értékkel tértek vissza, tehát a szabályunk beállítása sikeres volt, ezt megerősíti az újonnan lefuttatott ipfw show parancs is, amin látható, hogy a 6 pingelés közben használt csomag a 40-es szabályon áthaladt. 00040 6 504 pipe 5 ip from 10.1.1.2 to 10.1.2.2 out 65000 1609 233723 allow ip from any to any 65535 0 0 deny ip from any to any
A
már
meglévő
szabályainkhoz,
objektumunkhoz
további
elemeket
rendelhetünk. Például egy pipe objektumunkhoz még egy queue objektumot rendelünk: ipfw add 30 queue 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw queue 1 config queue 50000 weight 50 pipe 5
30-as szabályként hozzuk létre az 1-es queue-nkat, szintén a 10.1.1.2-ről érkező és a 10.1.2.2 címhez tartó csomagokat. Be is állítjuk 50000 hosszúra, 50%-os súllyal a már meglévő 5-ös pipe-ba irányítva. A pipe-oknál megadható paraméter még az ütemezés típusa is, tehát queue-k pipe-ba vezetésével lehet bottleneck linket szimulálni. A szabály működésének leellenőrzéséhez újranézzük meg az ipfw show parancs ide vonatkozó kimentét pingelés előtt és után is. Pingelés előtt: 00030 00040
0 0
0 queue 1 ip from 10.1.1.2 to 10.1.2.2 out 0 pipe 5 ip from 10.1.1.2 to 10.1.2.2 out
Pingelés után: 00030 00040
5 5
420 queue 1 ip from 10.1.1.2 to 10.1.2.2 out 420 pipe 5 ip from 10.1.1.2 to 10.1.2.2 out
Látható, hogy mindkettő szabályon átmentek a pingeléshez használt csomagok. Ebben a fejezetben bemutattam a méréseknél használt tesztkörnyezetet, az egyes gépek beállításait, a teszt topológiákat, a felhasznált eszközöket. A következő fejezetben
39
bemutatom részletesen az adott topológiát, a méréshez szükséges speciális beállításokat, az eredményeket pedig értékelni fogom.
40
5 Mérési eredmények Ebben a fejezetben megadom a 4.2-es fejezetben tárgyalt topológiák részletes leírását, a használt ipfw szabályokat, továbbá grafikonon és táblázatos formában mutatom be a kapott eredményeket, amelyeket értelmezek és értékelek is.
5.1 Egy küldő-fogadó páron végzett mérések A topológiát a 4.3.1-es ábrán már bemutattam, az Emulabban megadott NS forráskód a következő: set ns [new Simulator] source tb_compat.tcl set n0 [$ns node] set n1 [$ns node] set nDummy [$ns node] tb-set-node-os $n0 UBUNTU70-Step1 tb-set-node-os $n1 UBUNTU70-Step1 tb-set-node-os $nDummy FBSD83-Step1 set link0 [$ns duplex-link $n0 $nDummy 1000Mb 0ms DropTail] set link1 [$ns duplex-link $n1 $nDummy 1000Mb 0ms DropTail] tb-set-ip $n0 10.1.1.2 tb-set-ip $n1 10.1.2.2 $ns rtproto Static $ns run
Az Emulab képet is generál a kapott topológiáról, amin a node-ok IP címei és összeköttetései láthatóak. Sajnos ezt a funkciót butították, mert régebben a linkek sávszélessége és késleltetése is megjelent rajta. A küldő-fogadó pár Emulabos topológia képe az 5.1.1 ábrán látható.
5.1.1. ábra A küldő-fogadó pár Emulabos topológia képe
41
5.1.1 Késleltetés hatásának vizsgálata Az nDummy PC-n fut a Dummynet, a megadott ipfw szabályok a következőek: ipfw add 20 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb queue 10000 delay Xms plr 0
A pipe objektum beállításánál az X helyére 0, 5, 10, 50 és 100 értékeket állítottam be. A mérések eredményeit az 5.1.2 ábra mutatja, a pontos értékeket pedig az
Goodput [Mbit/s]
5.1.1 táblázat, melyben az értékek Mbit/s-ban értendőek. 1000 900 800 700 600 500 400 300 200 100 0
CUBIC RENO DFCP
0
5
10
50
100
Delay [ms] 5.1.2. ábra Késleltetés hatása egy küldő-fogadó pár esetén
delay [ms] 0 5 10 50 100
CUBIC
RENO
DFCP
897 897 897 376 193
897 897 897 376 193
821 821 821 821 479
5.1.1. táblázat Késleltetés hatása egy küldő-fogadó pár esetén (eredmények)
Az eredményekből látszik, hogy a 0, 5 és 10 ms késleltetésnél a CUBIC és Reno algoritmusok jobb eredményt érnek el a DFCP-nél, átviteli sebességükre nincs még hatással a 10 ms-nyi változás. 50 ms késleltetésnél a DFCP még mindig az előzőekkel megegyező adatot képes átvinni, de a CUBIC és Reno teljesítménye már több mint felére esik vissza. 100 ms késleltetésnél már a DFCP is veszít teljesítményéből, de még így is több mint kétszer annyi adatot képes átvinni, mint a CUBIC, Reno páros. Az eredményekből jól látható, hogy a DFCP teljesítményét kevésbé rontja le a késleltetés növekedése, mint a két TCP algoritmusét, a DFCP jobban teljesített a teszten. 42
5.1.2 Csomagvesztés hatásának vizsgálata Az nDummy PC-n megadott ipfw szabályok a következőek: ipfw add 20 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb queue 10000 delay 0ms plr X
A pipe objektum beállításánál az X helyére 0.001, 0.01, 0.05, 0.1 és 0.5 értékeket állítottam be. A mérések eredményeit az 5.1.3 ábra mutatja, a pontos értékeket pedig az 5.1.2 táblázat, melyben az értékek Mbit/s-ban értendőek.
Goodput [Mbit/s]
1000 800 600 CUBIC 400
RENO
200
DFCP
0 0
0,1
1
5
10
50
Packet loss [%] 5.1.3. ábra Késleltetés hatása egy küldő-fogadó pár esetén
PLR [%] 0 0,1 1 5 10 50
CUBIC 897 404 123 14,3 3,17 0,05
RENO 897 510 145 16,2 2,48 0,02
DFCP 821 773 718 648 583 216
5.1.2. táblázat Késleltetés hatása egy küldő-fogadó pár esetén (eredmény)
A grafikonon látható, hogy mindegyik protokoll esetében a csomagvesztés növelésével romlik a teljesítményük, de a DFCP goodput görbéje kevésbé esik vissza, viszont a két TCP esetében jelentős a visszaesés. A 0,1 és 1%-os csomagvesztés mellett a Reno jobban teljesít, mint a CUBIC, de 5%-os csomagvesztés felett már szinte azonosak az eredményeik, teljesítményük pedig nagyon visszaesik. A DFCP-nél ezzel ellentétben kisebb mértékben csökken a csomagvesztés hatására az átvitt adatok mennyisége, sokkal fokozatosabban, kisebb léptékben megy ez végbe.
Az
eredményekből jól látható, hogy a CUBIC és Reno nagyon érzékeny a csomagvesztésre, a DFCP pedig a hibavédő kódolás segítségével jobban tűri azt. 43
5.1.3 Késleltetés hatásának vizsgálata fix csomagvesztés mellett Az nDummy PC-n megadott ipfw szabályok a következőek: ipfw add 20 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb queue 10000 delay Xms plr 0.001
A pipe objektum beállításánál az X helyére 0, 5, 10, 50 és 100 értékeket állítottam be. A méréseknél tehát 0,1%-os csomagvesztés volt, a késleltetés érték pedig változtatva. A mérések eredményeit az 5.1.2 ábra mutatja, a pontos értékeket pedig az
Goodput [Mbit/s]
5.1.1 táblázat, melyben az értékek Mbit/s-ban értendőek. 900 800 700 600 500 400 300 200 100 0
CUBIC RENO DFCP
0
5
10
50
100
Delay [ms] 5.1.4. ábra 0,1%-os csomagvesztés mellett késleltetés változtatás
delay [ms] 0 5 10 50 100
CUBIC
RENO
DFCP
404 50,1 26,2 5,8 4,43
510 50,2 23,6 5,5 3,54
773 773 773 773 478
5.1.3. táblázat 0,1%-os csomagvesztés mellett késleltetés változtatás (eredmények)
Az eredményekből jól látható, hogy a TCP algoritmusoknál már kis 0,1%-os csomagvesztés melletti 5ms-os késleltetésre is jelentős teljesítmény csökkenés következik be. A késleltetés és csomagvesztés együttes fellépése esetén a TCP protokollok szinte működésképtelenek. A DFCP ezzel szemben a csomagvesztés okozta kisebb teljesítményromlás mellett még a hálózat késleltetés növekedése esetén is fixen tudja tartani az adatátvitelét, majd csak 100 ms-nál lesz nagyobb letörése, ami 0%-os csomagvesztésnél is megfigyelhető volt. Tehát a DFCP kis csomagvesztés és az RTT növekedése mellett jelentősen túlteljesíti a másik kettő vizsgált TCP protokollt. 44
5.1.4 Konvergencia idő vizsgálata A protokollok konvergencia idejére nézve végeztem vizsgálatokat, melyeket ebben a fejezetben mutatok be. A konvergencia idő alatt azt az időt értem, hogy egy adott protokoll az indítását követően mennyi idő múlva éri el az állandósult állapotát. Az nDummy PC-n fut a Dummynet, a megadott ipfw szabályok a következőek: ipfw add 20 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb queue 10000 delay Xms plr 0
A pipe objektum beállításánál az X helyére 10, 50, 100, 200 és 500 értékeket állítottam be. A mérések eredményeit az 5.1.5 és a 5.1.6 ábra mutatja be. 900
Goodput [Mbit/s]
800 700 600
10ms
500
50ms
400
100ms
300
200ms
200
500ms
100 0 0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15
Time [s] 5.1.5. ábra DFCP konvergencia ideje 1000
Goodput [Mbit/s]
900 800 700 600
10ms
500
50ms
400
100ms
300
200ms
200
500ms
100 0 0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15
Time[s] 5.1.6. ábra CUBIC konvergencia ideje
45
A grafikonokon jól látható, hogy a DFCP-nek szinte nincs konvergencia ideje, mivel a protokoll sajátossága, hogy a maximummal küld és így késleltetéstől független a konvergencia ideje. Ezzel szemben a CUBIC-nál a késletetés növekedésével egyre lassabban tud beállni az adási maximumra a Max Probing fázisa tovább eltart. 10 és 50 ms késleltetésnél 2 mp, 100ms-nál 3 mp, 200 ms-nál már 5 mp, végül 500 ms késleltetésnél már 9 mp kell az algoritmusnak, hogy megtalálja az adási maximumát, ami jelentős teljesítmény csökkenést eredményez. 10ms késleltetésnél még a CUBIC protokol tud több adatot átvinni, de 50ms késleltetés felett már a DFCP jóval megelőzi a CUBIC algoritmust a hasznos adatra számított átviteli sebességre nézve.
5.2 Két küldő-fogadó páron végzett mérések A két küldő-fogadó pár megalkotásához a következő NS parancsokat használtam. set ns [new Simulator] source tb_compat.tcl set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set nDummy0 [$ns node] tb-set-node-os $n0 UBUNTU70-Step1 tb-set-node-os $n1 UBUNTU70-Step1 tb-set-node-os $n2 UBUNTU70-Step1 tb-set-node-os $n3 UBUNTU70-Step1 tb-set-node-os $nDummy0 FBSD83-Step1 set link0 [$ns duplex-link $n0 $nDummy0 set link1 [$ns duplex-link $n1 $nDummy0 set link2 [$ns duplex-link $n2 $nDummy0 set link3 [$ns duplex-link $n3 $nDummy0 tb-set-ip $n0 10.1.1.2 tb-set-ip $n1 10.1.3.2 tb-set-ip $n2 10.1.2.2 tb-set-ip $n3 10.1.4.2 $ns rtproto Static $ns run
1000Mb 1000Mb 1000Mb 1000Mb
0ms 0ms 0ms 0ms
DropTail] DropTail] DropTail] DropTail]
Az Emulab rendszerében létrejött topológia rajz a következő, 5.2.1 ábrán látható.
46
5.2.1. ábra Két küldő-fogadó pár topológiája Emulabban
5.2.1 Késleltetés hatása versengő folyamok esetén Az nDummy PC-n megadott ipfw szabályok a következőek: ipfw add 5 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb plr 0 queue 10000 delay 10ms type WF2Q+ ipfw add 6 pipe 2 ip from 10.1.3.2 to 10.1.4.2 out ipfw pipe 2 config bw 1000Mb plr 0 queue 10000 delay Xms type WF2Q+ ipfw add 12 pipe 5 ip from {10.1.1.2 or 10.1.3.2} to {10.1.2.2 or 10.1.4.2} out ipfw pipe 5 config bw 1000Mb plr 0 queue 10000 delay 0ms type WF2Q+ ipfw add 10 queue 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw add 11 queue 2 ip from 10.1.3.2 to 10.1.4.2 out ipfw queue 1 config queue 10000 weight 50 pipe 5 ipfw queue 2 config queue 10000 weight 50 pipe 5
A kettes pipe objektum beállításánál az X helyére 10-től indulva 10-es lépésközzel 100-ig állítottam be az értékeket. Tehát az egyes folyamnak fix 10 ms a késleltetése, a kettes folyamnak pedig 10-100 ms-ig növekszik a késleltetése 10 ms-os lépésközzel. A linkek sávszélessége 1000Mbit/s. A mérések eredményeit az 5.2.2 ábra mutatja, a pontos értékeket pedig az 5.2.1 táblázat, melyben az értékek Mbit/s-ban értendőek.
47
800 700 Goodput [Mbit/s]
600 500 Cubic 1
400
Cubic 2
300
DFCP 1
200
DFCP 2
100 0 10
20
30
40
50
60
70
80
90
100
Delay [ms] 5.2.2. ábra Két küldő-fogadó párnál a késleltetés hatása
Delay [ms] 10 20 30 40 50 60 70 80 90 100
fix 10 ms Cubic 1 467 494 497 512 559 598 624 661 679 697
változó Cubic 2 450 421 412 391 344 296 253 221 205 185
fix 10 ms változó DFCP 1 DFCP 2 421 419 421 422 421 422 421 422 421 421 421 421 421 421 421 421 421 421 421 421
5.2.1. táblázat Két küldő-fogadó párnál a késleltetés hatása (eredmények)
A grafikonon jól látszik, hogy a DFCP protokoll a késleltetés növekedésével is igazságos marad, a kisebb késleltetésű folyam nem szorítja ki a nagy körülfordulási idővel rendelkező folyamot. Ezzel ellentétben a CUBIC algoritmusnál a növekedő késleltetésű linket használó folyamot kiszorítja a fixen 10 ms késleltetésnél futó folyam. A késleltetés növekedésével egyre jobba nyílik ki az „olló”, ez látszik is az 5.2.2 ábrán. Tehát a CUBIC algoritmus egyáltalán nem igazságos különböző körülfordulási idő értékeknél, míg a DFCP végig az maradt a vizsgált intervallumon. Az igazságosságot Jain’s indexszel is lehet jellemezni, amely megmutatja, hogy mennyire igazságosan osztoznak az erőforrásokon az egyes folyamok, az egyes érték jelenti a teljesen igazságos megoszlást. Az index számításához szükséges összefüggést az 5.2.1 számú 48
képlet írja le. Az n változó a folyamok számát jelenti, az xi pedig az adott folyam által elért adatsebességet jelenti. (∑ ∑
)
(5.2.1)
A Jain’s index értékét az előző mérésre vonatkozóan az 5.2.3 ábra mutatja. Az ábra megerősíti az előbb látottakat, a DFCP végig igazságos maradt, a CUBIC pedig a késleltetés növekedésével egyre igazságtalanabb. 1
Jain´s index
0,95 0,9 0,85
CUBIC DFCP
0,8 0,75 0,7 10
20
30
40
50
60
70
80
90
100
Delay [ms] 5.2.3. ábra Két küldő-fogadó párnál a sávszélesség megosztás igazságossága
5.2.2 Versengő folyamok átviteli sebessége Az nDummy PC-n megadott ipfw szabályok a következőek: ipfw add 5 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw pipe 1 config bw 1000Mb plr 0 queue 10000 delay 100ms type WF2Q+ ipfw add 6 pipe 2 ip from 10.1.3.2 to 10.1.4.2 out ipfw pipe 2 config bw 1000Mb plr 0 queue 10000 delay 100ms type WF2Q+ ipfw add 12 pipe 5 ip from {10.1.1.2 or 10.1.3.2} to {10.1.2.2 or 10.1.4.2} out ipfw pipe 5 config bw 200Mb plr 0 queue 10000 delay 0ms type WF2Q+ ipfw add 10 queue 1 ip from 10.1.1.2 to 10.1.2.2 out ipfw add 11 queue 2 ip from 10.1.3.2 to 10.1.4.2 out ipfw queue 1 config queue 10000 weight 50 pipe 5 ipfw queue 2 config queue 10000 weight 50 pipe 5
49
Az ipfw szabályok alapján látható, hogy a küldő oldalakat az nDummy PC-vel összekötő linkek 1000 Mbit/s sávszélességel és 100 ms késleltetéssel rendelkeznek. A létrehozott bottleneck linken pedig 200Mbit/s sávszélesség és 0ms késleltetése van. A mérések eredményeit az 5.2.4 ábra mutatja. 140
Goodput [Mbit/s]
120 100 80 60 40 20 0 0
1
2
3
4
5
6
7
8
9
10
Time [s] cubic1
cubic2
dfcp 1
dfcp2
5.2.4. ábra Versengő folyamok átviteli sebessége
A grafikonon az látható, hogy a DFCP-nek a hasznos adatátviteli sebessége szinte azonos 85 Mbit/s körüli, nincs benne ingadozás. Ez ugye a protokoll alapelképzeléséből adódik, tehát maximális sebességgel adunk, csomagok a hálózaton elveszhetnek, eldobásra kerülhetnek, a hibavédő kódolás pedig ez ellen véd. Ezzel szemben a CUBIC a már leírt algoritmusával próbálja beállítani a megfelelő ablakméretet, ez a folyamat körülbelül a 2. másodpercre stabilizálódik, ami az 5.2.4 ábrán jól kivehető.
50
6 Összefoglalás A feladatomhoz segítséget jelentett az Önálló laboratórium tárgyam, mivel abban az Emulab rendszerébe nyertem bepillantást és három kevésbé használt, de annál tanulságosabb torlódásszabályozási algoritmust ismertem meg. Így a szakdolgozatom elkezdéséhez jó alappal rendelkeztem, az Emulab rendszerhez megvolt a hozzáférésem, továbbá a témakörben kisebb jártasságot szereztem. A szakdolgozatomban ezt bővítettem
ki,
részletesebben megismerkedtem
a
napjainkban használt
főbb
torlódásszabályozási protokollokkal, a TCP Reno, a BIC és a CUBIC algoritmusokkal. Továbbá megismerkedtem a tanszékünkön fejlesztés alatt álló DFCP protokollal, melynek a kerneljét és a beállításait kézhez kaptam, a tesztek elkészítéséhez szükséges forgalomgeneráló és mérő programot is biztosították. A feladatom az volt, hogy a főbb TCP algoritmusokat és a DFCP protokoll újabb változatú kerneljét teszteljem, az előző változat használatával kapott eredményeket validájlam, valamint teljesítményelemzést végezzek új, eddig még nem vizsgált szempontok szerint. Ennek elvégzésére a Emulab rendszerében készítettem különböző topológiákat, ahol az összeköttetések csomagvesztését, késleltetését, sávszélességét tudtam emulálni, változatos körülményeket teremtve. Ebben a környezetben sikerült a protokollok néhány sajátos tulajdonságát megfigyelni, de valószínűleg még lehetnek olyanok is, amik rejtve maradtak, így további körülmények és topológiák megalkotására ösztönözve a kutatókat. A főbb teszteléseimet az egy küldő-fogadó párból álló topológián végeztem el, ahol kiderült, a DFCP versenyképes a két vizsgált TCP protokollal szemben. A késleltetés hatásának vizsgálatánál a TCP verziók 10 ms késleltetés fölött már lényegesebben gyengébben teljesítettek, mint a DFCP, ami csak 50 ms késleltetés fölött vesztett az átvitt adatok mennyiségéből. A következő tesztnél a DFCP-re sokkal kisebb hatással volt a csomagvesztés, mint a CUBIC-ra vagy TCP Reno-ra, amelyeknél drasztikus teljesítményromlás jelentkezett. A fix 0,1%-os csomagvesztés mellett végzett kísérletnél kiderült, hogy a DFCP-nek adott csomagvesztési ráta esetén csak 50 ms késleltetés fölött csökken az adatátviteli teljesítménye, ezzel szemben a TCP algoritmusok teljesítményében minden a késleltetés növelésével folyamatos romlás tapasztalható. Majd láthattuk, hogy a CUBIC konvergencia ideje a késleltetéstől függ, 51
extrém 500 ms késleltetés esetén akár 8 másodpercig is eltarthat. A DFCP konvergencia ideje független a késleltetéstől. Két küldő-fogadó párnál már megtekinthettük a TCP egyik fő hibáját, hogyha két folyam különböző körülfordulási idővel használ egy közös hálózati részt, akkor a kisebb RTT-vel rendelkező fél igazságtalanul nagyobb részben használja azt ki. A 30-40 ms késleltetéssel rendelkező 2-es számú CUBIC folyamot a másik, 10 ms késleltetéssel rendelkező 1-es számú CUBIC folyam már láthatóan kezdi elnyomni, ami 100 ms késleltetést elérve már szinte ki is van szorítva. A DFCP ezzel ellentétben végig igazságosan viselkedett, a nagyobb késleltetéssel működő folyam ugyanannyi adatot volt képes átvinni. Ennél a résznél megismerkedtem a Jains’s indexszel, ami a folyamok igazságosságát hivatott jellemezni, majd ezt is felhasználtam a mérés értékelésénél. A másik tesztnél a topológián versengő folyamok adatátviteli sebességét vizsgáltam, ahol látni lehetett, hogy a DFCP egyenletesen küldi az adatokat már a kezdéstől, míg a CUBIC-nak kell egy kis felfutási idő, a két folyamot versenyeztetve az első csomagvesztésig. Az eredményekből látható, hogy a TCP a csomagvesztés és a késleltetés hatására jelentős teljesítménybeli romlással reagál, több folyam esetén pedig unfairness probléma lép fel különböző késleltetési értékeknél. A DFCP ezeknél a körülményeknél jelentősen jobban teljesített, ezért például vezeték nélküli adatátviteleknél, ahol ezek a hatások fokozottan jelen vannak, stabilabb adatátvitelt képes biztosítani. A protokollnak még számos fejlesztésen kell átesnie főleg a kódolás és dekódolás terén, a méréseim során ezeket a lehetőségeket kikapcsoltam, a kiforratlanságuk miatt. A teszt eredmények alapján, a TCP melletti, jelentős adatátviteli protokoll fejlődhet ki belőle, főleg a vezeték nélküli kapcsolatok esetén érdemes tovább foglalkozni vele, vizsgálatokat, fejlesztéseket, teszteket folytatni.
52
Köszönetnyilvánítás Köszönetet szeretnék mondani Sonkoly Balázsnak, aki Önálló laboratórium témámként megismertetett az Emulab rendszerrel, később az ő segítségével kerülhettem a DFCP protokoll fejlesztési csapatához, ahol a szakdolgozatomat megírhattam, teszteléseket végezhettem. Külön köszönet Solymos Szilárdnak, aki a protokollhoz kapcsolódó
kérdéseimre
segítőkészen
válaszolt.
Legfőképpen
köszönöm
a
konzulenseim, Dr. Molnár Sándor és Móczár Zoltán egész féléves segítségét, munkám felügyeletét, rendelkezésre állásukat, amely a szakdolgozatom befejezéséhez szükséges volt.
53
Ábrajegyzék 2.1.1. ábra TCP Reno működése 2.1.2. ábra BIC ablaknövelési függvénye 2.1.3. ábra CUBIC ablaknövelési függvénye 2.2.1. ábra Raptor kódolás 3.1.1. ábra Az Utah-i Emulab állomás topológiája 3.3.1. ábra Egyszerű kapcsolat topológiája Emulabban 3.3.2. ábra Automatikus delay node beszúrás topológiája Emulabban 3.3.3. ábra Delay node explicit megadás topológiája 4.3.1. ábra Küldő-fogadó pár topológia 4.3.2. ábra Két küldő-fogadó pár topológia 5.1.1. ábra A küldő-fogadó pár Emulabos topológia képe 5.1.2. ábra Késleltetés hatása egy küldő-fogadó pár esetén 5.1.3. ábra Késleltetés hatása egy küldő-fogadó pár esetén 5.1.4. ábra 0,1%-os csomagvesztés mellett késleltetés változtatás 5.1.5. ábra DFCP konvergencia ideje 5.1.6. ábra CUBIC konvergencia ideje 5.2.1. ábra Két küldő-fogadó pár topológiája Emulabban 5.2.2. ábra Két küldő-fogadó párnál a késleltetés hatása 5.2.3. ábra Két küldő-fogadó párnál a 5.2.4. ábra Versengő folyamok átviteli sebessége
54
Táblázatok jegyzéke 4.3.1. táblázat Redundancia értékek 5.1.1. táblázat Késleltetés hatása egy küldő-fogadó pár esetén (eredmények) 5.1.2. táblázat Késleltetés hatása egy küldő-fogadó pár esetén (eredmény) 5.1.3.
táblázat
0,1%-os
csomagvesztés
mellett
késleltetés
változtatás
(eredmények) 5.2.1. táblázat Két küldő-fogadó párnál a késleltetés hatása (eredmények)
55
Irodalomjegyzék [1]
Information Sciences Institute University of Southern California: Transmission Control Protcol, RFC 793, 1981 september
[2]
Information Sciences Institute University of Southern California: Internet Protcol, RFC 791,1981 september
[3]
Róbert Sajtos: Emulab környezet megismerése, ismerkedés TCP torlódásszabályozási algoritmusokkal, mérések végzése, Önálló laboratórium beszámoló, 2012
[4]
Mark Allman, Vern Paxson, W. Richard Stevens: TCP Congestion Control, RFC 2581, 1999.april
[5]
Lawrence S. Brakmo, Larry L. Peterson: TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communications Vol. 13. NO 8. 1995 october
[6]
Cheng Jin, David X. Wei, Steven H. Low: FAST TCP: Motivation, Architecture, Algorithms, Performance, . IEEE/ACM Trans. on Networking Vol.:14 Issue 6, 2006
[7]
Ryan King, Richard Baraniuk, Rudolf Riedi: TCP-Africa: An Adaptive and Fair Rapid Increase Rule for Scalable TCP, Proceedings of IEEE INFOCOM 2005, Miami, FL, 2005 march
[8]
W. Richard Stevens: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, 1997 january
[9]
Lisong Xu, Khaled Harfoush, Injong Rhee: Binary Increase Congestion Control for Fast, Long Distance Networks, Proceedings of IEEE INFOCOM 2004, pp. 25142524, HongKong, 2004
[10] Lisong Xu, Injong Rhee: CUBIC: A New TCP-Friendly High-Speed TCP Variant, ACM SIGOPS Operating Systems Review Volume 42 Issue 5 Pages 64-74, 2008 july [11] Sally Floyd: HighSpeed TCP for Large Congestion Windows, RFC 3649, 2003 december [12] Tom Kelly: Scalable TCP: Improving Performance in Highspeed Wide Area Networks, ACM SIGCOMM Computer Communication Review, 2003 april [13] Kun Tan, Jingmin Song, Qian Zhang Murari Sridharan: A Compound TCP Approach for High-speed and Long Distance Networks, 2005 july [14] Shao Liu, Tamer Basar, Rayadurgam Srikant: TCP-Illinois: A Loss and DelayBased Congestion Control Algorithm for High-Speed Networks, 2008 june 56
[15] Aaron Falk, Yuri Pryadkin, Dina Katabi: Specification for the Explicit Control Protocol (XCP), 2006. november 5 [16] Saverio Mascolo, Claudio Casetti, Mario Gerla, S.S. Lee, M. Yahya Sanadidi: TCP Westwood: congestion control with faster recovery, UCLA CSD Technical Report #200017, 2000 october [17] Luigi. A. Grieco, Saverio Mascolo: Performance evaluation and comparison of Westwood+, New Reno and Vegas TCP congestion control, ACM Computer Communication Review, 2004. april [18] Kevin Fall, Sally Floyd: Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, 1996 july [19] CODDICTED:TCP Congestion control algorithm: http://coddicted.com/tcpcongestion-control-algorithm/ (Valid 2013.12.03) [20] Szilárd Solymos: Torlódásszabályozás nélküli transzport protokoll kutatása, Tudomyányos Diákköri Konferencia, 2010 [21] Szilárd Solymos: Robusztus, torlódásszabályozás nélküli transzport protokoll tervezése és fejlesztése, szakdolgozat, 2011 [22] EMULAB: Emulab Homepage:http://emulab.net/ (Valid 2013.12.03) [23] Paul Meeneghan, Declan Delaney: An Introduction to NS, Nam and OTcl scripting 2004-2005 [24] Marta Carbone, Luigi Rizzo: Dummynet Revisited, 2009 november 30 [25] FreeBSD: Man Pages ipfw, http://www.freebsd.org/cgi/man.cgi?query=ipfw&manpath=FreeBSD+9current&format=html (Valid 2013.12.03) [26] Jon C.R. Bennett and Hui Zhang: WF2Q: Worst-case Fair Weighted Fair Queueing, INFOCOM'96, Mar, 1996. [27] Sándor Molnár, Zoltán Móczár, András Temesváry, Balázs Sonkoly, Szilárd Solymos, Tamás Csicsics: Data Transfer Paradigms for Future Networks: Fountain Coding or Congestion Control?, IFIP NETWORKING 2013, New York, USA, 22-24 May, 2013. [28] BME-TMIT HSNLab: Digital Fountain based Communication Protocol (DFCP) Research: http://sb.tmit.bme.hu/mediawiki/index.php/TransportProtocols (Valid 2013.12.03)
57
