DIGITÁLIS SZÖKŐKÚT ALAPÚ TRANSZPORT PROTOKOLL TESZTHÁLÓZATI VIZSGÁLATA

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék Csicsics Tamás DIGITÁLIS SZÖKŐKÚT ALAPÚ TRANSZPORT PROTOKOLL TESZTHÁLÓZATI VIZSGÁLATA KONZULENSEK Dr. Molnár Sándor, egyetemi docens Móczár Zoltán, doktorandusz BUDAPEST, 2013

Tartalom 1. Bevezetés... 1 1.1. Dokumentum felépítése... 1 1.2. Általános bevezetés... 1 1.3. Célkitűzések... 3 2. Elméleti összefoglaló... 5 2.1. Hálózati kommunikáció... 5 2.2. Szállítási protokollok... 8 2.2.1. TCP protokoll... 8 2.2.2. UDP... 9 2.3. Tesztkörnyezetben használt protokollok... 10 2.3.1. TCP Cubic... 10 2.3.2. TCP Reno... 12 2.3.3. DFCP protokoll... 13 2.4. FreeBSD... 15 2.5. DummyNet... 16 2.6. Előzmények... 18 3. Elvégzett munka bemutatása... 21 3.1. Tesztkörnyezet kialakítása... 21 3.1.1. FreeBSD telepítése... 23 3.1.2. Rendszer konfigurálása... 23 3.2. Topológiák kialakítása... 25 3.2.1. Dumbbell... 25 3.2.2. Parking lot... 28 3.3. Mérések elvégzése... 31 3.3.1. Dumbbell... 33 3.3.2. Parking lot... 35

4. Összefoglalás... 46 4.1. Mérések, DFCP összegzése... 46 4.2. Továbblépési javaslatok... 46 Irodalomjegyzék... 48 Ábrajegyzék... 49

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

Összefoglaló A diplomaterv célja egy új torlódásszabályozás nélküli, szállítás rétegbeli protokoll teljesítményelemzése, külön összehasonlítva egyes TCP (Transmission Control Protocol) variánsokkal. A protokoll fejlesztését a különféle TCP verziók gyengeségei tették szükségessé. A dolgozat tartalmazza a protokollok ismertetését, valamint a megértéshez szükséges egyéb elméleti összefoglalókat is. A mérések valós teszthálózatban készültek az egyetem egyik laborjában. A különféle hálózati jellemzőkkel (pl.: késleltetés, csomagvesztés) történő mérés érdekében DummyNet hálózat emulációs rendszer segítségével készültek a tesztmérések. A hálózat emuláló szoftver FreeBSD 8.2 operációs rendszeren futott, míg a hoszt gépek, amik között a tényleges adatátvitel történt Linux operációs rendszert futtattak. A diplomaterv külön kitér e teszthálózatok létrehozására, megtervezésére, a kiépített topológiák sajátosságaira. A mérések elsősorban nagysebességű csatornán történő adatátvitelre koncentrálódtak, ugyanis leginkább ezek azok a csatornák, amiket a TCP nem tud megfelelően kihasználni. Ezért a hálózati elemek között mindenhol 1 gigabites link biztosította a kapcsolatot. A mérések során sikerült kimutatni, hogy az új torlódásszabályozás nélküli megközelítés nem csupán egyszerűen működőképes, hanem egyes esetekben messze túlszárnyalja a TCP Cubic és New Reno eredményeit. Azonban a DFCP (Digital Fountain based Communication Protocol) protokoll még mindig csak kutatás alatt áll, nem végleges verzió, így rendelkezik hibákkal, amiket a jövőben meg kell oldani, például stabilitás, adaptív viselkedés. Diplomaterv Csicsics Tamás

Abstract The purpose of this Diploma Thesis document is to give testbed analysis of a new digital fountain based communication protocol with paying particular attention to compare it with various TCP (Transmission Control Protocol) versions. The research of this protocol was initiated by the weaknesses of TCP protocols. Those weaknesses are real issues especially when high speed networks are used. The thesis includes the description of the compared protocols and any other necessary knowledge to understand the analysis. The measurements were done in one of the laboratories of the Budapest University of Technology and Economics. The various network conditions were emulated by DummyNet which is a network emulation software. The DummyNet was running on a FreeBSD 8.2 operating system, while the host computers had Linux operating systems. This document describes what is the procedure of making the testbed, what was configured in DummyNet and in other softwares too. The result of this analysis showed that this new transport layer protocol has many advantages compared to TCP, especially when packet drop rate is high in the network. Of course it has some deficiencies too, for example fairness to other type of transport protocols, adaptive mechanism to change transmission adjustments based on packet loss. Diplomaterv Csicsics Tamás

1. Bevezetés 1.1. Dokumentum felépítése A diplomatervben először egy általános bevezetés található a tematika felvezetéséhez, kifejtve az utat, amely elvezetett az új protokoll szükségességéhez, azaz bemutatja az elterjedt szállítási protokollok gyengeségeit, amit az új megoldás orvosolni próbál. Ezen bevezető után a célkitűzés és feladatok részletes ismertetése következik. A ténylegesen elvégzett munka bemutatása előtt egy elméleti összefoglaló található, amely a munka megértéséhez szükséges fogalmakat, protokollokat ismerteti, valamint kitér az irodalomkutatásra is. Az elméleti rész után következik az elvégzett feladat ismertetése, a szükséges mérési rendszerek kiépítésével, a tényleges mérési sorozatok leírásával, valamint az eredmények ismertetésével és értékelésével. A dolgozat utolsó részében a végleges konklúziók, továbbfejlesztési lehetőségek elemzése található meg. 1.2. Általános bevezetés A mai modern világban életünk szerves részévé vált az internet használata. Manapság már nem csupán információkhoz jutáshoz, e-mail-ek írásához vagy olvasásához használhatjuk, hanem a hivatalos ügyek intézése is egyre általánosabbá válik, akárcsak ismerőseinkkel való kapcsolattartás is egyre inkább az internet segítségével történik. Ezeken kívül rengeteg egyéb dologhoz is lehetőséget nyújt a hálózat, például média tartalmakhoz való hozzáférés rohammértékben nő, gondoljunk csak a különböző videó megosztó, zenelejátszó portálokra. 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ülnek ki, hanem a lakosság nagy része találkozik vele függetlenül életkorától, nemétől vagy szakmájától. Ez a hatalmas felhasználói bázis (~4 milliárd ember) nem csupán hatalmas infrastruktúrális igényt jelent, hanem hatalmas üzletet is az internet szolgáltatóknak. A szolgáltatók, akik közé a mobilszolgáltatók is csatlakoztak, hiszen a saját hálózataik is egyre jobban távolodnak a TDM (Time Division Multiplexing) hálózatoktól, 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. 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 akár háztartási gépek is, amivel a hálózatok Diplomaterv 1 Csicsics Tamás

terhelése egyre csak nő, nem is beszélve az úgynevezett okostelefonokról, amelyek tudását gyakorlatilag lehetetlen internet kapcsolat nélkül használni. Magának az Internetnek 1 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, az ARPANET (Advanced Research Projects Agency Network). 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, valamint a hálózat kiterjedtsége se volt globális. Alapvetően a TCP egészen a közelmúltig, pontosabban a szélessávú internet általános elterjedéséig, jól látta el a feladatait, azaz elsősorban biztosította a sikeres csomagátvitelt és torlódásszabályzást a hálózatban. Napjainkra ugyanakkor jellemzővé váltak a nagysebességű internet hozzáférések, amelyek nem csupán nagyobb sávszélességet biztosítanak, hanem alacsonyabb késleltetéseket is a hálózatban, valamint gyakran megbízhatóbbak is. Azonban ezekkel a megnövekedett minőségi mutatókkal a hagyományos TCP protokoll nem tud lépést tartani, 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 az eredeti TCP megoldást 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 DFCP (Digital Fountain based Communication Protocol - Digitális szökőkút alapú transzport protokoll [12]), korábbi nevén P7, protokollal. 1 : Általában Internet -en a kezdeti USA-béli internetes hálózatot értjük, míg az internet az egész világra kiterjedő összekapcsolt hálózatot takarja Diplomaterv 2 Csicsics Tamás

A DFCP-hez kapcsolódó kutatási-fejlesztési feladatok a Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) TMIT (Távközlési és Médiainformatikai Tanszék) tanszékén folynak. A projekt vezetője Dr. Molnár Sándor egyetemi docens, további főbb tagok: Dr. Sonkoly Balázs oktató, Móczár Zoltán doktorandusz, Solymos Szilárd hallgató. Mint minden fejlesztés során jelen esetben is kisebb lépésekben történik a munkavégzés, minden ilyen részfeladat, részcélkitűzés esetére szükség van a folyamatos tesztelésekre, visszajelzésekre, amik segítségével hatékonyabbá lehet tenni a fejlesztést, illetve pontosan megállapítható, hogy hol is, hogyan áll a projekt, illetve az addig elvégzett munka. A feladatom ezeknek a teszteknek az elvégzése volt, hogy az eredmények alapján visszajelzéseket kapjon a projekt csapat. Mivel a cél az internet szállítási protokolljának leváltása, így a tesztek során törekedtem a minél életszerűbb környezetekhez, hiszen a világon leginkább elterjedt protokoll volt a viszonyítási alap. 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, főleg nemzetközi összefogásokkal érhető csak el. Szerencsére, hogy ezt a célt megközelíthessük többféle 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 egyike sem tökéletes, ugyanakkor relatív jó visszajelzést adnak a hálózatok viselkedéséről. Mivel mindegyikük külön jellemzőkkel bír, ezért a projektben törekedtünk, hogy egyaránt rendelkezésre álljanak szimulációs és valódi tesztkörnyezetben végzett mérések is. 1.3. Célkitűzések A diplomaterv célja, hogy a DFCP protokollt valós hálózati elemek segítségével kialakított környezetben tesztelje, amihez a műszaki egyetem egyik laboratóriuma, az I. épületben található IB213 állt rendelkezésre. A mérések során alkalmazott különféle topológiákban közös, hogy a hálózati paraméterek váltakozását FreeBSD [1] operációs rendszeren futó DummyNet [2] szoftver emulálta. A méréseket nem elég csupán a fejlesztés alatt álló DFCP protokollal elvégezni, hiszen annak az eredményei mellett legalább olyan fontos a manapság általánosan elterjedt szállítási protokollokkal való összehasonlítás is. Ehhez fel kell vezetni a meglévő TCP protokollokat, kitérni a jellemzőikre, majd ezek után pedig következhet a DFCP elve, kihangsúlyozva az eltéréseket, legelsősorban a torlódásszabályzás nélkülözését. A Transmission Control Diplomaterv 3 Csicsics Tamás

