Torlódásvezérlés nélküli transzport protokoll teljesítményelemzése Emulab hálózatemulációs környezetben

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék

Torlódásvezérlés nélküli transzport protokoll teljesítményelemzése Emulab hálózatemulációs környezetben Szakdolgozat

Készítette

Konzulensek

Zóber Gábor

Dr. Sonkoly Balázs adj. Móczár Zoltán

2012. december 16.

Tartalomjegyzék Kivonat

4

Abstract

5

1. Bevezetés

6

2. Nagysebességű transzport protokollok

8

2.1. TCP: Transzport protokoll torlódásvezérléssel . . . . . . . . . . . . . . . . .

8

2.1.1. TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.1.2. BIC TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3. CUBIC TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. DFCP: Torlódásvezérlés nélküli transzport protokoll . . . . . . . . . . . . . 12 2.2.1. A DFCP működése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. A működést befolyásoló paraméterek . . . . . . . . . . . . . . . . . . 14 3. Emulab hálózatemulációs környezet

16

3.1. Az Emulab működése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Példák topológia megadására . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1. Első példa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2. Második példa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.3. Harmadik példa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4. A tesztkörnyezet kialakítása és a mérések megtervezése

22

4.1. Célkitűzések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. A tesztkörnyezet kialakítása . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Mérési forgatókönyvek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. Egy küldő-fogadó pár változó késleltetéssel . . . . . . . . . . . . . . . 24 4.3.2. Egy küldő-fogadó pár változó csomagveszteséggel . . . . . . . . . . . 25 4.3.3. Dumbbell topológia két küldő-fogadó pár esetén . . . . . . . . . . . . 25 4.3.4. Parking lot topológia három küldő-fogadó pár esetén . . . . . . . . . 25 4.4. Felhasznált eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.1. A protokollok tesztelésére használt forgalomgeneráló alkalmazások . 26 4.4.2. A számítógépek hardvertulajdonságai . . . . . . . . . . . . . . . . . 30 4.4.3. Az ipfw és Dummynet alkalmazások . . . . . . . . . . . . . . . . . . 30

1

5. Mérési eredmények

33

5.1. Egy küldő-fogadó pár . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1. A csomagveszteség hatásának vizsgálata . . . . . . . . . . . . . . . . 34 5.1.2. A késleltetés hatásának vizsgálata

. . . . . . . . . . . . . . . . . . . 35

5.2. Két küldő-fogadó pár . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Három küldő-fogadó pár . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.1. Első eset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.3.2. Második eset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6. Összefoglalás

47

Ábrák jegyzéke

49

Táblázatok jegyzéke

50

Irodalomjegyzék

52

2

HALLGATÓI NYILATKOZAT Alulírott Zóber Gábor, 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 autentikált 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é.

Budapest, 2012. december 16.

Zóber Gábor hallgató

Kivonat A TCP (Transmission Control Protocol) az Internet születése óta a legelterjedtebb szállítási rétegbeli protokoll. Mivel a TCP különböző verziói által használt szabályozási elv, a torlódásvezérlés nem képes minden hálózati feltétel mellett hatékonyan működni, így a jövőre nézve fontos feladat egy olyan megoldás kidolgozása, ami képes az Internet változó követelményeinek megfelelni. Egy lehetséges alternatívát jelent egy olyan új protokoll kifejlesztése, amely nem alkalmaz torlódásvezérlést, helyette hatékony hibajavító kódolás segítségével biztosítja a megbízható átvitelt. Dolgozatomban egy ilyen elven működő, jelenleg még fejlesztés alatt álló transzport protokoll, a DFCP (Digital Fountain based Communication Protocol) teljesítményelemzésével foglalkozom. A vizsgálatot az Emulab hálózatemulációs környezet segítségével végeztem el, ami egy kutatási és tesztelési célokra kialakított hálózati környezet. A DFCP viselkedését különböző topológiákon, illetve hálózati paraméterek mellett tanulmányoztam, majd összehasonlítottam két széles körben használt TCP verzióval, a TCP Reno-val és a CUBIC TCP-vel. A mérési eredmények azt mutatják, hogy a DFCP alkalmas a TCP esetén felvetődő problémák megoldására és így alternatívát nyújthat a jövő transzport protokolljára, mivel képes olyan helyzetekben is optimális teljesítményt elérni, amelyekben a TCP nem.

4

Abstract Since the beginning of the Internet, Transmission Control Protocol (TCP) is the most widely used transport layer protocol. Looking at the future, it is important to have a solution for the problems caused by TCP’s congestion control, which cannot work optimally under certain network conditions. A possible solution is to develop a new transport protocol that uses efficient erasure coding instead of congestion control to overcome packet loss. In my paper I give an analysis of such a protocol still under development, named Digital Fountain based Communication Protocol (DFCP). The analysis was done using the Emulab network testbed, which allows researchers to create arbitrary network topologies for testing purposes. To compare the performance and behavior of DFCP, TCP Reno and CUBIC TCP, different network scenarios were used. The results of the analysis show that DFCP is a good candidate for solving the problems addressed by TCP, and also that DFCP is able to give an alternative for a future transport protocol, since its ability to work optimally under conditions where TCP cannot.

5

1. fejezet

Bevezetés A TCP (Transmission Control Protocol) a TCP/IP protokollkészlet egyik fontos összetevője és egyben az egyik fő szállítási rétegbeli protokoll az UDP (User Datagram Protocol) mellett. A TCP megbízható, sorrendhelyes adatátvitelt biztosít két hálózaton elhelyezkedő számítógép és a rajtuk futó alkalmazások között. Ezzel szemben az UDP nem garantál megbízható átvitelt, elsősorban médiafolyamok (pl. hang, videó) továbbítására használják. Az 1970-es években megjelent TCP az akkori igényeknek teljesen megfelelt és sok különböző verzióját dolgozták ki az évek során. Az egyes TCP verziók eltérő hálózati körülmények esetén képesek a többi verziónál jobb teljesítményt nyújtani. A hálózati körülmények befolyásoló tényezői például a sávszélesség, késleltetés, csomagveszteség és a szállítási közeg is. Ez utóbbi napjainkban kiemelt szerepet kap a vezeték nélküli hálózatok egyre szélesebb körű alkalmazása miatt. A vezeték nélküli hálózatok esetén különösen fontos a hatékony átvitel, mivel több olyan probléma vetődik fel használatukkal, ami a hagyományos, vezetékes hálózatok esetén nem jelentkezik. A kifejlesztett különféle TCP verziók problémája, hogy egyik sem képes minden hálózati körülmény esetén optimális működésre, és ezen verziók nem képesek hatékony együttműködésre. Bár a TCP által használt fő szabályozási mechanizmus, a torlódásvezérlés sok esetben képes hatékony adatátvitel biztosítására, komoly kihívást jelent eltérő késleltetési értékek esetén az igazságos adatátvitel biztosítása és a csomagvesztéskor fellépő drasztikus teljesítményromlás, amely problémákat a TCP ezidáig nem tudott megoldani. A TCP használata során felmerülő problémák miatt szükség van egy olyan protokollra, ami képes minden esetben igazságos működésre és jobban ellenáll a csomagvesztésnek. A szakdolgozatom témája egy olyan új transzport protokoll vizsgálata, amely a TCP által használt torlódásvezérlés helyett hatékony hibajavító kódolás segítségével oldja meg a torlódás során fellépő csomagvesztés problémáját, miközben a végpontokon maximális sebességgel történik az adatküldés. Ez az új transzport protokoll, a DFCP (Digital Fountain based Communication Protocol), torlódásvezérlés használata nélkül oldja meg a felmerülő problémákat. Munkám során megvizsgáltam a DFCP protokollt különböző hálózati körülmények között és összehasonlítottam két fontos TCP verzióval, a TCP Reno-val és a CUBIC TCP-vel. A bevezető után ismertetem a TCP protokoll működési mechanizmusát, majd néhány

6

fontos TCP implementáció sajátosságait és a velük kapcsolatban felmerülő problémákat. Ezután bemutatom a DFCP protokoll által használt alapelveket és működésének főbb fázisait, valamint az azokat befolyásoló fontosabb paramétereket. Ezután kitérek az Emulab hálózatemulációs környezet ismertetésére, amelynek használatával elvégeztem a protokollok vizsgálatát különféle hálózati topológiákon, változó paraméterek mellett. Ennek során bemutatom az Emulab működését, a topológiák, kísérletek létrehozásának módját, a topológiához tartozó számítógépekkel történő interakciót és egyéb használati sajátosságot. Ezt követően ismertetem a mérések, vizsgálatok célkitűzését, a tesztkörnyezet kialakításának lépéseit és az alkalmazott operációs rendszerek felkészítését a mérések elvégzésére, majd kitérek a feladat megoldásához szükséges programok, alkalmazások alapvető használatára. Ezután bemutatom az elvégzett méréseket, az eredményeket ábrák segítségével tárgyalom, a pontos vizsgálati számértékeket pedig táblázatos formában is megadom. Végül összefoglalom az elvégzett munkát és értékelem az eredményeket.

7

2. fejezet

Nagysebességű transzport protokollok 2.1. TCP: Transzport protokoll torlódásvezérléssel A TCP (Transmission Control Protocol) [3], [12], [15] az Internet forgalmának torlódásvezérlésére évtizedek óta használt egyik legfontosabb szállítási rétegbeli protokoll (OSI 4. réteg), ami két végpont között megbízható és sorrendhelyes átvitelt biztosít. A torlódásvezérlést a kiküldött szegmensekre érkező nyugták alapján végzi el, így a hálózatot és a fogadó felet is megóvja a túlterheléstől illetve a csomagvesztéstől. További feladata, hogy a torlódásvezérlést oly módon végezze el, hogy közben a hálózat erőforrásai igazságos módon legyenek megosztva a felhasználók között, ezt fairness tulajdonságnak hívják. A TCP az évek során sok módosításon esett át, több TCP verzió is megjelent, mivel az Internet fejlődése, forgalmának változása egyre újabb kihívások elé állította és állítja még napjainkban is, mivel a különféle hálózati sajátosságok különböző torlódásvezérlési módszereket igényelnek. Ezen TCP verziók több csoportba sorolhatók. Vannak csomagvesztés alapú, késleltetés alapú, mérés alapú, hibrid illetve explicit torlódásvezérlési algoritmust alkalmazó verziók. A csomagvesztés alapú módszerek nem tesznek lehetővé kifinomult torlódásvezérlést, mivel ekkor csupán egy egy-bites információ jelzi, hogy van-e csomagvesztés vagy nincs. Csomagvesztés alapú módszert alkalmaz például a TCP Reno [14], a BIC TCP (Binary Increase Congestion control TCP) [10] és a CUBIC TCP [8]. A késleltetés alapú módszerek az összeköttetés körülfordulási idejét (RTT, Round-Trip Time) becsülik meg és ez alapján a sorbanállási időt szabályozzák. Késleltetés alapú módszert alkalmaz például a FAST TCP [5]. A hibrid módszerek a csomagvesztés és a késleltetés alapú módszereket ötvözik, ilyen például a Compound TCP [9]. A mérés alapú módszerek a rendelkezésre álló sávszélességet mérik és ez alapján végzik a torlódásvezérlést, ilyen a TCP Westwood [2]. Léteznek explicit torlódásvezérlési módszerek is, például az XCP (eXplicit Control Protocol) [6], ezek a köztes hálózati eszközök (router-ek) által küldött információk alapján működnek.

8

2.1.1. TCP Reno A TCP Reno a torlódásvezérlést csúszóablakos módszer szerint végzi, ekkor csak a torlódási ablaknak (congestion window) megfelelő mennyiségű nyugtázatlan csomag lehet a hálózatban. A torlódási ablak segítségével az adási sebesség befolyásolható. A torlódási ablak mellett a lassú indítási küszöb is nagy szerepet játszik, ami azt befolyásolja, hogy a torlódásvezérlés lassú indulás (Slow Start) vagy torlódás elkerülés (Congestion Avoidance) fázisban van. A lassú indulás fázisban a torlódási ablak exponenciálisan növekszik egy bizonyos küszöbértékig, vagy amíg csomagvesztés nem történik. Ekkor a torlódás elkerülés fázisba lép, amikor az AIMD (Additive Increase Multiplicative Decrease) algoritmus szerint történik a torlódási ablak szabályozása. Megemlítendő még a gyors újraküldés (Fast Retransmit) mechanizmusa. Ha ugyanarra a csomagra háromszor érkezik nyugta, de van olyan csomag, amire még mindig vár, akkor ebben az esetben megfelezi a torlódási ablak és a lassú indítási küszöb méretét, majd azonnal újraküldi a hiányzó csomagot, ezután pedig átmegy a gyors javítás (Fast Recovery) fázisba. A gyors javítás fázis során megvárja a hiányzó csomag nyugtáját. Ha a gyors javítás fázis lezárult, akkor visszakerül a torlódás elkerülési fázisba. Bevezették továbbá a szelektív nyugtázást (SACK, Selective Acknowledgment), amivel a fogadó fél a nem összefüggő csomag (szegmens) blokkokat is képes nyugtázni, így a burst-ös csomagvesztés javítható. Látható, hogy a TCP Reno a torlódásvezérlést a csomagvesztés mértéke alapján végzi el. A TCP Reno működési fázisai a 2.1. ábrán [3] láthatóak.

