SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

DIPLOMSKI RAD br. 2554

ANALIZA PERFORMANSI PROTOKOLA TCPsnoop U BEINIM LOKALNIM MREAMA

Dejan Jaki

Zagreb, lipanj 2005.

Mentor rada: prof.dr.sc Alen Baant

Voditelj rada: dr.sc eljko Ili

Sadraj Uvod........................................................................................................................................... 1 1. Protokol TCP - openito .................................................................................................... 2 1.1. 2. Kratki uvod u protokol TCP ...................................................................................... 2

Protokol TCP-snoop........................................................................................................... 9 2.1. 2.2. 2.3. 2.4. Metoda SnoopData() ................................................................................................ 12 Metoda SnoopAck() .................................................................................................. 13 Odnos protokol TCP-snoop - protokol usmjeravanja ............................................. 15 Alternativna rjeenja na sloju linka.......................................................................... 16 Smjer predajnik pokretnog vora prijemnik bazne stanice........................... 17 Smjer predajnik bazne stanice prijemnik pokretnog vora........................... 17

2.4.1. 2.4.2. 3.

Rezultati simulacije i opis programa................................................................................ 20 3.1. 3.2. Model rjeenja simulatora........................................................................................ 20 Parametri simulacije i komponente simulatora........................................................ 21 Fritchmanov model beinog kanala s gubicima............................................. 23

3.2.1. 3.3.

Rezultati simulacije.................................................................................................. 24

Zakljuak.................................................................................................................................. 31 Literatura.................................................................................................................................. 32 Skraenice ................................................................................................................................ 33 Popis stranih izraza .................................................................................................................. 34 Dodatak .................................................................................................................................... 35

Uvod
Cilj ovog diplomskog zadatka je opis i implementacija poboljanja protokola TCP (engl. Transmission Control Protocol) u beinom okruenju. Za predmet razmatranja uzet je protokol TCP snoop kao jedno od rjeenja s najboljim rezultatima. Snoop se pridodaje kao modul mrenom sloju (engl. Network Layer) referentnog OSI modela (engl. Open System Interconnection) bez zadiranja u transportni sloj (engl. Transport Layer). Integracija snoop modula vrijedi za infrastrukturni WLAN (engl. Wireless Local Area Network) kao i za neovisni WLAN (engl. ad hoc). U ovom radu za razmatranje je uzet infrastrukturni WLAN jer u takvoj arhitekturi snoop daje najbolje rezultate. Protokol TCP je pouzdani transportni protokol prvenstveno namijenjen inim mreama gdje njegovi mehanizmi kontrole toka uredno funkcioniraju. Meutim, njegova implementacija u beinom okruenju je malo problematina te su potrebne odreene preinake. Sukladno s time razvila su se razna rjeenja i inaice protokola TCP u beinim lokalnim mreama. Neke od karakteristika beinih mrea su: visoka uestalost pogreke bita (engl. Bit Error Ratio), koji iznosi do ak 10-3, veliko varijabilno kanjenje segmenata (engl. jitter), kapacitet i veliina elije, interferencija s drugim elektromagnetskim izvorima, promjena mrene topologije i osjetno smanjena propusnost (engl. throughput). Sve navedene injenice bitno utjeu na kvalitetu usluge, QoS (engl. Quality of Service) ili drugim rijeima na stupanj zadovoljstva korisnika nekom mrenom uslugom. Najvei problem predstavlja beini kanal, odnosno njegova nestabilnost pri prijenosu informacije od poiljatelja do primatelja. Snoop je samo jedno od razvijenih rjeenja, ali kao takav pokazuje najbolje rezultate u cilju poveanja propusnosti i efikasnosti rada protokola TCP u WLAN-u.

Napomena: Termin pristupna toka e se u nastavku rada koristiti ravnopravno kao i termin bazna stanica u ovisnosti o tome dali se govori o WLAN-u ili WMAN-u (engl. Wireless Metropolitan Area Network).

1. Protokol TCP - openito

1.1. Kratki uvod u protokol TCP
Protokol TCP radi na nain opisan u nastavku, a za detaljniju analizu rada protokola TCP pogledati u (Stevens [1995]). Protokol TCP je pouzdani transportni protokol i osnova je rada dananje Internet mree, gdje se vee uz mreni protokol IP (engl. Internet Protocol). TCP prua pouzdani prijenos podataka i kontrolu toka koji ukljuuju mehanizme izbjegavanja zaguenja u mrei. Pouzdanost je ostvarena kroz mehanizme slanja i oekivanja potvrda o ispravnom prijemu za poslane segmente te koritenjem strategije ponovnog slanja nepotvrenih segmenata (retransmisija). Svaka potvrda poslana od primatelja sadri informaciju o rednom broju segmenta kojeg sljedeeg oekuje kao i o koliini podataka koju je trenutno primatelj spreman prihvatiti. Nadalje, poiljatelj prilikom slanja svakog segmenta pokree vremenski broja i izvodi ponovno slanje segmenta ukoliko potvrda o prijemu ne stigne prije isteka brojaa (engl. timeout). Tri temeljna algoritma na kojima se zasniva rad protokola TCP su : Spori start (engl. slow start); Izbjegavnje zaguenja (engl. congestion avoidance) i Brzo ponovno slanje (engl. fast retransmission).

Navedeni algoritmi vrijede za ''temeljni TCP'', tj. Tahoe TCP dok se u ostalim inaicama protokola uvode poboljanja. Tako se za Reno TCP dodaje algoritam ubrzanog oporavka (engl. fast recovery). Ovaj algoritam omoguuje da se umjesto pokretanja sporog starta nakon primitka ponovljenih potvrda (uzimaju se u obzir tri potvrde) nastavi s izbjegavanjem zaguenja. Time se poveava iskoristivost mrenih resursa jer se ne eka na istek vremenskog brojaa te ponovnog slanja. Da bi se razumjela analitika dana u nastavku rada potrebno je opisati neke od temeljnih varijabli i vrijednosti bitne za rad TCP-a. I poiljatelj i primatelj imaju varijable prozora zaguenja (engl. congestion window). Za poiljatelja je to cwnd te predstavlja mjeru kapaciteta mree, a na strani primatelja to je rcvwnd i predstavlja mjeru kapaciteta na odredinoj strani. Maksimalni broj nepotvrenih segmenata izraava se kao min{cwnd, 2

rcvwnd}. Kada primatelj primi segment van redoslijeda alje ponovljenu potvrdu (obino se uzimaju 3 ponovljene potvrde) i na taj nain signalizira poiljatelju da je segment na koji pokazuje potvrda izgubljen te se taj segment ponovno alje i izvrava se algoritam sporog starta. Mehanizam rada samog protokola dan je prvo grafiki (Sl. 1-1), a zatim i matematiki. Kao to je vidljivo sa slike (Sl. 1-1) za vrijeme sporog starta vezan je eksponencijalni porast prozora zaguenja, dok je izbjegavanje zaguenja linearan. Takoer vrijedi da nakon isteka brojaa spori start traje samo do polovice veliine prozora zaguenja.

Sl. 1-1 Spori start izbjegavanje zaguenja

Analiza i opis varijabli karakteristinih za protokol TCP dani su u nastavku : Inicijalizacija : cwnd = 1; // prilikom prijema svake potvrde povea se za 1 sstresh = 65536; // put od sporog starta do izbjegavanja zaguenja (engl. slow start treshold) Dolazak potvrde ACK : if ( cwnd < sstresh) // spori start sstresh cwnd += MSS; // maksimalna veliina segmenta else // izbjegavanje zaguenja (engl. congestion avoidance)

cwnd += MSS * MSS; Dolazak dupliciranih potvrda ACK : cwnd /= 2; // smanjenje veliine prozora za pola te ponovno slanje segmenata poevi od nepotvrenog 3

sstresh = cwnd; Pretpostavlja se za da je dolo do zaguenja u mrei i gubitka segmenta. Istek vremenskog brojaa - timeout : sstresh = cwnd/2; cwnd = 1; // ponovno slanje segmenta Protokol TCP koristi princip klizeih prozora (engl. sliding window) prikazan na slici (Sl. 1-2), gdje veliina prozora pokazuje maksimalni broj segmenata koje mrea moe primiti ili drugim rijeima kapacitet mree. Bitno je naglasiti da i poiljatelj i primatelj imaju svoje prozore. U svakoj pristigloj potvrdi primatelj obavjetava poiljatelja o veliini svog prozora. Prilikom slanja svaki segment podataka se oznaava rednim brojem (engl. sequence number) koji se upisuje u zaglavlje segmenta (paketa). Najvea doputena veliina segmenta (MSS Maximum Segment Size) definiran je kao : MSS = MTU IPheader - TCPhedaer . MTU (engl. Maximum Transfer Unit) je maksimalna veliina jedinice prijenosa za neki tip mrene tehnologije, dok se zaglavlja odnose na mreni odnosno transportni sloj. U tablici (Tablica 1) su prikazane veliine MTU-a definirani RFC (engl. Request for Comments) dokumentima.
Tablica 1 Pregled MTU-a za pojedine mrene tehnologije