Protocol számos változata érhető el, ugyanakkor a dolgozatban részletesen csupán két rendkívül elterjedt változat kerül ismertetésre, a TCP Cubic és a TCP New Reno. A tesztelendő protokollok meghatározásán kívül fontos volt a tesztkörnyezet pontos megtervezése és dokumentálása is, amihez a kutatói körökben is általánosan használt, ismert topológiák kerültek kialakításra. A mérések elsősorban a teljesítményelemzésre koncentráltak, pontosabban a linkeken elért adatátvitel sebességére, amiből könnyen megállapítható a fizikai kapcsolatok kihasználtsága is. A mérések eredményeiből táblázatok és grafikonok készültek az egyszerűbb átláthatóságért és könnyebb összehasonlíthatóságért. Diplomaterv 4 Csicsics Tamás

2. Elméleti összefoglaló Az alábbi összefoglaló célja, hogy az elvégzett munka megértéséhez szükséges ismereteket meghatározza, elérhetővé tegye. Első részben a szállítási protokollok kerülnek meghatározásra, pontosabban a TCP Cubic, New Reno valamint DFCP sajátosságai, illetve egy rövid általános hálózati adatátviteli rész is bemutatásra kerül. Ezután a tesztkörnyezet kialakításához felhasznált eszközökről, szoftverekről lesz szó. 2.1. Hálózati kommunikáció A hálózati kommunikációhoz [3] nem csupán a megfelelő hardverek szükségesek, hanem a hozzájuk kapcsolódó szoftveres támogatás is. OSI modell TCP/IP modell 7 Alkalmazási réteg APDU 6 Megjelenítési réteg PPDU Alkalmazási réteg 5 Viszony réteg SPDU 4 Szállítási réteg TPDU Szállítási réteg 3 Hálózati réteg Csomag Internetréteg 2 Adatkapcsolati réteg Keret Hoszt és hálózat réteg 1 Fizikai réteg Bit 2.1 ábra OSI és TCP/IP modell Diplomaterv 5 Csicsics Tamás

A különböző hálózatok közös jellemzője a nagymértékű strukturáltság. Elsősorban a tervezés bonyolultságának csökkentése érdekében a legtöbb hálózatot úgy alakítják ki, hogy azok egymásra épülő rétegeket vagy szinteket képezzenek. Ezen rétegek elnevezése, funkciója különbözhet az egyes hálózati megoldásokban. Minden rétegnek ugyanakkor közös a célja, szolgáltatásokat nyújtani a felette elhelyezkedő rétegnek, miközben a tényleges megvalósítás rejtve marad, azaz a szolgáltatásokat a rétegek interfészeken keresztül nyújtják a felettük elhelyezkedő szinteknek. A rétegekbe szervezett hálózati megoldások legismertebb változatai az OSI (Open System Interconnection) és a TCP/IP hivatkozási modell (2.1 ábra). Az OSI modell hét különböző réteget különböztet meg, mindegyiknek külön feladata van, ezeknek a rövid leírása: Fizikai réteg Feladata, hogy a biteket továbbítsa a kommunikációs csatornán, miközben biztosítja, hogy a bitek változás nélkül érkezzenek meg a másik oldalra. Főként a csatorna fizikai jellemzőivel foglalkozik, például a feszültség szintekkel, kábeljellemzőkkel. Segítségével elérhető, hogy a felette elhelyezkedő rétegek számára transzparens legyen a csatorna pontos kialakítása, típusa. Adatkapcsolati réteg Biztosítja azokat a funkciókat és eljárásokat, amelyek két hálózati elem közötti adatátvitelt tesznek lehetővé. Az átvitelt úgy oldja meg, hogy az átviendő adatokat a küldő oldalón adatkeretekbe tördeli, amelyeket sorrendben továbbít a fizikai réteg felé. Része a közeg-hozzáférési alréteg is, amely az osztott csatornákhoz való hozzáférést szabályozza. Az átvitelhez fizikai szintű egyszerű címzési sémát használ, azaz a használt címek fizikai címek (pl.: Media Access Control címek), legismertebb rétegbeli példa az Ethernet specifikáció. Hálózati réteg Feladata a változó hosszúságú adatok átvitelének biztosítása a küldő féltől egészen a címzettig. A küldő és fogadó fél között több hálózati elem és alhálózat is szerepelhet, így a hálózati réteg biztosítja az útvonalválasztást közöttük, illetve szükség esetén szegmentálást is biztosít. Ebbe a rétegbe Diplomaterv 6 Csicsics Tamás

tartozik az IP protokoll, illetve a hálózati útvonalválasztók (router-ek) is ezen réteg alapján dolgoznak. Szállítási réteg A szállítási réteg feladata az, hogy lehetővé tegye a forrás- és célállomásokban található társentitások közötti párbeszédet a viszonyrétegnek nyújtott szolgáltatások által. A fogadott adatokat szükség esetén feldarabolja, majd továbbítja a hálózati réteg felé. A viszonyréteg felé nyújtott szolgáltatásai által dől el, hogy a hálózat felhasználói számára milyen hálózati szolgáltatások állnak rendelkezésre. Ebbe a rétegbe tartoznak a dolgozat által tárgyalt DFCP és TCP protokollok is. Viszony réteg A réteg lehetővé teszi, hogy két gép egy viszonyt (session) hozzon létre egymás között, amelyek többféle szolgáltatást valósíthatnak meg. Ide tartoznak például a párbeszéd alapú adatátvitel, szinkronizáció, vezérjel kezelés. Ezek a szolgáltatások nem elengedhetetlenek, ugyanakkor minden alkalmazás számára előnyös lehet használatuk. Megjelenítési réteg Az átvitt információ szintaktikájával és szemantikájával foglalkozik. Ide értendő például az adatok ábrázolása, szerkezete, kódolása valamint az adattömörítés is. Itt történhet például egy soros adatfolyam XML (Extensible Markup Language, Kiterjeszthető Jelölő Nyelv) formátumba való alakítása, illetve visszaalakítása is. Alkalmazási réteg A réteg olyan protokollok sokaságát tartalmazza, amelyre a felhasználóknak gyakran szüksége van. Például állományok átvitelére az FTP (File Transfer Protocol), böngészéshez a HTTP (HyperText Transfer Protocol), de ide tartoznak az SMTP (Simple Mail Transfer Protocol), Telnet protokollok is. Diplomaterv 7 Csicsics Tamás

A TCP/IP a fentiekben ismertetett felépítéstől kis mértékben tér csak el, ugyanakkor ez az a modell, ami a világon leginkább elterjedt, köszönhetően az internetnek. Az OSI modellben megismert fizikai és adatátviteli réteg szerepét itt egy közös réteg látja el a hoszt és hálózat réteg. Ezután következik az internet réteg, melynek feladata gyakorlatilag megegyezik a hálózati rétegével, ugyanakkor mindig az IP protokollt használja a források és a címzettek közötti útvonalválasztásra. A szállítási rétegben helyezkedik el a TCP, majd az erre épülő viszony, megjelenítési és alkalmazási réteget a TCP/IP egységesen alkalmazási rétegnek kezeli. 2.2. Szállítási protokollok A szállítási rétegben többféle protokoll is megtalálható, azonban két különböző típus terjedt el, illetve általánosan használt, világszerte: A TCP és az UDP (User Datagram Protocol). 2.2.1. TCP protokoll A Transmission Control Protocol egy megbízható összeköttetés alapú protokoll, mégpedig úgy képes megbízható adatátvitelt biztosítani, hogy az alatta elhelyezkedő rétegben akár megbízhatatlan protokoll is lehet. Ezáltal hibamentes átvitelt tud biztosítani bármely két gép között az interneten. A protokoll kapcsolatorientált, a kapcsolatba lépő feleknek kölcsönösen nyugtázni kell a másik entitásnak a kapcsolat létrejöttét. A kapcsolatok azonosítására szolgálnak a portok, mégpedig kliens szerver kapcsolat esetén a szerver egy adott porton érkező kérésekre figyel, és az ott érkező kéréseket kiszolgálja. A TCP portok közül az első 1024 általános alkalmazás számára lett lefoglalva [11]. A protokoll ezen kívül a kommunikáció során beérkező küldendő bájtos adatfolyamot diszkrét méretű üzenetekre osztja, majd azokat egyesével továbbítja az internet rétegnek. A megbízhatóság érdekében a protokoll a teljes csomag tartalmára számol egy ellenőrző összeget, amellyel megállapítható, hogy a csomag sikeresen érkezett-e meg a céljához, illetve ezen kívül minden elküldött csomag után nyugtát is vár a küldő fél. Ha a nyugta nem érkezik meg, vagy nem jó sorrendben érkeznek a nyugták, akkor a küldő fél megismétli a megfelelő csomagtól az adást. A célállomás TCP folyamata összegyűjti a beérkezett üzeneteket, és egyetlen kimeneti adatfolyamként továbbítja őket a felsőbb réteg felé, miközben az előbb említett módon nyugtázza is a kapott csomagokat. A TCP forgalomszabályozást is végez annak Diplomaterv 8 Csicsics Tamás

