Analiza ponašanja transportnog protokola TCP

Analiza ponašanja transportnog protokola TCP (Izvadak iz diplomskog rada) Igor Minić Internet se razvio u vrlo veliki i kompleksan sustav, sa stotinama milijuna umreženih računala, komunikacijskih veza i mrežnih komponenti, koji je na mnoge načine promijenio svakodnevni život velikog broja ljudi. Kao svaki kompleksan sustav Internet je modularno projektiran te se svaki funkcionalni modul zove sloj (engl layer). Svaki sloj se sastoji od protokola koji definiraju format podataka, procedure prijenosa podataka, postupke dodjeljivanja resursa, itd. S obzirom na veliki i promjenjiv broj korisnika te stalne varijacije aktivnosti korisnika u mreži javlja se potreba za upravljanjem prometnim zagušenjem da bi se pružila optimalna komunikacija s kraja na kraj, te da bi se u potpunosti iskoristila maksimalna moguća propusnost koju mreža dopušta. Tu zadaću prvenstveno obavlja protokol TCP na transportnom sloju. U ovom radu simuliran i ispitan protokol TCP, neki od najvažnijih načina na koje upravlja zagušenjem u mreži te kako na njih utječu razni parametri i stanja u mreži. U prvom je poglavlju detaljno objašnjen protokol TCP i najvažniji mehanizmi upravljanja zagušenjem. Drugo poglavlje sadrži opis korištenog simulatora te simulacijskih scenarija. U trećem su poglavlju analizirani rezultati provedenih simulacija iz kojih su na kraju izvedeni zaključci. 1

1. Protokol TCP Prva inačica protokola TCP (engl. Transmission Control Protocol) je predložena 1974. godine u radu "A Protocol for Packet Network Intercommunication" [1]. Od tada pa do usvajanja protokolarnog složaja TCP/IP u eksperimentalnoj mreži s komutacijom paketa ARPANET 1983. godine, koja je spajala četiri američka sveučilišta i bila projekt agencije DARPA (engl. Defense Advanced Research Projects Agency), TCP je prošao određene preinake. Standard protokola TCP je definiran u RFC 793 [2] od strane IETF-a te se on bazira na istraživanju protokola u mreži ARPANET. Još jedan važni rad za projektiranje protokola TCP te samog Interneta je rad D. Clarka iz 1988. godine [3]. U tom radu autor pojašnjava da bi se sustav nepotrebno komplicirao postavljanjem prekomjerne kontrole toka i upravljanja pogreškama na fizičkom sloju ili sloju podatkovne poveznice. Razlog tomu je što se te funkcije u pravilu obavljaju na krajnjim točkama komunikacije te ih je logičnije postaviti u transportni sloj. TCP je najčešće korišteni, spojno orijentirani protokol koji pruža pouzdan transport struje okteta s kraja na kraj pomoću mehanizama potvrde i retransmisije uz očuvan redoslijed segmenata i upravljanje zagušenjem u mreži. S obzirom da TCP pruža pouzdanu uslugu on je pogodan za aplikacije kojima je važno da se svi podaci prenesu do primatelja u poslanom obliku i redoslijedu dok samo vrijeme prijenosa nije toliko kritično. Za razliku od protokola TCP, drugi jako poznati i često korišteni protokol transportnog sloja je UDP (engl User Datagram Protocol) koji je pogodan za aplikacije koje se obavljaju u stvarnom vremenu gdje je važnije da se podatci prenesu u krećem vremenu nego da se prenesu baš svi poslani podaci. TCP ima sučelja prema aplikacijskom sloju koji se nalazi iznad njega te prema mrežnom sloju koji je ispod njega. Aplikacija šalje podatke prema TCP-u u obliku struje okteta te je njegov zadatak pripremiti podatke za slanje, uspostaviti vezu s odredištem te osigurati pouzdanost veze. U sljedećem dijelu teksta su pobrojane i ukratko objašnjene sve funkcije protokola TCP: 2

Osnovni transport podataka: dvosmjerni prijenos kontinuiranog niza podataka pakiranjem okteta podataka u segmente koje potom predaje protokolu IP (engl. Internet Protocol) na mrežnom sloju. Adresiranje i multipleksiranje: više aplikacija na istom računalu može istovremeno koristiti protokol TCP uporabom dodatne informacije, tj. broja vrata (engl port number). Pouzdanost: TCP ima sposobnost oporavka od gubitka, udvostručenja, pogrešnog redoslijeda i pogreške u struji okteta jer dodjeljuje broj u nizu (engl sequence number) svakom oktetu koji predaje i traži da prijamna strana potvrdi ispravan prijam. Pouzdanost veze se osigurava pomoću sljedećih mehanizama: Zaštitne sume (engl. checksums): svaki TCP segment ima svoju zaštitnu sumu pomoću koje prijamnik može detektirati pogrešku, bilo u TCP zaglavlju ili u podacima. Detekcija dupliciranih podataka: u mrežama s komutacijom paketa može doći do duplikacije paketa pri prijenosu, stoga TCP prati koje je oktete primio te odbacuje kopije paketa koje je već primio Retransmisija: da bi protokol mogao garantirati pouzdanost podataka mora imati mogućnost ponovnog slanja podataka koji su izgubljeni ili primljeni s pogreškom. Označavanje niza (engl sequencing): s obzirom da je u mrežama s komutacijom paketa velika vjerojatnost da paketi neće doći u redoslijedu kojim su odaslani, jedan od zadataka protokola TCP je označavanje paketa te dostavljanje istih aplikaciji u pravilnom redoslijedu. Brojila (engl. timers): TCP sadrži više vrsta brojila koja označuju vrijeme koje je prošlo od odašiljanja podataka, ta ako u određenom vremenu nije dobivena potvrda za podatke oni se smatraju izgubljenima. Upravljanje tokom, tj. zagušenjem: svaka potvrda popraćena je informacijom o veličini prozora koja naznačuje koliko okteta predajnik smije odaslati prijem prijema potvrde. Upravljanje vezom: logička veza između procesa se uspostavlja prije, i raskida po obavljenoj komunikaciji upotrebom posebnih statusnih podataka. 3

Prioriteti i sigurnost: posebni zahtjevi koje specificiraju procesi, i to po potrebi i za pojedinačnu vezu. Neke od ovih funkcija detaljnije su objašnjene u sljedećim potpoglavljima s obzirom da su važne za sam protokol TCP i za razumijevanje simulacije. 1.1. TCP logička veza Slika 1.1 prikazuje stvaranje logičke veze između procesa A i B na računalima 1 i 2. Uspostavljanjem logičke veze ne znači da će svi podaci koji pripadaju toj vezi kroz mrežu putovati istim putem s obzirom se oni usmjeravaju pomoću protokola IP koji je bespojan. Slika 1.1 Uspostava TCP logičke veze Krajnje točke komunikacije između procesa nazivaju se priključnicama (engl. socket) a veza ostvarena putem njih asocijacija. Priključnica je definirana pomoću vrste transportnog protokola (npr. TCP ili UDP), IP adrese odredišta (npr. 31.147163.16) i 16-bitnog broja, tj. broja vrata (npr. 80 za protokol HTTP). Uz TCP priključnice na isti način koristi i protokol UDP. Poslužitelju u pravilu uslugu uvijek otvaraju na istim, dobro-poznatim vratima (engl. well-known ports), dok klijenti za svaki proces koriste nova, nasumično odabrana vrata (koja nisu dobro-poznata). 4