2.1. ábra. A TCP Reno működési fázisai

A TCP New Reno [7] a TCP Reno javított változata, ami 2004-ben jelent meg, a gyors újraküldési fázist módosítja azokon a rendszereken, amik nem támogatják a szelektív nyugtázást, ennek köszönhetően a többszörös hibák javítása szelektív nyugtázás nélkül is lehetségessé válik. A TCP Reno és TCP New Reno hiányossága, hogy nem tudja biztosítani a sávszélesség igazságos megosztását abban az esetben, amikor az egyes adatfolyamoknak nagyban különbözik a körülfordulási idejük. Ez az ún. RTT unfairness probléma, amikor a kisebb körülfordulási idővel rendelkező folyam elnyomja a másikat. Ezt a problémát igyekszik megoldani a következő alfejezetekben bemutatott BIC TCP [10] és CUBIC TCP [8]. 9

2.1.2. BIC TCP A BIC TCP az eddigi torlódási ablakot befolyásoló fázisokhoz két újabbat ad, az additív növelést (Additive Increase) és a bináris keresést (Binary Search). Amikor torlódást érzékel, akkor egy meghatározott β szorzótényezővel csökkenti a torlódási ablak méretét. Az algoritmus nyilvántartja azt az ablakméretet, ahol csomagvesztés történt (Wmax ), illetve a csökkentés utáni ablakméretet (Wmin ). A bináris keresés fázis során ezen két érték segítségével az algoritmus megkeresi azt az ablakméret nagyságot, amit a hálózat még csomagveszteség nélkül kezelni tudna, ez Wmax és Wmin átlaga lesz. Ha Wmin és az új érték közti különbség nagyobb, mint egy előre meghatározott Smax konstans, akkor csak Smax -al növeli meg Wmin -t, elkerülve az egy körülfordulási időn belüli túl nagy ablakméret növekedést, tehát a növekedés lineáris. Ha nem történik csomagvesztés, akkor az aktuális ablakméret lesz az új Wmin . Ha csomagvesztés történik, akkor az aktuális ablakméret az új Wmax lesz. Ez a folyamat addig folytatódik, amíg az ablakméret növekedés mértéke már kisebb, mint egy előre meghatározott Smin érték, ekkor az ablakméret a Wmax értéket veszi fel. A növekedési függvény először lineáris, majd logaritmikus, ahogy a 2.2.-es ábra [8] első két szakaszán látszik. Ha az új maximumon túl még mindig nem következik be csomagveszteség, akkor egy új maximum érték keresésére van szükség, ez a harmadik szakasz (Max Probing). Ekkor az előzőekkel ellentétesen először egy lassabb exponenciális növekedés következik be, majd ha ez alatt sem történik csomagveszteség, akkor egy gyorsabb additív növekedésbe kezd az ablakméret.

2.2. ábra. A BIC TCP új működési fázisai

Bár a BIC TCP nagysebességű hálózatokban jó fairness tulajdonságot és skálázhatóságot mutat, alacsony körülfordulási idő vagy alacsony sávszélesség esetén túl agresszív viselkedést eredményez, továbbá a torlódási ablakot befolyásoló mechanizmusok túl összetettek és nehézkessé teszik mind az implementálást, mind a teljesítményelemzést. Érdemes megemlíteni, hogy a BIC TCP a 2.6.8-as Linux kernel verziótól kezdve a 2.6.18-as verzióig alapértelmezett volt. 10

2.1.3. CUBIC TCP A CUBIC TCP a BIC TCP továbbfejlesztett, kevésbé agresszív változata, amiben a torlódási ablak egy kevésbé összetett, köbös függvény szerint változik, így biztosítva nagyobb igazságosságot (fairness) a többi TCP folyammal szemben. A függvény a (2.1) képlet szerint alakul: cwnd = C · (t − K)3 + Wmax

(2.1)

A (2.1) képletben szereplő C egy skálázó konstans, t az utolsó ablakméret q változás óta eltelt idő, Wmax a legutóbbi ablakméret csökkentés előtti ablakméret és K = 3 Wmax · Cβ , ahol β a csomagvesztéskor alkalmazott konstans csökkentő tényező. A 2.3. ábrán [8] jól látszik, hogy a csomagvesztés utáni karakterisztika két jól elkülöníthető részre (konkáv és konvex) oszlik, a kettő között pedig egy állandósult állapot található, ami időt hagy a hálózatnak a stabilizálódásra az újabb sebességnövelés előtt. Látható, hogy először az ablakméret a kezdeti csökkentés után gyorsan növekedni kezd, majd Wmax -ot megközelítve egyre lassul. Wmax -ot elérve a maximumkeresés során megpróbálja kihasználni a további elérhető sávszélességet. A maximumkeresés lassan indul és a Wmax -tól távolodva egyre gyorsul. Ez a lassú növekedés hozzájárul a kapcsolat stabilitásához és növeli a hálózat kihasználtságát, míg a gyors növekedési fázis biztosítja a jó skálázhatóságot. A köbös függvény fairness-t biztosít több CUBIC TCP folyam együttes átvitele esetén.

2.3. ábra. A CUBIC TCP ablaknövelése

Köszönhetően annak, hogy a torlódási ablak növelése nagyban függ a t időparamétertől, jó RTT fairness tulajdonsággal bír, hiszen a különböző körülfordulási idővel rendelkező versengő adatfolyamok ugyanazt a t paramétert fogják használni csomagvesztés esetén, így a torlódásvezérlés a körülfordulási időtől független. A CUBIC TCP a Linux rendszereken a 2.6.19-es kernel óta (2006) az alapértelmezett torlódásvezérlési algoritmus.

11

2.2. DFCP: Torlódásvezérlés nélküli transzport protokoll Bár a TCP első megjelenése óta több verzió is született különféle torlódásvezérlési megoldásokkal, még sincs olyan változat, ami az Internet heterogén volta miatt minden esetben optimális torlódásvezérlést és így megfelelő működést tudna elérni. A különféle TCP változatok további hibája, hogy nem képesek valódi inter-protokoll fairness-t megvalósítani [15], azaz versenyhelyzetben az eltérő torlódásvezérlési megoldásokat alkalmazó TCP folyamok igazságtalanul osztják meg a rendelkezésre álló sávszélességet, kiéheztetik egymást. Ezen problémákat kísérli meg megoldani a DFCP (Digital Fountain based Communication Protocol) protokoll [12], ami egy olyan új, még fejlesztés alatt álló protokoll, amely egyáltalán nem használ torlódásvezérlést, helyette hibajavító kódolás alkalmazásával védekezik az átvitel során fellépő csomagvesztés ellen. A következőkben bemutatom a DFCP protokoll alapvető működését és a működést befolyásoló fontosabb paramétereit.

2.2.1. A DFCP működése A protokoll működésének alapelve, hogy egy adott adatfolyam esetén a végpontok az elérhető maximális sebességgel küldik az adatokat, eközben torlódás léphet fel, melynek során csomós jellegű csomagvesztés következik be. A csomagvesztés javítása a TCP esetében alkalmazott újraküldés helyett hatékony hibajavító kódolás segítségével történik. A kódolás az ún. Raptor kódolással történik, ami a szökőkút kódolók egy implementációja. A szökőkút kódolók egy adott hosszúságú információból végtelen hosszú kódolt szimbólumokból álló folyamot állítanak elő. A Raptor kódolás előnye, hogy lineáris idejű kódolást és dekódolást tesz lehetővé, miközben olyan végtelen hosszú kódolt szimbólumfolyamot állít elő egy k szimbólumból álló üzenetből, aminek bármely d(1 + ) · ke ( > 0) méretű részéből nagy valószínűséggel visszaállítható lesz az eredeti információ. A Raptor kódolás további előnyös tulajdonsága, hogy a kódoláshoz és dekódoláshoz olyan egyszerű műveletek elvégzésére van szükség, mint a szimbólumok másolása vagy a kizáró vagy művelet. Mivel a maximális adatküldés miatt az egyes versengő adatfolyamok eltérő sávszélességhez jutnának, az igazságosság biztosítását fair ütemezés oldja meg. A működés néhány főbb fázisra osztható fel. Először a kapcsolat felépítésre van szükség az adó és a vevő között, ezután következhet az adatok küldése. A kapcsolatfelépítés során előre meghatározott méretű tárolók kerülnek lefoglalásra az operációs rendszerben, amik felhasználhatóak lesznek az adatok küldésére és fogadására. A küldendő adat ezekbe a tárolókba kerül és ezeken az adatokon történik kódolás. Az egyszerre kódolandó adatmennyiség (blokk) előre meghatározott. A vevő oldal először megvárja, hogy egy blokk dekódolásához elegendő mennyiségű adat érkezzen, majd dekódolja és sikeres dekódolás esetén nyugtát küld az adónak. Az adó ekkor kiküldheti a következő blokkot. Ha már nincs több küldendő blokk, akkor a kapcsolat bontása következik. A következőkben röviden ismertetem a protokoll működési fázisait, bővebb információ a [12]-ban olvasható.

12

Kapcsolatfelépítés A kapcsolat felépítése három lépésből áll. Az első lépés során a kezdeményező oldal kiküld egy SYN szegmenst, melynek fejlécébe a dekódoláshoz szükséges információkat helyez el, majd SYN_SENT állapotba kerül. Ekkor elindul egy időzítő, melynek lejártakor a szegmenst elveszettnek ítéli és újraküldi legfeljebb öt alkalommal. Ha az időzítő nem jár le, vagyis érkezett válasz a másik oldalról, akkor a második lépés következik. Ekkor a vevő SYN_RECV állapotba kerül és SYNACK szegmenst küld a kapcsolatot kezdeményező oldalnak, szintén a dekódoláshoz szükséges információkkal. Az első lépéshez hasonlóan egy időzítő segítségével legfeljebb öt újraküldés történik ebben az esetben is. Az ötödik sikertelen próbálkozás után a kapcsolatfelépítési folyamat megszakad mindkét esetben és az erőforrások felszabadulnak. A harmadik lépés során a két fél ACK szegmenst küld egymásnak, majd ESTABLISHED állapotba kerülnek. Kódolás A kódolás a már említett Raptor kódolás segítségével történik. Ez két részből áll, egy előkódolásból, vagyis LDPC (Low-Density Parity-Check) kódolásból, és egy LT kódolásból. Az LDPC kódolás során a küldendő k bájt (egy szimbólum egy bájt méretű) mennyiségű adatból n bájt adat képződik, ahol n > k, mivel a sikeres dekódoláshoz az eredeti adatmennyiséghez megfelelő mennyiségű redundáns bájt hozzáadása szükséges. A redundancia mértéke 2000 bájt. Az ekkor megkapott n bájtból ezután az LT kódolással egyetlen kódolt bájt keletkezik és a kódolás ismételt alkalmazásával tetszőleges hosszúságú kimenet kapható. Adatküldés Az adatküldés során a kapcsolatfelépítéskor lefoglalt tárolók tartalma kerül kiküldésre. A küldés csúszóablakos megoldással történik, így egy adott számú blokk küldése lehetséges nyugtára várakozás nélkül. Az ablak a használt tárolókból áll, maximális mérete az összes tároló száma. Egy adott blokk a kódolás után azonnal kiküldésre kerül. Egy blokk küldése addig tart, amíg a dekódoláshoz elegendő mennyiségű csomag kiküldésre nem került. Egy csomag 1420 bájt LT-kódolt adatot tartalmaz és alapértelmezett redundancia beállítással 49 csomag keletkezik, így egy blokk esetén 69580 kódolt bájt kerül elküldésre. Ha ezután nem érkezik nyugta a vevő oldaltól, akkor várakozás történik, ha pedig egy blokkra vonatkozóan nyugta érkezik, akkor a blokkhoz rendelt tárolók felszabadulnak és újabb adatok tárolására lesznek felhasználhatóak. Adatfogadás A vevő oldal szintén egy adott blokkhoz hozzárendelt tárolókat használ a beérkező csomagok feldolgozására. Ha beérkezik egy csomag, akkor először a csomag fejléce alapján meghatározásra kerül, hogy melyik blokkhoz tartozik, majd megtörténik a hozzárendelése a megfelelő tárolóhoz, ami lehet egy már másik csomaghoz hozzárendelt tároló, vagy egy

13