é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. 2.2.1.1. TCP torlódásvezérlés Probléma a TCP-vel, hogy a torlódásvezérlője nem képes univerzális, optimális megoldást nyújtani a folyamatosan változó, heterogén környezet okozta kihívásokra. Torlódásvezérlő feladatai: Hálózat elárasztása ellen véd Az adó irányítja, ahogy érzékeli a csomagvesztést Torlódásnál a küldő felezi a küldési ablakméretet, ha nincs torlódás, lineárisan növeli a kapott nyugták alapján. Például 5ms RTT (Round-trip time csomag körbefordulási ideje) esetén, a nyugták 5ms-onként érkeznek, így 0.1 másodperc alatt 100 csomaggal nőhet, azaz függ az RTT-től, míg egyetlen vesztés esetén egyből a felére esik vissza. Az egyik leglátványosabb hátránya, a csomagvesztésnél történő drasztikus ablakméret csökkentés, ami lassú hálózatoknál nem annyira szembetűnő, mint nagysebességűek esetén, hiszen ilyenkor a TCP-nek számottevő időre van szüksége, hogy elérje a csomagvesztés előtti sebességet, ezáltal a link kihasználtsága alacsony marad. Mint a 2.3. ábrán is látszik, a TCP nem képes fenntartani folyamatosan a nagy ablakméretet és ezzel nagyobb sávszélességet, főleg ha nem csupán a nagy ablakméret miatt keletkezik csomagvesztés a linken. 2.2.2. UDP Az UDP 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 csomag megérkezését, nem kapcsolatorientált, nincs hibajavítás, valamint nyugtázást sem használ. Az említetteken kívül az UDP a biztonsággal sem foglalkozik, nem támogatja az adatok titkosítását, ahogy egyéb biztonsági eljárásokat sem. UDP alapú 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. Az egyszerűbb működésnek megfelelően az UDP fejléce is kisebb a TCP fejlécénél, így Diplomaterv 9 Csicsics Tamás

kisebb a keletkező overhead is, illetve nagy előnye a TCP-vel szemben, hogy nem csupán a pont-pont adatátvitelt támogatja, hanem a pont-multipontot is. 2.3. Tesztkörnyezetben használt protokollok A TCP gyengeségeinek javítására, kiküszöbölésére több protokoll is készült az évek során, de ezek egyike sem tudta ténylegesen elhagyni a TCP alapjaiból következő hátrányokat. A következőkben a DFCP-vel összehasonlított variánsok ismertetése következik, majd az új protokoll bemutatásával folytatódik a dolgozat. 2.3.1. TCP Cubic A Cubic [4] egy csomagvesztés alapú torlódásszabályzással rendelkező TCP variáns, 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 az igazságosságot (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 ablakméret növelési algoritmusa egy köbös függvényt használ, aminek a formája nagyon hasonlít a BIC által alkalmazott függvény formájához. Egyik nagy előnye, hogy az ablakméretet növelése nem az RTT-től függ, hanem csak a legutolsó torlódástól. Az ablakméretet a következőképpen határozza meg: W cubic = C(t K) 3 + W max Ahol W cubic a használt ablakméret, a C egy skálázási faktor, t az eltelt idő, W max a legutolsó hiba (torlódás, csomagvesztés) előtti ablakméret. A K értékét a következőképpen lehet meghatározni: 3 K = W max β/c A β egy konstans együttható a csökkentés mértékét határozza meg, pl. vesztés esetén az új ablakméret βw max lesz. Az ablakméret alakulása (2.2. ábra): Diplomaterv 10 Csicsics Tamás

2.2. ábra Cubic ablaknövelési függvénye (forrás: [4]) A CUBIC ablak mérete nagyon gyorsan nő egy redukció után, de amint a W max közelébe ér, lelassul a növekedése, pontosabban ezen érték közvetlen közelében az ablakméret gyakorlatilag nem nő. W max ablakméret felett, az ablak mérete lassan növekszik, majd egyre felgyorsul, ahogy távolodik. A W max közelében lévő lassú növekedés erősíti a protokoll stabilitását és növeli a hálózat használhatóságát, míg a gyors növekedés biztosítja a protokoll skálázhatóságát. A torlódási ablak valós idejű növelése erősíti a protokoll fairness tulajdonságát. Fontos megjegyezni, hogy más késleltetés függő protokollok ablakméret növelő függvényei arányosan gyorsabban nőnek a kisebb RTT-vel rendelkező hálózatokban, ahol a CUBIC az RTT-től függetlenül növekszik. A kis RTT barátságosabbá teszi a CUBIC-ot a TCP-re, viszont kis késleltetéssel rendelkező hálózatokban a protokoll ablakméret növelése lassabb, mint a hagyományos TCP esetében. Bár a Cubic sok esetben javít a TCP teljesítményén még mindig nem képes megfelelően kiaknázni egy nagysebességű link kapacitását, ha az nagyobb késleltetéssel, illetve valamekkora csomagvesztéssel is rendelkezik. Diplomaterv 11 Csicsics Tamás

2.3.2. TCP Reno A TCP Reno változattal számos ponton javítottak az eredeti TCP protokoll torlódásszabályzásán. Ez a változat a négy torlódásvezérlő algoritmussal (2.3. ábra) próbálja meg elkerülni a torlódást: 2.3. ábra TCP Reno torlódásszabályzása forrás: [13] Slow Start: A Slow Start fázis a nevével ellentétben egyáltalán nem lassú, a torlódási ablakot (congestion window - cwnd) exponenciálisan növeli, egészen addig, míg elér egy (lassú) kezdési küszöb értéket (slow start threshold - sstresh) vagy a hálózatban torlódás alakul ki. Congestion Avoidance: A Slow Start után következik a torlódáselkerülési fázis (Congestion Avoidance), mikor az ablakméret növelése nagymértékben lelassul, pontosabban a mechanizmus ekkor minden beérkező nyugtára 1/cwnd értékkel növeli az ablakméretet. Így az ablak mérete megközelítőleg lineáris növekedést mutat, míg egy torlódási esemény (például csomagvesztés) be nem következik. Ha a torlódás bekövetkezett, akkor a forrás felére csökkenti az ablakméretet, az elveszett csomagot vagy csomagokat újraküldi, majd az ablak méretét újra elkezdi lineárisan növelni a következő torlódásig. Ha timeout történt, akkor a torlódási ablak értékét visszaállítja egyre, és újra kezdődik a Slow Start fázis. Diplomaterv 12 Csicsics Tamás

Fast Retransmit és Fast Recovery: A csomagvesztés gyorsabb detektálását teszi lehetővé. 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. Az újraküldött csomagok átvételéről a vevő nyugtát küld a küldőnek, így az nyomon követheti a helyreállítás állapotát. A küldő ebben az esetben azért nem lép újra a Slow Start fázisba, mert a duplikált nyugták egyben azt is jelzik, hogy a vevőbe továbbra is érkeznek csomagok, hiszen azok hatására generálja a vevő a duplikált nyugtákat. Az átviteli sebesség teljes lecsökkentése ezért indokolatlan lenne. A TCP Reno protokoll előzőekben ismertetett torlódásvédelmi mechanizmusát összefoglaló néven AIMD (Additive Increase Multiplicative Decrease Additív növelés multiplikatív csökkentés) mechanizmusnak nevezzük. 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áltuk SACK (Selective Acknowledgement) opcióval. 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. 2.3.3. DFCP protokoll Alapkoncepciója egy GENI [5] által javasolt elképzelés, 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 pedig hatékonnyá teszi az alkalmazott módszert. A DFCP a hibajavító kódoláshoz digitális szökőkút alapú kódolást használ [6], amely elméletben kódszavakból álló végtelen hosszúságú folyamot képes generálni. A Diplomaterv 13 Csicsics Tamás

fogadó félnek ezért nincs szüksége minden blokk sikeres fogadására, elég csupán az átküldött adatoknak annyi részletét fogadni, amelyből már sikeresen dekódolhatja az átvitt információt. A kódoláshoz a protokoll Raptor kódolást [7] használ. Például ha az eredeti üzenet k méretű, akkor az átküldött folyam bármely 1 + ε k része elegendő a dekódoláshoz, ahol ε a redundancia paraméter. A DFCP 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 DFCP 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. 2.4. ábra DFCP adatküldése forrás: Torlódásszabályozás nélküli transzport protokoll kutatása TDK [8] Diplomaterv 14 Csicsics Tamás

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. Az adatküldés folyamata megtekinthető a 2.4. ábrán. A protokoll implementációja nem végleges, így a munka során egy fejlesztés alatt álló protokollt kellett tesztelni. 2.4. FreeBSD A FreeBSD egy fejlett operációs rendszer, amelynek alapjait a Berkeley egyetemen kifejlesztett BSD típusú UNIX rendszer adta. A fő erőssége a hálózati kommunikáció, így leginkább intranetes vagy internetes kiszolgálóként szokás üzemeltetni. Széles körű támogatást nyújt a processzorok számára, azaz támogatja mind az x86, amd64, PowerPC, ARM, UltraSPARC architektúrákat is, így a beágyazott rendszerektől kezdve a nagy teljesítményű kiszolgálókig mindenhol használható. A BSD rendszernek más típusai is elterjedtek, ugyanakkor a FreeBSD rendelkezik a legnagyobb felhasználói bázissal. Ez, illetve a fentebb említett tulajdonságok miatt esett a választásom erre a rendszerre. A többi nyílt forráskódú verzió [1]: A NetBSD a lehető legnagyobb hordozhatóságra törekszik. Elfut a palmtopokon és a nagy szervereken egyaránt, és a NASA is használja az űrkutatásai során. Az OpenBSD a biztonságra és a kód egyszerűségére koncentrál: a nyílt forrású koncepciót kombinálják a szigorú ellenőrzésekkel, hogy így egy bizonyítottan korrekt rendszert hozzanak létre, megoldást kínálva ezzel a biztonságot megkövetelő szervezeteknek, mint például bankoknak, tőzsdéknek és amerikai kormányügyi szervezeteknek. Diplomaterv 15 Csicsics Tamás

A DragonFlyBSD a nagy teljesítményt és a skálázhatóságot célozza meg az egyszerűbb rendszerektől kezdve a hatalmas, fürtözött rendszerekig. Számos hosszútávú technikai célja van, de a legfontosabb, hogy egy olyan SMP-képes infrastruktúrát hozzon létre, amely könnyen érthető és karbantartható, valamint könnyű rá fejleszteni. Érdemes még megemlíteni, hogy a MAC OS X is BSD alapokra épít, ugyanakkor ez az operációs rendszer már nagy részben zárt forráskódú. A különböző Linux disztribúciókhoz képest általában a FreeBSD stabilabb és bizonyos esetekben gyorsabb operációs rendszer. A nagy előnye még, hogy készítettek hozzá egy Linux kompatibilitási csomagot, amivel sok eredetileg Linux operációs rendszerre írt program BSD alatt is futtathatóvá válik, ez a lehetőség ugyanakkor csak egyirányú, azaz Linux alatt nem futtathatóak BSD alkalmazások. 2.5. DummyNet A DummyNet egy élő hálózat emuláló eszköz, ami eredetileg különböző hálózati protokollok teszteléséhez készült. A szoftver elérhető mind BSD, OSX, Linux és Windows operációs rendszerekre is, azonban a tapasztalataink alapján a legmegbízhatóbban BSD rendszer alatt fut. Több ismertebb rendszer is használja linkek emulálására, ilyen az Emulab és a PlanetLab is. A DummyNet működése során (2.5. ábra) a különböző szabályokkal kiválasztott forgalmat elfogja, majd a beállított tulajdonságok emulálása után visszairányítja az eredeti cél felé. 2.5. ábra Dummynet működés forrás: [2] Diplomaterv 16 Csicsics Tamás

A forgalom kiválasztása, vagyis kijelölése a FreeBSD beépített tűzfalára építkezik, kiegészítve azt olyan saját funkciókkal, amikkel lehetőség 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) szimulálására, valamint csomagvesztések beállítására is [9]. A használatához az ipfw eszközre van szükség, mellyel egyébként a tűzfal is konfigurálható. A DummyNet nyújtotta funkciók eléréséhez úgynevezett pipe -okat kell rendelni a tűzfal szabályok közé, amikkel ezután különféle hálózati környezetek emulálása válik lehetővé. 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özött elfoglalt helyet (először az egyes szabályt ellenőrzi a rendszer, ha nem teljesül, akkor lép csak tovább a sorban következő szabályra), a pipe utáni egyes pedig a pipe azonosítója, ugyanis akár több szabályhoz is rendelhetjük. A pipe után meg kell adni, hogy mire legyen érvényes a szabály, jelen esetben a szabály minden bejövő ip címről minden ip cím irányába továbbítandó csomagra érvényes lesz. Az ipfw config pipe paranccsal konfigurálható a pipe, jelen esetben 10ms késleltetést kapott a 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, ami könnyen le is tesztelhető a ping parancs segítségével. Egyéb pipe config paraméterek (továbbiak: [9]): plr csomagvesztést adható meg, é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érete adható meg, alapesetben a maximális értéke 100 slot, azaz 100 csomag. Több folyamos mérésekhez szükséges, hogy különböző sorokat definiálhassunk és ezek közül egy ütemező tegye be a csomagokat egy adott pipe-ba. Egy egyszerű példa erre: Diplomaterv 17 Csicsics Tamás

