Önálló laboratórium beszámoló

Önálló laboratórium beszámoló Távközlési és Médiainformatikai Tanszék Készítette: Neptun-kód: Ágazat: E-mail cím: Konzulens: E-mail címe: Csicsics Tamás EUZ5LN Hálózatok és szolgáltatások cstomi@lantech.hu Dr. Molnár Sándor molnar@tmit.bme.hu A jövő Internetének tervezése és elemzése A P7 protokoll vizsgálata FreeBSD-Dummynet környezetben Feladat Az idők során a TCP (Transmission Control Protocol) protokoll és variánsai elavultakká váltak, nem igazán alkalmasak nagy sebességű hálózatok kihasználásához, ezért több kutatás is a leváltásukat tűzte ki célul. Feladatom az egyetemen fejlesztett P7 protokoll jelenlegi állapotának vizsgálata volt, melyhez egy teszthálózatot kellett kialakítanom. A lehetséges hálózat emuláló rendszerek közül a Dummynet-et választottam, mellyel le is teszteltem a protokollt összehasonlítva más, széles körben használt TCP variánsokkal. 2011/2012. 2. félév

Bevezető 1. A laboratóriumi munka környezetének ismertetése, a munka előzményei és kiindulási állapota A mai modern világban életünk szerves részévé vált az internet használata. Használhatjuk információkhoz jutáshoz, hivatalos ügyek intézéséhez, ismerőseinkkel való kapcsolattartáshoz és rengeteg egyéb dologhoz, például média tartalmakhoz való hozzáférésre. Az internetet használók mára már nem csupán a számítógéphez értők köréből kerül ki, hanem szinte minden ember találkozik vele függetlenül életkorától, nemétől. A hatalmas felhasználói bázis (~4 milliárd ember) nem csupán hatalmas adatforgalommal jár, hanem egyben hatalmas üzletet is jelent az internet szolgáltatóknak. A szolgáltatók egyre jobb szolgáltatásokat kínálnak az ügyfeleiknek, ami a heterogén kiszolgáló infrastruktúra folyamatos fejlődésével jár. Heterogén, hiszen manapság nem csupán számítógépek csatlakoznak egymáshoz az interneten keresztül, hanem akár televíziók, játékkonzolok, s háztartási gépek is. Magának az Internetnek a gyökerei az 1960-as évek végéig nyúlnak vissza, amikor is Egyesült Államok-béli katonai fejlesztések kezdtek a civil lakosság közelébe kerülni, pontosabban egy országszerte szétágazó saját hálózat kezdett kialakulni (ARPANET2). Ennek a hálózatnak a kommunikációs protokollja volt az NCP (Network Control Program), amely a ma is használatos TCP/IP (Transmission Control Protocol/Internet Protocol) rendszer ősének tekinthető. A TCP/IP adja a mai ember által ismert internet hálózati kommunikációs alapját, azaz biztosítja számunkra a globális hálózati kommunikációt. A TCP/IP bevezetésekor a korunkbeli hálózati infrastruktúrától erősen eltérő minőségű rendszer képezte az internet alapját, az átvitt információ töredéke volt a mainak, s a hálózat kiterjedtsége se volt globális. Alapvetően a TCP egészen a közelmúltig jól látta el a feladatait, azaz biztosította a torlódásszabályzást a hálózatban. Napjainkra ugyanakkor jellemző lett, a szinte mindenki számára elérhető, nagy sebességű internet, amely nem csupán nagyobb sávszélességet biztosít, hanem alacsonyabb késleltetéseket is a hálózatban. Azonban ezeket a megnövekedett minőségi mutatókat a hagyományos TCP protokoll nem képes kihasználni, túl konzervatív, lassan reagál a hálózatban bekövetkezett változásokra, így csak kis mértékben képes kihasználni a fizikai hálózat által biztosított sávszélességet. A kutatók ezért a protokoll újabb variánsain kezdtek dolgozni, amikkel szép eredményeket értek el, azaz megjelentek a nagyobb teljesítményt kihasználó protokollok, és így hálózatok is. Ezek a fejlesztések, kutatások ugyanakkor a TCP-t használták alapul, így bizonyos értelemben korlátozottak voltak a kutatók lehetőségei. Napjainkban ezért egyre inkább előtérbe kerülnek az olyan kutatások melyek a TCP leváltását tűzték ki célul, mégpedig teljesen új koncepciókra építkezve. Munkám során szerencsém, feladatom volt, egy fejlesztés alatt álló, merőben új szállítás rétegbeli protokollal megismerkedni, a P7 protokollal. A P7 kutatói/fejlesztői: a Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) hallgatója Solymos Szilárd és oktatói Dr. Molnár Sándor valamint Sonkoly Balázs. Mint minden fejlesztés során jelen esetben is szükség van folyamatos tesztelésekre, visszajelzésekre, amik segítségével hatékonyabbá lehet tenni a fejlesztést. Mivel a cél az internet szállítási protokolljának leváltása, így a tesztek során törekedni kell a minél életszerűbb környezetekhez. Az internet egy szó szerint értendően világméretű hálózat, így egy hasonló tesztkörnyezet összerakása valódi fizikai eszközökből nagyon bonyolult, illetve nagyon költséges feladat. Ezért erre a célra hálózat emulációs technikák/rendszerek állnak rendelkezésre, amikkel modellezni, szimulálni lehet valós hálózatok működését. Ezen rendszerek közül a féléves feladatom 1