Vrata u rasponu od 0 do 1023 su znana kao dobro-poznata vrata. Ona su korištena od strane procesa koji pružaju najkorištenije tipove mrežnih usluga. Nekoliko najpoznatijih TCP vrata, tj. najkorištenijih usluga je dano u Tablica 1.1. Tablica 1.1 Primjeri nekoliko najpoznatijih vrata i usluga koje ih koriste Broj Transportni Aplikacijski protokol ili usluga Opis usluge vrata protokol 20 TCP/UDP FTP (File Transfer Protocol) data FTP prijenos podataka 21 TCP FTP control FTP prijenos kontrolne informacije 22 TCP/UDP SSH (Secure Shell) Sigurnosna asocijacija 25 TCP SMTP (Simple Mail Transfer Protocol) Slanje e-mail poruka između poslužitelja 53 TCP/UDP DNS (Domain Name System) Pridruživanje informacija imenu domene 80 TCP HTTP (Hypertext Transfer Protocol) 143 TCP IMAP (Internet Message Access Protocol) Jedna od glavnih usluga na Internetu Pristup e-mail poslužitelju i upravljanje porukama Vrata u rasponu od 1024 do 49151 su vrata registrirana od strane IANA (engl. Internet Assigned Numbers Authority) [4] za određene usluge ali se mogu koristiti i za druge svrhe od strane korisnika. Vrata u rasponu od 41952 do 65535 su dinamička ili privatna vrata koja ne mogu bit registrirana te se koriste za privremene svrhe. Slika 1.2 Prikazuje primjer [5] uspostavljenih logičkih veza između tri računala, označenih s A, B i C. Računalo A s IP adresom 152.22.41.55 ima pokrenuta dva klijentska procesa na nasumično odabranim vratima 33522 i 33553 koji su spojeni logičkom vezom na dva 5

procesa računala B. Računalo B predstavlja poslužitelja s IP adresom 195.53.11.5 s pokrenute dvije usluge na dobro-poznatim vratima, FTP na vratima 21 i HTTP na vratim 80. Računalo C s IP adresom 3.5.23.2 predstavlja još jednog klijenta koji također ima otvorenu asocijaciju prema FTP poslužitelju. Sve otvorene asocijacije u primjeru su: (tcp, 152.22.41.55, 33522) - (tcp, 195.53.11.5, 21) (tcp, 152.22.41.55, 33553) - (tcp, 195.53.11.5, 80) (tcp, 3.5.23.2, 22112) - (tcp, 195.53.11.5, 21) Slika 1.2 Primjer logičkih veza 1.2. Struktura TCP segmenta Slika 1.3 prikazuje strukturu TCP segmenta. Veličina TCP zaglavlja bez opcija iznosi 20 okteta. U nastavku će ukratko biti objašnjeno svako polje TCP zaglavlja te će također biti navedeno standardno ime polja u literaturi na engleskom jeziku te njegova veličina. 6

Slika 1.3 Struktura TCP segmenta Izvorišna vrata (engl. source port): 16-bitni broj koji označuje broj vrata procesa pošiljatelja na izvorišnoj strani. Odredišna vrata (engl. destination port): 16-bitni broj koji označuje broj vrata procesa primatelja na odredišnoj strani. Broj u nizu ili redni broj (engl. sequence number): 32-bitni broj koji označuje trenutnu poziciju prvog okteta podataka višeg sloja ovog segmenta u cijelom nizu okteta te TCP veze. Kada broj dosegne 2 32-1 vraća se na 0. Broj potvrde (engl acknowledgment number): 32-bitni broj koji označava sljedeći broj u nizu koji predajnik očekuje od prijemnika. Broj će biti za jedan veći nego broj zadnjeg primljenog okteta. Ovo se polje koristi samo kada je ACK bit uključen. Duljina zaglavlja (engl. header length, data offset): 4-bitno polje koje označava konačnu duljinu TCP zaglavlja. Bez polja opcije, TCP zaglavlje je duljine 20 okteta, dok s poljem opcije može doseći do 60 okteta. Ovo je polje obavezno zato što se veličina polja opcije ne može u naprijed odrediti. Rezervirana polja (engl. reserved): 6-bitno polje koje trenutno nije u uporabi nego je rezervirano za moguću buduću uporabu. Upravljački bitovi (engl. control bits): 6-bitno polje gdje svaki bit označava korištenje određene zastavice, od lijevo prema desno slijede: 7

URG (engl Urgent Pointer): Ako je ovaj bit postavljen prijemnik mora provjeriti polje pokazivač hitnosti. ACK (engl Acknowledgement): Ako je ovaj bit postavljen prijemnik mora provjeriti polje broj potvrde. PSH (engl. Push Function): Ako je ovaj bit postavljen prijemnik mora predati taj segment aplikaciji što je prije moguće. Primjer uporabe ovog bita bio bila naredba Control-BREAK koja nema potreba čekati podatke koji su prije nje u redu. RST (engl. Reset Connection): Ako je ovaj bit postavljen prijamnik zna da predajnik prekida komunikaciju i svi podaci u redu i sva dodijeljena memorija može biti oslobođena. SYN (engl. Synchronize): Ovaj bit je postavljen kada predajnik želi sinkronizirati brojeve u nizu. Ovaj se bit koristi pri uspostavljanju veze između predajnika i prijamnika. FIN (engl. Finish): Ovaj je bit postavljen kada predajnik dosegne kraj toka okteta za trenutnu TCP konekciju. Veličina prozora (engl. window): 16-bitni broj koji se koristi za kontrolu toka i označuje veličinu prozora slanja. Broj govori predajniku koliko podataka prijamnik može primiti. Maksimalna veličina ovog polja bi ograničila veličinu prozora na 65535 okteta ali se može koristiti skaliranje tako da se mogu koristiti i veći prozori. Zaštitna suma (engl. checksum): 16-bitna vrijednost koju računa predajnik na osnovu TCP zaglavlja i podataka. Prijemnik uspoređuje tu vrijednost s vrijednosti koju na isti način on računa. Ako je neki bit promijenjen pri prijenosu vrijednosti se neće podudarati i bit će potrebna retransmisija, dok ako je segment stigao netaknut na odredište vrijednosti će se podudarati i prijamnik može potvrditi taj segment. Pokazivač hitnosti (engl. urgent pointer): 16-bitno polje koje govori prijamniku kad završava zadnji oktet hitnih podataka u segmentu. Ovo polje je potrebno zato što ponekad predajnik mora upozoriti prijamnik na određene hitne podatke koje je potrebno proslijediti aplikaciji što je prije moguće. Opcije (engl. options): U ovom je polju moguće zadati određene dodatne parametre koji pružaju dodatnu funkcionalnost protokolu TCP. Veličina polja je varijabilna s maksimalnom veličinom od 40 okteta s time da je polje opcionalno te može ali i ne treba 8

biti postavljeno. Jedan primjer opcija je MSS (engl. Maximum Segment Size) gdje TCP prijamnik obavještava predajnika o maksimalnoj veličini segmenta kojeg može primiti. Druge opcije koje se često koriste su razni parametri vezani za mehanizme kontrole toka ili zagušenja. Nadopuna (engl. padding): S obzirom da veličina polja opcije varijabilna, polje nadopuna se koristi da bi se TCP zaglavlje nadopunilo nulama do veličine višekratnika od 32 bita. Podaci višeg sloja (engl. data): Ovo polje varijabilne duljine sadrži podatke višeg sloja koji se prenose od TCP predajnika do prijamnika. Također je moguće da je ovo polje prazno (npr. u slučaju slanja potvrde bez slanja dodatnih podataka). 1.3. Uspostavljanje i prekid veze TCP pruža spojnu uslugu iznad mreže s komutacijom paketa. Kao što je već spomenuto, spojna usluga znači da se stvara virtualna veza između dvije krajnje točke komunikacije, iako to ne znači da će svi podaci biti usmjeravani istim putem kroz mrežu. Postoje tri glavne faze virtualne veze koje će biti objašnjene u ovom potpoglavlju, to su uspostavljanje veze, prijenos podataka te prekid veze. 1.3.1. Uspostavljanje TCP veze Da bi dva proces mogla komunicirati pomoću protokola TCP prvo moraju uspostaviti vezu razmjenjujući poruke na način koji prikazuje Slika 1.4, poznat i kao trostruko rukovanje (engl. three-way handshake). 9