RFC # 1356 1055 894, 895 1042 IBM standard

Opis tehnologije X.25, ISDN Serial Line IP (SLIP) Ethernet 4 Mbit/s Token Ring 16 Mbit/s Token Ring

MTU (okteta) 68 1066 1500 4464 17914

1374 1390

HIPPI FDDI

65535 4532

Sl. 1-2 Mehanizam klizeeg prozora

Upravo zbog navedenih razloga TCP prua pouzdani prijenos informacija i kontrolu toka. Prva polovica klizeeg prozora odnosi se na poslane ali nepotvrene segmenta dok je druga polovica za segmente koji se mogu poslati odmah. Prilikom primitka svake potvrde klizei prozor se pomie udesno za jedno mjesto. Bitno je jo naglasiti da je protokol TCP pouzdan i konekcijski orijentiran te kao takav ima ugraen mehanizam uspostave konekcije. Razlog tome je u mogunosti razmjene parametara izmeu poiljatelja i primatelja te rezervacija potrebnih resursa. Postupak uspostave veze (Sl. 1-3) naziva se three-way handshake i karakterizira ga izmjena sinkronizacijskih segmenata (SYN), dok je postupak raskidanja konekcije vezan uz razmjenu FIN segmenata. Strana koja pokree konekciju alje svoj sinkronizacijski segment s rednim brojem segmenta koji je sluajno odabran. Nakon primanja SYN segmenta primatelj odgovara sa svojim SYN segmentom i rednim brojem segmenta kojeg sljedeeg oekuje. Naposljetku poiljatelj potvruje redni broj segmenta te zapoinje prijenos prvog podatkovnog segmenta. Primjer slanja podatkovnih segmenata i naina rada protokola TCP prikazan je slikom (Sl. 1-4), (Kralj [2003]). Za navedeni primjer poiljatelju je dozvoljeno slanje 5840 okteta podataka i to od rednog broja 1000 uz pretpostavku da su svi segmenti veliine 1460 okteta. Prozori na poiljateljevoj i primateljevoj strani postavljeni su na 5840 okteta, a to znai da poiljatelj moe poslati maksimalno 4 segmenta prije nego to stigne potvrda koja e aurirati njegov klizni prozor i omoguiti nastavak slanja. Nakon slanja svih 5840 okteta, stie potvrda koja potvruje prva 3 TCP segmenta. Klizei prozori se auriraju te se dozvoljava slanje dodatna 3 segmenta. 5

Strana A

Strana B

SYN se q

=X

eq SYN s

CK X+ = Y, A

ACK Y+1

Sl. 1-3 Three-way handshake

U trenutku kada su poslana sljedea 3 segmenta poiljatelj privremeno obustavlja slanje podataka, veliina prozora je nula, a to traje sve dok ne stigne nova potvrda. Princip rada klizeih prozora objanjen je u (Kralj [2003]).

Sl. 1-4 Tok prijenosa TCP segmenata

Kao to se vidi iz prijanjih objanjenja protokol TCP koristi proirenu metodu ARQ (engl. Automatic Repeat Request) Go-back-N uz proraun perioda vremenske kontrole na osnovu procijenjenog vremenskog krunog kanjenja RTT (engl. Round Trip Time). RTT je vrijeme koje je proteklo od trenutka slanja segmenta do trenutka primitka potvrde o prijemu segmenta. 6

Protokol TCP na svaki gubitak segmenta ''reagira'' na nain: Smanjenjem cwnd varijable na polovicu vrijednosti varijable sstresh. Ovo doprinosi smanjenju koliine podataka koji se alju u mreu. Na taj nain smanjuju se gubici nastali zaguenjem u mrei; Ponovnim postavljanjem varijable cwnd na vrijednost jednog segmenta i ulazak u spori start te eksponencijalni rast prozora zaguenja do sstresh = cwnd/2 vrijednosti kada poinje linearno izbjegavanje zaguenja; Vraanje na poetnu vrijednost i proraun vremenskog isteka brojaa na osnovu prethodnih vrijednosti i uz pomo Karnovog algoritma koji kae da u sluaju ponovnog slanja segmenta, nova vrijednost vremena isteka brojaa rauna se mnoenjem prethodno izraunate vrijednosti s faktorom koji je najee iznosa 2, (Stevens [1995]). esto se ovaj mehanizam naziva i backoff strategija. U sluaju velike uestalosti pogreaka prozor zaguenja se smanjuje prije ponovnog slanja segmenta. Protokol TCP je izvorno razvijan kao transportni protokol vezan uz iane mree te je usko vezan uz mreni protokol IP i upravo je zbog tih razloga potrebna modifikacija protokola TCP u beinom okruenju. Ostale inaice protokola TCP biti e samo nabrojane, vie u (Stevens [1995]): New Reno TCP ; SACK TCP ; Vegas TCP.

Bitno je za naglasiti da Vegas TCP u odnosu na Reno TCP pokazuje poveanje propusnosti do ak 70 % uz 50 70 % manje retransmisija. Na slici (Sl. 1-5) dana je podjela razliitih inaica protokola TCP u beinom okruenju, (Elaarag [2002]). Puni nazivi navedenih kratica objanjeni su na kraju rada. U sluaju gubitaka i velike uestalosti pogreaka u mrei protokol TCP radi kao i u inom okruenju i tu je izvor problema za rad u beinom okruenju. Smanjenjem prozora zaguenja kao odgovor na nepostojee zaguenje znatno se smanjuje propusnost i poveava kanjenje u WLAN-u. Uzrok navedenih problema je u nestabilnosti beinog linka (engl. wireless link) na kojem nastaju i najvei gubici koji nisu uvijek zbog zaguenja nego, npr. zbog fadinga (iznenadni propadi snage signala), prekida veze, interferencija s drugim elektromagnetskim izvorima, viestaznog rasprostiranja signala (engl. multipath propagation), ogranienosti kapaciteta elije itd.

Sl. 1-5 Rjeenja problema protokola TCP u beinim lokalnim mreama

U sutini postoje dva osnovna pristupa u rjeavanju problematike TCP-a u WLAN-u: Sakriti od poiljatelja sve gubitke koji nisu posljedica zaguenja. U tom sluaju nema promjena u implementaciji mrene infrastrukture, te pokuati ukazati poiljatelju da je prisutan beini link na putu do odredita i tako smanjiti gubitke u mrei. Jedno od rjeenja iz prve skupine prikazano je u nastavku rada, a to je protokol TCP-snoop. Usporedbom protokola TCP-snoop s ostalim rjeenjima, a misli se na rjeenja s kraja na kraj i rjeenja zasnovana na razdvajanju konekcije uoava se da jedino snoop ne naputa osnovnu funkcionalnost djelovanja protokola TCP. Na primjer za sluaj pristupa razdvajanjem konekcije ''kri'' se rad protokola TCP s potvrdnim segmentima. Takav pristup bitno utjee na period potreban za obnavljanje veze prilikom promjene pristupne toke. Za protokol TCPsnoop to vrijeme se kree od 5 do 70 ms dok je kod protokola I-TCP to vrijeme ak 1400 ms ovisno o koliini podataka koje je potrebno prenijeti na novu pristupnu toku. Prilikom prelaenja cilj je to vie skratiti vrijeme neaktivnosti TCP konekcije (engl. idle time).

2. Protokol TCP-snoop
Za svaki gubitak segmenta protokol TCP smatra da je posljedica zaguenja to u beinim mreama (WLAN) nije uvijek sluaj kao to je ranije opisano. Protokol TCP-snoop svoje djelovanje izvodi na razini linka i jedna od njegovih bitnih prednosti su minimalne promjene u pristupnoj toki. TCP-snoop spada u kategoriju koje podiu performanse mree koristei metodu proxy-ja - PEP (engl. Performance Enhancing Proxy). (Ho Ng et al [1997]). Djelovanjem ispod transportnog sloja izvodi se lokalna retransmisija (ili ponovno odailjanje) izgubljenih segmenata bez pokretanja TCP mehanizama za kontrolu zaguenja. Ostale metode koje se koriste za prilagodbu TCP-a beinom okruenju pripadaju u neku od sljedee tri grupe : Rjeenja s kraja na kraj (engl. End to End) ; rjeenja na razini linka (engl. Link Layer), te rjeenja zasnovana na razdvajanju konekcije (engl. Spliting Connection).