elvégzéséhez a FreeBSD [1] rendszeren futó Dummynet emulációs szoftvert választottam, mellyel már előző félévekben foglalkoztam. Elméleti összefoglaló A fejezetben először a mért protokollok rövid elméleti összefoglalója 1 olvasható, majd a második részében következik a teszthálózatról szóló rész. A TCP protokoll A TCP egy szállítási rétegben (OSI modell [2]) elhelyezkedő protokoll, feladata a többi rétegbeli más protokollokéhoz hasonlóan, hogy lehetővé tegye a forrás- és célállomásokban található társentitások közötti párbeszédet. Manapság két különböző szállítási protokollt terjedt el igazán világszerte. Az egyik maga TCP, amely egy megbízható összeköttetés alapú protokoll. Feladata az, hogy hibamentes átvitelt biztosítson bármely két gép között az interneten. A beérkező bájtos adatfolyamot diszkrét méretű üzenetekre osztja, majd azokat egyesével továbbítja az internet rétegnek. A célállomás TCP folyamata összegyűjti a beérkezett üzeneteket, és egyetlen kimeneti adatfolyamként továbbítja őket. A TCP forgalomszabályozást is végez annak érdekében, hogy egy gyors forrásállomás csak annyi üzenetet küldjön egy lassabb célállomásnak, amennyit az fogadni képes. A másik protokoll az UDP (User Datagram Protocol), feladata datagram alapú szolgáltatás biztosítása, azaz rövid, gyors üzenetek küldése. Jellemzően akkor használják, amikor a gyorsaság fontosabb a megbízhatóságnál, mert az UDP nem garantálja a csomagok megérkezését. Ilyen szolgáltatások például a DNS (Domain Name System), a valós idejű multimédia átvitelek, vagy a hálózati játékok. Probléma a TCP-vel, hogy a hagyományos torlódásvezérlő nem képes univerzális, optimális megoldást nyújtani a folyamatosan változó, heterogén környezet okozta kihívásokra. Ennek megfelelően több variánsa is megjelent, melyek különböző környezetben próbálnak hatékonyabb működést elérni. Ezen változatok közül a két legelterjedtebbet a Reno-t és a Cubicot használtuk a P7-el való összehasonlításra. TCP Reno Ez a változat a csomagvesztés gyorsabb detektálását teszi lehetővé a Fast Retransmit algoritmus alkalmazásával. Ennek lényege, hogy szinte azonnal nyugta érkezzen a küldőhöz, ahogy a vevő megkapta a csomagot. Amennyiben három duplikált nyugta érkezik a forráshoz, az csomagvesztést érzékel és újraküldi a csomagot, anélkül, hogy az időzítő lejárna. Másik módosítás, hogy csomagvesztés esetén nem állítja a torlódási ablak méretét egyre, hanem megfelezi annak értékét, valamint a TCP ablakot is azonos erre az értékre állítja. Ezután pedig már egyesével növeli a hálózatban lévő csomagok számát. A TCP Reno nem működik hatékonyan, ha túl nagy a csomagvesztés aránya, mivel a csomagvesztést detektáló algoritmusa nem tudja megkülönböztetni a többszörös hibákat. Itt kell megjegyezni, hogy a mérés során a New Reno változatot használtunk SACK-el (Selective Acknowledgement). A TCP SACK megoldást ad a többszörös csomagvesztés detektálására, oly módon, hogy egyszeres nyugtázást alkalmaz, azaz egy csomagra egy nyugta érkezik. 1 A beszámolónak nem célja a TCP és verzióinak részletes bemutatása, de az irodalomjegyzék több pontjából is bővebb információkhoz juthat az olvasó. Pl.: [10]. 2