Slika 1.4 Uspostavljanje TCP veze Kao što Slika 1.4 prikazuje, uspostavljenje TCP veze između dva računala se sastoji od razmjene triju poruka. Čitajući dijagram odozgora prema dolje vidi se redoslijed slanja poruka. Računalo A inicira vezu slanjem TCP segmenta s postavljenim kontrolnim bitom SYN i sa svojim inicijalnim rednim brojem (engl. Initial Sequence Number, ISN) koji je na slici prikazan varijablom Ainit. Kao ISN svakog procesa svake TCP konekcije bira se nasumično odabrani broj za kojeg je važno da se u mreži ne nalazi već neki segment iste ove veze s tim ISN-om. Pri kreiranju veze poziva se generator ISN-a koji odabire novi 32- bitni broj. Generator je vezan za brojilo čiji se najniži bit uvećava svake 4 μs te iz tog razloga ISN ima period od približno 4,55 sata. Kako pretpostavljamo da segment ne može biti u mrežu dulje od MSL (engl. Maximum Segment Life) koji u pravilu iznosi oko 120 sekundi, možemo smatrati da je ISN jedinstven. Kada Računalo B primi TCP segment Računala A, obradi ga te šalje svoj odgovor koji ima postavljene kontrolne bitove SYN i ACK te sadrži svoj ISN, na slici prikazan kao varijabla Binit, te broj potvrde primljenog segmenta Računala A (na slici ANUM) koja je vrijednosti zadnjeg primljenog okteta +1, u slučaju na slici Ainit+1. Nakon što primi taj segment, Računalo A završava uspostavu veze slanjem novog segmenta s postavljenim kontrolnim bitom ACK, ali ovaj put bez postavljene zastavice SYN. Taj segment također sadrži svoj redni broj te radni broj potvrde. 10

1.3.2. Prijenos podataka Nakon što je veza uspostavljena i ISN-ovi razmijenjeni procesi mogu početi slati podatke preko logičke veze. Veliki dio razmatranja prijenosa podataka se bazira na proučavanju različitih tehnika kontrole toke i kontrole zagušenja veze što će biti detaljno objašnjeno u sljedećim potpoglavljima dok će ovdje biti navedena samo osnovna ideja. Jednostavna implementacija protokola TCP će prosljeđivati podatke protokolu IP koji će se zatim proslijediti prema protokolu sloja podatkovne poveznice te će se slati prema prijamniku kroz mrežu. TCP će prosljeđivati podatke dok ne popuni prozor za slanje čiju veličinu oglašava prijamnik u svojim odgovorima. Kada prijamnik primi segment on će ga obraditi te će poslati potvrdu predajniku, te će slati svoje podatke ako ima kakve. Predajnik će prema potvrdama znati je li potrebna retransmisija određenih podataka. Važno je napomenuti da TCP u većini izvedbi koristi kumulativnu potvrdu (engl. cumulative acknowledgment) gdje prijamnik šaljući potvrdu s određenim brojem označuje da je primio sve oktete do tog rednog broja, te redni broj potvrde označuje redni broj sljedećeg okteta kojeg prijamnik očekuje primiti. Ako nema nikakvih podataka za slanje TCP predajnik će biti u stanju mirovanja čekajući da mu aplikacija proslijedi podatke za slanje ili da primi podatke s drugog kraja veze. Ako podaci u redu za slanje dosegnu veličinu koja prelazi maksimalnu veličinu prozora kojeg prijamnik može primiti, predajnik mora stati sa slanjem te čekati potvrde podataka koje je poslao prije nego nastavi slati podatke iz reda. Ako potvrda ne dođe predajnik će pričekati istek brojila te će zatim pretpostaviti da su podaci izgubljeni te će ih ponovo poslati. 1.3.3. Raskidanje TCP veze Da bi se veza raskinula potrebna je razmjena četiri TCP segmenta kao što prikazuje Slika 1.5. Potrebna su četiri segmenta zato što je TCP full-duplex protokol što znači da se svaki kraj veze mora zatvoriti neovisno o drugom. 11

Slika 1.5 Raskidanje TCP veze Za razliku od uspostavljanja veze, za raskid veze se koriste kontrolni bitovi FIN. Kao što Slika 1.5 prikazuje, Računalo A pokreće raskidanje veze slanjem TCP segmenta s postavljenim kontrolnim bitovima FIN i ACK. Zastavica FIN je postavljena zato što Računalo A želi zatvoriti vezu a zastavica ACK zato što potvrđuje posljednje primljene podatke s obzirom da je do tog trenutka trajala komunikacija koja nije prikazana na slici. Na slici je također prikazan redni broj segmenta čija je vrijednost prikazana varijablom Ainit+n te broj potvrde, Binit+m. Kada Računalo B primi taj segment odmah ga potvrđuje segmentom s postavljenim kontrolnim bitom ACK, s time da zastavica FIN nije postavljena, te dojavljuje aplikacije zatvaranje veze. Kada aplikacija Računala B odluči zatvoriti vezu ono šalje TCP segment s postavljenim kontrolnim bitovima FIN i ACK, svoji rednim brojem i brojem potvrde kojim potvrđuje zadnji primljeni oktet. Računalo A potvrđuje primanje tog segmenta te je time TCP veza raskinuta. 12

1.4. Kontrola toka Kontrola toka je tehnika čija je primarna svrha usklađivanje brzine slanja podataka predajnika s mogućnostima obrade prijamnika. Važno je da je brzina slanja dovoljno velika da bi protokol pružao dobre performanse, ali ne prevelika da se prijamnik ne preoptereti podacima koje neće stići obraditi. Važno je napomenuti da kontrola toka nije isto što i kontrola zagušenja koja je prvenstveno orijentirana prema zagušenju u mreži i mrežnim komponentama poput usmjeritelja. TCP, u većini svojih izvedbi, koristi kontrolu toka kliznim prozorom (engl. sliding window) koja je već spominjana u ovom radu. Glavna ideja je korištenje prozora koji označuje maksimalan broj podataka koje predajnik može poslati prije nego primi potvrde za poslane podatke. Slika 1.6 Kontrola toka kliznim prozorom Slika 1.6 prikazuje jednostavan primjer [6] kontrole toka kliznim prozorom. Ovdje je prozor veličine 4 bita te klizi po podacima kako prima potvrde za njih. Prvo pošalje prva četiri bita, zatim primi potvrde za prva dva biti te šalje dodatna dva bita i tako nastavlja dalje. 13