ipfw add 5 queue 1 ip from 10.0.1.1 to any ipfw add 6 queue 2 ip from 10.0.2.2 to any ipfw config pipe 1 delay 10ms bw 100Mbit/s ipfw queue 1 config plr 0.1 weight 20 pipe 1 ipfw queue 2 config plr 0 weight 80 pipe 1 Az első két sorban látható a sorok (queue-k) létrehozása, miszerint azok a csomagok, melyek forrás IP címe 10.0.1.1 vagy 10.0.2.2 rendre kerüljenek az egyes, illetve kettes számú sorba. A harmadik parancs a már jól megismert pipe beállítás, miszerint 10ms késleltetéssel és 100Mbit/s sávszélesség korlátozással rendelkezzen a pipe. Az utolsó két parancs a sorok beállításai, mégpedig két kötelező paraméterrel (weight, pipe) és egy opcionálissal (plr). A plr nem más mint a csomagvesztés értéke, ami 0 és 1 közötti értéket vehet fel, ahol 1 a 100%-os csomagvesztést jelöli. A kötelező paramétereknél a weight jelzi a súlyozást, ugyanis alapértelmezés szerint a DummyNet WF2Q+ ütemezést használ, amihez meg kell adni a súlyozást is. A 80, 20-as beállítás ebben az esetben megfelel a 80% - 20%-os sávszélesség kiosztásnak. Fontos megjegyezni, hogy ez a szabály csak abban az esetben érvényesül, ha mindkét sorba érkezik csomag, azaz mindkét folyam aktív. Ha csak az egyik aktív, úgy az a teljes kapacitást megkapja. Az utolsó paraméter pedig az, hogy a sorból a csomagok hova kerüljenek, azaz egy pipe-nak az azonosítója. 2.6. Előzmények A diplomatervezés előtt már az önálló laboratórium keretében egy egyszerű topológiára (2.6. ábra) készültek úgynevezett validációs mérések, amik bizonyos támpontot adtak a jelen dolgozatban ismertetett mérések értelmezéséhez, kiértékeléséhez. Valamint rendelkezésre állt a hoszt gépekre egy módosított Linux verzió, amely tartalmazta a DFCP protokoll aktuális implementációját, valamint egy DFCP protokoll használatával adatátvitelt megvalósító alkalmazás is, mely az elért sávszélességeket is rögzítette, illetve egy feltelepített FreeBSD környezet, DummyNettel. Az egy folyamos, ideális kapcsolaton kapott eredmények [10] a 2.7. ábrán láthatóak (Megjegyzés: A DFCP protokoll az eredmények kiértékelésekor még P7 néven volt ismert). Diplomaterv 18 Csicsics Tamás

DFCP kliens Emulált hálózat (DummyNet) 2.6. ábra Egyszerű egy folyamos topológia Ideális kapcsolat 900 850 848 820 823 800 774 750 700 DFCP throughput DFCP goodput TCP Cubic TCP Reno 2.7. ábra Ideális kapcsolat esetén mért adatátviteli sebességek Mbit/s-ban A grafikon (2.6. ábra) a DFCP protokollhoz két érték is tartozik. Az egyik az úgynevezett goodput, ami nem más mint a kizárólag hasznos adatátvitelre vonatkozó érték, azaz nincsen benne fejlécekből, kódolásból eredő overhead. A throughput viszont nem csupán a hasznos adat tartalmazza, hanem a digitális szökőkút alapú kódolásból eredő többletet is. Egyéb mérések során ebbe az értékbe a csomag fejlécéből (pl. TCP, IP fejléc) származó overhead-et is bele szokás számolni, azonban jelen dolgozatban a DFCP throughput-on csakis a hasznos adat és a kódolásból eredő többlet együttes átviteli sebességét értjük. A Cubic és New Reno protokolloknál egyaránt a goodput eredmények kerültek ábrázolásra több okból kifolyólag is. Az egyik, hogy nehéz kiszámítani a pontos overhead-et TCP esetére, ugyanis a fejléc mérete változhat, a Diplomaterv 19 Csicsics Tamás

másik ok pedig, hogy az internet felhasználói szempontjából is a goodput érték az igazán meghatározó. Az eredmények hűen tükrözik, hogy a DFCP a maximális adatátviteli sebességre törekszik, hiszen képes elérni 848 Mbit/s-os átvitelt is szemben a Reno 823 Mbit/s és a Cubic 820 Mbit/s értékével szemben. Azonban az említett kódolás miatt a DFCP goodput értéke mégis alacsonyabb lesz, mindössze 774 Mbit/s. Ebből leszűrhető, hogy ideális körülmények között az új TCP variánsok nagyobb sávszélességet képesek elérni a DFCP-hez viszonyítva, ugyanakkor a későbbiekben láthatjuk, hogy koránt sem ideális esetben a DFCP sokkal jobb és stabilabb eredményeket képes elérni a TCP-nél. Diplomaterv 20 Csicsics Tamás

3. Elvégzett munka bemutatása A mérési környezet kialakítása nagyon hosszadalmas munkát igényelt, ugyanis a DFCP protokoll jelenleg nagyon érzékeny a különböző hardveres konfigurációkra. A kialakítás kezdetekor az eltérő hálózati kártyák is hátráltatták a kiépítést, ugyanis hiába gigabitesek, az eltérő csatlakozás és vezérlőchipek miatt más átviteli sebességekre képesek, ami miatt egyes kártyák küldési sebességét a fogadó kártyák nem tudták kezelni, ezért a tervezés elején azonos típusúra kellett cserélni. 3.1. Tesztkörnyezet kialakítása A mérési környezet topológiánként eltérő, így külön alfejezetekben találhatók meg a kialakítás lépései, ugyanakkor a használt eszközök megegyeznek, így ezek ismertetőjével kezdődik a fejezet. Alapvetően a mérések során három különböző funkciójú számítógépre volt szükség: Kliens Adatküldő számítógép, mely csatlakozást kezdeményez a szerver gép felé, majd sikeres csatlakozás után megkezdi a kijelölt protokoll segítségével történő adatátvitelt. DFCP Linux fut rajta. Hardver (Dumbbell topológia esetén a szerver gépekkel egyezett meg a hardveres konfiguráció): Processzor: Intel Core i3 530 Memória: 2Gbyte DDR3 LAN interfész: 1 db RTL8169SC gigabit ethernet-es hálózati kártya Operációs rendszer: TCP P7 lab20 - Debian Lenny Live (Solymos Szilárd) Jelölés: Dumbbell topológia esetén A1 és A2, Parking lot esetén C1-C3. Szerver Folyamatosan fut rajta egy szerveralkalmazás, mely a bejövő kéréseket fogadja, hogy kapcsolat épülhessen ki a kliens és szerver között az adatátvitel megkezdéséhez. Adatátvitel során ez a fogadó gép. DFCP Linux fut rajta. Hardver: Diplomaterv 21 Csicsics Tamás