Ideja TCP-snoop-a je u tome da se sakriju od poiljatelja svi gubici nastali na sloju linka. Na taj nain TCP poiljatelj ne zna za pogreke na beinom linku pa tako nema i bespotrebnog pokretanja mehanizama za kontrolu zaguenja. Sve to dovodi do postizanja zadovoljavajue razine propusnosti za korisnika. U radu je detaljno opisan protokol snoop te izvedena simulacija istog u programskom jeziku Java. Bitno je naglasiti da je implementirana tzv. osnovna inaica protokola TCP-snoop (engl. Basic TCP-snoop). Implementacija protokola izvodi se uvoenjem modula snoop modula u pristupnu toku (engl. Access Point-AP). Naglasak je na promatranju infrastrukturnog WLAN-a u centraliziranom pristupu. To znai da se sva komunikacija izmeu ine i beine domene odvija preko pristupne toke, a izravna komunikacija izmeu pokretnih vorova (engl. wireless hosts) nije mogua. Slika (Sl. 2-1) prikazuje infrastrukturni WLAN s implementacijom snoop modula u pristupnoj toki.

Sl. 2-1 Mrena topologija

Snoop modul nadgleda sve segmente koji prolaze TCP konekcijom u oba smjera, te u spremniku ima pohranjene sve TCP segmente od strane poiljatelja koji jo nisu potvreni od strane primatelja. Ukoliko nastanu gubici tada snoop izvodi lokalnu retransmisiju izgubljenih segmenata a da to poiljatelj ne zna. Snoop modul radi na principu spremi i proslijedi (engl. store and forward) bez unoenja protokolnog preteka (engl. overhead) koji bi dodatno smanjio propusnost mree. Kratka analiza protokola TCP uzeta je u razmatranje zato jer se protokol snoop direktno ''naslanja'' na njega. Sama implementacija izvedena je negdje izmeu mrenog i transportnog sloja. Bez zadiranja u rad protokola TCP. Nove funkcionalnosti se dodaju u pristupnu toku (snoop modul) i to vezano uz mreni sloj pristupne toke te male promjene kod mobilnog klijenta. Prednosti ovakvog pristupa posebno dolaze do izraaja u sluaju prelaenja mobilnog korisnika (engl. handoff), tj. prelaska u susjednu eliju ili drugim rijeima promjena pristupne toke. Tada nastaju veliki gubici, poveanje kanjenja i smanjenje propusnosti. Taj problem se rjeava grupiranjem trenutne pristupne toke korisnika i susjednih AP-a u multicast skupinu. U svakoj od stanica multicast skupine pokree se snoop agent tako da nova pristupna toka u trenutku prebacivanja ve ima kopije izgubljenih segmenata. Problem se javlja u sluaju kada nova pristupna toka nije lan multicast skupine pa je dio segmenata izgubljen za vrijeme prelaenja. Jedina modifikacija protokolnog sloaja je u mijenjanju mrenog sloja u pristupnoj toki. Snoop ''motri'' sve segmente koji prolaze kroz pristupnu toku u oba smjera te radi potrebno pohranjivanje u spremnik. Kada novi segment stigne u pristupnu toku od strane inog vora snoop ga dodaje u spremnik te ga prosljeuje kroz beini kanal do pokretnog vora. Nadalje, snoop nadzire i sve potvrde, ACKs (engl. Acknowledgements) poslane od primatelja (Balakrishnan et al. [1995]). U sluaju gubitka segmenta u beinom kanalu to se otkriva istekom lokalnog brojaa (engl. local timeout) i dupliciranih potvrda (Sl. 2-2) radi se ponovno slanje izgubljenih segmenata. Na taj nain pristupna toka ''skriva'' gubitke segmenata od poiljatelja te nema pokretanja mehanizama za izbjegavanje zaguenja karakteristinih za protokol TCP. Tablica (Tablica 2) prikazuje poboljanja koja TCP-snoop donosi za problem handoff-a, (Balakrishnan et al. [1995]). Bitno je uoiti da se unato uestalim promjenama pristupne toke vrijednost propusnosti bitno ne mijenja, to ne bi bio sluaj za protokol TCP bez snoop modula.

10

Poiljatelj
1 2

Primatelj

Prvo slanje

3 4 5

ack1 Duplicirane potvrde i ponovno slanje

ack1 ack1 ack1

2 3 4 5

Sl. 2-2 Otkrivanje gubitka segmenta

Snoop odrava visoku razinu propusnosti koja nije sklona naglim propadima. Nadalje, poboljanje protokola TCP-snoop u sluaju male uestalosti pogreaka nije toliko izraeno. Drugim rijeima, uvoenje snoop modula svu svoju efikasnost pokazuje u uvjetima visoke uestalosti pogreaka bita - BER.
Tablica 2 Ovisnost propusnosti o vremenu prelaenja

Vrijeme potrebno za handoff [s] 1 3 8 10

Propusnost [Mbit/s]

1.42 1.43 1.44 1.43

Razlog promjena u mrenom sloju pristupne toke lei u injenici da je to jedino mjesto u WLAN-u gdje korisnik moe imati potpunu kontrolu u radu protokola za usmjeravanje paketa izmeu ine i beine mree. U samoj pristupnoj toki mehanizmi transportnog sloja se ne pokreu. Originalna zamisao rada snoop modula ukljuuje promjene i kod ostalih mrenih elemenata kao to su pokretni i stacionarni vor. To se radi za sluaj slanja podataka od strane pokretnog vora, opisano u radu (Balakrishnan et al. [1995]). Meutim, zbog nedostatka opisa istog u literaturi u ovom radu to nee biti razmatrano. Sam rad protokola TCP-snoop vezan je uz dvije metode: 11

snoopData(). Metoda vezana uz obradu podatkovnih segmenata namijenjenih pokretnom voru kao i za njihovo pohranjivanje u spremnik. snoopAck(). Metoda radi obradu potvrdnih segmenata (ACKs) koji putuju prema stacionarnom voru i upravlja ponovnim slanjem izgubljenih segmenata prema pokretnom voru kroz beini kanal.

2.1. Metoda SnoopData()

Pojednostavljeni pseudokod ove metode prikazan je u nastavku: ako (novi segment i u rastuem slijedu) { stavi segment u spremnik; proslijedi segment na odredite; } inae ako (segment nije u slijedu a u spremniku postoji isti) { ako (redni broj segmenta < rednog broja potvrde) { proslijedi segment na odredite; } inae { ponovno poalji segment; } } inae ako (segment nije u rastuem slijedu i u spremniku ne postoji isti) { proslijedi segment prema pokretnom voru; } Postoje tri sluaja: Segment je u rastuem slijedu (novi segment). Segment se dodaje u spremnik te prosljeuje u beini kanal. Opcionalno se dodaje vremenska oznaka (engl. timestamp) na neki od segmenata unutar prozora. Segment nije u slijedu, tj. isti postoji pohranjen u spremniku. Ovaj sluaj je rijedak a nastupa zbog isteka brojaa na strani poiljatelja ili u sluaju ubrzanog ponovnog slanja. Postoje dva podsluaja: o Redni broj segmenta < broja potvrde. Moe nastupiti zbog gubitka prethodne potvrde a rjeava se prosljeivanjem segmenta. 12

o Redni broj segmenta broja potvrde. Nastupa zbog gubitka segmenta izmeu pristupne toke i pokretnog vora. Segment se prosljeuje prema pokretnom voru a retransmisija je posljedica isteka vremenskog brojaa. Segment nije u slijedu i u spremniku ne postoji kao pohranjeni segment. U ovom sluaju segment je izgubljen u inom dijelu mree ili je isporuen u pogrenom redoslijedu. Segment se prosljeuje prema pokretnom voru i oznaava se kao ponovno poslani.

2.2. Metoda SnoopAck()

Po potrebi ova metoda odbacuje pozitivno potvrene segmente (ACK) i osvjeava potvrdu RTT-a. Pseudokod metode: ako (nova potvrda) { brii potvrene segmente iz spremnika; osvjei RTT; proslijedi potvrdu prema stacionarnom voru; } inae ako (spontana potvrda) { odbaci tu potvrdu; } inae ako (dvostruka potvrda) { ako (segment nije u spremniku, izgubljen u inom dijelu mree ) proslijedi potvrdu prema stacionarnom voru; inae ako (neoekivana duplicirana potvrda) ponovno poalji segment uz najvii prioritet; inae ako (oekivana duplicirana potvrda, AP zna da je segment izgubljen) odbaci potvrdu; } Kao i za prethodnu metodu i ovdje postoje tri sluaja: Nova potvrda ACK. Uobiajeni sluaj, briu se potvreni segmenti iz spremnika, osvjeava se procjena RTT-a i prosljeuje potvrda prema stacionarnom voru.

13

Spontani (engl. spurious) ACK. Kada neoekivano stigne ve viena potvrda od strane stacionarnog vora. Ovaj sluaj je vrlo rijetko nastupa. Odgovor na ovakvo stanje je da se takva potvrda odbacuje.