1.5. Detekcija gubitka paketa Primarni način na koji TCP zaključuje da je došlo do gubitka paketa je istek vremenske kontrole retransmisije (engl. Retransmission Time-Out, RTO). Kasnije verzije metoda upravljanja zagušenjem pretpostavljaju gubitak i u slučaju primanja više dvostrukih potvrda, ali to će biti detaljnije obrađeno s metodama koje to koriste. Vremenska kontrola retransmisije postavlja se u trenutku slanja segmenta i briše u trenutku primanja potvrde za taj segment. Iako bi se logički dalo zaključiti da se RTO postavlja za svaki segment, u praksi se to svodi na jedan mjerač vremena koji se odnosi na zadnji nepotvrđeni segment. Ukoliko se do isteka RTO ne primi potvrda za odaslani segment TCP pretpostavlja da je taj segment izgubljen te se uz retransmisiju mijenjaju dodatni parametri objašnjeni u sljedećem potpoglavlju. S motrišta pošiljatelja gubitak paketa i gubitak potvrde izgleda isto, te je posljedica jednaka s obzirom da u oba slučaju RTO istekne. Ako bi RTO bio postavljen na vrijednost manju od vremena potrebnog da segment stigne do prijamnika i da se do predajnika vrati potvrda (engl. Round-Trip Time, RTT), on bi uzrokovao nepotrebne retransmisije. Isto tako, ako bi RTO bio postavljen na vrijednost znatno veću od RTT, uzrokovao bi nepotrebno čekanje predajnika na segmente koji su stvarno izgubljeni i koje treba što prije ponovo poslati. Iz tog razloga RTO ne može biti unaprijed postavljena, nepromjenjiva vrijednost nego se mora dinamički izračunavati vodeći računa o stanju u mreži. U današnjim izvedbama za izračun RTO se koristi izraz (1.1). = +4 (1.1) Gdje su: RTT - varijabla koja služi kao procjena prosječnog vremena obilaska do odredišta D - srednja devijacija RTT-a koja se računa kao = U izrazu (1.1) RTT se računa prema izrazu (1.2), uzimajući u obzir prethodno izračunatu srednju vrijednost RTT i iznos RTT izmjeren za prethodni paket. = 1 + 1 _ (1.2) 14

Gdje su: RTT(t) - nova srednja vrijednost RTT(t-1) - prethodno izračunata srednja vrijednost RTT_izmjereno - izmjereni iznos RTT zadnjeg potvrđenog segmenta α - težinski koeficijent (0 α<1) RTT se mjeri kao diskretna varijabla, odnosno kao broj vremenskih jedinica otkucaja sata gdje je zrnatost otkucaja u pravilu 500 ms, iako se u nekim novijim verzijama koriste i satovi s manjim korakom. Koeficijent α utječe na brzinu osvježavanja RTT-a. Ako je α bliži jedinici na novi RTT najviše utječe prethodno izračunati RTT, tj. dugoročni prosjek. Ako je koeficijent α bliži nuli na novi RTT najveći utjecaj ima izmjerena vrijednost RTT-a. Time se može podesiti ovisnost RTT-a o kratkotrajnim promjenama, tj. brzina prilagodbe na promjene. RTO ima smisla računati samo za segmente koji su uspješno poslani iz prvog pokušaja zato što se u situaciji kada je potrebna retransmisija javlja problem ispravnog određivanja RTT-a. Problem se javlja zato što su izvorni i ponovno poslani segment identični pa predajnik ne može znati na koji od njih se odnosi potvrda, te bi se u slučaju pogrešnog povezivanja potvrde s prvim poslanim segmentom uzrokovalo nepotrebno povećanje RTTa, a u slučaju pogrešnog povezivanja potvrde s ponovno poslanim segmentom nepoželjno smanjivao RTT. Iz tog razloga se RTO u slučaju ponovnog slanja segmenta računa prema Karnovom algoritmu [7], tj. nova vrijednost RTO se računa množenjem prethodno izračunate vrijednosti faktorom γ (uobičajeno je γ = 2). Nakon što prvi sljedeći segment prođe bez retransmisije vrijednost RTO se računa na prije opisan način. 1.6. Osnovne metode kontrole zagušenjem Upravljanje zagušenjem u komunikacijskim mrežama je jedno od najproučavanijih područja telekomunikacija. Pojam upravljanja zagušenjem odnosi se na situaciju koju TCP interpretira kao zagušenje, a to je prvenstveno istek vremena RTO. U ovom potpoglavlju su opisane četiri osnovne metode kontrole zagušenjem protokola TCP koje je osmislio i predložio Van Jacobson u radovima [8] i [9] i koje su definirane u RFC 5681 [10]. Osnovna verzija protokola TCP, TCP Tahoe, koristi polagani početak, izbjegavanje zagušenja i brzu retransmisiju, dok sljedeća verzija, TCP Reno, koristi sve što i TCP Tahoe plus brzi oporavak. 15

Sve metode kontrole zagušenjem koriste sljedeće parametre: Najveća veličina segmenta (engl. Maximum Segment Size, MSS): najveći broj podatkovnih okteta koje pošiljatelj smije poslati u jednom TCP segmentu, on ovisi o mrežnoj tehnologiji i odgovara duljini podatkovnog polja okvira na sloju podatkovne poveznice umanjenoj za duljine IP i TCP zaglavlja Prozor primatelja (engl. receiver window, rwnd): broj okteta koje primatelj objavljuje da može primiti Prozor zagušenja (engl. congestion window, cwnd): inicijalno 1 MSS te se povećava sa svakom potvrdom prema metodama za upravljanje zagušenjem Prozor pošiljatelja (engl. sender window, swnd): najveći broj segmenata koje pošiljatelj smije poslati, definira se kao manja od vrijednosti rwnd i cwnd =, (1.3) Prag polaganog početka (engl slow start threshold, ssthresh) Upravljanje zagušenjem odvija se reguliranjem klizećeg prozora pošiljatelja, swnd, koji za računanje koristi spomenute parametre cwnd, rwnd i ssthres 1.6.1. Spori početak i izbjegavanje zagušenja Na početku TCP veze prozor pošiljatelja swnd se inicira na vrijednost oglašenog prozora primatelja rwnd, dok se prozor zagušenja cwnd postavlja na neku veliku vrijednost te tako na početku ne utječe na brzinu slanja. Kada dođe do isteka RTO, tj. gubitka segmenta, prag polaganog početka ssthresh se inicijalizira postavljanjem na polovicu veličine prozora pošiljatelja swnd prije gubitka paketa, uz uvjet da ssthres ne smije biti manji od 2*MSS: h h=,2 (1.4) 2 Vrijednost prozora zagušenja cwnd se postavlja na 1 MSS. Nakon postavljanje tih vrijednosti pošiljatelj će postupno povećavati cwnd kako bi povećao brzinu slanja. Ta faza se naziva spori početak (engl Slow Start). Na početku te faze veličina cwnd je 1 MSS što znači da predajnik može poslati samo jedan segment i onda mora čekati potvrdu uspješnog primitka prije nastavka slanja. Po primitku potvrde predajnik povećava cwnd za 1 MSS i tako onda za svaki uspješno poslani segment. Tako je nakon uspješnog 16

slanja prvog segmenta cwnd = 1 +1 = 2 MSS i pošiljatelj šalje dva segmenta. Ako su i oni uspješno potvrđeni cwnd = 2 + 2 = 4 MSS te se zatim šalju 4 segmenta. Ako su i oni uspješno potvrđeni cwnd se nastavlja eksponencijalno povećavati dok ne dosegne prag polaganog početka ssthresh. Nakon što cwnd dosegne vrijednost ssthres TCP prelazi u fazu izbjegavanja zagušenja (engl. Congestion Avoidance). U toj fazi prozor cwnd raste linearno te se povećava za maksimalno jedan segment po vremenu obilaska, tj. cwnd se povećava za _ đ _ _ _, tako da je faktor rasta cwnd: MSS za RTT ako se potvrdi svaki drugi segment 1 MSS za RTT ako se potvrdi svaki segment Linearni rast cwnd se može nastaviti najviše do veličine memorijskog spremnika. Slika 1.7 prikazuje ponašanje prozora zagušenja cwnd pri korištenju mehanizama spori početak i izbjegavanje zagušenja u slučaju isteka RTO u trenutcima 0 i 17. S obzirom da je cwnd bio veličine 20 u trenutku 16, nakon isteka RTO u trenutku 17 ssthresh se postavlja na polovicu te vrijednosti te TCP prelazi u fazu sporog početka. 17