TCP Cubic A Cubic, mely az újabb Linux rendszerek alapértelmezett transzport protokollja, a BIC (Binary Increase Congestion control) továbbfejlesztett változata. A BIC egy nagy sebességű, nagy késleltetésű hálózatokhoz optimalizált torlódásszabályzással rendelkező TCP verzió, amely azonban túlságosan is agresszív, így megnehezíti más protokollokkal való együttműködést, illetve az elemzéseket. A TCP Cubic viszont egyszerűsíti az ablakkezelést, javítja a korrektséget (fairness), miközben megőrzi a BIC erősségeit, különös tekintettel a stabilitásra és a skálázhatóságra. Ahogy az új protokoll neve is jelzi, a CUBIC az ablakméret növelési függvényhez egy köbös függvényt használ, aminek a formája nagyon hasonlít a BIC által használt függvény formájához. P7 Alapkoncepciója egy GENI (Global Environment for Network Innovations) által javasolt elképzelés [3], amely szerint egyáltalán nincs szükség torlódásszabályozásra. Az elv az, hogy a hálózatban minden entitás maximális sebességgel küldhet adatokat. Ha ez nem vezetne torlódás kialakulásához, akkor ez lenne az elképzelhető leghatékonyabb megoldás. Azonban ha az adatküldés maximális sebességgel történik, akkor nagymértékű, főként csomós csomagvesztés következik be. A GENI a csomagvesztés okozta probléma megoldására hatékony hibajavító kódolás használatát javasolja. Ennek számos előnye van, ugyanis minden hálózati erőforrást teljesen kihasználnánk, és ha többlet erőforrás állna rendelkezésre, akkor azt is képesek vagyunk azonnal kihasználni, ez hatékonnyá teszi az alkalmazott módszert. Használatakor első lépésben szükség van a kapcsolat felépítésére az adó és a vevő között. Ez a TCP protokollhoz hasonlóan történik. Ha létrejön a kapcsolat, akkor lehetőség nyílik az adatok küldésére. Az adatküldéshez a felhasználói programtól érkező küldendő szimbólumokat kódolja a protokoll, majd a kódolt adatok elküldésre kerülnek. A P7 protokoll speciális felépítésű fejlécet használ, amelyben a dekódolást segítő információ is továbbításra kerül. A küldés során beállítástól függően: a) az adó nem használ újraküldést, és nem kap nyugtákat a vevő oldaltól. b) nyugtázással biztosítja az adattovábbítást. A vevő oldal megvárja, amíg elegendő mennyiségű adat érkezik, amikor már nagy valószínűséggel sikeresen végrehajtható a dekódolás. Ekkor végrehajtja a dekódolást, siker esetén pedig visszajelzést küld az adónak. A visszajelzés hatására az adó abbahagyja az adatok küldését. Ezután a vevő a dekódolt adatokat átadja a várakozó felhasználói programnak. A kapcsolatot az adatátvitel végén bontani kell, ez szintén a TCP protokollhoz hasonló módon történik. A protokoll implementációja nem végleges, így a munkám során egy fejlesztés alatt álló protokoll kellett tesztelnem. Hálózat emuláció A teszt környezet összerakásához szükség volt egy hálózatemuláló szoftverkörnyezetre is. A választásom a Dummynet-re esett, mely egy széles körben használt, megbízható szoftver. 3