Dvostruki ACK segment (DUPACK). Sluaj kada pristigne potvrda identina onoj primljenoj prethodno. Opet postoji nekoliko podsluaja: o Kada segment nije u spremniku iz razloga to je izgubljen na putu izmeu stacionarnog vora i pristupne toke. Takva potvrda se jednostavno prosljeuje prema stacionarnom voru radi ouvanja stanja TCP-a. o Neoekivani DUPACK nakon to je segment izgubljen. Odgovor na ovo stanje je ponovno slanje segmenta u najvii prioritet. Za ovaj sluaj potrebna su dva reda za slanje, jedan za segmente vieg a drugi za segmente nieg prioriteta. Nadalje snoop vodi rauna i o maksimalnom broju dupliciranih potvrda za segment. o Oekivani DUPACK, koji stie nakon to pristupna toka sazna da je segment izgubljen. Takva potvrda se u pravilu odbacuje.

Slanje segmenata s viim prioritetom donosi poboljanju performansi mree u uvjetima visokih pogreaka bita. Na taj se nain omoguuje da ponovno poslani segmenti stignu do pokretnog vora u to kraem vremenu ime se smanjuje broj dupliciranih potvrda te tako poveava propusnost mree. Snoop vodi evidenciju o broju lokalnih retransmisija za svaki segment i resetira broja u sluaju da neki segment stigne ponovno od poiljatelja uslijed isteka brojaa na poiljateljovoj strani ili uslijed ubrzanog ponovnog slanja. Kao to je ranije reeno snoop radi i lokalnu retransmisiju za istek lokalnog brojaa. Za sluaj transfera podataka od pokretnog vora prema stacionarnom, uvode se negativne potvrde, (NACK) za traenje segmenata koji nedostaju. To se radi u sluaju isteka vremenske kontrole kod pristupne toke i kada je primljen odreeni broj segmenata. U ovom radu naglasak je na prouavanju rada protokola TCP za smjer prema pokretnom voru (engl. downlink) iz razloga to je za beine mree karakteristina asimetrija u prijemu podataka. Drugim rijeima prema klijentu se alje puno vea koliina podataka nego u odlaznom smjeru prema posluitelju. Podaci koji se alju prema posluitelju uglavnom su vezani uz zahtjeve odreenih resursa sa posluitelja koji sadre male koliine podataka.

14

2.3. Odnos protokol TCP-snoop - protokol usmjeravanja

Kao to je ranije opisano princip rada protokola TCP-snoop temelji se na pohranjivanju nepotvrenih segmenata da bi se poboljale performanse s kraja na kraj. U pravilu veliina spremnika s pohranjenim segmentima proporcionalna je veliini klizeeg prozora na strani primatelja. U nastavku je malo ire opisano ponaanje protokola TCP-snoop za sluaj prelaenja koje je i ranije dijelom opisano ali u puno manjem opsegu. Pri promjeni pristupne toke nova pristupna toka mora preuzeti sve nepotvrene segmente od stare pristupne toke kako bi se mogla izvriti lokalna retransmisija. Kada pristupna toka primi zahtjev za prelaenjem sadran u poruci beacon, pridruuje se multicast skupini na ranije opisani nain. Nova pristupna toka prima sve segmente namijenjene toj multicast skupini i snoop modul osvjeava informaciju o novim TCP konekcijama u pristupnoj toki. Na taj nain snoop modul gradi novi spremnik s informacijama o svim aktivnim TCP konekcijama. Kada nastupi prelaenje, pozitivno potvreni segmenti poinju prolaziti kroz novu pristupnu toku. Prvi primljeni potvrdni segment odreuje koji su segmenti primljeni na strani pokretnog vora do tog trenutka za tu TCP konekciju. Ova informacija slui za auriranje stanja snoop modula i ienje spremnika u pristupnoj toki. U stvarnosti, stanje prije i nakon navedene sinkronizacije nije nikada identino. Razlog tome lei u injenici da nova pristupna toka moe imati vlastiti spremnik s nekoliko segmenata koji su izgubljeni tijekom samog prelaenja. Upravo u ovom dijelu do izraaja dolazi sva snaga i robustnost protokola TCPsnoop. Naime, kako snoop odrava semantiku TCP konekcije s kraja na kraj i sakriva gubitke od poiljatelja ti se segmenti nee ponovno slati nego e se jednostavno ignorirati ili u sluaju veih gubitaka zatraiti od prijanje pristupne toke. U najgorem sluaju ovi segmenti e uzrokovati kratki i neznatni pad mrenih performansi koji se i ionako oekuje tijekom postupka prelaenja. Praktina mjerenja pokazala su da je potrebno svega nekoliko novoposlanih segmenata da bi snoop modul u novoj pristupnoj toki obnovio informaciju o novonastalom stanju. Upravo zbog ranije opisanog naina nema uobiajenog preuzimanja cjelokupnog stanja o TCP konekciji nego se radi nadziranje stanja stare pristupne toke od strane nove pristupne toke i tako se postupak prelaenja skrauje i rjeava puno efikasnije. Slika (Sl. 2-3) prikazuje klasian nain prelaenja.

15

Pristupna toka 1
segm1 beacon

Pokretni vor

Pristupna toka 2

g stron
segm2

acon er be

r buffe

est requ
forward re quest

segm3 segm4

handoff period
segm5

Sl. 2-3 Prikaz izmijenjenih poruka za vrijeme postupka prelaenja

2.4. Alternativna rjeenja na sloju linka

Radi same usporedbe ukratko je i opisano rjeenje pod nazivom AIRMAIL (engl. AsymmetrIc Reliable Mobile Access In Link-layer). Dvije osnovne metode koje AIRMAIL kombinira su ranije spomenuti ARQ i FEC (engl. Forward Error Correction). Bitno je naglasiti da AIRMAIL djeluje dobro ne samo u zatvorenim prostorima nego i u otvorenim (vanjskim) irokopojasnim beinim sustavima kao to je WiMAX, standard IEEE 802.16a ili drugim rijeima WMAN. Asimetrija proizlazi iz injenice da pokretni vorovi imaju puno manju snagu i slabiju mogunost obrade podataka nego to to imaju bazne stanice (engl. Base Stations) te da odluku o slanju i primanju paketa donosi bazna stanica. Iz tog razloga tenja je u ''postavljanju'' to vie inteligencije u samu baznu stanicu te da se u pokretnim vorovima procesiranja svedu na minimum. Naglasak je u optimalnom iskoritenju prijenosnog pojasa (engl. bandwith) od strane bazne stanice bez pokretanja nepotrebnih retransmisija te ouvanju napajanja pokretnog vora pomou statusnih poruka izmijenjenih s baznom stanicom. FEC kao tehnika ispravljanja greaka kombinira se na razini bita, okteta i paketa. Kombinacija navedenih triju razina provodi se kao ''kodiranje kanala'' (engl. channel coding) i to pomou adaptivnog algoritma temeljenog na automatu s konanim brojem stanja opisanim u (Ayanoglu et al. [1994]). Slika (Sl. 2-4) prikazuje tipino ustrojstvo beine mree zasnovane na elijskom principu i pokrivanju radio signalom kao to je IEEE 802.16. U nastavku je ukratko opisano djelovanje protokola AIRMAIL i to za sve smjerove komunikacije.

16

2.4.1.

Smjer predajnik pokretnog vora prijemnik bazne stanice

Kontrola toka i slijed zahtijeva provodi se kroz nekoliko koraka: Pokretni vor alje podatke sve dok se ne dosegne maksimalna veliina spremnika za slanje (engl. maximum transmit buffer size) koja se rauna na osnovu mjerenja RTT-a, zahtijeva za ponovnim slanjem te dali ima jo podataka za slanje. Paketi koji ekaju na ponovno slanje imaju vii prioritet od ostalih. Kada pokretni vor vie nema paketa za slanje on postavlja tzv. e-bit u zaglavlje zadnje poslanog paketa. Bazna stanica alje poruke o svome stanju (engl. status messages) periodiki kroz beini kanal. Te poruke ne nose informaciju o veliini spremnika za slanje kao to je to sluaj u nekim drugim protokolima. Pomou vremenskog brojaa stanja (engl. status timer) koji se pokree prilikom slanja poruke stanja odreuje se gubitak paketa u beinom kanalu. Vremenski broja nalazi se samo na strani bazne stanice. U sluaju da primljeni paket sadri e-bit broja se ne pokree nego bazna stanica odmah alje poruku o stanju. Pokretni vor ponovno alje pakete koji ekaju na retransmisiju prije slanja ostalih paketa. Za ovaj korak bitno je rei da da je veliina spremnika za slanje kod pokretnog vora vea nego veliina ''prozora'' kod bazne stanice i tako se rjeavaju problemi vezani uz gubitak statusnih poruka prema pokretnom voru. Ova injenica bitno utjee na propusnost koja je ovom sluaju definirana kao broj paketa koji se prenesu za vrijeme trajanja RTT-a. Ovaj korak je najsloeniji te opis pojedinih detalja nije naveden iz razloga prelaska granica tematike samog rada.