szabad tároló. Ha nincs szabad tároló, akkor a beérkezett csomag eldobásra kerül. Amennyiben egy blokk esetén már megérkezett a szükséges mennyiségű csomag, akkor elindulhat a dekódolás. Dekódolás A dekódolás során a kódolással fordított sorrendben először az LT dekódolás, majd az LDPC dekódolás következik. A dekódolási folyamat addig fut, amíg minden bájt visszaállítása meg nem történik. Ha a dekódoláshoz nincs elég beérkezett információ, akkor a folyamat szintén leáll. Sikeres dekódolás esetén az adott blokkról a fogadó oldal nyugtát küld a küldő oldalnak, hogy felszabadíthassa a blokkhoz tartozó tárolóit, majd a fogadó oldal továbbítja a dekódolt adatot a felhasználói alkalmazásnak. Ezután a fogadó oldal is felszabadítja a tárolóit. Sikertelen dekódolás esetén szintén nyugtát küld, mivel a küldő oldal így tudja csak felszabadítani a tárolóit. Kapcsolatbontás Az utolsó fázis a kapcsolat bontása. Az első lépésben a kapcsolatbontást kezdeményező oldal FIN szegmenst küld a másik oldalnak, amely erről nyugtát küld, a küldő oldal pedig FIN_WAIT1 állapotba kerül. A kapcsolatfelépítéshez hasonlóan itt is az időzítő lejárta után újraküldés történik legfeljebb öt alkalommal. A második lépésben a másik oldal a nyugta elküldése után CLOSE_WAIT állapotba, a kapcsolatbontást kezdeményező oldal pedig FIN_WAIT2 állapotba kerül. Ha a másik oldal is bontaná a kapcsolatot, akkor FINACK szegmenst küld és LAST_ACK állapotba kerül. A kezdeményező oldal ismét ACK szegmenssel nyugtáz, majd TIME_WAIT állapotba kerül, ekkor bizonyos idő elteltével az erőforrások felszabadulnak, a másik oldal pedig CLOSE állapotba kerül és szintén felszabadítja az erőforrásokat.

2.2.2. A működést befolyásoló paraméterek A protokoll működését öt fontos paraméter befolyásolja, amik a tesztelésre használt alkalmazással egyszerűen beállíthatóak. Az első paraméter a maximális ablakméret. Ezzel szabályozható az operációs rendszer által lefoglalt küldési és vételi tárolók száma. A második paraméter a redundancia, amivel meghatározható a blokkok küldése esetén használt határérték. Ennek segítségével megadható, hogy hány csomagot küldjön blokkonként. Ez a paraméter azért fontos, mert csomagvesztés esetén megfelelő mennyiségű redundanciát kell a küldésbe vinni a blokkok sikeres dekódolásához. A paraméter alapértelmezett értéke 49 csomag. A harmadik paraméterrel a nyugtázás kapcsolható ki vagy be. Ekkor az adatküldés sebessége még tovább növelhető, mivel az adó a blokk kiküldése után azonnal felszabadítja a tárolót és nem vár nyugtára, így azonban már nem véd semmi a túlzott adási sebességtől, ami csomagvesztéshez vezethet. A negyedik paraméterrel a kódolás kapcsolható ki. A kódolás kikapcsolása esetén csak 14

az első blokk kerül kódolásra, majd eltárolásra, az ezután küldött blokkok tartalmukat tekintve az elsővel lesznek azonosak. Ennek segítségével vizsgálható a kódolás hatása a protokoll teljesítményére. Az ötödik paraméterrel a dekódolás kapcsolható ki. Ekkor a beérkező csomag tartalma helyett csak a beérkezett adatmennyiség kerül tárolásra. Ezzel a paraméterrel vizsgálható a dekódolás hatása a protokoll teljesítményére. Az elvégzett mérések során minden esetben bekapcsolt nyugtázást, kikapcsolt kódolást és dekódolást használtam. A következő fejezetben ismertetem a tesztkörnyezetet, amelyben a DFCP és TCP protokollok teljesítményét, viselkedését vizsgáltam különféle hálózati paraméterek mellett.

15

3. fejezet

Emulab hálózatemulációs környezet Az Emulab [13] egy hálózati tesztkörnyezet, ami lehetőséget biztosít egyszerűbb, vagy akár egészen összetett hálózatok kiépítésére hálózatfejlesztési és kutatási célokra. Világszerte több tesztkörnyezet is kiépült, az első az Egyesült Államokban a University of Utah egyetemen, de később a világ számos részén létrehoztak ehhez hasonló tesztkörnyezeteket elsősorban Észak-Amerikában, Európában és a Távol-Keleten. A továbbiakban a University of Utah tesztkörnyezetét ismertetem, a munkám során ezen dolgoztam. A tesztkörnyezetben közel 600 darab számítógép áll a felhasználók rendelkezésére különböző hardvertulajdonsággal. Többségében 2-8 magos processzorral, 1-12 GB memóriával és 4-6 darab hálózati interfésszel, amik 100 Megabitesek vagy Gigabitesek, ezen kívül a közelmúltban váltak elérhetővé 10 Gigabites interfésszel rendelkező számítógépek is. Lehetőség van vezeték nélküli interfésszel rendelkező számítógépek használatára is. Ezen számítógépek mindegyike négy vagy több interfésszel kapcsolódik nagy teljesítményű switch-ekhez (Cisco, HP, Arista), amely interfészek a felhasználók számára elérhetőek és használhatóak (kísérleti interfészek), ezen felül egy külön interfész kapcsolódik a szerverekhez biztosítva a kísérletek közbeni zavartalan adatátvitelt. A tesztkörnyezet pontos fizikai topológiája a 3.1. ábrán [13] látható. A használható számítógépek (node-ok) száma függ attól, hogy hány számítógép van pillanatnyilag szabadon a rendszerben, illetve attól, hogy a projekt, amihez a felhasználó tartozik, milyen határt szab ennek. A tesztkörnyezet számítógépein többféle operációs rendszer használható, közülük sok azonnal elérhető, ezek különböző Linux disztribúciók (főleg Red Hat Linux és Ubuntu), FreeBSD illetve Windows XP és Windows 7. Ezen kívül az operációs rendszer konfigurálása és a szükséges csomagok, alkalmazások telepítése után a futó rendszert le lehet menteni egy egyedi névvel ellátott képfájlba és később bármikor használható lesz egy új kísérletben az új node-okon, így az esetlegesen hosszadalmas konfigurálási idő nagyban csökkenthető, mivel a kísérlet leállítása után a node-okon és az azokon futó operációs rendszereken elvégzett módosítások elvesznek.

16

3.1. ábra. A tesztkörnyezet fizikai topológiája

3.1. Az Emulab működése A tesztkörnyezetben egy kísérlet a következő életciklust futhatja be: először a kísérlet létrehozása (névvel ellátása, a topológia és egyéb paraméterek megadása egy Network Simulator [1], azaz NS fájl feltöltésével), ezután a rendszer betölti és aktiválja a kísérletet (swap in), melynek során lefoglalja a szükséges számú node-ot, majd ezután lefut a Linktest alkalmazás, ami ellenőrzi hogy a létrehozott kapcsolatok valóban úgy működnek-e, ahogy azokat specifikáltuk. A Linktest több szinten futtatható (level 1–4), az első szinten ellenőrzi, hogy a linkek két oldalán elhelyezkedő node-ok elérik-e egymást és vizsgálja a késleltetést is. A második szinten ellenőrzi, hogy a node-ok elérik-e az összes többi node-ot, ami részt vesz a kísérletben. A harmadik szinten csomagveszteséget, majd a negyediken sávszélességet vizsgál. A Linktest a tesztek lefutása után naplózza az eredményt. Ezután a felhasználó szabadon rendelkezik a kísérleti node-okkal, majd miután végzett, a kísérletet deaktiválhatja (swap out). Ekkor a kísérlet a swapped out állapotot veszi fel, de a kísérlet beállításait a rendszer elmenti, így legközelebb már nem szükséges újra keresztülmenni a létrehozási procedúrán, csak aktiválni kell azt. A munkának korlátot szab, hogy legfeljebb 120 óráig maradhat betöltve egy kísérlet, de ha a kísérleti hálózaton két órán keresztül (idle time) nem folyik forgalom, vagy a node-okhoz nem történik hozzáférés, akkor a rendszer automatikusan deaktiválja azt. Egy új kísérlet létrehozásakor a hálózat topológiáját szövegesen, NS szintaxisban lehet megadni, ekkor kell meghatározni a felhasznált node-ok számát, a rajtuk futtatott operációs rendszert, a node-ok közti kapcsolatokat, a kapcsolatok hálózati paramétereit

17

(sávszélesség, késleltetés, csomagveszteség) és más egyéb beállítást. Arra is lehetőség van, hogy egy meglévő, már létrehozott kísérlet topológiáján utólag változtassunk, azaz, hogy módosítsuk a már betöltött NS fájlt, ezzel kihagyható az esetlegesen hosszúra nyúló swap in folyamat, ha csak kisebb változtatás történik a topológián. Egy kísérlet típusa kétféle lehet, hagyományos vagy batch. Az előbbi esetében az aktiválás a felhasználó utasítására történik függetlenül attól, hogy a rendszerben van-e elég szabad node az aktiváláshoz, így az aktiválás nem feltétlenül lesz sikeres, lehetséges, hogy erőforráshiány miatt nem történik meg. Batch módban azonban a rendszer automatikusan aktiválja a kísérletet, ha elegendő erőforrás van szabadon hozzá, ebben az esetben azonban az idle time alapértelmezetten sokkal rövidebb, csupán 15 perc, de ez módosítható. További korlátozás, hogy egy felhasználó egy batch módú kísérletet használhat egyszerre. Ha a kísérlet aktiválódik, deaktiválódik, a felhasználó módosítja azt, esetleg valamilyen hiba miatt (pl. erőforráshiány) nem fut le az aktiválás, akkor a rendszer automatizált emailben üzenetet küld a felhasználónak. Ha a kísérlet létrejött és aktív, akkor a kísérlet webes felületén több hasznos információhoz hozzájuthatunk, ilyen a node-ok kísérleti IP-címe (pl. 10.1.1.2 ), a felhasznált számítógépek fizikai azonosítója (pl. pc266 ), kísérleti azonosítója (pl. node1 ) és a cím, amin a node-ot távolról elérhetjük (pl. node1.kiserletNev.projectNev.emulab.net). A felületen megnézhetjük a létrehozott topológiát vizuálisan is egy ábrán, ez segíthet abban, hogy gyorsan kiderítsük megfelel-e a kísérleti topológia az elvárásainknak. A felületen egyéb olyan (alapvető) információk is megtalálhatók, mint például a kísérlet neve, rövid leírása, projekt- és csoport tagság, létrehozó, a létrehozás ideje, a legutóbbi módosítás ideje, aktuális állapot stb. A távoli elérési cím segítségével kapcsolódhatunk a node-okhoz SSH-n, vagy Remote Desktop Connection segítségével. A tesztkörnyezetben a felhasználók kapcsolódhatnak egy, a kísérletektől független közös számítógéphez is, ez minden tesztkörnyezetbeli számítógéphez soros interfésszel kapcsolódik, így ennek használatával a node-okat elérhetjük Telnet-en keresztül is. Ez a lehetőség különösen hasznos lehet, ha a felhasználó egy rosszul sikerült konfiguráció során kizárja magát egy node-ról, de ezen kívül érthető okokból a Telnet használata nem javasolt. Fontos, hogy a kísérlet aktiválása során a topológiától függően egy vagy több VLAN-t hoz létre a rendszer, így biztosítva, hogy a kísérletek zavartalanul folyhassanak egymás mellett, és olyan node-ok ne tudják elérni egymást (broadcast üzenetekkel sem), amik nem egy kísérlethez tartoznak. A VLAN-ok alkalmazása különösen előnyös delay node használata esetén, aminek feladata, hogy a link egy vagy több hálózati paraméterének hatását emulálja. Ekkor a delay node két oldalán található link, és így a linkeken elhelyezkedő két node külön VLAN-hoz fog tartozni, így az egyik node felől érkező, és a másik node felé irányuló forgalom mindenképpen a delay node-on kell, hogy keresztülmenjen biztosítva, hogy a forgalom a megfelelő tulajdonságokkal (késleltetés, csomagveszteség, sávszélesség) rendelkezik. Ha a delay node két oldala ugyanazon VLAN-hoz tartozna, akkor a delay node-ot megkerülve közvetlenül elérhetnék egymást, ami nem a kívánt viselkedést eredményezné. Megemlítendő, hogy egyazon kísérlet deaktiválása, majd újra aktiválása során (swap out-swap in) nem feltétlenül lesznek ugyanazok a kiosztott IP címek, és a node-ok közötti 18