Slika 1.7 Spori početak i izbjegavanje zagušenja 1.6.2. Brza retransmisija i brzi oporavak Već je rečeno da nakon što predajnik pošalje onoliko okteta koliko mu je dopušteno ostaje blokiran do sljedeće potvrde ili do isteka RTO. S obzirom da se RTO udvostručava za izgubljeni paket, u slučaju čestih gubitaka predajnik može dugo čekati istek RTO što loše utječe na performanse protokola. Taj problem rješava brza retransmisija (engl. Fast Retransmit). Glavna ideja brze retransmisije je da se ne čeka istek RTO nego da se segment ponovo pošalje čim postoji naznaka njegovog gubitka, odnosno ako prijamnik počne primati dvostruke potvrde od pošiljatelja. Brza retransmisija se pokreće čim predajnik primi 3 dvostruke potvrde za redom. S obzirom da TCP koristi kumulativnu potvrdu ako se određeni paket izgubi a ostali paketi nakon njega dolaze do odredišta normalno on će slati potvrde s rednim brojem potvrde postavljenim na radni broj sljedećeg segmenta kojeg treba primiti, a to je upravo izgubljeni segment. Takve potvrde se nazivaju dvostruke potvrde (engl. duplicate acknowledgment, DUPACK). Dvostruke potvrde mogu značiti 18

gubitak segmenta, uz to da se segmenti nakon njega dostavljaju normalno ili poremećaj redoslijeda, tako da je segment isporučen više od tri mjesta dalje od svog očekivanog mjesta. Ako segmenti stižu uz koliko-toliko očuvan redoslijed nema nepotrebnih retransmisija jer je većina DUPACK-a uzrokovana gubicima. Nakon brze retransmisije predajnik se vraća u fazu sporog početka. Dakle sve varijable upravljanja tokom, RTO, cwnd, swnd, ssthresh, se postavljaju kao da je došlo do isteka RTO samo što predajnik ne čeka toliko dugo da ponovo pošalje izgubljeni paket. U praksi je ustanovljeno da vraćanje predajnika u fazu sporog početka rezultira nepotrebnim drastičnim usporavanjem prijenosa radi gubitka samo jednog segmenta. Kao rješenje tog problema uvodi se brzi oporavak (engl. Fast Recovery). Metoda brzog oporavka dodana je u kombinaciji s metodom brze retransmisije. Ideja brzog oporavka je omogućiti brži oporavak TCP veze tako da čim predajnik primi tri dvostruke potvrde napravi sljedeće korake: izračuna prag polaganog početka ssthresh prema izrazu (1.5) h h= 2,2 (1.5) napravi brzu retransmisiju izgubljenog segmenta i privremeno poveća cwnd tako da za svaku dvostruku potvrdu cwnd poveća za 1 MSS, da se nadoknade paketi koji su već stigli, tako će za ona tri segmenta koji su uzrokovali tri DUPACK-a cwnd biti povećan prema izrazu (1.6) = h h+3 (1.6) kada stigne nova potvrda koja potvrđuje dolazak novih podataka, znači da je gubitak nadoknađen, postavlja cwnd na vrijednost ssthresh (1.7) te prelazi u fazu izbjegavanja zagušenja = h h (1.7) Prednost brzog oporavka je to što je prozor zagušenja prepolovljen a nije vraćen na 1 MSS kao što bi se dogodilo bez brzog oporavka što ilustrira Slika 1.8. 19

Slika 1.8 Brza retransmisija i brzi oporavak 1.7. Dodatne metode kontrole zagušenjem U ovom potpoglavlju su opisane ostale verzije protokola TCP. One se sve nadovezuju na osnovne metode iz prošlog potpoglavlja uvodeći nove funkcije i algoritme. Službene podatke o tome koja je verzija protokola TCP najčešće implementirana, odnosno koji mehanizam upravljanja zagušenjem se najčešće koristi nije bilo moguće naći. Prema mnogim izvorima TCP Reno je najčešće implementirana verzija protokola TCP, što se spominje u radovima [18], [19] i [20], iako neki drugi izvori kao najčešću implementaciju navode TCP New-Reno, na primjer rad [11], Također je sve češće podržan i TCP SACK, iako se da zaključiti da se znatno rjeđe koristi od Rena i New-Rena. 20

1.7.1. TCP Vegas TCP Vegas je modifikacija TCP Reno metode i predstavljen je u radu [12]. On uvodi novu strategiju retransmisije, u odnosu na TCP Reno, koja se bazira na mjerenju RTT-a pomoću sata s finijom granularnošću, te također nove metode otkrivanja zagušenja u fazama sporog početka i upravljanja zagušenjem. U radu [13] je također opisan rad metode TCP Vegas uz dodatni algoritam koji u fazi sporog početka pokušava zaključiti koliku propusnost dopušta mreža na osnovu razmaka dolazaka potvrda, ali taj algoritam je deklariran kao eksperimentalan te je isključen iz testiranja. TCP Vegas bilježi vrijednost sata za svaki odaslani segment te kada primi potvrdu računa novu vrijednost RTT-a koja je preciznija od vrijednosti koju računa TCP Reno jer je zrnatost sata TCP Vegasa finija u odnosu na sat koji koristi TCP Reno. Pomoću te preciznije vrijednosti RTT-a računa se RTO za svaki segment te se u slučaju dobivanja DUPACK-a provjerava istek RTO-a, te ako je istekao vrši se ponovno slanje bez čekanja još dva DUPACK-a. U slučaju primanja potvrde koja nije DUPACK, ali je prva ili druga potvrda nakon retransmisije, Vegas ponovo provjerava istek RTO-a te ako je to vrijeme isteklo ponovno šalje taj segment te će ta retransmisija uhvatiti pakete koji su izgubljeni prije prvog ponovnog slanja. Također, TCP Vegas smanjuje prozor zagušenja cwnd samo u slučaju kada je paket koji se ponovo šalje bio poslan nakon zadnjeg smanjenja prozora cwnd za razliku od TCP Reno gdje je moguće da se cwnd smanjih više puta ako se dogodi gubitak više paketa unutar jednog RTT. Glavna prednost metode Vegas u odnosu na Reno je to što je Reno reaktivna metoda koja zagušenje otkriva kada se ono već dogodilo, pomoću gubitaka segmenata, i ne može otkriti početna stanja zagušenja, dok je Vegas više proaktivna metoda koja pokušava predvidjeti zagušenje na temelju propusnosti koju dopušta mreža i to radi u fazi izbjegavanja zagušenja. Tu propusnost Vegas procjenjuje na temelju razlike očekivane i stvarne propusnosti. Očekivana propusnost se računa prema izrazu (1.8) gdje RTT base označava RTT nezagušene mreže (u praksi se uzima najmanja izmjerena vrijednost RTT-a). č = (1.8) Stvarna propusnost se računa prema izrazu (1.9), tj. kao omjer broja okteta poslanih unutar jednog RTT-a (N) i veličine tog RTT-a. Taj se izračun obavlja svaki RTT. 21