2.4.2.

Smjer predajnik bazne stanice prijemnik pokretnog vora

Bazna stanica alje nove pakete u sluaju da je veliina prozora razliita od nule, sve dok dolaze zahtjevi za ponovnim slanjem te sve dok ne ponestane paketa za slanje. Kao i za sluaj slanja pokretnog vora ukoliko nema vie paketa za slanje alje se e-bit na nain opisan ranije. Vremenski broja se pokree nakon slanja cijelog bloka paketa ili nakon slanja paketa s e-bitom. Uz to alje se i eksplicitni zahtjev za statusom (engl. Explicit status request message) ukoliko bazna stanica ne primi poruku od pokretnog vora prije isteka vremenskog brojaa. Pod pojmom bloka smatra se fiksni broja paketa odreen samim algoritmom AIRMAIL-a.

17

Sl. 2-4 elijska organizacija mrene infrastrukture

Pokretni vor alje poruku o statusu nakon to primi cijeli blok paketa. Na primjer biti pokazuje dali je paketi unutar bloka ispravno primljen. Biti = 1 znai da je paket i primljen a biti = 0 znai da nije primljen. Radi utede predajne snage pokretni vor ne alje poruke o statusu periodiki kako to radi bazna stanica, isto tako ih ne alje ni nakon prijema svakog paketa. Poruke o statusu alje samo nakon prijema cijelog bloka paketa ili nakon prijema e-bita.

Sluaj kada bazna stanica ponovno alje traene pakete. Bitna injenica je da se alju samo izgubljeni paketi unutar bloka a ne cijeli blok i tako se tedi na irini prijenosnog pojasa. Nadalje, bazna stanica takoer i pokree vremenski broja radi otkrivanja dali je pokretni vor poslao poruku o statusu koja potvruje prijenos bloka paketa u nekom vremenu intervalu odreenim brojaem. Ukoliko poruka o statusu ne stigne prije isteka brojaa, bazna stanica alje alje eksplicitni zahtjev za statusom. Ukoliko ni nakon nekoliko slanja eksplicitnih poruka o statusu odgovor ne stigne bazna stanica raskida konekciju ili postavlja vezu u stanje hibernacije

Pouzdanost protokola temelji se na utedi resursa i principu ponovnog slanja izgubljenih paketa. Odluka o prisutnosti pogreaka unutar paketa temelji se na dobro poznatom mehanizmu CRC (engl. Cyclic Redudancy Check). Optimizacijom koda koji se dodaje na pakete moe se smanjiti broj retransmisija te ispraviti pogreke. Za stvarnovremenske aplikacije kao to su audio i video mehanizam retransmisije nije dobar jer unosi prevelika kanjenja. U tom sluaju rabi se FEC koji osigurava dobar QoS. Dobrim podeavanjem 18

parametara FEC-a iskoristivost kanala raste kao to se i smanjuje kanjenje tijekom promjene bazne stanice. AIRMAIL je kao i snoop jo jedna od inaica protokola za poboljanje TCP-a u beinom okruenju. Svoje djelovanje temelji na retransmisijama i utedi prijenosnog pojasa na razini sloja linka, bez zadiranja u transportni sloj. Meutim za promatranu problematiku vezanu uz TCP u WLAN-u snoop daje puno bolje rezultate, osobito za propusnost, nego AIRMAIL. Meutim za sluaj WMAN-ova AIRMAIL je jedno od najboljih rjeenja. Prednost rjeenja s retransmisijom na sloju linka su u tome da je rjeenje nevidljivo od sloja IP na vie, te da protokol TCP zadrava svoj znaaj s kraja na kraj. Neki od nedostataka koji se pojavljuju su: problemi ukoliko TCP i protokol sloja linka rade retransmisiju istovremeno, pojava promijene redoslijeda segmenata, uslijed velikih kanjenja i kolebanja kanjenja (engl. jitter), problemi vezani uz due periode prekida konekcije te problemi tzv. uskog grla pristupne toke (engl. bottleneck) ili drugim rijeima problem viestrukih TCP konekcija izmeu dvaju domena (Jang et al. [2003]). Jo je bitno naglasiti da protokol sloja linka koristi ''poznavanje'' rada protokola TCP kako bi se gubici sakrili od poiljatelja. Treba naglasiti da je ovdje vie naglasak na odravanju iznosa propusnosti konstantnim s obzirom na karakteristiku beinog kanala.

19

3. Rezultati simulacije i opis programa

Za potrebe diplomskog rada razvijen je simulator protokola TCP-snoop ''TCP Snoop Simulator''. Simulator je izveden u programskom jeziku Java radi objektne orijentiranosti samog jezika i mogunosti realizacije pojedinih komponenata mrene topologije. Cilj diplomskog zadatke bio je pokazati poboljanja koje unosi integracija snoop modula u pristupnu toku u WLAN-u na neke od osnovnih komponenti protokola TCP kao to su veliina prozora zaguenja, broj poslanih segmenata u jedinici vremena, propusnost, itd. Komponente mrene topologije sa slike (Sl. 2-1) implementirane su kao klase u simulatoru.

3.1. Model rjeenja simulatora

Slika (Sl. 3-1) daje prikaz grafikog suelja prema korisniku GUI (engl. Graphical User Interface).

Sl. 3-1 Korisniko grafiko suelje

20

Kao to je vidljivo sa slike (Sl. 3-1) grafiko suelje sastoji se od nekoliko dijelova: Simulation Log. U ovom prozoru se pri poetku i zavretku simulacije ispisuje datoteka log.txt koja opisuje tijek simulacije i bitne dogaaje vezane uz simulaciju (npr. da li je uspostavljena konekcija izmeu komunicirajuih entiteta, broj poslanih i izgubljenih segmenata i sl.). Result options. Prikaz rezultat je dan kao funkcija vremena. Postoji mogunost biranja prikaza veliine prozora zaguenja, rednih brojeva segmenata te propusnosti sve u ovisnosti o trenutku simulacije. Nadalje, u ovom dijelu je dio vezan za aktivaciju snoop modula u pristupnoj toki kao poboljanja u radu protokola TCP u beinom okruenju. Naposlijetku, postoji mogunost provedbe paralelne simulacije za razne algoritme i mogunost usporedbe rezultata na istom grafu. Ovdje je bitno za rei da se svi rezultati ispisuju u tekstualnu datoteku u stupastom obliku upravo radi lake obrade rezultata. Za prikaz rezultata moe se uzeti bilo koji alat za iscrtavanje grafova kao to je Microsoft Excel ili besplatni program Gnuplot te je taj dio ostavljen korisniku na izbor. Channel options. Dio predvien za podeavanje karakteristika beinog kanala kao to je model kanala, vrijeme propagacije kroz beini kanal, vjerojatnost gubitaka segmenata. Server options. Najbitniji dio simulatora u kojem se unose parametri kljuni za simulaciju, odnosno rad protokola TCP. Implementirana su 2 mehanizma protokola TCP, i to Tahoe i Reno. Rad simulatora predstavljen je kroz vremenske cikluse. U jednom vremenskom ciklusu klijent i pristupna toka mogu primiti, obraditi te poslati samo jedan TCP segment. Svi TCP segmenti koji se izmjenjuju izmeu entiteta postavljeni su na korisniki zadanu vrijednost MSS i kao takvi se alju.

3.2. Parametri simulacije i komponente simulatora

Za izvoenje simulacije koritene su sljedee vrijednosti TCP parametara: MSS je postavljen na 40 okteta; sstresh ima vrijednost 65536 okteta; vrijeme propagacije segmenata beinim kanalom iznosi 100 ms; veliina datoteke koja se prenosi je 1600 okteta; vrijeme propagacije segmenata po inom linku postavljeno je na 10 ms i pretpostavka je da gubici segmenata na inom linku nisu mogui (engl. error free link).

21