kapcsolat nem biztos, hogy ugyanazokon a kísérleti interfészeken keresztül történik akkor sem, ha a topológián nem változtattunk. Lehetőség van azonban arra, hogy tesztkörnyezet specifikus NS parancsokkal előre megadjuk a kívánt IP címeket, netmaszkot és a használni kívánt interfészeket. Egy kísérletben használt kapcsolat (link) a paramétereitől függően lehet ideális vagy nem ideális. Akkor tekinthető ideálisnak, ha nincs sem késleltetés sem csomagveszteség, és a sávszélesség pedig 100 vagy 1000 Mbit/s. Ha ezek közül valamelyik feltétel nem teljesül, akkor a kapcsolat nem ideális és a rendszer a linkre beiktat egy delay node-ot a link két végén elhelyezkedő node közé. Valójában egy nem ideális link esetén két link jön létre, egy az egyik node és a delay node között, valamint egy a másik node és a delay node között. Ez látható a 3.3. ábrán. Ezt a feladatot a delay node-on futó Dummynet [11] alkalmazás végzi el, ami egy hálózati emulációs szoftver, amit elsősorban hálózati protokollok tesztelésére fejlesztettek ki. Működése folyamán a Dummynet a hálózati forgalmat saját objektumaiba (pipe, queue, scheduler) irányítja a létrehozott szabályoknak megfelelően, ezek az objektumok és szabályok képesek befolyásolni a forgalom tulajdonságait. Az objektumok és szabályok megadása az ipfw tűzfalmenedzsment alkalmazással lehetséges. A scheduler, azaz ütemező a következő algoritmusok egyikét használhatja: FIFO, WF2Q+ (Weighted Fair Queueing), RR (Deficit Round Robin), QFQ (Quick Fair Queueing). A delay node-on alapesetben FreeBSD 4.10-es operációs rendszer fut, de mivel ez igen régi, így az operációs rendszer igény esetén pontosan meghatározható. Ha a kapcsolat nem ideális, akkor a delay node automatikusan megjelenik, de lehetőség van a delay node-ot explicit is meghatározni a topológiát leíró NS fájlban. Korlátozó tényező lehet, hogy a delay node csupán egy adott kapcsolat, tehát két node között végez munkát, hiába rendelkezik négy interfésszel. A linkek duplexek, vagyis a rajtuk folyó forgalom mindkét irányba egyszerre halad, simplex link létrehozására nincs lehetőség. Sokszor adódhat azonban olyan helyzet, amikor egy link paramétereinek a különböző irányokban különböző értékeket kell felvenniük, erre a célra használható egy tesztkörnyezet specifikus NS parancs, amivel megadható az irányonkénti késleltetés, csomagveszteség és sávszélesség. Az összes kísérleti node-on (beleértve a delay node-ot) root joggal rendelkezünk, így jogosultságbeli korlátok nincsenek.

3.2. Példák topológia megadására A következőkben bemutatom hogyan adható meg néhány egyszerű topológia.

3.2.1. Első példa Ebben az esetben két node-ot hozok létre, amik egy ideális gigabites linkkel kapcsolódnak egymáshoz. Az ehhez szükséges NS fájl: [1:] set ns [new Simulator] [2:] source tb_compat.tcl

19

[3:] set node0 [$ns node] [4:] set node1 [$ns node] [5:] tb-set-node-os $node0 UBUNTU12-64-STD [6:] tb-set-node-os $node1 UBUNTU12-64-STD [7:] set link0 [$ns duplex-link $node0 $node1 1000Mb 0ms DropTail] [8:] $ns rtproto Static [9:] $ns run Az első két sor a fejléc, itt jön létre az új NS szimulátor és itt töltjük be a tesztkörnyezet specifikus parancsokat tartalmazó TCL fájlt. A harmadik és negyedik sor létrehoz két új node-ot node0 és node1 néven. Az ötödik és hatodik sor specifikálja, hogy ezen node-ok milyen operációs rendszert futtatnak, ami jelen esetben az Ubuntu 12.04 LTS 64-bites verzió. A hetedik sor létrehozza az ideális gigabites duplex linket a két node között. Leolvasható, hogy a link sávszélessége 1000 Megabit/s, a késleltetés 0 ms és a queue típusa DropTail, de lehetőség van DropTail helyett RED (Random Early Detection) vagy GRED (Gentle RED) queue használatára is. A DropTail típusú queue használatakor a queue méret csomagban vagy bájtban megadható, RED vagy GRED használatakor ezen kívül több egyéb paraméter is beállítható. A link csomagvesztesége 0%-os, ez az alapértelmezett érték, de természetesen a megfelelő NS paranccsal ez is beállítható. Az utolsó előtti sor bekapcsolja a node-ok közötti statikus útvonal irányítást, biztosítva, hogy minden node az összes többit elérhesse, majd az utolsó sor elindítja a szimulációt. A létrejött topológia a 3.2. ábrán látható.

3.2. ábra. Első egyszerű topológia

3.2.2. Második példa Ebben az esetben egy nem ideális, gigabites duplex linket hozok létre az előbbi helyett. Itt csak azt a sort közlöm, amiben változás történt az előző esethez képest: [7:] set link0 [$ns duplex-link $node0 $node1 1000Mb 20ms DropTail] Látható, hogy a kapcsolat 20 ms-os késleltetéssel rendelkezik, ekkor a link már nem tekinthető ideálisnak, így a két node közé automatikusan bekerül egy delay node, ami a késleltetés emulálását végzi majd a rajta futó Dummynet alkalmazás segítségével. A létrejött topológia a 3.3. ábrán látható.

20

3.3. ábra. Második egyszerű topológia

3.2.3. Harmadik példa Ebben az esetben a delay node-ot explicit határozom meg, ekkor a következők szerint kell eljárni: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set node0 [$ns node] [4:] set node1 [$ns node] [5:] set nodeDelay [$ns bridge] [6:] tb-set-node-os $node0 UBUNTU12-64-STD [7:] tb-set-node-os $node1 UBUNTU12-64-STD [8:] tb-set-delay-os FBSD83-STD [9:] set link0 [$ns duplex-link $node0 $nodeDelay 1000Mb 5ms DropTail] [10:] set link1 [$ns duplex-link $node1 $nodeDelay 1000Mb 10ms DropTail] [11:] $ns rtproto Static [12:] $ns run Látható, hogy a delay node nem node-ként specifikálandó, hanem bridge-ként. A nyolcadik sor meghatározza a delay node-on futó operációs rendszert. Fontos tudni, hogy ez az összes, kísérletben résztvevő delay node-ra érvényes lesz. A kilencedik és tizedik sorban az eddigi egy link meghatározása helyett két link meghatározására van szükség, az egyik node és a delay node között, illetve a másik node és a delay node között. Ilyen és hasonlóan egyszerű topológia esetében az explicit megadás nem tűnik szükségesnek, de adódhat olyan helyzet, amikor mégis az. A létrejött topológia a 3.4. ábrán látható.

3.4. ábra. Harmadik egyszerű topológia

A következőkben ismertetem a mérésekhez kialakított topológiákat, az elvégzett méréseket, majd értékelem a mérések eredményét. 21

4. fejezet

A tesztkörnyezet kialakítása és a mérések megtervezése 4.1. Célkitűzések A következő fejezetben bemutatott mérések célja, hogy a DFCP protokoll átfogó teljesítményelemzését adják előre megválasztott tulajdonságokkal rendelkező hálózati topológiákon. Feladatom egyfelől a korábban elvégzett teszthálózati mérések eredményeinek validációjára terjedt ki, másfelől lehetőséget teremtett arra, hogy a laboratóriumi körülmények között nehezen kialakítható, összetettebb hálózati topológiák kiépítése később megtörténhessen. A DFCP használatával elvégzett vizsgálatok eredményeit szükséges egyúttal a már meglévő transzport protokollokkal összehasonlítani, ezért a méréseket a napjainkban legelterjedtebb TCP változattal, a CUBIC TCP használatával és bizonyos esetekben TCP Reno-val is elvégeztem. A következő alfejezetekben ismertetem a vizsgálatokhoz kialakított tesztkörnyezetet, a mérési forgatókönyveket és a felhasznált eszközöket.

4.2. A tesztkörnyezet kialakítása Az Emulab környezetben sokféle operációs rendszer használatára nyílik lehetőség. Mivel a tanszéki mérésekhez leginkább hasonló körülményeket igyekeztem megteremteni, ezért nem a legfrissebb Ubuntu 12.04-es operációs rendszert használtam a küldő és fogadó oldali számítógépeken, hanem az Ubuntu 7.04-es operációs rendszert. Az ehhez tartozó alapértelmezett kernel helyett a 2.6.26-2-1.2.5-lab20 számú egyedi kernelt töltöttem be, amely tartalmazta a DFCP implementációját. Az operációs rendszert a már korábban említett módon saját névvel láttam el a későbbi megkönnyített újrafelhasználás érdekében. A rendszeren elvégeztem a DFCP szerver- és kliensoldali tesztprogramok, valamint néhány egyéb alapvető Linux-os alkalmazás telepítését (iperf, mc). A már elérhető alkalmazások közül az ssh és ftp klienseket használtam szükség esetén. A mérések elvégzéséhez szükség volt Dummynet-et futtató számítógépekre is, hogy a megfelelő hálózati paramétereket be lehessen állítani. Ezek a számítógépek vagy delay nodeok voltak, vagy hagyományos node-ok utólag felkészítve a szükséges feladat elvégzésére, de mindkét esetben a FreeBSD 8.3-as operációs rendszert futtattam rajtuk. 22

A következőkben ismertetem a node-okon beállított kernelváltozók és egyéb paraméterek pontos értékét. Ezek megegyeztek a korábbi tanszéki mérések során használt értékekkel. Módosítások az Ubuntu 7.04-es számítógépeken Az egyedi kernel betöltése a /boot/grub/grub.conf és /boot/grub/menu.lst állományok módosításával történt meg. Az állományokban a következő sorokat helyeztem el: title

Ubuntu, kernel 2.6.26-2-1.2.5-lab20

root

(hd0,1)

kernel

/boot/vmlinuz-2.6.26-2-1.2.5-lab20 root=UUID=700bb730-f7eb-4e23$

initrd

/boot/initrd.img-2.6.26-2-1.2.5-lab20

quiet savedefault Ezután a fenti két fájlt, amelyek a kernelt és a boot folyamat során betöltött ideiglenes fájlrendszert tartalmazzák, a megfelelő helyre mozgattam. Kernelváltozók: • 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 • net.core.rmem_default=111616 • net.core.wmem_max=131071 • net.core.rmem_max=131071 A fenti kernelváltozók megadják az alapértelmezett és maximális küldési, illetve fogadási bufferméretet az összes típusú kapcsolat számára, továbbá beállítják a TCP-t használó kapcsolatok minimális, alapértelmezett és maximális küldési, illetve fogadási bufferméretét. A kísérleti interfészek küldési várakozási sorának hosszát (Transmit Queue Length, txqueuelen) 50000 csomagra állítottam be. Módosítások a FreeBSD 8.3-as számítógépeken Kernelváltozók: • net.inet.ip.dummynet.pipe_slot_limit=10000 • net.inet.ip.fw.one_pass=0 Ezen kernelváltozók szükségesek a Dummynet megfelelő használatához. Az első kernelváltozó segítségével megadható a Dummynet által használt queue-k maximálisan beállítható mérete. A második változó beállításával lehetségessé válik, hogy egy adott beérkező, vagy kimenő csomagra egymás után több Dummynet szabályt is alkalmazzunk, ez elengedhetetlen a későbbi dumbbell topológián elvégzett mérésekhez. 23

Az ipfw alkalmazás kezdeti beállításához az /etc/rc.conf állomány módosítása volt szükséges. Ezen állományban elhelyeztem a firewall_enable=’YES’ és firewall_type=’open’ opciókat. Az első opcióval aktiválható az ipfw által menedzselt tűzfal, ami a későbbi Dummynet-es szabályokat is alkalmazza majd. A második opcióval a tűzfal alapértelmezett viselkedése adható meg. Ezután az alkalmazás indítása előtt egyetlen alapértelmezett szabályt adtam meg az /root/ipfw.rules állomány segítségével: ipfw add 65000 allow ip from any to any. Ez a szabálylista végére kerül, az implicit mindent tiltó szabály elé, így a későbbi szabályokra nem érvényes csomagok sem kerülnek eldobásra. Ezután a Dummynet és ipfw alkalmazásmodulok betöltésére volt szükség a kldload dummynet és kldload ipfw parancsok segítségével. Ezen beállítások elvégzése abban az esetben volt szükséges, amikor a Dummynet-et futtató számítógépek nem delay node-ok voltak, mert delay node-ok használatakor az Emulab rendszer automatikusan elvégezte a Dummynet és ipfw alkalmazások alapvető beállításait, így csak a fenti két kernelváltozó értékét kellett megadni. Végül hozzáadtam a mérési forgatókönyveknek megfelelő, topológiafüggő ipfw szabályokat, amelyeket az elvégzett méréseknél fogok ismertetni a topológiák létrehozásához használt NS fájlokkal együtt.