= (1.9) Kao što je rečeno Vegas računa razliku očekivane i stvarne vrijednosti, = č. Ako je Diff jako mali, tj. manji od zadanog praga koji označuje premali broj dodatnih podataka u mreži (Diff < α), Vegas će linearno povećavati cwnd u sljedećem RTT-u. Ako je Diff velik, tj. veći od zadanog praga koji označuje preveliki broj dodatnih podataka u mreži (Diff > β), Vegas će linearno smanjivati cwnd. U slučaju α < Diff < β cwnd se neće mijenjati. TCP Vegas također uvodi promjene u fazi sporog starta u odnosu na Reno. U toj fazi Vegas također pokušava procijeniti raspoloživu propusnost na sličan način kao u fazi izbjegavanja zagušenjem te povećava cwnd eksponencijalno svaki drugi RTT sve dok vrijednost stvarne propusnosti ne padne ispod vrijednosti očekivane i tada prelazi u fazu izbjegavanja zagušenja. 1.7.2. TCP New-Reno TCP New-Reno je modifikacija metode Reno koja je definiranu u RFC 6582 [14]. TCP New-Reno uvodi modifikaciju faze brzog oporavka metode Reno koja poboljšava efikasnost protokola. Kao što je već rečeno Reno će sa svakim gubitkom smanjiti prozor zagušenja cwnd za pola pri ulasku u fazu brzog oporavka te je time podložan velikom smanjenju cwnd u slučaju više gubitaka unutar istog prozora. Kao i Reno, New-Reno isto ulazi u fazu brze retransmisije nakon što primi dvostruke potvrde ali za razliku od Rena ne izlazi iz faze brzog oporavka dok svi podaci koji su poslani do vremena ulaska u fazu brzog oporavka ne budu potvrđeni. Kada New-Reno uđe u fazu brzog oporavka bilježi broj poslanih segmenata te kada dobije sljedeću potvrdu događa se jedan od dva moguća slučaja: ako potvrda potvrđuje sve segmente koji su poslani do trenutka ulaska u fazu brzog oporavka, izlazi iz faze brzog oporavka i postavlja cwnd na veličinu ssthresh te nastavlja s fazom izbjegavanja zagušenja ako je potvrda samo djelomična, tj. ne potvrđuje sve segmente koji su poslani do trenutka ulaska u fazu brzog oporavka tada zaključuje da je sljedeći segment izgubljen te ga ponovo šalje i postavlja broj dobivenih DUPACK-ova na nulu; izlazi iz faze brzog oporavka nakon što su svi poslani podaci potvrđeni 22

1.7.3. TCP SACK TCP SACK (engl. Selective Acknowledgment) [15] je proširenje metode TCP New-Reno koje omogućuje otkrivanje i ponovno slanje više izgubljenih segmenata u jednom RTT-u. SACK je znatno proširenje TCP logike s obzirom da uvodi novi mehanizam potvrđivanja paketa, koji za razliku od dosadašnje kumulativne potvrde, koja dopušta otkrivanje jednog izgubljenog segmenta, razmjenom dodatne informacije omogućuje otkrivanje više izgubljenih segmenata koji trebaju ponovno slanje. SACK koristi polje opcija u zaglavlju TCP segmenta u koje upisuje granice blokova paketa koje je slijedno primio. Svaki blok je definiran s dva 32-bitna cijela broja. Ti brojevi predstavljaju lijevi rub bloka, koji je prvi redni broj u bloku koji se potvrđuje i desni rub bloka, koji je prvi redni broj koji sljedeći dolazi nakon zadnjeg rednog broja bloka. Svaki blok predstavlja oktete koji su slijedno primljeni, tj. okteti koji se nalaze na radnim brojevima manjim od rednih brojeva bloka (lijevi rub - 1) i rednim brojevima većim od rednih brojeva bloka (desni rub) nisu primljeni. S obzirom da je polje opcija ograničeno na 40 okteta SACK može potvrditi najviše četiri bloka primljenih paketa, iako se to u praksi najčešće svodi na tri bloka zato što se polje opcija koristi i za druga poboljšanja performansi protokola TCP (kao na primjer timestamp). Predajnik ulazi u fazu brzog oporavka isto kao i u metodama Reno i New-Reno te postavlja cwnd na pola dosadašnje vrijednosti s razlikom da u ovoj metodi zna koliko je paketa nepotvrđeno te tu vrijednost sprema u varijablu pipe. Svaki put kada primi potvrdu za određeni segment vrijednost varijable pipe smanji za 1 te ako je ta vrijednost manja od cwnd provjeri koji su segmenti nepotvrđeni te ih ponovo šalje. Svaki put kada ponovno pošalje segment vrijednost varijable pipe povećava za 1. Iz faze brzog oporavka izlazi kada dobije potvrde za sve segmente poslane prije ulaska u tu fazu, isto kao i metoda New- Reno. Korištenje SACK metode se mora eksplicitno naglasiti pri uspostavljanju TCP veze te oba kraja te veze moraju podržavati SACK, u slučaju da to nije slučaj koristi se neka druga metoda kao na primjer New-Reno. 23

1.7.4. TCP FACK TCP FACK (engl. Forward Acknowledgment) [16] je nadogradnja metode SACK koja koristi mogućnosti koje pruža SACK te pomoću njih pruža precizniju kontrolu slanja podataka u fazi brzog oporavka. FACK algoritam uvodi dvije nove varijable stanja, snd.fack i retran_data, pomoću kojih prati točan broj odaslanih nepotvrđenih okteta. Varijabla snd.fack se osvježava tako da njena vrijednost označuje najveći redni broj okteta koje je prijamnik točno primio. U svim fazama osim faze brzog oporavka varijabla snd.fack se osvježava pomoću rednog broja potvrde te ima istu vrijednost kao varijabla snd.una, koja je definirana u protokolu TCP, u strukturi TCB (engl. Transmission Control Block), kao redni broj prvog okteta nepotvrđenog segmenta. U fazi brzog oporavka predajnik nastavlja osvježavati varijablu snd.una pomoću rednih brojeva potvrda, dok varijablu snd.fack osvježava pomoću podataka SACK metode. Kada je primljen SACK blok koji potvrđuje podatke sa rednim brojem većim od trenutne vrijednosti varijable snd.fack ona se osvježuje tako da sadrži najveći redni broj primljenih podataka plus jedan. Algoritmi predajnika koji se bave pouzdanošću protokola nastavljaju koristiti snd.una, dok su algoritmi koji se bave upravljanjem zagušenjem promijenjeni tako da koriste varijablu snd.fack. FACK definira dodatnu varijablu awnd koja označuje broj odaslanih okteta za koje predajnik nije dobio potvrdu (1.10). Varijabla snd.nxt je također jedna od varijabla definiranih u protokolu TCP i označuje redni broj prvog okteta segmenta koji je sljedeći na redu za slanje. =.. (1.10) U fazi brzog oporavka za računanje awnd se mora koristiti i broj ponovo poslanih podataka dan varijablom retran_data. Svaki put kada je neki segment ponovo poslan retran_data se poveća za veličinu tog segmenta te kada segment napusti mrežu (na primjer kada je potvrđen) retran_data se smanji za veličinu tog segmenta. Broj odaslanih okteta za koje predajnik nije dobio potvrdu se računa prema izrazu (1.11). =.. + _ (1.11) Dok je awnd < cwnd predajnik smije slati podatke dok u suprotnom mora čekati dok se vrijednost varijable awnd ne spusti ispod vrijednosti cwnd. FACK ne definira koji će se podaci slati nego to preuzima od metode SACK, najčešće se šalju najstariji podaci prvi. 24