Dummynet A Dummynet a FreeBSD beépített tűzfalára építkezik, kiegészítve azt olyan funkciókkal, amikkel lehetőségünk adódik a sávszélesség szabályozására, sorok és ütemezők módosítására, késleltetés, multi-path (több útvonal) emulálására, valamint csomagvesztéseket is állíthatunk be [4]. A használatához az ipfw eszközre van szükségünk, mellyel egyébként a tűzfalat is konfigurálhatjuk. A Dummynet nyújtotta funkciók eléréséhez úgynevezett pipe -okat kell rendelnünk a tűzfal szabályok közé, amikkel ezután emulálhatunk bizonyos környezeteket. Pl.: Egy pipe hozzáadása, majd konfigurálása, hogy a késleltetés 10ms legyen rajta minden IP forgalom-ra: ipfw add 10 pipe 1 ip from any to any ipfw config pipe 1 delay 10ms Az első sorban lévő tízes szám jelzi a tűzfal szabályok közt elfoglalt helyet (először az egyes szabályt ellenőrzi a rendszer, ha nem teljesül, akkor lép csak tovább), a pipe utáni egyes pedig az azonosító, ugyanis akár több szabályhoz is rendelhetünk egy pipe-ot. A pipe után meg kell adni, hogy mire legyen érvényes a szabály, jelen esetben a szabály bármely bejövő IP címről bármely cél IP cím irányába továbbítandó csomagra érvényes lesz. Az ipfw config pipe paranccsal konfigurálhatjuk a pipe-ot, jelen esetben 10ms késleltetést állítottunk be a csatornára (link). Megjegyzés: Egy kérés-válasz esetén a linken oda-vissza megy egy-egy csomag, így kétszer adódik hozzá a 10ms a késleltetéshez, azaz összesen 20ms lesz, amit könnyen tesztelhetünk a ping parancs segítségével. Egyéb pipe config paraméterek (továbbiak: [4]): plr csomagvesztést állíthatunk be, értéke 0 és 1 között lehet (1=100%-os dobás) bw sávszélesség beállítása, pl.: 1000Mbit/s queue sor méretét adhatjuk meg, pl.: 100 slot A munka állapota, készültségi foka a félév elején Linux környezet a laborban, mely tartalmazta a méréshez szükséges P7 implementációt, kliens-szerver programokat. P7 protokoll részletes ismertetői (TDK, szakdolgozat) Hálózatemulációs környezetekről publikációk Dummynet ismeretek 4