4.3. Mérési forgatókönyvek A mérési forgatókönyvek először egyszerűbb, majd egyre fokozódó bonyolultságú helyzetek elé állítják a vizsgált protokollokat. Kezdetben egy küldő-fogadó pár és egy Dummynet-et futtató node volt összekapcsolva, így vizsgáltam a protokollok teljesítményét változó késleltetés és csomagvesztés értékek mellett. Ezután egy dumbbell topológiát alakítottam ki két küldő-fogadó párral és egy Dummynet-et futtató node-dal, ekkor különböző késleltetés értékek mellett vizsgáltam két versenyhelyzetbeli adatfolyammal a protokollok viselkedését. Végül kialakítottam egy parking lot topológiát három küldő-fogadó párral és azon két eltérő helyzetet vizsgáltam, különböző paraméterhalmazzal, három egymással versengő adatfolyammal. DFCP protokoll vizsgálata esetén a tesztprogram segítségével beállított ablakméret minden esetben 100 csomag volt és az adatok küldése 60 másodpercig tartott, kódolás és dekódolás használata nélkül, nyugtázással. Az igazságos ütemezéshez a dumbbell topológia és a parking lot topológiák esetén WF2Q+ [4] ütemezőt használtam, az egyidejű adatfolyamok közt egyenlő, 50-50%-os súlyokkal. A csomagveszteség és késleltetési paraméterek minden esetben egyirányúak, vagyis a küldő oldal felől a fogadó oldal irányába értendőek.

4.3.1. Egy küldő-fogadó pár változó késleltetéssel A küldő és fogadó oldali node-okat ideális gigabites linkekkel (link0 és link1 ) kapcsoltam össze a Dummynet-et futtató node-dal. A Dummynet segítségével egy 1 Gbit/s sávszélességű emulált linket hoztam létre 0%-os csomagveszteséggel. A protokollok viselkedését változó késleltetés mellett vizsgáltam, így a Dummynet-tel emulált link késleltetését 0, 5, 10, 50 és végül 100 ms-ra változtattam. A kialakított fizikai topológia a 4.1. ábrán látható.

24

4.1. ábra. Fizikai topológia egy küldő-fogadó pár esetén

4.3.2. Egy küldő-fogadó pár változó csomagveszteséggel A node-okat a Dummynet-et futtató node-al összekapcsoló gigabites link0 és link1 linkek ebben az esetben is ideálisak voltak és szintén egy 1 Gbit/s sávszélességű emulált linket hoztam létre a Dummynet segítségével, azonban ekkor a késleltetés minden esetben 0 ms, az egyirányú csomagveszteség pedig 0,1%, 1%, 5%, 10%, majd végül 50% volt. A csomagveszteségeknek megfelelő, kliensoldali tesztalkalmazással beállított redundancia paramétereket a 4.1. táblázat foglalja össze. A kialakított fizikai topológia megegyezik a 4.1. ábrán láthatóval. 4.1. táblázat. Redundancia értékek Csomagveszteség [%] 0,1 1 5 10 50

Redundancia 52 56 62 69 186

4.3.3. Dumbbell topológia két küldő-fogadó pár esetén Ekkor a két küldő-fogadó node párt szintén ideális gigabites linkekkel (link0, link1, link2 és link3 ) kapcsoltam össze a Dummynet-et futtató node-al. Az emulált linkek 1 Gbit/s sávszélességűek voltak, 0%-os csomagveszteséggel. Az adatküldés node0 és node2 között állandó 10 ms-os késleltetéssel történt, eközben pedig node1 és node3 között változó késleltetéssel, kezdetben 0 ms, majd 10 ms-os növekedéssel végül 100 ms-os késleltetéssel. A két adatfolyam egymással versengett az elérhető hálózati erőforrásokért. Az igazságosság biztosításának érdekében a küldő oldalról Dummynet-en áthaladó csomagokat a Dummynet-et futtató node igazságos ütemezéssel küldte tovább a fogadó oldalnak. A kialakított fizikai topológia a 4.2. ábrán látható.

4.3.4. Parking lot topológia három küldő-fogadó pár esetén Ebben az esetben három küldő-fogadó node párt használtam, amiket ideális gigabites linkekkel (link0, link1, link2, link3, link4 és link5 ) kapcsoltam össze a megfelelő Dummynet-es node-okkal. Az első küldő-fogadó pár a node1 -node2, a második a node3 -node4, a harmadik pedig a node0 -node5 pár. A köztük levő adatfolyamokra első rövid folyam, második rövid folyam, illetve hosszú folyam néven fogok később hivatkozni. A kialakított fizikai topológia a 4.3. ábrán tekinthető meg. Látható, hogy két Dummynet-

25

4.2. ábra. Fizikai dumbbell topológia két küldő-fogadó pár esetén

es node került beállításra, Dummynet0 és Dummynet1, köztük egy idális gigabites linkkel (link6 ). A parking lot topológián két különböző esetet vizsgáltam. Első eset Az első esetben a Dummynet0 node által emulált link 1 Gbit/s-os 10 ms egyirányú késleltetéssel és 0%-os csomagveszteséggel. A Dummynet1 által emulált link pedig 500 Mbit/s-os 0–100 ms között változó egyirányú késleltetéssel és 0%-os csomagveszteséggel. Ez esetben tehát az utóbbi link szűk keresztmetszetet (bottleneck) jelent a rajta keresztülmenő adatfolyamoknak. Második eset A második esetben a Dummynet0 node által emulált link szintén 1 Gbit/s-os, 0%-os csomagveszteséggel, azonban ekkor 50 ms egyirányú késleltetést alkalmaztam. A Dummynet1 által emulált link 1 Gbit/s-os 0–100 ms között változó egyirányú késleltetéssel és 0%-os csomagveszteséggel. A dumbbell topológiához hasonlóan mindkét esetben az igazságosság biztosításának érdekében a küldő oldal irányából a Dummynet-en áthaladó csomagokat a Dummynet-et futtató node-ok igazságos ütemezéssel küldték tovább a fogadó oldal irányába.

4.4. Felhasznált eszközök 4.4.1. A protokollok tesztelésére használt forgalomgeneráló alkalmazások A szerver- és kliensoldali alkalmazás C nyelven íródott, konzolból indítható, szöveges formában. Indításkor megadhatók az előző alfejezetben röviden ismertetett paramétereken kívül egyéb paraméterek is. A paraméterek a program futásáig érvényesek, újbóli indítás esetén szükséges újra megadni azokat, ha nem az alapértelmezett értékeket kívánjuk használni. Az alkalmazások segítségével nem csak DFCP protokoll használatával lehet adatot küldeni, hanem TCP Reno-val, vagy CUBIC TCP-vel is, ehhez a megfelelő paraméter megadása szükséges. A tesztalkalmazások a szöveges kimenetre az adatküldés lezárulta után kiírják

26

4.3. ábra. Fizikai parking lot topológia három küldő-fogadó pár esetén

az elért hasznos adatmennyiségre számított átviteli sebességet (goodput) és a küldés alatt eltelt időt. A pontos eredmények alapértelmezett esetben egy CSV állományba kerülnek naplózásra. A szerveroldali alkalmazás lehetséges paraméterei A szerveroldali alkalmazás általam használt verziójában az alábbi kapcsolók használhatók: • -p: A szerver által használt port • -n: Küldendő adatmennyiség (MB) • -w: Ablakméret • -a: Nyugtázás ki vagy bekapcsolása • -e: Kódolás ki vagy bekapcsolása • -d: Dekódolás ki vagy bekapcsolása • -c: A szerver által várt adatfolyam hossza (másodperc) • -z: A használni kívánt TCP verzió • -f: Fájlba naplózás ki vagy bekapcsolása • -k: Konzolra naplózás ki vagy bekapcsolása • -x: Adott idő kihagyása az átvitel elejéről (másodperc) A kliensoldali alkalmazás lehetséges paraméterei A kliensoldali alkalmazás általam használt verziójában az alábbi kapcsolók használhatók: • -s: A szerver IP-címe • -p: A kliens által használt port • -n: Küldendő adatmennyiség (MB) • -w: Ablakméret • -r: Redundancia • -a: Nyugtázás ki vagy bekapcsolása 27

• -e: Kódolás ki vagy bekapcsolása • -m: Maximális tokenszám • -i: Token inkremens • -t: Token generálási intervallum • -b: Sávszélesség korlát nagysága (Kbit/s vagy Mbit/s) • -c: A kliens által küldött adatfolyam hossza (másodperc) • -z: A használni kívánt TCP verzió • -f: Fájlba naplózás ki vagy bekapcsolása • -k: Konzolra naplózás ki vagy bekapcsolása • -x: Adott idő kihagyása az átvitel elejéről (másodperc) Példa adatküldésre DFCP használatával Először a szerveroldali alkalmazást kell indítani a következő paranccsal: ./server3 -p 12345 -c 10 -e 1 -d 1 Ezután a kliensoldali alkalmazást kell indítani: ./client3 -s 10.1.1.3 -p 12345 -c 10 -e 1 -m 0 A szerveroldali alkalmazás szöveges kimenete a következőképpen alakul: Listening.. Logging to logs_20121212054549.csv Accepted client: 10.1.1.2:50635 Transfer duration:

10.0005 seconds

Total: Bandwidth (Throughput): Bandwidth (Goodput):

928.5231 Mbps

820.1447 Mbps

Connection closed. Closing logfile... Listening.. Látható, hogy 10 másodpercig történt küldés kódolás és dekódolás használata nélkül, fájlba naplózással a szerver 12345-ös portján keresztül. Az átbocsátóképesség 929 Mbit/s-ot ért el, ebből a hasznos átviteli sebesség 820 Mbit/s volt. Az adatok fogadásának lezárulta után az alkalmazás várja az esetleges következő adatfolyamot. Példa adatküldésre CUBIC TCP használatával Először a szerveroldali alkalmazást kell indítani a következő paranccsal: ./server3 -p 12346 -c 10 -z cubic Ezután a kliensoldali alkalmazást kell indítani: 28

./client3 -s 10.1.1.3 -p 12346 -c 10 -z cubic A szerveroldali alkalmazás szöveges kimenete a következőképpen alakul: net.ipv4.tcp_congestion_control = cubic Listening.. Logging to logs_20121212054820.csv Accepted client: 10.1.1.2:38570 Transfer duration:

10.0001 seconds

Total: Bandwidth (Goodput):

897.9180 Mbps

Connection closed. Closing logfile... Listening.. Ebben az esetben a -z cubic opció használatával a CUBIC TCP volt a kiválasztott transzport protokoll, a szerver által használ port pedig az 12346-os. A hasznos átviteli sebesség 898 Mbit/s lett 10 másodperces átvitel esetén. Az adatok fogadásának lezárulta után az alkalmazás ebben az esetben is várja az esetleges következő adatfolyamot. Amennyiben a TCP Reno-t kívánjuk használni, akkor a -z reno kapcsoló használata szükséges, ebben az esetben minden egyéb a CUBIC TCP-hez hasonlóan alakul. Az előbbiekben ismertetett tesztalkalmazásokon kívül az iperf alkalmazást is használtam bizonyos esetekben, főként a kapott eredmények ellenőrzése miatt és különböző TCP gyorstesztek elvégzésre. Az alkalmazás használatára a következőkben bemutatok egy rövid példát. Példa adatküldésre az iperf alkalmazással Először a szerveroldali alkalmazást kell indítani a következő paranccsal: iperf -s Ezután a kliensoldali alkalmazást kell indítani: iperf -c 10.1.2.2 -i 10 -t 60 A -c kapcsolóval megadtam a fogadó oldali node IP-címét, majd a -i 10 kapcsolóval, hogy milyen időközönként írja ki a kimenetre az eredményt, utána pedig -t 60 kapcsolóval beállítottam az adatküldés időtartamát. A kliensoldali alkalmazás szöveges kimenete a következőképpen alakul: -----------------------------------------------------------Client connecting to 10.1.2.2, TCP port 5001 TCP window size: 16.0 KByte (default) 29

-----------------------------------------------------------[

3] local 10.1.1.2 port 50204 connected with 10.1.2.2 port 5001

[

3]

0.0-10.0 sec

1.10 GBytes

944 Mbits/sec

[

3] 10.0-20.0 sec

1.10 GBytes

942 Mbits/sec

[

3] 20.0-30.0 sec

1.10 GBytes

942 Mbits/sec

[

3] 30.0-40.0 sec

1.10 GBytes

942 Mbits/sec

[

3] 40.0-50.0 sec

1.10 GBytes

941 Mbits/sec

[

3] 50.0-60.0 sec

1.10 GBytes

942 Mbits/sec

[

3]

6.58 GBytes

942 Mbits/sec