Unutar simulatora sam ini link nije implementiran kao klasa nego se simulira na nain da se slanje svakog segmenta odgaa za period vremena od 10 ms. Tako se opisuje propagacija inim linkom na putu do pristupne toke. to se beinog kanala tie, u simulatoru postoji mogunost biranja razdiobe gubitaka izmeu tzv. Fritchmanovog modela kanala i uniformne razdiobe gubitaka segmenata u beinom kanalu, (Kralj [2003]). Sve simulacije izvedene u radu odnose se na Fritchmanov model kanala koji je ukratko opisan u nastavku rada i predstavlja poopeni Gilbertov model beinog kanala s gubicima. Sluaj s uniformnom razdiobom ne preporuuje se za simulacije s aktivnim snoop modulom jer daje izrazito loe rezultate i implementiran je u simulatoru samo radi usporedbe. Maksimalna veliina prozora zaguenja i kod poiljatelja i kod primatelja iznosi 65536 okteta. Takoer, definira se i maksimalni broj retransmisija, nakon kojega se konekcija izmeu entiteta raskida i ispisuje poruka o isteku vremenske kontrole. Simulator se sastoji od nekoliko komponenti a to su: Klijent pokretni vor. Rad klijenta zasniva se na dobro poznatim mehanizmima rada protokola TCP. Za svaki primljeni segment od strane poiljatelja alje potvrdni segment s rednim brojem segmenta kojeg sljedeeg oekuje. Prilikom ponovnog slanja segmenta ne rauna se RTT (koristi se pojednostavljeni mehanizam retransmisije) i to samo za segmente koji iniciraju (SYN) odnosno raskidaju konekciju (FIN), (Kralj [2003]). Beini kanal s gubicima. Implementiran kao zasebna klasa u Javi te povezuje klijenta s posluiteljem, odnosno s pristupnom tokom. Model kanala i nain funkcioniranja opisan je u nastavku rada. Pristupna toka. Bitna komponenta simulatora jer obavlja funkciju mosta (engl. bridge) izmeu dvaju domena. Za vrijeme uspostave konekcije izmeu klijenta i posluitelja pristupna toka je transparentna ili drugim rijeima svoju funkciju poinje obavljati tek kod slanja podatkovnih segmenata i aktivnog snoop modula. Svi segmenti poslani od posluitelja kao i potvrdni segmenti, poslani od klijenta, prolaze kroz tu komponentu. Nadalje, upravo je u pristupnoj toki implementiran snoop modul koji pohranjuje potvrde i segmente lokalno u spremnik. Takoer, u sluaju aktivnog snoop modula rauna se vrijednost lokalnog vremenskog brojaa za sluaj lokalne retransmisije. U originalnom modelu protokola TCP-snoop uvode se prioriteti za pakete koji ekaju na ponovno slanje u spremniku pristupne toke. Navedeni prioriteti za ponovno slanje paketa nisu razmatrani u ovom radu.

22

Posluitelj stacionarni vor. Ima ulogu poiljatelja i svi mehanizmi bitni za rad protokola TCP, kao to su algoritmi kontrole zaguenja, dinamiko raunanje vremenskog brojaa implementirani su upravo u ovoj komponenti.

TCP segment. Pojednostavljeni model TCP segmenta bez dodatnih zaglavlja, preuzet iz rada (Kralj [2003]). Slika (Sl. 3-2) prikazuje strukturu TCP segmenta koritenog u simulaciji. Polje Duljina segmenta odnosi se na podatkovni dio TCP segmenta i to u oktetima. Prilikom prijema segmenta, dotini se odmah obrauje bez pohranjivanja u spremnik, osim u sluaju aktivnog snoop modula.

Engine simulatora. Jedina klasa s main metodom. Kreira grafiko suelje prema korisniku, odreuje razmjetaj komponenti unutar grafikog suelja, omoguuje unos korisnikih parametara za pojedine metode unutar simulatora te ispis bitnih dogaaja vezanih uz simulaciju. Navedeno ne znai da se kompletan tijek simulacije ispisuje unutar grafikog suelja, za to slui konzola (engl. console) unutar samog Java razvojnog okruenja.

Sl. 3-2 TCP segment implementiran u simulatoru

3.2.1.

Fritchmanov model beinog kanala s gubicima

Navedeni model opisuje se kao Markovljev lanac prvog reda s dva stanja, (Pan et al. [2000]). Svako od dva stanja odgovara stanju beinog kanala na putu izmeu poiljatelja i primatelja, odnosno izmeu pristupne toke i beinog klijenta. Markovljev lanac ima stanja ON i OFF. Dok je beini kanal u stanju ON svi segmenti se ispravno prenose do beinog klijenta, a u sluaju stanju OFF svi poslani segmenti su izgubljeni u kanalu. Gubici koji nastaju u beinom kanalu su usnopljeni, to znai da se na segmente gleda kao na uzastopni niz koji tvori jedinstveni tok podataka. Za Fritchmanov model bitno je rei da su gubici u dolaznom i odlaznom smjeru (engl. uplink) u potpunosti neovisni te da je prijelaz iz jednog stanja u drugo mogu samo na razini cijelog segmenta odnosno na kraju vremenskog odsjeka. Ovaj podatak vezan je uz polje unutar simulatora ''Average Loss Length'' koje predstavlja duljinu snopa gubitaka kao broj vremenskih odsjeaka. 23

Prosjena vremena zadravanja u stanjima opisana su varijablama Ton i Toff te se ravnaju po geometrijskoj razdiobi. Za sluaj da je u sluajni broj izmeu 0 i 1 i da je z vjerojatnost naputanja stanja, duljina zadravanja x u jednom od stanja rauna se kao: u = (1 z ) x log(u ) = log(1 z ) x
log(u ) = x log(1 z )

x=

log(u ) log(1 z )

Prilikom pokretanja simulacije korisnik unosi vrijednost Toff i vjerojatnost pogreke Pb. Varijabla Pb drugim rijeima predstavlja stacionarnu vjerojatnost boravka beinog kanala u stanju OFF. Vrijednost varijable Pb rauna se na nain:
Pb = Toff Ton + Toff

Poto je vjerojatnost Pb poznata iz navedenog izraza, lako je izraunati stacionarnu vjerojatnost boravka u stanju ON, pomou izraza:
Pg = 1 Pb

Bitno je jo naglasiti da su uvjetima u kanalu izloeni ne samo segmenti nego i potvrde koje klijent alje posluitelju. Uvjeti simulacije za sluaj kada je snoop modul aktivan u pristupnoj toki i kada nije su isti upravo da bi se uoila poboljanja koja unosi snoop modul na rad protokola TCP u beinom okruenju. Ovdje je potrebno napomenuti da je problem odreivanja modela koji bi dobro opisivao beini kanal poseban problem i opisan je s raznim matematikim modelima.

3.3. Rezultati simulacije

Za potrebe prikaza rezultata simulacije pokrenuto je nekoliko simulacijskih postupaka, te su u radu prikazani ponajbolji dobiveni rezultati. Slika (Sl. 3-3) pregledno predoava poboljanja koje unosi aktivnost snoop modula u pristupnoj toki na veliinu prozora zaguenja. Jasno se vidi poboljanje vezano uz broj segmenata koje poiljatelj moe poslati u mreu, a da ne mora ekati prijem potvrdnog segmenta od strane primatelja. Poboljanje je znatno jer u trenutku oko 1500 milisekunde poiljatelj moe u sluaju aktivnog snoop modula poslati ak 70-ak 24

TCP segmenata, dok je u suprotnom sluaju taj broj neto vei od 40 TCP segmenata. Obzirom da veliina prozora zaguenja predstavlja na neki nain trenutnu mjeru kapaciteta mree, navedeno poboljanje dobiva jo vie na svome znaaju. Kao to je vidljivo sa slike (Sl. 3-3) nakon isteka vremenske kontrole zapoinje period sporog starta sve do perioda izbjegavanja zaguenja. Trajanje vremena isteka vremenskog brojaa isto je za sluaj bez aktivnog snoop modula i s aktivnim snoop modulom. Moe se uoiti da protokol TCP-snoop ''poznaje'' i ''slijedi'' mehanizme rada protokola TCP uz znatan porast ukupnih performansi sustava. Jo treba dodati da su sve simulacije i prikazani rezultati napravljeni za referentni protokol Tahoe TCP zato to od svih inaica protokola TCP u WLAN-u pokazuje najloije rezultate.
3500 3000 CW ND [oktet] 2500 2000 1500 1000 500 0 0 500 1000 1500 2000 2500 3000 3500

Vrijeme [ms] Regular TCP TCP Snoop

Sl. 3-3 Tahoe TCP veliina prozora zaguenja

Iz svega navedenog moe se zakljuiti da protokol TCP-snoop sprjeava istek vremenskog brojaa na strani poiljatelja i odrava poveanu vrijednost veliine prozora zaguenja u svakom vremenskom trenutku simulacije. Upravo su ova dva imbenika kljuna za odravanje konstantne vrijednosti propusnosti, to osobito dolazi do izraaja za vrijeme prelaenja izmeu susjednih pristupnih toaka. U ovom radu propusnost je uzeta kao predmet razmatranja vezana uz rad protokola TCP bez aktivnog snoop modula i to za protokole TCP Tahoe i Reno radi usporedbe. Razlog za to je to problem prelaenja nije uzet u detaljnije razmatranje, tj. nije predmet razmatranja diplomskog rada. Obzirom da protokol TCP-snoop najbolje funkcionira u uvjetima uestalih pogreaka, poeljno je kod simulacije poveati vjerojatnost boravka beinog kanala u OFF stanju. U simulaciji se ne razmatra BER, ali treba rei da je utjecaj snoop modula u sluaju malih iznosa 25