2. Az elvégzett munka és eredmények ismertetése Az általam konkrétan elvégzett munka bemutatása Tesztkörnyezet létrehozása A mérések elvégzéséhez szükség volt a megfelelő környezet kialakításához. Mivel az internetet teljes mértékben szoftveres módon emulálom egy számítógép segítségével, így a fizikai összeállításban csupán 3 számítógép és a közöttük lévő gigabites hálózatot megvalósító infrastruktúra szerepel (dumbbell topológia, 1. ábra). A mérésben résztvevő számítógépek és funkcióik: P7 Kliens gép Feladata a mérések során a P7 szerverrel felvenni a kapcsolatot, majd az előre meghatározott információt a megfelelő méretben átjuttatni a szervernek. HW: CPU: Intel Core 2 Duo E8400@3Ghz, RAM: 2Gbyte DDR2, LAN: TP- LINK TG-3468 PCI-E 1 Gbps hálózati kártya Operációs rendszer: TCP P7 lab20 - Debian Lenny Live (S.Szilárd) P7 Szerver gép Feladata a kliens gép által kezdeményezett kapcsolatkiépítést végrehajtani, a fogadott adatokból az eredeti információ dekódolása HW: CPU: Intel Core 2 Duo E8400@3Ghz, RAM: 2Gbyte DDR2, LAN: TP- LINK TG-3468 PCI-E 1 Gbps hálózati kártya Operációs rendszer: TCP P7 lab20 - Debian Lenny Live (S.Szilárd) Dummynet Feladata: A hálózat emulálása, kapcsolat biztosítása a P7 gépek között HW: CPU: Intel Core i3 530, RAM: 2Gbyte DDR2, LAN: 2 db TP-LINK TG- 3486 gigabit ethernet-es PCI-E hálózati kártya Operációs rendszer: FreeBSD 8.2 Gigabit Ethernet 10.0.1.10 P7 Kliens 10.0.2.20 P7 Szerver FreeBSD Dummynet 1. ábra tesztkörnyezet 5

A Linux-ot futtató számítógépek operációs rendszerében csupán a hálózati beállításokat kellett megadnom (IP cím, átjáró), amihez ráadásul rendelkezésemre állt pár Szilárd által készített szkript, míg a Dummynet-es gépet teljes mértékben nekem kellett telepíteni és bekonfigurálni. A telepítéshez a FreeBSD egy már általam is használt stabil verzióját használtam a 8.2-t. A telepítés során ügyelni kellett, hogy csak elsődleges partícióra lehet telepíteni a rendszert, logikairól nem képes megfelelően működni. A megfelelő hálózati funkciók elérhetővé tételéhez a következő módosításokat, konfigurációs parancsokat használtam a telepítés után (csak a méréshez szükségesek): Alap hálózati működéshez, routing funkciók ellátásához gateway_enable= YES firewall_enable= YES firewall_type= OPEN ifconfig_re0= inet 10.0.1.1 netmask 255.255.255.0 ifconfig_re1= inet 10.0.2.2 netmask 255.255.255.0 sysctl parancsok: A rendszer gyorsabbá tételéhez kern.sched.slice=1 kern.ipc.maxsockbuf=10485760 net.inet.tcp.delayed_ack=0 net.inet.ip.fastforwarding=1 Dummynet betöltés után ( kldload Dummynet ) net.inet.dummynet.hash_size=4096 net.inet.dummynet.io_fast=1 net.inet.ip.dummynet.pipe_slot_limit=100000 net.inet.ip.dummynet.pipe_byte_limit=1048576000 A konfigurálás során folyamatosan teszteltem az átviteli sebességet, így a kezdeti 470 Mbit/s átviteli sebességű, Dummynet-en áthaladó, TCP forgalmat sikerült 583 Mbit/s-ra növelni 2. A TCP mérést az iperf segédprogram segítségével végeztem, ahol is a P7 Szerver látta el az iperf server (iperf s w 65535) feladatát, míg a P7 Kliens volt az iperf kliens (iperf c 10.0.2.20 w 65535). A mérések megkönnyítése érdekében minden alkalmazott beállítás az operációs rendszer indulása során, illetve a bejelentkezéskor automatikusan betöltődött. Ehhez az alábbi fájlokat kellett kiegészítenem a konfigurációs bejegyzésekkel: /boot/loader.conf kern.hz 10000-re állítása 1000-ről (hány interrupt történhet 1 ms alatt) /etc/rc.conf hálózati beállítások.login sysctl beállítások alkalmazása, Dummynet betöltése Mérések elvégzése A mérések elvégzésekor egyaránt paraméterezni kellett a Dummynet rendszert és a P7 protokoll használatához készített alkalmazásokat (kliens-szerver) is. A hálózat emulációs beállításokat a pipe-ok konfigurálásával értem el, míg a P7 esetben a kliens oldalon a client3 programot kellett megfelelően paraméterezni, míg szerver esetén a server3 applikációt. A mérések során leginkább az elérhető legnagyobb sávszélességet vizsgáltam, miközben a 2 A Dummynet konfigurálásának kezdetén a hálózati kártyák RTL8169SC (gigabit) típusúak voltak mind a szerver, mind a kliens gépben, amiket később lecseréltem a már említett kártyákra, emiatt itt kisebb értékek láthatók, mint a későbbi ábrákon. A többi részegység nem változott a mérés során. 6