0.0-60.0 sec

A szerveroldali alkalmazás szöveges kimenete pedig a következőképpen alakul: -----------------------------------------------------------Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) -----------------------------------------------------------[

4] local 10.1.2.2 port 5001 connected with 10.1.1.2 port 50204

[

4]

0.0-60.0 sec

6.58 GBytes

941 Mbits/sec

Látható, hogy 60 másodperc alatt 6,58 GB adatot sikerült elküldeni, átlagosan 941 Mbit/s sebességgel.

4.4.2. A számítógépek hardvertulajdonságai Az Emulab különböző típusú számítógépek használatát teszi lehetővé. Ezek közül a munkámhoz a pc3000 és d710 megnevezésű számítógépeket használtam, ezek az alábbi hardvertulajdonságokkal rendelkeznek. pc3000 • 3 GHz 64-bit Xeon processzor • 2 GB 400 Mhz DDR2 RAM • 6 darab 10/100/1000 Intel hálózati interfész • 2 darab 146 GB 10.000 rpm SCSI diszk d710 • 2,4 GHz-es 64-bit Quad Core Xeon E5530 processzor • 12 GB 1066 MHz DDR2 RAM • 6 darab Broadcom NetXtreme II BCM5709 gigabites hálózati interfész • 2 darab 250 GB 7200 rpm SATA diszk

4.4.3. Az ipfw és Dummynet alkalmazások Az előző fejezetben látható volt, hogy a hálózat főbb paraméterei a Dummynet alkalmazás segítségével állíthatók be az ipfw tűzfalmenedzsment szoftveren keresztül Dummynetspecifikus szabályok alkalmazásával, a következőkben erre látható egy példa. 30

Példa A 4.1. ábrán látható topológia esetén két szabály hozzáadása is elegendő: ipfw add 50 pipe 1 ip from 10.1.1.2 to 10.1.1.3 out ipfw pipe 1 config bw 1000Mb queue 10000 delay 10ms plr 0 Az első szabály létrehoz egy pipe objektumot, ami a 10.1.1.2-es IP-címről a 10.1.1.3-as IP-címre küldött csomagokra lesz érvényes. Minden csomag, ami eleget tesz ennek a kitételnek, belekerül a létrehozott pipe-ba. A második szabállyal a pipe hálózati paraméterei adhatóak meg, ebben az esetben ez 1000 Mbit/s sávszélességet, 10000 csomagos queue méretet, 10 ms-os késleltetést és 0%-os csomagvesztést jelent. Fontos, hogy a pipe létrehozásakor meg kell adni a pipe sorszámát és a szabály sorszámát, ez utóbbi jelen esetben 50. Ez azért fontos, mert a szabály sorszáma egyben jelzi annak precedenciáját is, így egy rosszul megadott szabálylista használatával előfordulhat, hogy egy csomagra akaratlanul nem a megfelelő szabályt alkalmazzuk. Ugyanezen okból kifolyólag a nem eltávolítható, implicit tagadó szabály, ami alapértelmezetten a szabálylista része, a legkisebb precedenciával, vagyis a legnagyobb sorszámmal rendelkezik. A szabálylista lekérdezhető az ipfw list vagy ipfw show parancsok bármelyikével. Az utóbbi parancs használatával arra is választ kaphatunk, hogy hány csomagra volt érvényes eddig egy adott szabály. Az ipfw show parancs kimenete: 00050

0

0 pipe 1 ip from 10.1.1.2 to 10.1.1.3 out

65000 44 7647 allow ip from any to any 65535

0

0 deny ip from any to any

Látható a második oszlop alapján, hogy az előbb hozzáadott szabály nem vonatkozott egyik csomagra sem, azonban 44 darab egyéb csomag továbbításra került. Miután a ping program segítségével kiküldök öt darab csomagot a 10.1.1.2-es IP-címről a 10.1.1.3-as IPcímre, akkor a kimenet az alábbiak szerint módosul: 00050

5



0


Más esetekben szükség van arra, hogy a pipe objektumokhoz queue objektumokat is rendeljünk. A queue objektumok segítségével több adatfolyamot lehet egy pipe-hoz rendelni, így ezen adatfolyamok együtt kezelhetők, tehát együtt alkalmazható rájuk például egy megadott késleltetési érték. További fontos haszna a queue objektumoknak, hogy használatukkal az adatfolyamok között igazságos ütemezés valósítható meg. Az alábbi parancsokkal a fent megadott pipe-hoz egy új queue rendelhető: ipfw add 10 queue 1 ip from 10.1.1.2 to 10.1.1.3 out ipfw queue 1 config queue 10000 weight 50 pipe 5 Az ipfw show parancs kimenete 10 csomag kiküldése után a ping alkalmazással: 31

00010 10

840 queue 1 ip from 10.1.1.2 to 10.1.1.3 out

00050 10



0


A kimenet alapján látható, hogy mind a 10-es, mind pedig az 50-es számú szabályt alkalmaztuk a kiküldött csomagokra, mivel összetartozó pipe és queue objektumokat használtunk. A következő fejezetben ismertetem a mérésekhez használt pontos ipfw szabálylistát, a topológiákat, továbbá a mérések eredményét és magyarázatát.

32

5. fejezet

Mérési eredmények Ebben a fejezetben bemutatom a mérési forgatókönyvek alapján elvégzett vizsgálatok eredményeit. Az eredményeket grafikonokon is ábrázoltam, az egyes adatfolyamokat különböző színnel, vagy vonaltípussal jelölve. A grafikonok függőleges tengelye minden esetben a hasznos adatmennyiségre számított átviteli sebesség (goodput), a vízszintes tengely pedig az első esetben csomagveszteség, az utána következő esetekben a hálózati körülfordulási idő (RTT), ami megegyezik a beállított egyirányú késleltetésekkel. A node-ok alapvető beállítását a tesztkörnyezet kialakítása során ismertetett módon végeztem el. A mérés eredményeinek magyarázata után minden esetben közlöm a számszerű eredményeket táblázatos formában, amelyben a mértékegységgel nem ellátott oszlopok Mbit/s-ban értendőek.

5.1. Egy küldő-fogadó pár A kiépített topológia a 4.1. ábrán látható összeállítás. A 3. fejezetben említettem, hogy az Emulab környezet webes felületén lehetőség nyílik megtekinteni a kísérletek topológiáját, ez látható az 5.1. ábrán ebben az esetben. A topológia megadása az alábbi NS fájl segítségével történt: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set node0 [$ns node] [4:] set node1 [$ns node] [5:] set nodeDummy [$ns node] [6:] tb-set-node-os $node0 Ubuntu704-P7 [7:] tb-set-node-os $node1 Ubuntu704-P7 [8:] tb-set-node-os $nodeDummy FBSD83-STD [9:] set link0 [$ns duplex-link $node0 $nodeDummy 1000Mb 0ms DropTail] [10:] set link1 [$ns duplex-link $node1 $nodeDummy 1000Mb 0ms DropTail] [11:] $ns rtproto Static [12:] $ns run Az 5.1. ábrán látható a kísérletben használt node-ok neve, IP-címe, valamint a link-ek sebessége. Mivel nincs csomagvesztés és késleltetés beállítva, ezért ezeket az ábra nem jelöli. 33

5.1. ábra. Topológia egy küldő-fogadó pár esetén

A kiépített topológián a már ismertetett forgatókönyvek szerint két esettel foglalkoztam, először a csomagvesztés, majd a késleltetés hatását vizsgáltam a protokollok teljesítményére különböző értékek mellett. A vizsgált protokollok a DFCP, a CUBIC TCP és a TCP Reno voltak.

5.1.1. A csomagveszteség hatásának vizsgálata A Dummynet-et futtató node-on (nodeDummy) kezdetben az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw

add 50 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out add 10 queue 1 ip from 10.1.1.2 to 10.1.2.2 out queue 1 config queue 10000 pipe 1 pipe 1 config bw 1000Mb queue 10000 delay 0ms plr 0.001

A szabályok megadása után elindítottam az adatküldést, majd a forgatókönyvnek megfelelően az utolsó szabály csomagveszteség opcióját (plr ) az újabb mérés előtt a megfelelő értékre állítottam be. A mérések eredménye az 5.2. ábrán láthatóak szerint alakult. A két TCP verzió közül a TCP Reno reagált jobban a 0,1% és 1%-os csomagveszteségekre, hiszen körülbelül 150 Mbit/smal nagyobb átvitelre volt képes a CUBIC TCP-hez képest. Az 5%-os csomagveszteséget elérve és azon túl a két TCP verzió szinte pontosan megegyező eredménnyel teljesített. Az 510-50%-os csomagveszteségi paraméterek mellett mindkettő legfeljebb 17 Mbit/s-os átviteli sebességet tudott elérni. A DFCP protokoll minden csomagveszteségi érték mellett jobban teljesített a két TCP verziónál. Látható, hogy 10%-os csomagveszteségig egyenletes átviteli sebesség csökkenés történik, nagyobb teljesítményromlás csak 50%-ot elérve tapasztalható, míg ez a TCP esetében már korábban megtörténik és sokkal nagyobb mértékben. 34

5.2. ábra. Csomagveszteség hatása egy küldő-fogadó pár esetén

Az eredmények alapján elmondható, hogy a CUBIC TCP és a TCP Reno sokkal érzékenyebb a csomagveszteségre, mint a DFCP. A pontos mérési eredmények az 5.1. táblázatban láthatóak. 5.1. táblázat. Egy küldő-fogadó pár pontos eredményei (változó csomagveszteség) PLR [%] 0,1 1 5 10 50

CUBIC 501 176 16 3,08 16

Reno 651 332 17 2,4 17

DFCP 773 718 649 583 216

5.1.2. A késleltetés hatásának vizsgálata Ekkor az alábbi kezdeti ipfw szabályokat használtam: ipfw ipfw ipfw ipfw

add 50 pipe 1 ip from 10.1.1.2 to 10.1.2.2 out add 10 queue 1 ip from 10.1.1.2 to 10.1.2.2 out queue 1 config queue 10000 pipe 1 pipe 1 config bw 1000Mb queue 10000 delay 0ms plr 0

Ebben az esetben is az utolsó szabály módosítására volt szükség a különböző késleltetési értékek megadásához. A delay opciót 0–100 ms között változtattam.

35

A mérések eredménye az 5.3. ábrán láthatóak szerint alakult. A 0 ms, 5 ms és 10 ms-os késleltetések alkalmazásakor a két TCP verzió azonos teljesítményre volt képes, az átviteli sebesség mindhárom alkalommal jobb volt, mint DFCP használatával. 50 ms-os és 100 ms-os késleltetés esetén a DFCP protokoll láthatóan sokkal jobban teljesített, nagyobb sebességcsökkenés csak 100 ms esetén fordult elő, míg a két TCP verzió már 50 ms esetén alulmaradt a DFCP-hez képest. Elmondható tehát, hogy egy küldő-fogadó pár esetén a DFCP protokoll a késleltetésre kevésbé érzékeny, mint a CUBIC TCP és a TCP Reno.

5.3. ábra. Késleltetés hatása egy küldő-fogadó pár esetén

A pontos mérési eredményeket az 5.2. táblázat tartalmazza. 5.2. táblázat. Egy küldő-fogadó pár pontos eredményei (változó késleltetés) RTT [ms] 0 5 10 50 100

CUBIC 898 896 895 360 186

Reno 898 896 895 360 186

DFCP 821 821 821 821 473

5.2. Két küldő-fogadó pár A dumbbell topológia kiépítéséhez az alábbi NS fájlt használtam: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set node0 [$ns node] 36

[4:] set node1 [$ns node] [5:] set node2 [$ns node] [6:] set node3 [$ns node] [7:] tb-set-node-os $node0 Ubuntu704-P7 [8:] tb-set-node-os $node1 Ubuntu704-P7 [9:] tb-set-node-os $node2 Ubuntu704-P7 [10:] tb-set-node-os $node3 Ubuntu704-P7 [11:] tb-set-node-os $nodeDummy FBSD83-STD [12:] set link0 [$ns duplex-link $node0 $nodeDummy 1000Mb 0ms DropTail] [13:] set link1 [$ns duplex-link $node1 $nodeDummy 1000Mb 0ms DropTail] [14:] set link2 [$ns duplex-link $node2 $nodeDummy 1000Mb 0ms DropTail] [15:] set link3 [$ns duplex-link $node3 $nodeDummy 1000Mb 0ms DropTail] [16:] $ns rtproto Static [17:] $ns run Az 5.4. ábrán látható a kísérlet topológiája az Emulab webes felületének használatával.

5.4. ábra. Topológia két küldő-fogadó pár esetén

A kiépített topológián azt vizsgáltam, hogy azonos transzport protokoll használatával két versenyhelyzetbeli adatfolyam milyen viselkedést mutat különböző késleltetési értékek mellett. A vizsgált protokollok a DFCP és a CUBIC TCP voltak.