Processzor: Intel Core 2 Duo E8400@3Ghz Memória: 2Gbyte DDR2 LAN interfész: 1 db RTL8169SC gigabit ethernet-es hálózati kártya Operációs rendszer: TCP P7 lab20 - Debian Lenny Live (Solymos Szilárd) Jelölés: Dumbbell topológia A3 és A4, Parking lot esetén A1-A3. DummyNet FreeBSD operációs rendszert futtató hálózati emulációt biztosító számítógép. Legalább négy darab gigabites hálózati interfésszel kell rendelkeznie, hogy egyszerre négy számítógéppel is közvetlen kapcsolatban lehessen. Tipikusan két kliens és két szerver között emulálja a különböző hálózati sajátosságokat. Hardver: Processzor: Intel Core i3 530 Memória: 2Gbyte DDR3 LAN interfész: 3 db RTL8169SC gigabit ethernet-es hálózati kártya, 1 db Intel (alaplapi) Operációs rendszer: FreeBSD 8.2 A környezet kialakítása során fontos szempont volt, hogy lehetőleg azonos típusú gépeken történjenek a mérések, amivel a hardveres eltérésekből adódó torzításokat lehet csökkenteni. Sajnos a laborban nem állt rendelkezésre ilyen mennyiségű teljesen egyforma számítógép, ezért főként a már említett típusbesorolás alapján lettek a gépek kiválogatva, illetve kevesebb hálózati elemet érintő mérések esetén az elérhető legnagyobb átviteli sebesség alapján lettek kiválasztva. A fizikai kialakításon kívül szükség volt a számítógépek megfelelő konfigurálására is. 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 megadni (IP cím, átjáró, statikus útvonalak), míg a DummyNet gépek esetében friss telepítéssel kezdődött a munka, és csak ezután jött a beállítások finomhangolása. A telepítéshez a FreeBSD egyik utóbbi stabil verzióját választottam ki, a 8.2-est. Diplomaterv 22 Csicsics Tamás