késleltetések és csomagvesztési értékek folyamatosan változtak a hálózatban. A P7-tel kapcsolatban újraadási értéket, adatmennyiséget változtattam, illetve a nyugtázást kapcsoltam ki/be. Nyugtázás esetén a P7 nyugták átvitele egy elkülönített, megbízható csatornán történik, amit a Dummynet-ben egy külön pipe létrehozásával oldottam meg, ami egy ideális csatornát valósított meg. A két pipe létrehozása: ipfw add 50 pipe 1 ip from 10.0.1.10 to 10.0.2.20 in ipfw add 99 pipe 10 ip from any to any Mint látható a 99-es szabály bármely IP címről jövő bármely cím felé menőre érvényes lesz, de csupán abban az esetben, ha az 50-es nem lép életbe. Ezzel elértem, hogy az adatforgalom az 1-es, a nyugták a 10-es pipe-ba kerüljenek. A TCP Reno és Cubic teszteket is a P7-hez rendelkezésre álló segédprogrammal végeztem el, a minél pontosabb összehasonlíthatóság érdekében, illetve az iperf optimalizáló viselkedése miatt. A P7-es tesztek minden esetben nyugtázásos esetet jelentenek, ugyanis nyugta nélkül hardveres és egyéb limitációk miatt nem minden esetben sikerült elvégeznem a méréseket. Fontos megjegyeznem, hogy ahol külön nem jelzem, ott a redundancia paraméter értéke 49, ami annyit jelent, hogy egy blokk 49 csomagból áll. Ha ezt az értéket növeljük, úgy nő a protokoll redundanciája, azaz jobban ellenáll a csomagvesztéseknek, azonban ez a hasznos adatátviteli sebesség csökkenésével jár. A 49-es érték egy kb. 10%-os plusznak felel meg (ε=0,095). A hibajavító kódolás miatt a fogadó oldalnak el kellene végeznie a dekódolást is, azonban ez jelen implementáció esetében még nem kiforrott, túl sok erőforrást igényel, ami visszafogja az átviteli sebességet is akár 4 Mbit/s-os értékig. Ezért a tesztek során a dekódolást kikapcsoltam, a fogadó gépnek ugyanis elég azt megállapítania, hogy a kapott csomagok mennyiségéből képes-e visszaállítani a kódolt információt vagy sem. Ezt pedig könnyen meg tudja állapítani, mivel az adatküldések során nem csupán a küldő, hanem a fogadó is tisztában van az átviendő adatmennyiség pontos értékével. A mérési eredmények összefoglalásához során csupán pár diagramot csatolok, a többi egy külön Excel fájlban található meg, illetve a beszámoló rövidsége miatt csak a tömör eredmények közlése történik meg. Az eredményeket a már említett P7 segédprogrammal kaptam meg, TCP New Reno és Cubic esetén eleve goodput 3 értéket kaptam, míg a P7 esetén throughput 4 eredményekből számítottam ki a goodputot, ami jelen esetben a kódolásból eredő adat többlet levonását jelentette. Ideális kapcsolat Az eredmények bemutatását a legegyszerűbb eset, az ideális kapcsolat eredményével vezetem be (5. ábra). A beállítások: Hálózati beállítás: ipfw pipe 1 config bw 0 plr 0 queue 1000M delay 0ms ipfw pipe 10 config bw 0 plr 0 queue 1000M delay 0ms Azaz, 0ms késleltetés, nincs csomagvesztés, 1000 slot-os sorméret, sávszélesség korlátozás nélkül. A pipe 10 beállítása minden mérésnél azonos, így a továbbiakban eltekintenék felsorolásától. 3 Goodput: Hasznos adatmennyiségre kapott adatátviteli sebesség 4 Throughput: Adatátviteli sebesség fejlécekkel és egyéb nem hasznos adatokkal 7