37

A Dummynet-et futtató node-on (nodeDummy) kezdetben az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw ipfw ipfw ipfw ipfw ipfw ipfw

add 5 pipe 1 ip from 10.1.3.2 to 10.1.1.2 out pipe 1 config bw 1000Mb plr 0 queue 10000 delay add 6 pipe 2 ip from 10.1.4.3 to 10.1.2.3 out pipe 2 config bw 1000Mb plr 0 queue 10000 delay add 12 pipe 5 ip from {10.1.3.2 or 10.1.4.3} to pipe 5 config bw 1000Mb plr 0 queue 10000 delay add 10 queue 1 ip from 10.1.3.2 to 10.1.1.2 out add 11 queue 2 ip from 10.1.4.3 to 10.1.2.3 out queue 1 config queue 10000 weight 50 pipe 5 queue 2 config queue 10000 weight 50 pipe 5

10ms type WF2Q+ 10ms type WF2Q+ {10.1.1.2 or 10.1.2.3} out 0ms type WF2Q+

Látható, hogy három pipe objektum és két queue objektum létrehozására volt szükség. Az első két pipe segítségével elkülönítettem a két versengő adatfolyamot, hogy eltérő késleltetési értéket lehessen megadni azoknak. Ez kezdetben mindkét adatfolyam esetén 10 ms volt, majd a második adatfolyam késleltetését növeltem 10 ms-os lépésközökkel, egészen 100 ms-ig. A harmadik pipe-ra és a hozzárendelt két queue objektumra a megfelelő WF2Q+ ütemezés alkalmazásához volt szükség. Az első két pipe objektum kimenete a harmadik pipe bemenete, így minden csomag, ami a 10.1.3.2 IP-címről a 10.1.1.2 IP-címre, illetve a 10.1.4.3 IP-címről a 10.1.2.3 IP-címre érkezik, két pipe objektumon halad keresztül. A harmadik, közös pipe-hoz rendelt queue objektumok súlya 50-50%, biztosítva az igazságos ütemezést. A mérések eredményét az 5.5. ábra szemléltei. A CUBIC TCP esetében az ábrán látható első adatfolyam (Cubic flow 1) állandó, 10 ms-os késleltetéssel rendelkezett, a második adatfolyam (Cubic flow 2) pedig a vízszintes tengelyen láthatóak szerinti egyre növekvő késleltetéssel. Az ábrán jól megfigyelhető a CUBIC TCP-re jellemző RTT unfairness probléma, hiszen az alacsony késleltetésű adatfolyam 30 ms-nál nagyobb késleltetés értékek mellett elnyomja a második adatfolyamot. Ez a jelenség a második adatfolyam késleltetésének növelésével egyre meghatározóbbá válik, 100 ms-os késleltetés esetén már csak negyedakkora átviteli sebességre képes, mint az első adatfolyam. A DFCP protokoll használatakor a két versengő adatfolyam (DFCP flow 1, DFCP flow 2) késleltetéstől függetlenül azonos átviteli sebesség értékeket ért el, minden esetben körülbelül 420 Mbit/s-ot. Látszik, hogy a DFCP protokoll nem érzékeny a hálózati körülfordulási időre, ha az egyik adatfolyam késleltetése nagyobb, mint a másik adatfolyamé, vagyis az RTT unfairness probléma a protokollra nem jellemző. A pontos mérési eredmények az 5.3. táblázatban láthatóak. A dumbbell topológián elvégzett mérések után, egy bonyolultabb, három küldő-fogadó párból álló parking lot topológián folytattam a vizsgálatokat.

38

5.5. ábra. Késleltetés hatása két küldő-fogadó pár esetén

5.3. táblázat. Két küldő-fogadó pár pontos eredményei RTT [ms] 10 20 30 40 50 60 70 80 90 100

DFCP flow 1 423 423 424 424 424 424 425 425 424 425

DFCP flow 2 422 423 423 423 423 422 423 422 422 421

39

CUBIC flow 1 461 462 464 499 578 630 669 699 721 741

CUBIC flow 2 461 459 457 419 342 289 250 220 197 178

5.3. Három küldő-fogadó pár A parking lot topológia kiépítéséhez az alábbi NS fájlt használtam: [1:] set ns [new Simulator] [2:] source tb_compat.tcl [3:] set node0 [$ns node] [4:] set node1 [$ns node] [5:] set node2 [$ns node] [6:] set node3 [$ns node] [7:] set node4 [$ns node] [8:] set node5 [$ns node] [9:] set nodeDummy0 [$ns node] [10:] set nodeDummy1 [$ns node] [11:] tb-set-node-os $node0 Ubuntu704-P7 [12:] tb-set-node-os $node1 Ubuntu704-P7 [13:] tb-set-node-os $node2 Ubuntu704-P7 [14:] tb-set-node-os $node3 Ubuntu704-P7 [15:] tb-set-node-os $node4 Ubuntu704-P7 [16:] tb-set-node-os $node5 Ubuntu704-P7 [17:] tb-set-node-os $nodeDummy0 FBSD83-STD [18:] tb-set-node-os $nodeDummy1 FBSD83-STD [19:] set link0 [$ns duplex-link $node0 $nodeDummy0 1Gb 0ms DropTail] [21:] set link1 [$ns duplex-link $node1 $nodeDummy0 1Gb 0ms DropTail] [22:] set link2 [$ns duplex-link $node2 $nodeDummy0 1Gb 0ms DropTail] [23:] set link3 [$ns duplex-link $node3 $nodeDummy1 1Gb 0ms DropTail] [24:] set link4 [$ns duplex-link $node4 $nodeDummy1 1Gb 0ms DropTail] [25:] set link5 [$ns duplex-link $node5 $nodeDummy1 1Gb 0ms DropTail] [26:] set link6 [$ns duplex-link $nodeDummy0 $nodeDummy1 1Gb 0ms DropTail] [27:] tb-set-hardware $nodeDummy0 d710 [28:] tb-set-hardware $nodeDummy1 d710 [29:] $ns rtproto Static [30:] $ns run A kiépített topológián a már ismertetett forgatókönyvek szerint két esetet vizsgáltam, először különböző sávszélességek mellett, ahol az egyik link szűk keresztmetszetet jelentett, a második esetben pedig azonos, gigabites sávszélességek mellett, de az egyik linken megnövelt késleltetéssel. A kísérlet aktiválása után a topológia az 5.6. ábrán látható módon épült ki. A vizsgált transzport protokollok ebben az esetben is a DFCP és a CUBIC TCP voltak, azonban az előző vizsgálatoktól eltérően ekkor két Dummynet-et futtató node-ra volt szükség, ezek név szerint nodeDummy0 és nodeDummy1. A két Dummynet-es node-on eltérő ipfw szabályok használatára volt szükség, ezeket az ismertetett eseteknél tárgyalom.

40

5.6. ábra. Topológia három küldő-fogadó pár esetén

A topológián három adatfolyam versenyhelyzetbeli viselkedését vizsgáltam. Az adatfolyamok közül kettő rövid (short flow 1 és short flow 2), egy pedig hosszú (long flow). Az első rövid adatfolyam node1 és node2 között, a második rövid adatfolyam node3 és node4 között, a hosszú adatfolyam pedig node0 és node5 között haladt.

5.3.1. Első eset Az első Dummynet-et futtató node-on (nodeDummy0 ) az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw ipfw ipfw

add 12 pipe 5 ip from {10.1.5.2 or 10.1.7.2} to {10.1.6.2 or 10.1.2.2} out pipe 5 config bw 1000Mb plr 0 queue 10000 delay 10ms type WF2Q+ add 10 queue 1 ip from 10.1.5.2 to 10.1.6.2 out add 11 queue 2 ip from 10.1.7.2 to 10.1.2.2 out queue 1 config queue 10000 weight 50 pipe 5 queue 2 config queue 10000 weight 50 pipe 5

Látható, hogy egy pipe objektum és két queue objektum létrehozása elegendő volt, mivel a node-on áthaladó csomagoknak ugyanolyan hálózati paraméterekkel kellett rendelkezniük. A két queue objektum segítségével az első rövid adatfolyamhoz tartozó csomagok, vagyis a 10.1.7.2 IP-címről a 10.1.2.2 IP-címre küldött csomagok, és a hosszú adatfolyamhoz 41

tartozó, vagyis a 10.1.5.2 IP-címről a 10.1.6.2 IP-címre küldött csomagokra könnyedén végrehajtható volt a WF2Q+ ütemezés, egyenlő súlyokkal. A második Dummynet-et futtató node-on (nodeDummy1 ) kezdetben az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw ipfw ipfw


Az előző szabályokhoz hasonlóan itt is egy pipe objektumra és két queue objektumra volt szükség. Az egyik queue a második rövid adatfolyamhoz tartozó, 10.1.3.2 IP-címről a 10.1.4.2 IP-címre küldött csomagokhoz volt rendelve, a másik queue pedig a hosszú adatfolyamhoz, tehát a 10.1.5.2 IP-címről a 10.1.6.2 IP-címre küldött csomagokhoz. A sávszélesség a node által emulált linken 500 Mbit/s-ra lett beállítva, a késleltetési paraméter értéke pedig 0 ms és 100 ms között változott a mérések során. Az ütemezés itt is WF2Q+ ütemezővel történt, 50-50%-os súlyokkal. Az első rövid adatfolyam tehát node1 -ből indul és node2 -be tart, ennek során versenyhelyzet alakul ki közte és a hosszú adatfolyam között, ami szintén áthalad a nodeDummy0 által emulált gigabites linken. A második rövid adatfolyam, amely node3 -ból indul és node4 -be tart, szintén versenyhelyzetbe kerül a hosszú adatfolyammal, ami először a nodeDummy0, majd utána a nodeDummy1 által emulált bottleneck linken is áthalad. A mérések eredménye az 5.7. ábrán láthatóak szerint alakult. A CUBIC TCP használatával az első rövid adatfolyam (kék, szaggatott vonal) a második emulált link 10 ms-os késleltetéséig egyenlően osztozik az elérhető erőforrásokon a hosszú adatfolyammal (kék vonal). Mivel a hosszú adatfolyam egy bottleneck linken is áthalad a rövid folyammal történő verseny után és ott versenyhelyzetbe kerül a második rövid folyammal, ezért az összesített sebessége sokkal kisebb lesz, ami érthető viselkedés. A második rövid adatfolyam (kék, pontozott vonal) és a hosszú adatfolyam szintén egyenlően osztja meg az elérhető 500 Mbit/s-ot, így az általuk elért sebesség megegyezik. A bottleneck link 10 ms-os késleltetését tovább növelve tapasztalható, hogy jelentkezik az RTT unfairness probléma, mivel 50 ms-os késleltetéstől már az első rövid adatfolyam hatása miatt a másik két folyam teljesítménye romlik. Ekkor a második linken elérhető legnagyobb sebesség felső korlátját a hosszú adatfolyam által elért sebesség adja, a kettő sebessége azonban az igazságos ütemezésnek köszönhetően hozzávetőlegesen megegyezik. A DFCP protokoll használatával az első rövid adatfolyam (piros, szaggatott vonal) minden késleltetési érték esetén az igazságos módon elérhető legnagyobb sebességgel teljesít. Ez a bottleneck link sávszélesség korlátja miatt végig magasabb, mint a hosszú adatfolyam (piros vonal) által elért sebesség. A második rövid adatfolyam (piros, pontozott vonal) végig igazságosan osztozik a bottleneck link sebességén. Kijelenthető tehát, hogy a fenti összetett versenyhelyzetben a DFCP protokoll nem volt érzékeny a hálózati körülfordulási 42

idő változására, míg a CUBIC TCP 10 ms felett igen. Az első eset pontos mérési eredményei az 5.4. táblázatban olvashatók (SF: Short flow, LF: Long flow).

5.7. ábra. Késleltetés hatása három küldő-fogadó párral az első esetben

5.4. táblázat. Három küldő-fogadó pár pontos eredményei (első eset) RTT [ms] 0 5 10 50 100

DFCP SF1 635 634 634 636 635

DFCP SF2 213 213 212 214 211

DFCP LF 212 212 211 213 210

43

CUBIC SF1 686 686 686 727 764

CUBIC SF2 234 233 233 177 89

CUBIC LF 232 230 230 146 80

5.3.2. Második eset Az első Dummynet-et futtató node-on (nodeDummy0 ) az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw ipfw ipfw


A szabálylista közel azonos az előző eset első szabálylistájával, azonban most a késleltetés 50 ms. A második Dummynet-et futtató node-on (nodeDummy1 ) kezdetben az alábbi ipfw szabályokat alkalmaztam: ipfw ipfw ipfw ipfw ipfw ipfw