BER-a na performanse WLAN-a gotovo neznatan, ak i degradirajui, (Balakrishnan et al. [1995]). Za primijetiti (Sl. 3-3) je da je poboljanje vezano za veliinu prozora zaguenja u simulaciji trenutno. U stvarnosti to nije sluaj zato to protokol TCP-snoop ima svojstvo spore konvergencije na poboljanje performansi unutar WLAN-a, te se smatra jednim od nedostataka protokola. Analizom simulacije utvreno je da je da u sluaju gubitaka veeg broja potvrda posluitelj i dalje nastavlja sa slanjem podatkovnih segmenata. Meutim, sluaj gubitka samo jednog podatkovnog segmenta uslijed trenutnog stanja beinog kanala za posljedicu ima niz retransmisija. Slika (Sl. 3-4) prikazuje ovisnost rednog broja segmenta (engl. sequence number) o vremenu simulacije opet za dva sluaja, bez aktivnog snoop modula i s aktivnim snoop modulom u pristupnoj toki. Uoava se nagli porast rednih brojeva poslanih TCP segmenata oko trenutka t = 305 ms za sluaj aktivnog snoop modula to znai da poiljatelj ''ne zna'' za gubitke u beinom kanalu i ne radi retransmisiju segmenata. Redni broj segmenta rauna se na nain da je svaki sljedei redni broj jednak zbroju maksimalne veliine segmenta i prethodnog rednog broja TCP segmenta. Inicijalni redni broj prvog TCP segmenta koji se alje postavljen je na 1 radi boljeg prikaza pri iscrtavanju rezultata. U sluaju kada snoop modul nije aktivan neki od segmenta s istim rednim brojem alju se vie puta, to znai da se pokreu mehanizmi kontrole zaguenja koji izrazito degradiraju performanse WLAN-a. U radu (Vangala [2002]) navedeni su podaci za ostale inaice protokola TCP, tako Tahoe, Reno, New Reno pokazuju osjetno poboljanje u broju poslanih segmenata u sluaju aktivnog snoop modula dok najvee poboljanja pokazuje TCP Vegas.
2000 1800 1600 1400 1200 1000 800 600 400 200 0 0 1000 2000 3000 4000 5000 6000 7000 8000 Vrijeme [ms] Regular TCP Snoop TCP

Redni broj segmenta [oktet]

Sl. 3-4 Tahoe TCP ovisnost rednog broja segmenta o vremenu simulacije

26

Zanimljivo je da protokol TCP SACK koji pokazuje najbolje rezultate bez prisutnosti snoop modula, za sluaj njegove prisutnosti postaje najloije rjeenje za implementaciju u WLAN-u. Slika (Sl. 3-5) predoava vrijednost veliine prozora zaguenja za sluaj kada se maksimalna vrijednost lokalnog brojaa u pristupnoj toki smanji. Uoava se manji broj TCP segmenata koje poiljatelj moe poslati u mreu, (Sl. 3-5). Nain na koji se rauna vrijednost lokalnog brojaa je dobro poznati Karnov algoritam, (Stevens [1995]). Princip odreivanja vrijednosti brojaa opisan je slikom (Sl. 3-6). Isti se princip primjenjuje na posluitelju kao i na poiljatelju i u pristupnoj toki. Ovaj pristup daje dobre rezutate i u uvjetima uestalih pogreki to je karakteristino za beini kanal. Ukratko, kada stigne potvrda za prvi sljedei segment koji nije ponovno poslan iznos vremenskog brojaa rauna se na nain opisan slikom (Sl. 3-6).
3000 2500 CWND [oktet] 2000 1500 1000 500 0 0 500 1000 1500 2000 2500 3000 3500 Vrijeme [ms] Regular TCP TCP Snoop

Sl. 3-5 Tahoe TCP veliina prozora zaguenja

Kao to je ranije navedeno pristupna toka je transparentna za sve TCP segmente sve do trenutka aktiviranja snoop modula. Razlog tome lei u pretpostavci da u inom dijelu mree, tj. na putu izmeu posluitelja i pristupne toke gubici nisu mogui. Takoer, pretpostavka je da pristupna toka ne unosi dodatno kanjenje ako snoop modul nije aktivan. ''Problem'' koji unosi snoop na rezultate simulacije je poveanje kanjenja s kraja na kraj (engl. end-to-end) uslijed spremanja segmenata u spremnik pristupne toke te uslijed pretraivanja i usporedbe segmenta koji se obrauje sa segmentima unutar spremnika. Bitno je naglasiti problem prorauna vrijednosti lokalnog brojaa na strani pristupne toke, koji se esto postavlja na fiksnu vrijednost, tako da su mogua i daljnja poboljanja. U simulatoru je pokuana realizacija s ugraenom Java funkcijom random() koja bi raunala vrijednost 27

vremenskog brojaa u odnosu na neku maksimalnu vrijednost, meutim opisani postupak nije se pokazao kao najbolji jer ne uzima u obzir vrijednost vremena propagacije TCP segmenta kroz beini kanal, ne sprjeava istek vremenskog brojaa na posluitelju i ponekad daje izrazito lou razdiobu vrijednosti lokalnog brojaa.

Sl. 3-6 Eksponencijalni backoff algoritam za proraun vremenskog brojaa

Na slikama (Sl. 3-7, Sl. 3-8) dan je prikaz rezultata za jedan te isti simulacijski postupak, tj analizirani su propusnost i veliinu prozora zaguenja za sluaj kada snoop modul nije aktivan. Svi parametri simulacije ostaju isti za sve simulacijske postupke. Vrijednosti iznosa propusnosti su apsolutne to znai da nemaju praktinu vrijednost nego samo slue za prikaz rezultata. Na grafu propusnosti uoava se da u pojedinim trenucima vrijednost propusnosti pada na vrijednost nula.
6 Propusnost [segment/ms] 5 4 3 2 1 0 0 2000 4000 6000 8000 10000 Vrijeme [ms]

Sl. 3-7 Tahoe TCP graf propusnosti na klijentskoj strani

Uzrok stanja propada iznosa propusnosti na vrijednost nula je u injenici da za vrijeme dok se eka na istek vremenskog brojaa podatkovni segmenti ne alju ili je beini kanal u stanju OFF. To za klijenta u simulaciji znai da ne prima nikakve segmente jer su svi poslani 28

segmenti izgubljeni u beinom kanalu na putu do odredita, npr trenuci simulacije od t = 790 ms do t = 2209 ms (Sl. 3-7). Nastavak slanja novih segmenata uvjetovan je stanjem u mrei i na opisani nain provodi se kontrola toka. Naime kako je ranije opisano i potvrdni segmenti izloeni su gubicima u beinom kanalu, tada su svi segmenti koji se alju izgubljeni i ovaj sluaj u stvarnoj mrei nastupa samo kod izrazito izraenog fadinga odnosno iznenadnih i snanih propada radio signala.
300 250 CWND [oktet] 200 150 100 50 0 0 2000 4000 6000 8000 10000 Vrijeme [ms]

Sl. 3-8 Tahoe TCP veliina prozora zaguenja

Slika (Sl. 3-9) prikazuje iznos propusnosti o vremenu uz napomenu da se razmatra protokol TCP Reno i to samo radi usporedbe. Uoava se neto bolja karakteristika grafa propusnosti nego za sluaj Tahoe TCP. To se deava zbog novog algoritma koji uvodi TCP Reno, a to je algoritam ubrzanog oporavka (engl. fast recovery). Pomou navedenog algoritma izbjegava se period sporog starta nakon primitka 3 ponovljene potvrde koje bi ukazivale de je segment na kojeg pokazuje potvrda izgubljen. Umjesto sporog starta nastavlja se linearno izbjegavanje zaguenja. Tako se efikasnije koriste mreni resursi jer se ne troi vrijeme na ekanje isteka vremenske kontrole, a vrijednost veliine prozora zaguenja ne smanjuje se na 1 segment nego na polovicu ime je omoguen brzi oporavak veze nakon gubitaka pojedinanih segmenata, (Stevens [1995]). Na kraju rada valja spomenuti jo jednu manjkavost protokola TCP-snoop, a to je sluaj kada je na pristupnu toku vezan vei broj beinih klijenata. Osobito je to izraeno za sluaj istovremenog slanja vee koliine podataka posluitelju (engl. upload) kada je snoop modul aktivan.

29

8 Propusnost [segment/m s] 7 6 5 4 3 2 1 0 0 1000 2000 3000 Vrije me [ms] 4000 5000 6000

Sl. 3-9 Reno TCP - graf propusnosti na klijentskoj strani

Tada se zauzima vie prijenosnog pojasa (engl. bandwith) u beinom kanalu zbog retransmisija segmenata i zauzee medija od pojedinog klijenta se produuje, (Ho Ng et al. [1997]). Meutim, ovakav sluaj rijetko nastupa, a postoje i posebni programski alati i protokoli koji omoguuju i ispravljaju navedeni nedostatak protokola TCP-snoop.

30