2. Simulacija Sve su simulacije u ovom radu ređene pomoću mrežnog simulatora NS2 (engl. Network Simulator version 2). NS2 je open-source mrežni simulator čije se simulacije ne događaju u stvarnom vremenu nego su vođene događajima (engl. event-driven) te je vrlo koristan u proučavanju dinamičkog ponašanja komunikacijskih mreža [17]. NS2 pruža razne mogućnosti simuliranja žičnih i bežičnih mrežnih scenarija i protokola te zahvaljujući svojoj modularnoj građi dopušta stvaranje novih simulacijskih objekata. On se sastoji od osnovnih komponenti i same jezgre simulatora napisanih u programskom jeziku C++ te simulacijskih skripti koje se pišu u programskom jeziku Object Tcl (OTcl). OTcl je povezan sa jezgrom pisanom u C++ tako da se simulacije mogu definirati, mijenjati i izvoditi bez potreba za ponovnim kompajliranjem C++ dijela simulatora pri svakoj promjeni. NS2 rezultate simulacije zapisuje u izlazne datoteke koje definira korisnik te se koriste dodatni alati za analizu tih podataka i prikaz željenih rezultata. Najčešće korišteni dodatni alati su NAM (engl. Network Animator) koji služi za generiranje animacija na temelju simulacije, GNUPLOT ili Xgraph koji služe za generiranje grafova na temelju izlaznih datoteka te se također vrlo često koriste skripte pisane u programskom jeziku AWK koji služi za obradu velikih količina tekstualnih podataka te se u ovom radu koristi besplatna implementacija GAWK (GNU AWK). 2.1. Simulacijsko okruženje U ovom radu će biti simulirane dvije vrste scenarija čiji će cilj biti prikaz i analiza ponašanja pojedinih mehanizama izbjegavanja zagušenja protokola TCP, objašnjenih u poglavljima 1.6 i 1.7, u idealnom slučaju te u situacijama pri interakciji više raznih TCP tokova, interakciji sa drugim podatkovnim tokovima te utjecajima određenih drugih parametara na protokol TCP kao što je povećana vjerojatnost pogreške i sl. U oba scenarija će se pratiti kako spomenute situacije utječu na protokol TCP prateći parametre propusnosti protokola (engl. throughput), prozora zagušenja (cwnd) te vremena povrata (RTT). 25

2.1.1. Mrežni model i parametri Oba simulacijska scenarija će koristiti istu mrežnu topologiju koju prikazuje Slika 2.1. Na slici je prikazana topologija koja se sastoji od šest čvorova povezanih duplex poveznicama. Čvorovi n0 i n1 generiraju promet te ga prosljeđuju prema čvoru n2. Poveznica n2-n3 simulira "usko grlo" veze, tj. na njoj će se stvarati zagušenje i događati gubici, dok su čvorovi n4 i n5 odredišni čvorovi. Slika 2.1 Mrežna topologija simulacijskih scenarija U oba scenarija poveznice n0-n2, n1-n2, n3-n4, n3-n5 imaju zadane iste parametre, maksimalnu propusnost 1000 Mb/s i kašnjenje 1 ms dok poveznica n2-n3 ima manju maksimalnu propusnost koja iznosi 100 Mb/s te veće kašnjenje iznosa 10 ms. Sve poveznice imaju istu vrstu reda čekanja Drop Tail, tj. svi se paketi tretiraju jednako te kada se red popuni novo pridošli paketi se odbacuju sve dok se u redu ne oslobodi mjesto za nove pakete, te je maksimalna veličina reda postavljena na 50 paketa. Oba scenarija koriste dva toka podataka na prikazanoj topologiji. U prvom scenariju se koristi TCP tok između čvorova n0 i n4 kojemu će se mijenjati mehanizam upravljanja zagušenjem i kojeg koristi aplikacija FTP (engl. File Transfer Protocol), te UDP tok između čvorova n1 i n5 kojeg koristi aplikacija CBR (engl. Constant Bit Rate). Određen je skup početnih parametara koji će se koristiti u tom scenariju te će biti naglašeno ako se pojedini parametri mijenjaju. Početni parametri TCP toka su: $tcp1 set fid_ 0 $tcp1 set window_ 1000 $tcp1 set windowinit_ 1 26

$tcp1 set overhead_ 0 $tcp1 set packetsize_ 1000 $tcp1 set maxburst_ 0 $tcp1 set maxrto_ 64 $tcp1 set slow_start_restart true $tcp1 set tcptick_ 0.1 $tcp1 set syn_ 1 UDP tok i parametri CBR aplikacije se neće mijenjati te oni glase: $cbr1 set packetsize_ 1000 $cbr1 set interval_ 0.005 $cbr1 set rate_ 70Mb Sve simulacije prvog simulacijskog scenarija će trajati 60 sekundi i imati će stalna vremena početka i prekida slanja koja glase: $ns at 5.0 "$ftp1 start" $ns at 55.0 "$ftp1 stop" $ns at 15.0 "$cbr1 start" $ns at 35.0 "$cbr1 stop" U tom scenariju će biti prikazano ponašanje pojedinih mehanizama izbjegavanja zagušenja protokola TCP u interakciji sa UDP tokom te će svaki mehanizam biti ispitan izmjenom dodatnih parametara mreže. Gubitak paketa na poveznici n2-n3 je postignut procedurom errormod u kojoj je učestalost gubitaka definirana po uniformnoj distribuciji slučajne varijable, te se vjerojatnost gubitka mijenja ovisno o tome što se proučava simulacijom. Neke će simulacije biti provedene bez gubitaka, dok će druge sadržavati gubite te će vjerojatnost gubitaka uvijek biti naglašena. Jedinica gubitka je paket. 27

U drugom scenariju se koristite dva TCP toka, prvi između čvorova n0 i n4, te drugi između n1 i n5. Oba TCP toka imaju iste početne parametre kao TCP tok iz prvog scenarija i oba toka koristi instanca aplikacije FTP. Sve simulacije drugog simulacijskog scenarija će također trajati 60 sekundi i imat će stalna vremena početka i prekida slanja koja glase: $ns at 2.0 "$ftp0 start" $ns at 45.0 "$ftp0 stop" $ns at 15.0 "$ftp1 start" $ns at 58.0 "$ftp1 stop" Kao što je vidljivo iz gornjih vremena slanja, slanje dva TCP toka će se preklapati punih 30 sekundi, od 15. do 45. sekunde. U tom scenariju će biti ispitana interakcija dva različita mehanizama zagušenja te pravednost između njih. 2.1.2. Prikupljanje i prikaz rezultata Već je spomenuto da NS2 kao izlaz daje datoteke iz kojih se onda analizira simulacija. Izlazne datoteke definira korisnik te oba simulacijska scenarija sadrže dvije datoteke u kojima se prate sve aktivnosti u simulaciji. Prva služi da stvaranje animiranog prikaza simulacije (za prvi simulacijski scenarij to je datoteka outsim1nam.nam, a za drugi outsim2nam.nam) a druga (za prvi scenarij to je datoteka outsim1all.tr, a za drugi outsim2all.tr) se sastoji od detaljnih podataka o svim događajima u simulaciji upisanih u redove, gdje se svaki red sastoji od sljedećih informacija: 1. Identifikator tipa događaja: "+": ulazak paketa u red "-": izlazak paketa iz reda "r": paket je uspješno primljen "d": paket je izgubljen "c": sudar paketa na sloju podatkovne poveznice 2. Vremenski trenutak u simulaciji kada se događaj dogodio 3. Identifikacijski broj izvorišnog čvora (engl. source node) paketa 4. Identifikacijski broj odredišnog čvora (engl. destination node) paketa 28