2. ábra Ideális kapcsolat mérési eredménye Az ábrán (4. ábra) látható, hogy a két TCP protokoll maximálisan 820Mbit/s átviteli sebességet ért el, amit a P7 a throughput esetben túl is szárnyal, azonban a kódolás miatti többletet levonva a goodput érték már csak 774Mbit/s, ami csupán 94%-os teljesítmény a két TCP változatéhoz képest. Hálózati forgalom csomagvesztéses kapcsolaton keresztül Hálózati beállítás: ipfw pipe 1 config delay 0ms plr [0,001;0,01;0,05;0,1;0,2;0,5] queue 1000 bw 0 Tehát a 0.1%, 1%, 5%, 10%, 20%, 50%-os csomagvesztéses eseteket vizsgáltam. A csomagvesztés növelésével rendre növelni kellett a redundancia paraméter értékét, azaz a kezdeti 49 csomag/blokk értéket is. Ezek megtalálhatók az ábra után következő táblázatban (1. táblázat). 3. ábra Csomagvesztéses kapcsolat mérési eredménye 8

Az ábráról (3. ábra) leolvasható, hogy a P7 bizonyos esetben képes akár az 50%-os csomagvesztést is jó sebességgel kezelni, amivel messze túlteljesíti a TCP Reno eredményeit is. Az ábrán ugyanakkor nem szerepel, de amennyiben a csomagvesztés a kapcsolat kiépítése során történik, úgy az adatátvitel ideje több másodperccel is megnőhet, vagy szélsőséges esetben (50%) akár sikertelenné is válhat, de ez igaz a többi TCP variánsra is. Redundancia értékek: Csomagvesztés (%) 0,1 1 5 10 50 Redundancia 52 54 61 68 148 Epszilon 0,162 0,207 0,363 0,52 2,308 Várt goodput (Mbit/s) 729 702 622 558 256 Mért goodput (Mbit/s) 730 703 623 562 262 1. táblázat Redundancia paraméter változása a csomagvesztés növelésével A táblázatban látható, hogy a sikeres adatátvitel érdekében mennyire kellett megnövelni a redundanciát. Az epszilon értéket az alábbi képlettel kaptam meg: ε = ([Csomagméret] * [redundancia paraméter] / [hasznos adat])-1 pl.: (1420*49/63536-1) = 0,162 Az epszilon segítségével pedig megállapítható, hogy elméletileg az adott kódolás mellett mekkora átviteli sebesség csökkenés kell kapnunk, amiből kiszámítható a várt sebesség. (1 - (ε / (1 + ε))) * [kezdeti átviteli sebesség] Hálózati forgalom késleltetéssel rendelkező kapcsolaton keresztül Hálózati beállítás: ipfw pipe 1 config delay [0; 5; 10; 100]ms plr 0 queue 1000 bw 0Mbit/s Azaz a 0, 5, 10, 100ms-os késleltetéses eseteket vizsgáltam. 4. ábra Késleltetéses kapcsolat mérési eredménye Megfigyelhető a 4. ábrán, hogy a késleltetés változtatásakor a P7 a többi TCP változathoz hasonlóan viselkedik, azaz a kis késleltetéseket jól bírja, azonban a nagyobb már a töredékére csökkenti az átviteli sebességet. 9