Zakljuak
Protokol TCP kao temeljni transportni protokol neizbjean je u svijetu modernih komunikacijskih tehnologija. Beine mree danas zauzimaju sve vei postotak kao najprihvatljivije i najisplativije rjeenje vezano uz prijenos informacije. Osobito to dolazi do izraaja u uvjetima kada instalacija ine infrastrukture nije mogua ili neisplativa. Svakim danom javljaju se novi IEEE 802.11x standardi vezani uz WLAN-ove koji sa sobom donose i nove usluge za korisnika. Dananji WLAN-ovi uglavnom se ostvaruju kao beine mree s radioprijenosom i koriste tehniku proirenog spektra DSSS (engl. Direct Sequence Spread Spectrum) na fizikom sloju. Naravno, za pouzdani prijenos podataka koristi se protokol TCP, ali u raznim inaicama opisanim u radu. Najbitnija prednost protokola TCP je u prilagodljivosti koju posjeduje za razliite prijenosne sustave. Meutim neki njegovi temeljni principi nisu prilagoeni za rad u beinom okruenju. Razlog tome su veliki gubici koji nastaju u beinom kanalu. Upravo zato uvode se poboljanja namijenjena iskljuivo radu protokola TCP u WLAN-u. U radu je detaljno opisana jedna od takvih inaica protokola TCP, a to je TCP-snoop. Analiza samog protokola TCP-snoop napravljena je koristei vlastiti simulator razvijen u programskom jeziku Java. Upravo je taj protokol u raznim radovima naveden kao najprihvatljivije rjeenje za WLAN-ove, (Vangala et al. [2002]). Kada se kae najprihvatljivije, onda se misli na performanse i isplativost rjeenja. Protokol Tahoe TCP bio je predmet promatranja u radu sa i bez snoop modula u pristupnoj toki. Isti na gubitke reagira smanjenjem veliine prozora i manjim brojem segmenata koje poiljatelj moe poslati u jedinici vremena. S obzirom da protokol TCP-snoop djeluje ispod transportnog sloja on ne pokree algoritme kontrole zaguenja. Isto tako protokol TCP-snoop pripada skupini protokola koji dobro ''poznaju'' mehanizme rada protokola TCP. Osnovna zamisao rada protokola TCP-snoop je pohranjivanje segmenata namijenjenih pokretnom voru i obavljanje lokalne retransmisije segmenata izgubljenih u beinom kanalu. Simulacije izvedene u radu pokazale su neka od poboljanja koja protokol TCP-snoop unosi u poboljanje rada protokola TCP u beinoj okolini. Prvenstveno se ta poboljanja odnose na injenicu da nema smanjenja veliine prozora zaguenja na strani poiljatelja u sluaju gubitka segmenata i na to da se od poiljatelja ''sakriju'' gubici nastali u beinom kanalu.

31

Literatura
[1] BALAKRISHNAN, H. SESHAN, S. KATZ , H. R. 1995. Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks. ACM Wireless Communications Magazine, Vol. 1, Number 4. STEVENS, W.R. 1995. TCP/IP Illustrated: The protocols, Volume 1.Adisson Wesley Longman Inc. VANGALA, S. LABRADOR, A. M. 2002. Performance of TCP over Wireless Networks with the Snoop Protocol. In Proceedings of IEEE LCN, Tampa Florida, pp. 600 601, November 2002. HO NG, C. CHOW, J. TRAJKOVI, LJ. 2002. Performance Evaluation of TCP over WLAN 802.11 with the Snoop Performance Enhancing Proxy. OPNETWORK Conference 2002, Washington, DC, August 2002. XYLOMENOS, G. POLYZOS, G. SAARANEEN, M. 2001. TCP Performance Issues over Wireless Links.IEEE Communications Magazine, Volume 39, pp. 52 - 58. ELAARAG, H. 2002. Improving TCP Performance over Mobile Networks. ACM Computing Surveys, Vol. 34, pp. 357 374, November 2002. SCHILLER, J. 2003. Mobile Communications 2nd edition.Adisson Wesley Inc. JANG, H. SUH, Y. 2003. A Flow Control Scheme for Improving TCP Throughput and Fairness for Wireless Networks. Proceedings of IEEE Wireless Communications and Networking Conference (WCNC 2003), March 2003. PAN, J. MARK, W. J. and SHEN, X. 2000. TCP Performance and Its Improvement Over Wireless Links. GLOBECOM 2000 IEEE Telecomunnications Conference no.1, San Francisco, pp. 62 66, November 27 30, 2000.

[2] [3]

[4]

[5] [6] [7] [8]

[9]

[10] BAANT, A. i dr. 2003. Osnovne arhitekture mrea. Element, Zagreb. [11] KRALJ, Z. 2003. Tehnike upravljanja zaguenjem u beinim lokalnim mreama. Diplomski rad, ZZT FER, Zagreb.

32

Skraenice
ARQ ATM BER BER CRC DSSS FDDI FEC GBN GUI IP ISDN I-TCP MSS MTU OSI PEP PSTN QoS RFC RLP RTO RTT TCP WAP Automatic Repeat reQuest Asynchronous Transfer Mode Bit Error Ratio Bit Error Ratio Cyclic Redudancy Check Direct Sequence Spread Spectrum Fiber Distributed Data Interface Forward Error Corection Go-Back-N Graphical User Interface Internet Protocol Integrated Services Digital Network Indirect TCP Maximum Segment Size Maximum Transfer Unit Open System Interconnection Performance Enhancing Proxy Public Switched Telephone Network Quality of Service Request for Comments Radio Link Protocol Retransmission TimeOut Round Trip Time Transmission Control Protocol Wireless Application Protocol

B-ISDN Broadband ISDN

EBSN Explicit Bad State Notification

HIPPI High Performance Parallel Interface

MTCP Mobile Host TCP

SACK Selective Acknowledgement

WLAN Wireless Local Area Network WMAN Wireless Metropolitan Area Network 33

Popis stranih izraza

ad hoc bandwith beacon bottleneck burst congestion avoidance congestion window downlink end to end engine fast recovery fast retransmission handoff idle time jitter link layer multicast multipath propagation router slow start splitting connection three-way handshake throughput uplink wireless link nezavisan, samostalan irina prijenosnog pojasa poruka, zraka usko grlo snop izbjegavanje zaguenja prozor zaguenja dolazni smjer s kraja na kraj jezgra simulatora ubrzani oporavak ubrzano ponovno slanje prelaenje, prekapanje vrijeme neaktivnosti kolebanje kanjenja sloj linka vieodredino razailjanje viestazno rasprostiranje signala usmjeriva spori start razdvajanje konekcije trostruko rukovanje propusnost odlazni smjer beini link

34

Dodatak
Upute za koritenje programske podrke Za pokretanje simulatora potrebno je kreirati novi direktorij te kopirati cijeli Java projekt u taj direktorij, npr. C:\temp\TCPSnoop. Uz sam projekt potrebno je kopirati i Engine.bat skriptu koju treba pokrenuti. Nakon toga otvara se grafiko suelje u kojem korisnik unosi eljene parametre potrebne za simulaciju. Sama simulacija pokree se klikom na dugme ''Start''. Po zavretku simulacije vidi se ispis dogaaja u Command prompt-u a u samom grafikom suelju neki bitni podaci vezani uz simulaciju kako je prikazano slikom (Sl. 3-1). Treba naglasiti da ovo vrijedi za sluaj kada je projekt ve preveden (engl. compile) tj. postoje .class datoteke za pojedine klase. Ukoliko to nije sluaj potrebno je prvo program prevesti u byte codove (datoteke s ekstenzijom .class) i to pomou naredbe javac. Slika (Sl. 1) predoava internu blok-shemu simulatora i prikaz komunikacijskih ruta izmeu pojedinih objekata u simulaciji

Sl. 1 Arhitektura TCP-snoop simulatora

Primjer konfiguracije .bat skripte koja slui za pokretanje simulatora:

@ECHO OFF java -cp C:\temp\TCPSnoop hr.fer.tel.jaksic.Engine pause

Slijedi prikaz dijela dogaaja koji se ispisuju u konzolu:

Server: ESTABLISHED - Sending Data Segment Download burst length = 23 Download state = 0 // ON state of wireless channel

35

Engine: segment delivered to access point t = 507 Engine: segment delivered to client t = 607 Channel: fromServer.seqNum = 82 Channel: fromServer.length = 40 Channel: fromServer.ackNum = 301 Client: receivedSegment.ackNum = 301 Client: state ESTABLISHED 2 // number of state Client RCV_NXT = 42 Client: receivedSegment.seqNum = 42 Client: receivedSegment.length = 40 Client: Expected segment received! Client RCV_NXT = 82 Loss Distribution = 1 Upload burst length = 36 Upload state = 0 Channel: fromClient.seqNum = 301 Channel: fromClient.ackqNum = 82 Channel: fromClient.length = 0 // ACK segment Engine: segment delivered to client t = 608

36