3.1.1. FreeBSD telepítése A telepítést alapvetően a sysinstall segédprogrammal végeztem, ami merőben leegyszerűsíti a telepítést, végigvezet minden fontosabb ponton, így hamar beállíthatjuk a billentyűzetkiosztást, regionális beállításokat is, valamint segít a merevlemez partíciónálásában is. Ugyanakkor érdemes betervezni, hogy csak elsődleges partícióra lehet telepíteni a rendszert, azaz logikaiakra nem. A folyamat során még ki kell választanunk, hogy milyen telepítést szeretnénk, azaz az alap rendszeren a fejlesztői eszközöket is telepítjük-e. Érdemes élni ezzel a lehetőséggel, hiszen megkönnyíti új modulok beépítését a kernelbe, vagy meglévők újrafordítását. A telepítés befejezése előtt lehetőség van csomagok telepítésére is, ilyen csomag például az ismert gnome grafikus felület is. Utolsó lépésben a hálózatot is konfigurálhatjuk, beállíthatjuk, hogy DHCP (Dynamic Host Configuration Protocol) szervertől kérje vagy statikus IP címet használjon a rendszer. NTP, azaz Network Time Protocol beállításokat is megadhatjuk, illetve rengeteg egyéb beállítást is. A sysinstall segédprogram a telepítés befejeztével is futtatható, így segítséget nyújt az előre nem látott (kihagyott, rossz értéket kapott) konfigurációk újbóli beállításához is. 3.1.2. Rendszer konfigurálása A friss rendszerrel ugyanakkor nem lehet még nekiállni a DummyNet használatának, ezért a megfelelő hálózati funkciók elérhetővé tételéhez a következő módosításokat, konfigurációs parancsokat adtam meg a telepítés után (csak a méréshez szükségesek): /etc/rc.conf: (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.1 netmask 255.255.255.0 Az első parancs a rendszerben engedélyezi az átjáró szerepkört, ami elengedhetetlen, hogy csomagokat küldhessünk egyik alhálózatból a másikba a mérések során. A második firewall_enable beállítás engedélyezi a tűzfalat, amire aztán a Diplomaterv 23 Csicsics Tamás

DummyNet támaszkodhat a 2.4-es pontban leírtaknak megfelelően. A firewall_type segítségével lehet konfigurálni a tűzfalat, azaz igény szerint itt egy szkriptet is belinkelhetünk, de jelen esetben csak az OPEN paramétert adtam meg, ami nyílttá teszi a rendszert, azaz nem blokkolja a forgalmat. A tűzfal beállításai után következnek az interfészek beállításai, ahol alapvetően csak az IP címeket és alhálózati maszkokat adtam meg. (Megjegyzés: A fenti IP cím beállításokat kétfolyamos Dumbbell topológiához állítottam be, más topológiához más beállítás tartozott.) A fent megadott beállításokkal a rendszer már képes volt átjáróként funkcionálni két különböző alhálózatba tartozó számítógép között, így a hálózati paraméterek emulálását leszámítva alkalmassá vált mérések elvégzésére, azonban a kezdeti eredmények alacsony adatátviteli értékeket mutattak, így szükség volt még a rendszer finomhangolására, amit a sysctl segítségével tettem meg: 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 A fenti beállítások közül az elsőt és az utolsót emelném ki, az első esetén az ütemező időszeleteit csökkenthetjük, amivel a hálózati teljesítményen javíthatunk, hiszen ott kell gyorsan feldolgozni sok csomagot. Az utolsó fastforwarding egy optimalizációs megoldás, mely a legtöbb esetben, ha a csomag nem feltétlenül igényli, bizonyos validációs eljárások kihagyásával, csökkentésével lerövidíti a csomagok feldolgozását és továbbküldését. A rendszer változóinak finomhangolása után még be kellett töltenem a rendszerbe a DummyNet modult, ugyanis az alapértelmezettként nem indul el. Az indítása nagyon egyszerű, elég a kldload dummynet parancsot kiadni. Ez után megadtam a DummyNet-re vonatkozó beállításokat is, hogy minél jobb eredményeket érhessek el a mérések során: Diplomaterv 24 Csicsics Tamás

net.inet.dummynet.io_fast=1 net.inet.ip.dummynet.pipe_slot_limit=100000 net.inet.ip.dummynet.pipe_byte_limit=1048576000 A dummynet.io_fast=1 lényege, hogy azokat a csomagokat, amelyek olyan folyamban találhatóak, amelyre nem érvényesül semmilyen késleltetés vagy csomagvesztés, az eredeti módon kezelje a rendszer, azaz ne kerüljön be a DummyNethez. A dummynet.io_fast=2 beállítással pedig tiltani lehet, hogy csomagok kerülhessenek a DummyNet-be. A következő beállítás a net.inet.ip.dummynet.pipe_slot_limit, amivel a maximális sorméreteket lehet befolyásolni, azaz, hány csomag férjen egy queue-ba. Az utolsó beállítás a net.inet.ip.dummynet.pipe_byte_limit, ami csak abban tér el az előző beállítástól, hogy a sorok méretére nem csomagszámot kell megadni, hanem byte-ok szerint kell meghatározni a maximális értéket. A fentiekben részletezett konfigurálási lépések segítségével a kezdeti 470 Mbit/s átviteli sebességű, Dummynet-en áthaladó, TCP forgalmat sikerült 583 Mbit/s-ra növelni, ami 24%-os gyorsulást jelent. (Megjegyzés: ezek az eredmények még nem a fentebb felsorolt hálózati kártyákkal történtek, így a tényleges gyorsulás mértéke eltérhet ezektől az adatoktól). 3.2. Topológiák kialakítása A mérések megkezdéséhez szükséges volt a megfelelő topológiák kialakítására is, jelen esetben a Dumbbell-re és parking lot-ra. 3.2.1. Dumbbell Az első hálózati összeállítás a Dumbbell topológia, amelynek a széles körben ismert változata a 3.1. ábrán látható. A lényege, hogy két küldő-fogadó párból áll, amelyek egymás között küldenek adatot egy közös csatornán, ami a szűk keresztmetszetet (bottleneck) jelenti. Az ábrán látható, hogy az A1 az A3-nak és az A2 az A4-nek küld adatokat, amiket az első útválasztó (router) egy közös csatornára irányít. Diplomaterv 25 Csicsics Tamás

Folyam 1. A1 A3 Bottleneck Folyam 2. A2 A4 3.1. ábra Általános Dumbbell topológia A ténylegesen megvalósított hálózat (3.2. ábra) ettől az általános sémától kis mértékben eltér, ugyanis a két router helyett itt egy darab DummyNet gépet használtam ugyanarra a célra. A funkcionalitás nem sérült, hiszen a DummyNet külön képes kezelni a befelé érkező és kifelé menő csomagokat, azaz gyakorlatilag ugyanúgy külön kezelhetőek a linkek, akárcsak a két útválasztós esetben, valamint az útválasztást is meg tudja oldani, ezért nem sérül ez a szerepkör sem. link1 A1 10.0.1.10 A3 10.0.3.30 link2 Emulált hálózat (DummyNet) A2 10.0.2.20 A4 10.0.4.40 3.2. ábra A megvalósított Dumbbell topológia Diplomaterv 26 Csicsics Tamás

A mérésekhez a DummyNet emulálta a hálózatot úgy, hogy a link1 és link2-re (3.2. ábra) külön is be lehetett állítani különböző késleltetéseket, sávszélesség korlátozásokat valamint csomagvesztési valószínűségeket. A kiinduló beállítás esetén a két folyam egy-egy külön queue-ba került be, ahonnan a WF2Q+ (Worst-case Fair Weighted Fair Queueing) ütemező 50-50%-os súlyozással tette át azokat egy közös pipe-ba, ami a közös linket korlátozta 1 Gbit/s adatátviteli sebességre. Azonban a széleskörű mérések érdekében szükség volt arra is, hogy a link1 és link2 külön késleltetési jellemzőkkel bírjanak, azonban ezt a tulajdonságot csak pipe-okra lehet konfigurálni, így szükségessé vált a DummyNet beállítások módosítása. A problémát végül még két külön pipe beiktatásával sikerült kiküszöbölni (3.3. ábra), azaz először a két folyam egy-egy különböző pipe-ba érkezett be, majd onnan bekerülnek a saját queue-kba, ahonnan pedig a már említett közös pipe-ba kerülnek. A többlet pipe szám azonban felvetette a kérdést, hogy nem sérül-e, pontosabban nem-e esik vissza az elérhető sávszélesség, de pár ellenőrző mérés után kiderült, hogy a különbség elhanyagolható, gyakorlatilag mérési hibahatáron belüli volt az eltérés. IN OUT Flow 1 Pipe 1 Queue 1 Flow 1 Pipe 3 Flow 2 Flow 2 Pipe 2 Queue 2 3.3. ábra Folyamok útja a DummyNet-en belül, Dumbbell topológia esetén A megvalósításhoz használt ipfw parancsok: ipfw add 5 pipe 1 ip from 10.0.1.10 to 10.0.3.30 in ipfw add 6 pipe 2 ip from 10.0.2.20 to 10.0.4.40 in ipfw add 12 pipe 5 ip from { 10.0.1.10 or 10.0.2.20 } to { 10.0.3.30 or 10.0.4.40 } out ipfw add 15 pipe 10 ip from any to any ipfw add 10 queue 1 ip from 10.0.1.10 to 10.0.3.30 out ipfw add 11 queue 2 ip from 10.0.2.20 to 10.0.4.40 out Diplomaterv 27 Csicsics Tamás

Az első parancsok szokás szerint a pipe-ok létrehozására vonatkoznak, tartalmazzák az irányt, hogy bejövő vagy kimenő csomagokat vizsgáljunk meg, valamint, hogy milyen forrás IP címről és milyen cél IP cím felé tartó csomagokat tegyünk be a pipe-okba. A visszafelé irányhoz is külön pipe-ot hoztam létre, aminek csak egy lényeges feladata volt, hogy a célállomás nyugtáit kezelje. Ezek után létrehoztam a queue-kat is a kimenő csomagokra, majd következhetett a részletes beállítás: ipfw pipe 1 config bw 0 plr 0 queue 10000 delay 0 ipfw pipe 2 config bw 0 plr 0 queue 10000 delay 0 ipfw pipe 5 config plr 0 queue 10000 delay 0 bw 1000Mbit/s ipfw pipe 10 config bw 0 plr 0 queue 10000 delay 0 ipfw queue 1 config queue 10000 weight 50 pipe 5 ipfw queue 2 config queue 10000 weight 50 pipe 5 Minden pipe és queue 10 000 csomagméretű puffert kapott, hogy biztosan ne legyen gond a kezdeti nagyobb burst-ös átvitellel, amit a DFCP produkál az adatátvitel megkezdésekor. Kezdetben egy közös sávszélesség korlátozást állítottam be, mégpedig az 5-ös azonosítóval rendelkező pipe-hoz, ami a közös link korlátját jelentette. A többi linkre nem állítottam be hasonló korlátozást, így a bw paramétert 0 értéken, azaz korlátlanon hagytam. A késleltetések módosításához a pipe 1 és 2 delay paraméterét kellett beállítani, a csomagvesztéshez pedig a plr paramétereket. Kezdetben mindkettőt 0 ms-os értéken hagytam, azaz csak a valós fizikai kapcsolatból származó késleltetés jelent meg, ami 0,1 ms és 0.5 ms közötti értékeket vett fel. Ezen alapbeállítások után a queue beállításait adtam meg, mégpedig a méreten kívül, hogy 50-es súlyozást kapjanak, ami jelen esetben 50-50%-os eloszlást jelent, valamint megadtam, hogy az 5- ös pipe-hoz csatlakozzanak. 3.2.2. Parking lot A Parking lot egy több folyamos rendszer (3.4. ábra), ahol általában egy kitüntetett folyam szerepel (3.4. ábrán Flow 1), ami több útválasztón, különböző tulajdonságú linken is keresztülhalad, miközben más-más adatforgalommal találkozik ezeken a csatornákon. Diplomaterv 28 Csicsics Tamás

3.4. ábra Általános példa a Parking lot topológiára forrás: [14] A laboratóriumi megvalósítás (3.5. ábra) a Dumbbell topológiához hasonlóan tér el, azaz a két router helyett egy-egy DummyNet számítógép került a hálózatba, illetve az előző ábrán látottakhoz képest az egyes számú folyamnak csupán két különböző csatornán kell keresztülfolynia nem pedig hármon. Folyam 1. C1 10.0.1.10 A1 10.0.3.30 Folyam 2. Folyam 3. C2 10.0.2.20 A2 10.0.4.40 C3 10.0.5.50 A3 10.0.6.60 3.5. ábra A megvalósított Parking lot tesztkörnyezet A Dumbbell topológiához képest itt már két DummyNet-re volt szükség, így a konfigurálás is több munkát igényelt. A Dumbbell topológiánál említett pipe-ok létrehozásán kívül a két gép közötti útvonalválasztást is meg kellett adni, hogy a nem szomszédos alhálózatok is elérhetőek legyenek az egyes hálózati csomópontokról. Az Diplomaterv 29 Csicsics Tamás

útvonalválasztáshoz létrehoztam egy új alhálózatot a két környezetet emuláló gép között, majd a rc.conf fájlba elmentettem az útvonalválasztó beállításait valamint az interfészek IP cím kiosztását, hogy minden indulásnál a megfelelő konfigurációval álljon fel a rendszer: ifconfig_em0="inet 10.0.9.9 netmask 255.255.255.0" ifconfig_re0="inet 10.0.5.5 netmask 255.255.255.0" ifconfig_re1="inet 10.0.3.3 netmask 255.255.255.0" ifconfig_re2="inet 10.0.6.6 netmask 255.255.255.0" static_routes="c10" route_c10="-net 10.0.1.0/24 10.0.9.10" A forgalmat küldő, illetve fogadó feleknél is szükség volt a routing táblák megfelelő beállításaira, amihez egy rövid szkript készült, így meggyorsította a beállítást. A fenti beállítások után a számítógépek elérhetővé váltak egymás számára a hálózaton, de semmilyen DummyNet beállítás nem érvényesült még, ezért a következő ipfw beállításokat adtam meg: DummyNet 1 (Folyam 1 és 2 megy rajta keresztül): ipfw add 12 pipe 5 ip from { 10.0.1.10 or 10.0.2.20 } to { 10.0.3.30 or 10.0.4.40 } out ipfw add 15 pipe 10 ip from any to any ipfw add 10 queue 1 ip from 10.0.1.10 to 10.0.3.30 out ipfw add 11 queue 2 ip from 10.0.2.20 to 10.0.4.40 out ipfw pipe 5 config plr 0 queue 10000 delay 0 bw 1000Mbit/s ipfw pipe 10 config bw 0 plr 0 queue 10000 delay 0 ipfw queue 1 config queue 10000 weight 50 pipe 5 ipfw queue 2 config queue 10000 weight 50 pipe 5 Látható, hogy csak két pipe-ot használtam, egyet a célállomások felé, egyet pedig az ellenkező irányba a nyugták számára. A közös linkre 1000 Mbit/s-os korlátot állítottam be, majd a már megismert módon a queue-kat is beállítottam. Diplomaterv 30 Csicsics Tamás

DummyNet 2 (Folyam 1 és 3 megy rajta keresztül): ipfw add 12 pipe 5 ip from { 10.0.1.10 or 10.0.5.50 } to { 10.0.3.30 or 10.0.6.60 } out ipfw add 15 pipe 10 ip from any to any ipfw add 10 queue 1 ip from 10.0.1.10 to 10.0.3.30 out ipfw add 11 queue 2 ip from 10.0.5.50 to 10.0.6.60 out ipfw pipe 5 config plr 0 queue 10000 delay 0 bw 1000Mbit/s ipfw pipe 10 config bw 0 plr 0 queue 10000 delay 0 ipfw queue 1 config queue 10000 weight 50 pipe 5 ipfw queue 2 config queue 10000 weight 50 pipe 5 A második DummyNet-es rendszerre is hasonló paramétereket adtam meg, csupán az IP címek változtak meg, a későbbiekben természetesen külön konfiguráltam a két hálózati elemet. A késleltetések a fenti beállításokban nem külön folyamokra vonatkoztak, hanem a közös linkekre, így nem volt szükség annyi pipe-ra mint a Dumbbell esetén. Ezért a változó késleltetési értékeket csak a pipe 5-re állítottam be mindkét hálózati emulációs szoftveren. 3.3. Mérések elvégzése A mérések a különböző topológiák ellenőrzőmérésével kezdődtek, amivel egyrészt az alapvetően elérhető maximális sebességekről sikerült információt szerezni, valamint a tűzfalszabályok helyességéről. A késleltetések és csomagvesztések mérése az egyszerűen kezelhető ping segédprogrammal történtek. Késleltetéses mérés esetén alapesetben, azaz az emulált rendszer 0 ms értékkel lett konfigurálva, 0,1 ms volt az RTT, minden más esetben megegyezett a beállítottakkal. A csomagvesztés ellenőrzéséhez ping parancs i kapcsolójával kellett csökkenteni az ICMP ECHO kérések küldése között eltelt időt, tipikusan 0,1 volt az az érték, mellyel másodpercenként 1000 csomagot küldött az egyik fél a másiknak. A több ezer csomagból, valamint az elveszettek számából pedig jól lehetett közelíteni a tényleges csomagvesztést, ami szintén megfelelt a beállítottaknak. Az elérhető sávszélesség mérése egy client3, server3 elnevezésű program párossal történt, melyeket Solymos Szilárd, a kutatócsoport egyik tagja készített. Működésük során a client3 felveszi a kapcsolatot a server3 programmal, majd a Diplomaterv 31 Csicsics Tamás

kiválasztott protokoll segítségével megkezdi az adatok továbbítását, amiből ki is számítja az elért sávszélességet. Támogatott protokollok: New Reno (SACK), Cubic, DFCP. Programok főbb paraméterezése: client3 -s <ip cím> - szerver gép elérése -p <port szám> - csatlakozáshoz használt port -n <átküldendő adatmennyiség> - a küldendő adatmennyiség, ha nincs c paraméter -c <másodperc> - adatátvitel időtartama, azaz milyen hosszan küldjön a kliens gép a szerver felé adatokat -x <másodprec> - a megadott időtartamot nem veszi figyelembe, a tranziens viselkedés figyelmen kívül hagyására - a <0/1> - nyugtázás tiltása vagy engedélyezése -w <ablakméret> - az ablakméret beállítása, a mérések során 100 volt -r <blokkméret csomagokban> - a küldendő redundáns csomagok számát szabályozhatjuk vele A server3 esetén is hasonló paraméterezés áll rendelkezésre, lényeges különbség az r paraméter hiánya. A méréseknél fontos volt, hogy a mérés menete pontosan legyen meghatározva. Kezdetben a mérések 1Gbyte adatátvitelével történtek, de ez szélsőséges esetekben nem adott pontos adatokat, vagy teljesen használhatatlan volt. Például ideális esetben túl hamar véget ért a mérés, több mint 50%-os csomagvesztés esetén pedig a TCP verziók órák alatt sem voltak képesek átvinni a tesztelendő adatmennyiséget. Ezért idő alapú mérésekre kellett áttérni, így az átvitelek egységesen 60 másodpercig tartottak, amiből az első 15 másodperc nem számított bele a közzétett mérési eredményekbe. A kihagyás célja elsősorban a TCP slow-start és egyéb induláskori sajátosságainak figyelmen kívül hagyása volt. A DFCP 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égezni a méréseket. Fontos megjegyezni, hogy ahol külön nincs jelezve, ott a redundancia Diplomaterv 32 Csicsics Tamás

Goodput (Mbit/s) paraméter értéke 49, ami annyit jelent, hogy egy blokk 49 csomagból áll. Ezen érték növelésével együtt 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 online dekódolás használata nélkül futottak, 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. A Raptor kódolás miatt a DFCP esetén sokkal nagyobb a throughput és goodput között az eltérés, így fordulhatott elő, hogy ideális esetben a Cubic és Reno is gyorsabb hasznos adatátvitelre képes. 3.3.1. Dumbbell A mérések során a két vetélkedő folyam vizsgálata történt meg, miközben különböző hálózati paraméterek érvényesültek rájuk. 3.3.1.1. Késleltetés vizsgálata két folyam esetén 900 800 700 600 500 400 300 200 100 DFCP flow 1 DFCP flow 2 Cubic flow 1 Cubic flow 2 Reno flow 1 Reno flow 2 0 10 20 30 40 50 60 70 80 90 100 Késleltetés (ms) 3.6. ábra Két folyam vizsgálata egy fix és egy változó késleltetéssel Diplomaterv 33 Csicsics Tamás

Goodput (Mbit/s) A mérés során a linkeken a késleltetéseket különböző módon változtattam, egész pontosan az első folyamhoz állandó 10 ms-os késleltetést állítottam be, míg a második folyamra esőt 10 és 100 ms között változtattam. A link sávszélessége 1 Gbit/s volt. A 3.6. ábrán megfigyelhető, hogy a DFCP protokoll esetén a két folyam megtartja végig a sebességét, míg a Cubic és Reno esetén a két folyam szétágazik a különböző késleltetések miatt. A probléma ezzel a viselkedéssel, hogy méltánytalan, ugyanis a kisebb késleltetéssel rendelkező folyam nem engedi, hogy a másik elérje az adott késleltetéshez tartozó maximális sebességét, azaz nem csak a válaszidő miatt, hanem a másik folyam miatt is visszaesik a másodiknak a sebessége. Ez a jelenség az úgynevezett RTT unfairness. A DFCP ezzel szemben végig kiegyenlítetten szerepel. Megjegyzés: A Reno és Cubic mérések eredményei csak minimális mértékben tértek el egymástól, így sajnos a grafikonon elfedik egymást. 3.3.1.2. Csomagvesztés vizsgálata két folyam esetén 500 450 400 350 300 250 200 150 100 50 0 0 0.1 0.2 0.5 1 2 5 Csomagvesztés (%) DFCP flow 1 DFCP flow 2 Cubic flow 1 Cubic flow 2 Reno flow 1 Reno flow 2 3.7. ábra Két folyam, egyező csomagvesztések A 3.7. ábrán az az eset látható, amikor a két külön folyamra ugyanolyan csomagvesztési valószínűség érvényesül. A DFCP mérések minden esetben 5 %-os csomagvesztéshez beállított redundancia paraméterrel készültek, éppen ezért a hasznos adatátvitel nem csökkent és messze meghaladta a másik két TCP átvitel eredményét. Diplomaterv 34 Csicsics Tamás

Goodput (Mbit/s) 450 400 350 300 250 200 150 100 50 0 0.1 0.2 0.5 1 2 5 Csomagvesztés (%) DFCP flow 1 DFCP flow 2 Cubic flow 1 Cubic flow 2 Reno flow 1 Reno flow 2 3.8. ábra Két folyam, egy rögzített és egy változó csomagvesztéssel A következő mérés azt az esetet mutatja be (3.8. ábra), amikor az egyes link állandó 0.1 %-os csomagvesztéssel rendelkezik, míg a második esetén 0.1 és 5 % között váltakozik a csomagvesztés valószínűsége. Jól látható, hogy DFCP esetén mindkét folyam hasonló sávszélességgel viszi át az adatokat, míg a TCP-k esetén nem csupán az RTT unfairness jelentkezik, hanem link kihasználása is elég gyenge, hiszen 1Gbit/s linken a két darab Reno folyam például csupán 396 + 8 = 404 Mbit/s sebességet ér el, míg a DFCP pedig 339 + 356 = 695 Mbit/s-ot. 3.3.2. Parking lot A Parking lot topológia esetén négy különböző esetet mértem le, főként a késleltetésekre és csomagvesztésekre koncentrálva, illetve sávszélesség korlátozást is alkalmaztam egyes esetekben. 3.3.2.1. Változó késleltetés Egy késleltetéses mérési szcenárióval kezdem a mérések bemutatását (3.1. táblázat, 3.9. ábra), ahol az első link (bal oldali emulált hálózat a 3.5. ábrán) állandó 10 ms késleltetéssel rendelkezett, míg a második 0 és 100 ms között változott. Csomagvesztést nem állítottam be, azaz a csatorna megbízható volt, egyedüli korlátozás a sávszélességé volt, amit egységesen mindkét linkre 1 Gbit/s-ra konfiguráltam be. Diplomaterv 35 Csicsics Tamás

Goodput (Mbit/s) Késleltetés: 0 5 10 50 100 ms DFCP flow 1 421,15 421,15 421,15 421,15 421,15 Mbit/s DFCP flow 2 421,18 421,17 421,17 421,17 421,18 Mbit/s DFCP flow 3 421,15 421,15 421,15 421,15 421,15 Mbit/s Cubic flow 1 460,26 460,26 460,26 230,89 128,39 Mbit/s Cubic flow 2 460,29 460,29 460,29 689,4 702,24 Mbit/s Cubic flow 3 460,27 460,26 460,26 278,21 142,4 Mbit/s Reno flow 1 460,26 460,26 460,26 231,03 128,42 Mbit/s Reno flow 2 460,29 460,29 460,29 689,56 702,6 Mbit/s Reno flow 3 460,27 460,27 460,27 278,11 142,52 Mbit/s 3.1. táblázat Változó késleltetések 800 700 600 500 400 300 200 100 0 0 5 10 50 100 Késleltetés (ms) DFCP flow 1 DFCP flow 2 DFCP flow 3 Cubic flow 1 Cubic flow 2 Cubic flow 3 3.10. ábra Változó késleltetések DFCP, Cubic protokollok mérésekor A DFCP nagyon jó eredményeket ért el, hiszen gyakorlatilag végig egyenletesen osztozott a két folyam a linkeken a beállított 50-50%-os súlyozásnak megfelelően, ami a link kihasználtságát is jótékonyan befolyásolta. A TCP verziók esetén ismét megjelent az igazságtalan eloszlás, azaz érvényesült az RTT unfairness jelenség. Ugyanakkor 10 ms-os késleltetésig a TCP variánsok jobb goodput eredményt értek el, mint a DFCP, köszönhetően a kódolásból eredő többletnek. A grafikonon (3.9. ábra) nem ábrázoltam külön a TCP Reno protokollt, ugyanis eredménye szinte teljesen megegyezett a Cubic eredményekkel, de a táblázatban (3.1. táblázat) megtekinthető. Diplomaterv 36 Csicsics Tamás

3.3.2.2. Változó késleltetés és konstans sávszélesség korlát A következő mérés során a második DummyNet-es gépen fix 500 Mbit/s sávszélesség korlátot állítottam be, ami az első és harmadik folyamot befolyásolja (lásd 3.5. ábra). Az első DummyNet-es gépen továbbra is 1 Gbit/s maradt a link sávszélessége, a késleltetések az előző méréshez hasonlóan változtak, azaz az elsőn 10 ms volt, míg a másodikon 0-tól 100 ms-ig változott a nagysága. Késleltetés 0 5 10 50 100 ms DFCP flow 1 210,58 210,58 210,58 210,58 210,58 Mbit/s DFCP flow 2 631,11 631,13 631,38 631,745 631,74 Mbit/s DFCP flow 3 210,57 210,57 210,58 210,57 210,58 Mbit/s Cubic flow 1 230,14 230,14 230,14 230,12 128,46 Mbit/s Cubic flow 2 690,46 690,44 690,45 690,38 702,97 Mbit/s Cubic flow 3 230,13 230,13 230,13 230,11 142,37 Mbit/s Reno flow 1 230,14 230,14 230,14 230,06 128,22 Mbit/s Reno flow 2 690,42 690,4 690,46 690,38 703,56 Mbit/s Reno flow 3 230,13 230,13 230,13 230,03 142,52 Mbit/s 3.2. táblázat Változó késleltetések 1 Gbit/s és 500 Mbit/s sávszélesség mellett A mérési eredményeket bemutató 3.2. táblázatból jól látszik, hogy a Cubic és Reno újra nagyon hasonlóan teljesített, így a grafikonon (3.11. ábra) már csak a Cubicot ábrázoltam. A kapott eredmények érdekes képet festenek a protokollok működéséről, hiszen a két, pontosabban három, eltérő megvalósítás nagyon hasonló átviteli sebességet ért el, valamint a görbéik is hasonlóan párhuzamosak lettek. A leginkább szembetűnő az a TCP változatok nagyon jó teljesítménye az első folyamra, ugyanis a nagyobb késleltetés esetén is 10%-al nagyobb átviteli sebességet sikerült elérniük, mint a DFCP. Az egyes és hármas folyamra a DFCP esetén végig azonos sebességet kaptunk, nagyon jól érvényesült az 50 50%-os súlyozás. A TCP esetén ez az egyenletes eredmény szintén igaz egészen 50 ms-ig, ami után erős visszaesést tapasztaltam, valamint a két folyam is egyre jobban tért el egymástól. A kettes folyam nagyon magas értékét annak köszönhetjük, hogy a mérés során végig 10 ms-os késleltetés vonatkozott rá, nem változott alatta semmilyen hálózati paraméter, a 100-as ablakméret pedig biztosította, hogy stabilan magas értékeket kapjunk. Ugyanakkor érdemes megfigyelni, hogy 50 ms Diplomaterv 37 Csicsics Tamás

Kihasználtság (%) Goodput (Mbit/s) után az első és harmadik folyam teljesítménye nagyobb mértékben csökkent, mint a másodiké, amivel a link kihasználtsága is romlott. 800 700 600 500 400 300 200 100 DFCP flow 1 DFCP flow 2 DFCP flow 3 Cubic flow 1 Cubic flow 2 Cubic flow 3 0 0 5 10 50 100 Késleltetés (ms) 3.11. ábra Változó késleltetések 1 Gbit/s 500 Mbit/s sávszélesség mellett 100 90 80 70 60 50 40 30 20 10 0 0 5 10 50 100 Késleltetés (ms) DFCP link 1 DFCP link 2 Cubic link 1 Cubic link 2 3.12. ábra Linkek kihasználtsága a 3.3.2.2. mérés során Diplomaterv 38 Csicsics Tamás

Goodput (Mbit/s) A 3.12. ábra jól szemlélteti az előző állításomat, azaz 100 ms esetén a második link kihasználtsága nagyot zuhant Cubic használata esetén, míg a DFCP stabilan tartotta a 80% feletti kihasználtságot. Ezen eredmények is megerősítik az eddig tapasztaltakat, hogy a DFCP nem csupán nagy átviteli sebességeket képes elérni változó késleltetésű csatornákon, hanem ezeket az értékeket stabilabban tudja tartani a TCP változatoknál, ahogyan a magas link kihasználtságot is. 3.3.2.3. Késleltetések, első linken fix 50 ms-mal A harmadik tesztem szintén egy késleltetést fókuszba helyező mérés volt, ahol az eddigiekkel szemben az első linkre 50 ms-os késleltetést állítottam be, ami a 10 ms-al ellentétben 100-as ablakméret mellett is érzékelhető lassulást okoz a protokollok teljesítményében. A második linken pedig 0 és 70 ms között módosítottam a késleltetéseket. A csomagvesztés mindkét linken 0 % volt, valamint a sávszélesség korlát is azonos volt, mégpedig 1 Gbit/s. 800 700 600 500 400 300 200 100 0 0 5 10 20 30 40 50 60 70 DFCP flow 1 DFCP flow 2 DFCP flow 3 Cubic flow 1 Cubic flow 2 Cubic flow 3 Késleltetés (ms) 3.13. ábra Késleltetések, amikor az első link állandó 50ms késleltetéssel rendelkezett A lényegesen magasabb első linkes késleltetéssel az első folyamra eső összes késleltetés így 50-től 120 ms-ig vett fel értékeket, ami jóval nagyobb az előző mérés maximum 60 ms-os késleltetésénél. Az első beállításnál az első és második folyam egyaránt 50 ms-os késleltetést kapott, ami már jelentősen lerontotta teljesítményüket Diplomaterv 39 Csicsics Tamás

Cubic protokoll használatakor (3.13. ábra), ezáltal az egyes link kihasználtsága is csupán 54%-ot ért el (3.3. táblázat). A második linken kezdetben nem volt késleltetés, így a harmadik folyamot csak az első jelenléte korlátozta, ezért a kihasználtság is nagyon magas lett: 92%. A késleltetés növelésével kezdetben a harmadik TCP folyam ki tudta használni az első folyam lassulását, így magas maradt a második link kihasználtsága, azonban 10 ms után a harmadik folyam sebessége is meredeken csökkent, így 70 ms-nál már csak 32% volt. Ezzel szemben DFCP esetén újra megbizonyosodhattunk a kifejezetten erős késleltetés tűrő tulajdonságával, hiszen egészen 70 ms-ig, ahol az első folyam már 120 ms-os RTT-vel rendelkezett, a három folyam közel azonos teljesítményt ért el. Érdemes megfigyelni, hogy az első folyam átviteli sebességének csökkenésével a második és harmadik folyam a csökkentett értékkel megegyezően nőtt, azaz a linkek kihasználtsága nem változott, maradt végig 84%-os. Késleltetés 0 5 10 20 30 40 50 60 70 ms Cubic link 1 54,36 52,68 50,84 47,67 45,30 43,40 41,91 40,64 39,57 % Cubic link 2 92,05 92,04 92,05 84,08 62,48 49,94 41,90 36,21 31,94 % DFCP link 1 84,24 84,23 84,23 84,23 84,23 84,23 84,23 84,26 84,23 % DFCP link 2 84,23 84,23 84,23 84,23 84,24 84,23 84,23 84,23 84,23 % 3.3. táblázat Linkek kihasználtsága (%) A mérési eredményekhez hozzá tartozik, hogy eredetileg nem csupán 70 ms-ig, hanem egészen 100 ms-ig szerettem volna elvégezni a méréseket, azonban egy ismeretlen hiba folytán a második folyam mindig elakadt a 70 ms-nál nagyobb értékekre. Elakadáson azt értem, hogy egy idő után a C2-es küldő számítógép nem küldött több csomagot A2-nek (3.5. ábra), aminek valamilyen csomagvesztés lehetett az oka, de alaposabb kutatással sem találtam meg a hiba gyökerét. A kapott ábrával kapcsolatban érdemes megjegyezni, hogy a görbéi, nem csupán az eredményeket mutatják meg, hanem bizonyos pontokon ellenőrzést is lehet végezni velük. Például tekintsük azt az esetet, mikor a második linken is 50 ms a késleltetés, ekkor a második és harmadik folyamnak elviekben azonos eredményt kell elérniük és az ábráról jól látható, hogy ez teljesül is, hiszen pont abban a pontban metszi egymást a két görbe. Diplomaterv 40 Csicsics Tamás

Goodput (Mbit/s) 3.3.2.4. Csomagvesztés A harmadik mérési összeállítás során a változó csomagvesztéses esetekre vizsgáltam meg a protokollokat. A beállítások ebben az esetben is hasonlóak voltak, azaz az első linken egy állandó kismértékű csomagvesztést állítottam be, a második linken pedig egy adott intervallumról állítottam be az értékeket, valamint mindkét csatorna kapott fix 10 ms értékű késleltetést is. A sávszélesség korlátozások az előző mérésekhez hasonlóan egységesen 1 Gbit/s nagyságúak voltak. A csomagvesztés és a késleltetés együttes megjelenése ugyanakkor jelentősen lerontja a TCP különböző változatainak a teljesítményét, így a mérést azzal kezdtem, hogy megállapítsam mi az a csomagvesztési értéktartomány, amit érdemes mérni, azaz a TCP nem teljesít túlzotton rosszul. Cubic 100,00 97,14 80,00 60,00 40,00 20,00 0,00 42,89 29,97 9,86 3,85 0,01% 0,05% 0,10% 1% 5% Csomagvesztés 3.14. ábra Cubic fix 10 ms-os késleltetés és változó csomagvesztés mellett A kapott eredmények (3.14. ábra) és az eddigi tapasztalatok alapján, a DFCP és Cubic teljesítménye között nagyon nagy az eltérés, ha csomagvesztés is történik, ezért a jobb ábrázolhatóság érdekében az első linkre állandó 0,01%-os csomagvesztést állítottam be, míg a másikon a vesztést 0,01% és 5% között változtattam. 5%-os vesztés esetén olyan nagy különbséget kaptam a DFCP-hez viszonyítva, hogy a nagyobb értékek nehézkes ábrázolhatósága és kevés információtartalma miatt nem emeltem többet a csomagvesztést. Diplomaterv 41 Csicsics Tamás