Mérések elemzése, összefoglalása A mérések során megismertem a P7 protokoll jelenlegi állapotának viselkedését, s nagyon értékes, érdekes tapasztalatokat szereztem egy új koncepcióról (további információk: [5]). A P7 nagyon érzékeny a paraméterezésére, ami majd különösképp megnehezítheti egy adaptív algoritmus kidolgozását a protokollhoz. A leginkább érzékeny paraméter ugyanakkor az újraküldést konfiguráló r, ami nagyon nagy befolyással van a használható sávszélességre, illetve hibatűrésre is. Viszont ez a hibatűrés igazán figyelemreméltó, hiszen nagyon magas csomagvesztés esetén gyors és megbízható adatátvitelt tesz lehetővé. A Dummynet, megfelelő konfiguráció után, egy könnyen használható rendszer, stabil alapokon, azonban nem mindig elég pontos. Például a késleltetések esetében az 5ms alatti értékek esetén nem a beállított értékeket kaptuk. A rendszer ugyanakkor sok konfigurálást is igényel, hogy nagy sebességű forgalmat is mérhessünk vele, ezért igyekeztem minden lehetséges mérési esetre szkriptet írni. A következő félévek során mégis jó alapot adhat a mérésekhez, azonban ehhez mélyrehatóbb módosításra lehet szükség. Összegezve, véleményem szerint van jövője a torlódásszabályozás nélküli protokolloknak, ugyanakkor a jelenlegi eszközök is fejlesztésre szorulnak, hogy minél pontosabban lehessen tesztelni a kutatási eredményeket. Összefoglalás A félév során célom volt, hogy minél pontosabb eredményekkel szolgálhassak a P7 jelenlegi állapotáról, amit úgy érzek sikerült is teljesíteni. A félév során több előre nem várt problémába ütköztem. Az egyik ilyen a PCI csatolóval rendelkező RTL8169SC hálózati kártyák sebességéből fakadt, ugyanis nem voltak képesek igazán megközelíteni az 1 gigabites sebességet, illetve elvileg ugyanolyan konfigurációban is különböző eredményeket kaptam velük, ami csomagok eldobásához vezetett. A jövőben szeretném folytatni a megkezdett munkát, azaz többfajta topológiára elvégezni a teszteket, hogy ez által is részese lehessek az egyetemen folyó kutatómunkának. 10

Beszámoló Péter (BPOX43) 2011-11-05 3. Irodalom, és csatlakozó dokumentumok jegyzéke A tanulmányozott irodalom jegyzéke: [1] The FreeBsd Project http://www.freebsd.org [2] OSI, Wikipedia: http://en.wikipedia.org/wiki/osi_model (2012.04.19.) [3] D. Clark, S. Shenker and A. Falk, GENI Research Plan, Version 4.5 of April 23, 2007. [4] Dummynet tutorial: http://cs.baylor.edu/~donahoo/tools/dummy/tutorial.htm (2011.12.01.) [5] Solymos Szilárd, TDK - Torlódásszabályozás nélküli transzport protokoll kutatása, 2010 Október [6] Roman Chertov, Sonia Fahmy, Ness B. Shroff, Fidelity of Network Simulation and Emulation: A Case Study of TCP-Targeted Denial of Service Attacks Febr. 2008 [7] Mike Hibler Robert Ricci Leigh Stoller Jonathon Duerig, Shashi Guruprasady Tim Stacky Kirk Webby Jay Lepreau, Large-scale Virtualization in the Emulab Network Testbed [8] Yixin Wu, Suman Kumar, Seung-Jong Park, On Transport Protocol Performance Measurement over 10Gbps High Speed Optical Networks 2009 IEEE [9] Marta Carbone, Luigi Rizzo, Dummynet Revisited, Volume 40, Number 2, April 2010 [10] Habibullah Jamal, Kiran Sultan, Performance Analysis of TCP Congestion Control Algorithms, INTERNATIONAL JOURNAL OF COMPUTERS AND COMMUNICATIONS Issue 1, Volume 2, 2008 11