5. Ime vrste paketa 6. Veličina paketa u oktetima 7. Polje od 7 bita koje označava zastavice, "-" označava neaktivnu zastavicu: 1. bit: "E" - ENC (engl. Explicit Congestion Notification) echo je uključen 2. bit: "P" - zastavica prioriteta u IP zaglavlju je aktivna 3. bit: nije u uporabi 4. bit: "A" - akcija zagušenja 5. bit: "E" - označuje događaj zagušenja 6. bit: "F" - koristi se TCP brzi početak 7. bit: "N" - ECN je uključen 8. Identifikacijski broj toka 9. Izvorišna adresa u formatu a.b gdje je a adresa, a b su vrata 10. Odredišna adresa u formatu a.b gdje je a adresa, a b su vrata 11. Redni broj (broj u nizu) 12. Jedinstveni identifikacijski broj paketa Valja napomenuti da je izgled izlazne datoteke pri simuliranju bežičnih scenarija nešto drugačiji od prikazanog, no s obzirom da se u radu koriste samo žični scenariji to nije toliko važno te se dodatne informacije o simulatoru NS2 mogu naći u [21]. Gore opisana datoteka služi za detaljnu analizu simulacije, te se iz nje mogu izvesti svi grafovi koji se koriste u analizi ali se zbog jednostavnosti koriste dodatne datoteke, te svaka ima definiranu metodu koja za vrijeme simulacije filtrira i računa željene parametre te određuje format datoteke, dok će se analiza gornje, sveobuhvatne, datoteke vršiti dodatnim AWK skriptama. 29

3. Rezultati simulacija i njihova analiza U ovom će poglavlju biti prikazani i analizirani rezultati simulacija. Potpoglavlja 3.1, 3.2, 3.3 i 3.4 će biti bazirana na prvom simulacijskom scenariju. Za svaku simulaciju će biti iscrtana dva grafa. Prvi graf će prikazivati propusnost protokola TCP crvenom bojom i propusnost protokola UDP zelenom bojom u Mbit/s, kroz vrijeme simulacije. Drugi graf će prikazivati promjenu veličine prozora zagušenja cwnd protokola TCP u paketima kroz vrijeme. Također će se za obradu rezultata simulacija koristiti AWK skripte, throusim1.awk, rttsim1.awk i cwndsim1.awk, koje će računati prosječnu propusnost protokola TCP, njegov prosječni RTT, te prosječnu veličinu prozora cwnd. Potpoglavlje 3.5 će biti bazirano na drugom simulacijskom scenariju. Također će za svaku simulaciju biti iscrtana dva grafa koji će prikazivati promjene propusnosti i veličine prozora cwnd oba TCP toka u vremenu simulacije. Za dodatnu obradu podataka će se također koristiti AWK skripte, throusim2.awk, cwnd1sim2.awk i cwnd1sim2.awk, koje će računati prosječnu propusnost oba protokola, te prosječnu veličinu prozora cwnd prvog i drugog toka tijekom cijele simulacije i u intervalu od 15. do 45. sekunde. 3.1. Rezultati referentnih simulacija U ovom su potpoglavlju dani rezultati referentnih simulacija, tj. simulacija s početnim parametrima koji su navedeni u potpoglavlju 2.1.1 i koji predstavljaju idealne uvjete, tako da su ove simulacije provedene bez modula koji simulira pogreške na poveznici n2-n3. Kao što je već spomenuto slanje podataka protokolom UDP će se u svim simulacijama pokretati u isto vrijeme tako da svi mehanizmi izbjegavanja zagušenja imaju iste uvjete. 30

Slika 3.1 Tahoe propusnost, referentno Slika 3.2 Tahoe cwnd, referentno Slika 3.1 prikazuje propusnost protokola TCP Tahoe. Iz nje se odmah vidi jedna značajna veza između protokola UDP i TCP, a to je da kada aplikacija CBR, koja šalje preko protokola UDP, počne slati podatke ona zauzima sav kapacitet kanala koji može zauzeti, te se TCP tome prilagođava. Prosječna propusnost protokola TCP, od pete sekunde do pedesetpete, koliko traje njegovo slanje iznosi 48.49 Mbit/s. Prosječna veličina prozora cwnd iznosi 121 paketa, te se usporedbom gornja dva grafa može vidjeti veza između prozora zagušenja cwnd i propusnosti protokola. Ta veza je u ovom simulacijskom scenariju tako naglašena zato što je oglašavani prozor primatelja rwnd postavljen na 1000 dok cwnd nikada ne doseže tu veličinu. Iz izraza (1.3) u potpoglavlju 1.6 znamo da je prozor pošiljatelja swnd jednak manjoj od te dvije vrijednosti, tj. u ovom će slučaju swnd biti uvijek jednak cwnd. Procjena prosječnog vremena obilaska, RTT, iznosi 24.69 ms. Slika 3.3 Reno propusnost, referentno Slika 3.4 Reno cwnd, referentno Slika 3.3 prikazuje propusnost protokola TCP Reno te se iz nje može odmah uočiti da je propusnost veća nego kod protokola TCP Tahoe. Prosječna propusnost protokola TCP Reno iznosi 52.25 Mbit/s zahvaljujući tome što se cwnd ne vraća na 1 tako često kao kod protokola TCP Tahoe. Samim time je i prosječna vrijednost prozora cwnd veća te iznosi 133 paketa. Prosječni RTTT iznosi 24.75 ms. 31

Slika 3.5 Vegas propusnost, referentno Slika 3.6 Vegas cwnd, referentno Slika 3.5 prikazuje propusnost protokola TCP Vegas. S obzirom da su mehanizmi upravljanja zagušenjem objašnjeni i simulirani u ovom radu samo nadogradnja jedni drugih, za očekivati je da će se većim djelom slično ponašati. Uspoređujući referentne grafove protokola TCP Vegas s onom protokola TCP Reno i Tahoe odmah se uočava manji broj promjena veličine prozora cwnd, te samim time i manji broj promjena razine propusnosti. To je zahvaljujući mehanizmima opisanim u potpoglavlju 1.7.1 koji omogućavaju protokolu TCP Vegas više proaktivnu ulogu, za razliku od ostalih mehanizama koji su više reaktivni, gdje može detektirati zagušenje i prije nego nastupe stvarni gubitci koji bi uzrokovali smanjenje veličine prozora cwnd, te samim time i smanjenje propusnosti. Prosječna propusnost protokola TCP Vegas iznosi 61.97 Mbit/s, prosječna veličina prozora cwnd iznosi 161 paket dok je prosječni RTT 24.32 ms. Slika 3.7 New-Reno propusnost, referentno Slika 3.8 New-Reno cwnd, referentno Propusnost protokola TCP New-Reno prikazuje Slika 3.7. S obzirom da je New-Reno, kao i Vegas, modifikacija protokola TCP Reno, njegova krivulja propusnosti je slična krivulji protokola Reno ali primjetno drugačija od protokola Vegas s obzirom da New-Reno uvodi drugačije promjene od Vegasa, objašnjene u potpoglavlju 1.7.2. Iz krivulja se vidi da vrijednost prozora cwnd kod New-Rena još rjeđe pada na veličinu 1 nego kod Rena te je samim time i prosječna propusnost protokola TCP New-Reno veća i iznosi 53.17 Mbit/s, te 32