Ez a szabálylista közel azonos az előző eset második szabálylistájával, azzal a különbséggel, hogy az emulált link ekkor már nem bottleneck link, a sebessége 1 Gbit/s. A link késleltetésének értéke kezdetben 0 ms, majd 10 ms-os lépésközzel végül eléri a 100 ms-ot. Az adatfolyamok forrás- és cél IP-címe megegyezik az előző esetben látottakkal. A mérések eredménye az 5.8. ábrán láthatóak szerint alakult. A CUBIC TCP használatával az első rövid folyam végig ugyanazt a teljesítményt nyújtotta. A közös átviteli szakaszon a hosszú folyam és az első rövid folyam igazságosan osztotta meg az erőforrásokat, azonban a második emulált linken, amin a hosszú folyam szintén áthalad, az egyre növekvő késleltetés miatt mégis csökkenő teljesítményt mutat. A második rövid folyam a kezdeti alacsony késleltetési értékek mellett elnyomja a legelejétől fogva 50 ms-os késleltetéssel rendelkező hosszú adatfolyamot. A kezdeti 50 ms-os, első emulált linken megadott késleltetés miatt már a vizsgálat elején jelentkezik az RTT unfairness probléma. A második emulált link késleltetésének növekedésével a második rövid folyam és a hosszú adatfolyamok átviteli sebessége egyre közelít egymáshoz, a vizsgálat legvégére a hosszú adatfolyam összes késleltetése 50 + 100 = 150 ms, a második rövid adatfolyam késleltetése pedig 100 ms, a teljesítmények pedig már csak 30 Mbit/s-ban térnek el egymástól. Látható, hogy a második link 50 ms-os késleltetésekor a két emulált link késleltetése megegyezik, a két rövid adatfolyam pedig egyező teljesítményt nyújt az igazságos ütemezés miatt, ez megegyezik az elvárt viselkedéssel, validációs pontnak tekinthető. DFCP használatával az első rövid folyam a vizsgálat során szinte végig megegyező sebességet ért el. Kezdetben, amikor a második emulált link késleltetése 0 ms volt, az első rövid folyam és a hosszú folyam egyenlő teljesítményt mutattak, ezután a hosszú folyam 44

5.8. ábra. Késleltetés hatása három küldő-fogadó párral a második esetben

teljesítménye egyenletesen csökkent a növekvő késleltetés miatt. A második rövid folyam kezdetben egyenletesen növekvő sebességre volt képes egészen addig, amíg a második link el nem érte az 50 ms-os késleltetést, ettől a ponttól kezdve azonban a teljesítmény fokozatosan csökkent. A kezdeti növekedés azzal magyarázható, hogy a második link kihasználatlan erőforrásokkal rendelkezett az igazságos ütemezés ellenére is, mivel a hosszú adatfolyam már a legelején 50 ms-os késleltetéssel rendelkezett és ez folyamatosan nőtt. A második rövid link ezután kezdődő csökkenő teljesítménye pedig azért volt tapasztalható, mert elérte a töréspontnak számító 50 ms-os késleltetést, ettől az értéktől kezdve a protokoll a korábbi mérések során is csökkenő teljesítményt nyújtott. A második linken versengő két adatfolyam pedig még ekkor sem érhetett el azonos sebességet, mivel a hosszú adatfolyam késleltetése végig 50 ms-mal több volt a második rövid folyaménál, azonban az elért sebességek nagysága fokozatosan közelített egymáshoz a késleltetés növekedésével. A két rövid folyam 50 ms-os pontban történő egybeesése ebben az esetben is tapasztalható. Általánosságban elmondható tehát, hogy a DFCP protokoll használatával nem jelentkezett az RTT unfairness probléma, az igazságosság végig biztosított volt. A második eset pontos mérési eredményei az 5.5. táblázatban olvashatók (SF: Short flow, LF: Long flow).

45

5.5. táblázat. Három küldő-fogadó pár pontos eredményei (második eset) RTT [ms] 0 10 20 30 40 50 60 70 80 90 100

DFCP SF1 422 456 469 470 470 470 470 470 470 470 470

DFCP SF2 426 460 512 551 567 470 394 339 298 265 239

DFCP LF 421 387 335 294 262 237 216 198 183 170 159

46

CUBIC SF1 186 185 187 187 188 188 188 188 188 188 188

CUBIC SF2 746 723 443 305 233 188 157 134 117 104 94

CUBIC LF 176 148 129 114 102 92 83 76 70 65 61

6. fejezet

Összefoglalás A munkám kiindulási állapotában rendelkeztem a feladatkiírásban is szereplő elvégzendő feladatokkal és célokkal, illetve a protokollok teszteléséhez elengedhetetlen Emulab hozzáféréssel. A DFCP protokoll vizsgálatához szükséges egyedi kernelt szintén megkaptam az ehhez szükséges beállítási információkkal együtt. A feladatom az volt, hogy a TCP bizonyos verzióival és a DFCP protokollal összehasonlítást végezzek a korábbi teszthálózati méréseket megerősítve, közben pedig a protokollok teljesítményelemzését adjam. A munkám során két egyszerű és három összetettebb forgatókönyv szerint kiépítettem hálózati topológiákat, majd ezek használatával elvégeztem a szükséges méréseket. Az előírt forgatókönyvek változatos hálózati helyzetek elé állították a vizsgált protokollokat, így azok különböző paraméterektől függő sajátosságait sikerült felderíteni. Mivel a forgatókönyvek csak korlátozott számú egyedi helyzetet tudtak felvázolni, ezért a későbbiekben az eredményeim alapján szükség lehet további forgatókönyvek megalkotására és ezek alapján további mérések elvégzésére. Az egy küldő-fogadó pár esetén végzett csomagvesztési kísérlet megmutatta, hogy a forgatókönyv szerinti egyszerű helyzetben a DFCP protokoll nagyon jó eredményt képes elérni a két TCP verzióval szemben. A TCP-t használó adatfolyamok minden csomagvesztési érték mellett gyengébben teljesítettek, mint a DFCP-t használó adatfolyamok. Mivel a további forgatókönyvek a csomagveszteség befolyásoló hatását egyáltalán nem vizsgálják, a későbbiekben szükségessé válhat annak tanulmányozása összetettebb topológiákon. Az eredmények azt mutatják, hogy változó csomagvesztés esetén a két vizsgált TCP verzió a DFCP-hez képest már sokkal korábban érzékennyé vált ennek a paraméternek a változására. Két küldő-fogadó pár esetén a CUBIC TCP protokoll 30–40 ms-os késleltetés felett egyre növekvő RTT unfairness tulajdonságot mutatott. Ez a DFCP protokoll esetén nem jelentkezett, végig érzéketlen volt a hálózat körülfordulási idejére, kijelenthető tehát, hogy a TCP vizsgált változatával szemben a DFCP igazságos működést valósított meg változó késleltetések esetén is. Három küldő-fogadó pár esetén két esetet vizsgáltam. Az első esetben a második link szűk keresztmetszet jelentett a sávszélesség paraméter miatt. A TCP protokoll viselkedésének elemzésekor kiderült, hogy ezen forgatókönyv szerint 10 ms-os bottleneck link

47

késleltetés esetén jelentkezik az RTT unfairness probléma, ami a késleltetés növekedésével egyre inkább fokozódik. DFCP használatakor ebben az esetben is igazságos az adatfolyamok közti erőforrás megosztás. A második esetben CUBIC TCP protokoll estén az RTT unfairness probléma már a vizsgálat elején jelentkezett a kezdeti beállításokból adódóan, azonban a DFCP a vizsgálat során végig igazságos működést mutatott. A vizsgálatok elvégzése után megállapítható, hogy a TCP bizonyos körülmények esetén, jellemzően magas csomagveszteség vagy késleltetés mellett igazságtalanul viselkedik, hiszen az adatfolyamok sebességelosztása nem egyenlő. A DFCP protokoll azonban kedvező eredményeket ért el a különböző helyzetekben. Mivel az ismertetett forgatókönyvek szerint kódolás és dekódolás használata nélkül folytak a mérések, a következőkben ezek alkalmazásával, esetleges továbbfejlesztésével is érdemes foglalkozni. A munkám során elvégzett eddigi teljesítményelemzés fényében a protokoll további vizsgálata mindenképpen javasolt, mivel a jövőben képes lehet a TCP alternatíváját nyújtani.

48

Ábrák jegyzéke 2.1. A TCP Reno működési fázisai . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2. A BIC TCP új működési fázisai . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. A CUBIC TCP ablaknövelése . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. A tesztkörnyezet fizikai topológiája . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Első egyszerű topológia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Második egyszerű topológia . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Harmadik egyszerű topológia . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Fizikai topológia egy küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . 25 4.2. Fizikai dumbbell topológia két küldő-fogadó pár esetén . . . . . . . . . . . . 26 4.3. Fizikai parking lot topológia három küldő-fogadó pár esetén . . . . . . . . . 27 5.1. Topológia egy küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . . . . . 34 5.2. Csomagveszteség hatása egy küldő-fogadó pár esetén . . . . . . . . . . . . . 35 5.3. Késleltetés hatása egy küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . 36 5.4. Topológia két küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . . . . . 37 5.5. Késleltetés hatása két küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . 39 5.6. Topológia három küldő-fogadó pár esetén . . . . . . . . . . . . . . . . . . . 41 5.7. Késleltetés hatása három küldő-fogadó párral az első esetben

. . . . . . . . 43

5.8. Késleltetés hatása három küldő-fogadó párral a második esetben

49

. . . . . . 45

Táblázatok jegyzéke 4.1. Redundancia értékek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Egy küldő-fogadó pár pontos eredményei (változó csomagveszteség) . . . . . 35 5.2. Egy küldő-fogadó pár pontos eredményei (változó késleltetés) . . . . . . . . 36 5.3. Két küldő-fogadó pár pontos eredményei . . . . . . . . . . . . . . . . . . . . 39 5.4. Három küldő-fogadó pár pontos eredményei (első eset) . . . . . . . . . . . . 43 5.5. Három küldő-fogadó pár pontos eredményei (második eset) . . . . . . . . . . 46

50

Irodalomjegyzék [1] The Network Simulator - ns-2. http://www.isi.edu/nsnam/ns/. [2] Andrea Zanella, Gregorio Procissi, Mario Gerla, and M. Y. Sanadidi. TCP Westwood: Analytic Model and Performance Evaluation. In Proc. of Globecom 2001, San Antonio, Texas, USA, 2001. [3] Sonkoly Balázs, Németh Felicián, and Császár András. Nagysebességű transzport protokollok szimulációs vizsgálata. http://qosip.tmit.bme.hu/cgi-bin/twiki/view/ Meres/NagysebesseguTCPSzimulaciokMeresiSegedlet/. [4] J. C. R. Bennett and H. Zhang. WF2Q: Worst-case fair weighted fair queueing. In Proc. of the IEEE INFOCOM’96, San Francisco, CA, USA, 1996. [5] David X. Wei, Cheng Jin, Steven H. Low, and Sanjay Hegde. FAST TCP: motivation, architecture, algorithms, performance. In Proc. of IEEE/ACM Transactions on Networking, 2006. [6] Dina Katabi, Mark Handley, and Charlie Rohrs.

Congestion control for high

bandwidth-delay product networks. In Proc. of SIGCOMM 2002, Pittsburgh, PA, USA, 2002. [7] S. Floyd, T. Henderson, and A. Gurtov. The NewReno Modification to TCP’s Fast Recovery Algorithm. http://tools.ietf.org/html/rfc3782/. [8] Injong Rhee and Lisong Xu. CUBIC: A new TCP-friendly high-speed TCP variant. In Proc. of the 3rd International Workshop on Protocols for Fast Long-Distance Networks, Lyon, France, 2005. [9] Kun Tan, Jingmin Song, Qian Zhang, and Murari Sridharan. A compound TCP approach for highspeed and long distance networks. In Proc. of IEEE Infocom 2006, Barcelona, Spain, 2006. [10] Lisong Xu, Khaled Harfoush, and Injong Rhee. Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks. In Proc. of IEEE Infocom 2004, Hong Kong, China, 2004. [11] L. Rizzo. Dummynet. http://info.iet.unipi.it/~luigi/dummynet/.

51

[12] Solymos Szilárd. Robusztus, torlódásszabályozás nélküli transzport protokoll tervezése és fejlesztése, BSc szakdolgozat, 2011. [13] University of Utah Flux Research Group. Emulab: The Utah Network Testbed. http: //www.emulab.net/. [14] Van Jacobson. Congestion Avoidance and Control. In Proc. of SIGCOMM 1988, Stanford, CA, USA, 1988. [15] Zóber Gábor. TCP torlódásszabályozási algoritmusok vizsgálata az Emulab környezetben, Önálló laboratórium beszámoló, 2012.

52

Torlódásvezérlés nélküli transzport protokoll teljesítményelemzése Emulab hálózatemulációs környezetben

Recommend Documents