analiza performansi protokola tcp-snoop u bezicnim lokalnim mrezama - diplomski
TRANSCRIPT
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
DIPLOMSKI RAD br. 2554
ANALIZA PERFORMANSI PROTOKOLA
TCP–snoop U BEŽIČNIM LOKALNIM
MREŽAMA
Dejan Jakšić
Zagreb, lipanj 2005.
Mentor rada: prof.dr.sc Alen Bažant Voditelj rada: dr.sc Željko Ilić
Sadržaj
Uvod........................................................................................................................................... 1
1. Protokol TCP - općenito .................................................................................................... 2
1.1. Kratki uvod u protokol TCP ...................................................................................... 2
2. Protokol TCP-snoop........................................................................................................... 9
2.1. Metoda SnoopData()................................................................................................ 12
2.2. Metoda SnoopAck().................................................................................................. 13
2.3. Odnos protokol TCP-snoop - protokol usmjeravanja ............................................. 15
2.4. Alternativna rješenja na sloju linka.......................................................................... 16
2.4.1. Smjer predajnik pokretnog čvora – prijemnik bazne stanice........................... 17
2.4.2. Smjer predajnik bazne stanice – prijemnik pokretnog čvora........................... 17
3. Rezultati simulacije i opis programa................................................................................ 20
3.1. Model rješenja simulatora........................................................................................ 20
3.2. Parametri simulacije i komponente simulatora........................................................ 21
3.2.1. Fritchmanov model bežičnog kanala s gubicima............................................. 23
3.3. Rezultati simulacije.................................................................................................. 24
Zaključak.................................................................................................................................. 31
Literatura.................................................................................................................................. 32
Skraćenice ................................................................................................................................ 33
Popis stranih izraza .................................................................................................................. 34
Dodatak .................................................................................................................................... 35
1
Uvod
Cilj ovog diplomskog zadatka je opis i implementacija poboljšanja protokola TCP (engl.
Transmission Control Protocol) u bežičnom okruženju. Za predmet razmatranja uzet je
protokol TCP snoop kao jedno od rješenja s najboljim rezultatima. Snoop se pridodaje kao
modul mrežnom 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 žičnim mrežama gdje njegovi mehanizmi kontrole toka
uredno funkcioniraju. Međutim, njegova implementacija u bežičnom okruženju je malo
problematična te su potrebne određene preinake. Sukladno s time razvila su se razna rješenja i
inačice protokola TCP u bežičnim lokalnim mrežama. Neke od karakteristika bežičnih mreža
su: visoka učestalost pogreške bita (engl. Bit Error Ratio), koji iznosi do čak 10-3, veliko
varijabilno kašnjenje segmenata (engl. jitter), kapacitet i veličina ćelije, interferencija s
drugim elektromagnetskim izvorima, promjena mrežne topologije i osjetno smanjena
propusnost (engl. throughput).
Sve navedene činjenice bitno utječu na kvalitetu usluge, QoS (engl. Quality of Service) ili
drugim riječima na stupanj zadovoljstva korisnika nekom mrežnom uslugom. Najveći
problem predstavlja bežični kanal, odnosno njegova nestabilnost pri prijenosu informacije od
pošiljatelja do primatelja. Snoop je samo jedno od razvijenih rješenja, ali kao takav pokazuje
najbolje rezultate u cilju povećanja propusnosti i efikasnosti rada protokola TCP u WLAN-u.
Napomena: Termin pristupna točka ć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).
2
1. Protokol TCP - općenito
1.1. Kratki uvod u protokol TCP
Protokol TCP radi na način opisan u nastavku, a za detaljniju analizu rada protokola TCP
pogledati u (Stevens [1995]).
Protokol TCP je pouzdani transportni protokol i osnova je rada današnje Internet mreže, gdje
se veže uz mrežni protokol IP (engl. Internet Protocol). TCP pruža pouzdani prijenos
podataka i kontrolu toka koji uključuju mehanizme izbjegavanja zagušenja u mreži.
Pouzdanost je ostvarena kroz mehanizme slanja i očekivanja potvrda o ispravnom prijemu za
poslane segmente te korištenjem strategije ponovnog slanja nepotvrđenih segmenata
(retransmisija). Svaka potvrda poslana od primatelja sadrži informaciju o rednom broju
segmenta kojeg sljedećeg očekuje kao i o količini podataka koju je trenutno primatelj spreman
prihvatiti. Nadalje, pošiljatelj prilikom slanja svakog segmenta pokreće vremenski brojač i
izvodi ponovno slanje segmenta ukoliko potvrda o prijemu ne stigne prije isteka brojača
(engl. timeout).
Tri temeljna algoritma na kojima se zasniva rad protokola TCP su :
• Spori start (engl. slow start);
• Izbjegavnje zagušenja (engl. congestion avoidance) i
• Brzo ponovno slanje (engl. fast retransmission).
Navedeni algoritmi vrijede za ''temeljni TCP'', tj. Tahoe TCP dok se u ostalim inačicama
protokola uvode poboljšanja. Tako se za Reno TCP dodaje algoritam ubrzanog oporavka
(engl. fast recovery). Ovaj algoritam omogućuje da se umjesto pokretanja sporog starta nakon
primitka ponovljenih potvrda (uzimaju se u obzir tri potvrde) nastavi s izbjegavanjem
zagušenja. Time se povećava iskoristivost mrežnih resursa jer se ne čeka na istek vremenskog
brojača 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 pošiljatelj i primatelj imaju varijable prozora
zagušenja (engl. congestion window). Za pošiljatelja je to cwnd te predstavlja mjeru
kapaciteta mreže, a na strani primatelja to je rcvwnd i predstavlja mjeru kapaciteta na
odredišnoj strani. Maksimalni broj nepotvrđenih segmenata izražava se kao min{cwnd,
3
rcvwnd}. Kada primatelj primi segment van redoslijeda šalje ponovljenu potvrdu (obično se
uzimaju 3 ponovljene potvrde) i na taj način signalizira pošiljatelju da je segment na koji
pokazuje potvrda izgubljen te se taj segment ponovno šalje i izvršava se algoritam sporog
starta.
Mehanizam rada samog protokola dan je prvo grafički (Sl. 1-1), a zatim i matematički. Kao
što je vidljivo sa slike (Sl. 1-1) za vrijeme sporog starta vezan je eksponencijalni porast
prozora zagušenja, dok je izbjegavanje zagušenja linearan. Također vrijedi da nakon isteka
brojača spori start traje samo do polovice veličine prozora zagušenja.
Sl. 1-1 Spori start izbjegavanje zagušenja
Analiza i opis varijabli karakterističnih za protokol TCP dani su u nastavku :
Inicijalizacija :
cwnd = 1; // prilikom prijema svake potvrde poveća se za 1
sstresh = 65536; // put od sporog starta do izbjegavanja zagušenja (engl. slow start treshold)
Dolazak potvrde – ACK :
if ( cwnd < sstresh) // spori start
sstresh cwnd += MSS; // maksimalna veličina segmenta
else // izbjegavanje zagušenja (engl. congestion avoidance)
cwnd += MSS * MSS;
Dolazak dupliciranih potvrda – ACK :
cwnd /= 2; // smanjenje veličine prozora za pola te ponovno slanje segmenata počevši od
nepotvrđenog
4
sstresh = cwnd;
Pretpostavlja se za da je došlo do zagušenja u mreži i gubitka segmenta.
Istek vremenskog brojača - timeout :
sstresh = cwnd/2;
cwnd = 1; // ponovno slanje segmenta
Protokol TCP koristi princip klizećih prozora (engl. sliding window) prikazan na slici (Sl.
1-2), gdje veličina prozora pokazuje maksimalni broj segmenata koje mreža može primiti ili
drugim riječima kapacitet mreže. Bitno je naglasiti da i pošiljatelj i primatelj imaju svoje
prozore. U svakoj pristigloj potvrdi primatelj obavještava pošiljatelja o veličini svog prozora.
Prilikom slanja svaki segment podataka se označava rednim brojem (engl. sequence number)
koji se upisuje u zaglavlje segmenta (paketa). Najveća dopuštena veličina segmenta (MSS –
Maximum Segment Size) definiran je kao :
MSS = MTU – IPheader - TCPhedaer .
MTU (engl. Maximum Transfer Unit) je maksimalna veličina jedinice prijenosa za neki tip
mrežne tehnologije, dok se zaglavlja odnose na mrežni odnosno transportni sloj. U tablici
(Tablica 1) su prikazane veličine MTU-a definirani RFC (engl. Request for Comments)
dokumentima.
Tablica 1 Pregled MTU-a za pojedine mrežne tehnologije
RFC # Opis tehnologije MTU (okteta)
1356 X.25, ISDN 68
1055 Serial Line IP (SLIP) 1066
894, 895 Ethernet 1500
1042 4 Mbit/s Token Ring 4464
IBM standard 16 Mbit/s Token
Ring
17914
1374 HIPPI 65535
1390 FDDI 4532
5
Sl. 1-2 Mehanizam klizećeg prozora
Upravo zbog navedenih razloga TCP pruža pouzdani prijenos informacija i kontrolu toka.
Prva polovica klizećeg prozora odnosi se na poslane ali nepotvrđene segmenta dok je druga
polovica za segmente koji se mogu poslati odmah. Prilikom primitka svake potvrde klizeći
prozor se pomiče udesno za jedno mjesto. Bitno je još naglasiti da je protokol TCP pouzdan i
konekcijski orijentiran te kao takav ima ugrađen mehanizam uspostave konekcije. Razlog
tome je u mogućnosti razmjene parametara između pošiljatelja 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 pokreće konekciju šalje svoj sinkronizacijski segment s rednim
brojem segmenta koji je slučajno odabran. Nakon primanja SYN segmenta primatelj odgovara
sa svojim SYN segmentom i rednim brojem segmenta kojeg sljedećeg očekuje. Naposljetku
pošiljatelj potvrđuje redni broj segmenta te započinje prijenos prvog podatkovnog segmenta.
Primjer slanja podatkovnih segmenata i načina rada protokola TCP prikazan je slikom (Sl.
1-4), (Kralj [2003]). Za navedeni primjer pošiljatelju je dozvoljeno slanje 5840 okteta
podataka i to od rednog broja 1000 uz pretpostavku da su svi segmenti veličine 1460 okteta.
Prozori na pošiljateljevoj i primateljevoj strani postavljeni su na 5840 okteta, a to znači da
pošiljatelj može poslati maksimalno 4 segmenta prije nego što stigne potvrda koja će ažurirati
njegov klizni prozor i omogućiti nastavak slanja. Nakon slanja svih 5840 okteta, stiže potvrda
koja potvrđuje prva 3 TCP segmenta. Klizeći prozori se ažuriraju te se dozvoljava slanje
dodatna 3 segmenta.
6
SYN seq = X
SYN seq = Y, ACK X+1
ACK Y+1
Strana A Strana B
Sl. 1-3 Three-way handshake
U trenutku kada su poslana sljedeća 3 segmenta pošiljatelj privremeno obustavlja slanje
podataka, veličina prozora je nula, a to traje sve dok ne stigne nova potvrda. Princip rada
klizećih prozora objašnjen je u (Kralj [2003]).
Sl. 1-4 Tok prijenosa TCP segmenata
Kao što se vidi iz prijašnjih objašnjenja protokol TCP koristi proširenu metodu ARQ (engl.
Automatic Repeat Request) Go-back-N uz proračun perioda vremenske kontrole na osnovu
procijenjenog vremenskog kružnog kašnjenja – RTT (engl. Round Trip Time). RTT je vrijeme
koje je proteklo od trenutka slanja segmenta do trenutka primitka potvrde o prijemu segmenta.
7
Protokol TCP na svaki gubitak segmenta ''reagira'' na način:
• Smanjenjem cwnd varijable na polovicu vrijednosti varijable sstresh. Ovo doprinosi
smanjenju količine podataka koji se šalju u mrežu. Na taj način smanjuju se gubici nastali
zagušenjem u mreži;
• Ponovnim postavljanjem varijable cwnd na vrijednost jednog segmenta i ulazak u spori
start te eksponencijalni rast prozora zagušenja do sstresh = cwnd/2 vrijednosti kada
počinje linearno izbjegavanje zagušenja;
• Vraćanje na početnu vrijednost i proračun vremenskog isteka brojača na osnovu
prethodnih vrijednosti i uz pomoć Karnovog algoritma koji kaže da u slučaju ponovnog
slanja segmenta, nova vrijednost vremena isteka brojača računa se množenjem prethodno
izračunate vrijednosti s faktorom γ koji je najčešće iznosa 2, (Stevens [1995]). Često se
ovaj mehanizam naziva i backoff strategija.
U slučaju velike učestalosti pogrešaka prozor zagušenja se smanjuje prije ponovnog slanja
segmenta. Protokol TCP je izvorno razvijan kao transportni protokol vezan uz žičane mreže te
je usko vezan uz mrežni protokol IP i upravo je zbog tih razloga potrebna modifikacija
protokola TCP u bežičnom okruženju.
Ostale inačice protokola TCP biti će samo nabrojane, više u (Stevens [1995]):
• New Reno TCP ;
• SACK TCP ;
• Vegas TCP.
Bitno je za naglasiti da Vegas TCP u odnosu na Reno TCP pokazuje povećanje propusnosti do
čak 70 % uz 50 – 70 % manje retransmisija. Na slici (Sl. 1-5) dana je podjela različitih inačica
protokola TCP u bežičnom okruženju, (Elaarag [2002]). Puni nazivi navedenih kratica
objašnjeni su na kraju rada.
U slučaju gubitaka i velike učestalosti pogrešaka u mreži protokol TCP radi kao i u žičnom
okruženju i tu je izvor problema za rad u bežičnom okruženju. Smanjenjem prozora zagušenja
kao odgovor na nepostojeće zagušenje znatno se smanjuje propusnost i povećava kašnjenje u
WLAN-u. Uzrok navedenih problema je u nestabilnosti bežičnog linka (engl. wireless link) na
kojem nastaju i najveći gubici koji nisu uvijek zbog zagušenja nego, npr. zbog fadinga
(iznenadni propadi snage signala), prekida veze, interferencija s drugim elektromagnetskim
izvorima, višestaznog rasprostiranja signala (engl. multipath propagation), ograničenosti
kapaciteta ćelije itd.
8
Sl. 1-5 Rješenja problema protokola TCP u bežičnim lokalnim mrežama
U suštini postoje dva osnovna pristupa u rješavanju problematike TCP-a u WLAN-u:
• Sakriti od pošiljatelja sve gubitke koji nisu posljedica zagušenja. U tom slučaju nema
promjena u implementaciji mrežne infrastrukture, te
• pokušati ukazati pošiljatelju da je prisutan bežični link na putu do odredišta i tako
smanjiti gubitke u mreži.
Jedno od rješenja iz prve skupine prikazano je u nastavku rada, a to je protokol TCP-snoop.
Usporedbom protokola TCP-snoop s ostalim rješenjima, a misli se na rješenja s kraja na kraj i
rješenja zasnovana na razdvajanju konekcije uočava se da jedino snoop ne napušta osnovnu
funkcionalnost djelovanja protokola TCP. Na primjer za slučaj pristupa razdvajanjem
konekcije ''krši'' se rad protokola TCP s potvrdnim segmentima. Takav pristup bitno utječe na
period potreban za obnavljanje veze prilikom promjene pristupne točke. Za protokol TCP-
snoop to vrijeme se kreće od 5 do 70 ms dok je kod protokola I-TCP to vrijeme čak 1400 ms
ovisno o količini podataka koje je potrebno prenijeti na novu pristupnu točku. Prilikom
prelaženja cilj je što više skratiti vrijeme neaktivnosti TCP konekcije (engl. idle time).
9
2. Protokol TCP-snoop
Za svaki gubitak segmenta protokol TCP smatra da je posljedica zagušenja što u bežičnim
mrežama (WLAN) nije uvijek slučaj 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 točki. TCP-snoop spada u kategoriju koje podižu performanse mreže koristeći
metodu proxy-ja - PEP (engl. Performance Enhancing Proxy). (Ho Ng et al [1997]).
Djelovanjem ispod transportnog sloja izvodi se lokalna retransmisija (ili ponovno odašiljanje)
izgubljenih segmenata bez pokretanja TCP mehanizama za kontrolu zagušenja.
Ostale metode koje se koriste za prilagodbu TCP-a bežičnom okruženju pripadaju u neku od
sljedeće tri grupe :
• Rješenja s kraja na kraj (engl. End to End) ;
• rješenja na razini linka (engl. Link Layer), te
• rješenja zasnovana na razdvajanju konekcije (engl. Spliting Connection).
Ideja TCP-snoop-a je u tome da se sakriju od pošiljatelja svi gubici nastali na sloju linka. Na
taj način TCP pošiljatelj ne zna za pogreške na bežičnom linku pa tako nema i bespotrebnog
pokretanja mehanizama za kontrolu zagušenja. Sve to dovodi do postizanja zadovoljavajuće
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 inačica protokola TCP-snoop (engl. Basic TCP-snoop).
Implementacija protokola izvodi se uvođenjem modula snoop modula u pristupnu točku (engl.
Access Point-AP). Naglasak je na promatranju infrastrukturnog WLAN-a u centraliziranom
pristupu. To znači da se sva komunikacija između žične i bežične domene odvija preko
pristupne točke, a izravna komunikacija između pokretnih čvorova (engl. wireless hosts) nije
moguća. Slika (Sl. 2-1) prikazuje infrastrukturni WLAN s implementacijom snoop modula u
pristupnoj točki.
Sl. 2-1 Mrežna topologija
10
Snoop modul nadgleda sve segmente koji prolaze TCP konekcijom u oba smjera, te u
spremniku ima pohranjene sve TCP segmente od strane pošiljatelja koji još nisu potvrđeni od
strane primatelja. Ukoliko nastanu gubici tada snoop izvodi lokalnu retransmisiju izgubljenih
segmenata a da to pošiljatelj ne zna.
Snoop modul radi na principu spremi i proslijedi (engl. store and forward) bez unošenja
protokolnog preteka (engl. overhead) koji bi dodatno smanjio propusnost mreže. Kratka
analiza protokola TCP uzeta je u razmatranje zato jer se protokol snoop direktno ''naslanja'' na
njega. Sama implementacija izvedena je negdje između mrežnog i transportnog sloja. Bez
zadiranja u rad protokola TCP. Nove funkcionalnosti se dodaju u pristupnu točku (snoop
modul) i to vezano uz mrežni sloj pristupne točke te male promjene kod mobilnog klijenta.
Prednosti ovakvog pristupa posebno dolaze do izražaja u slučaju prelaženja mobilnog
korisnika (engl. handoff), tj. prelaska u susjednu ćeliju ili drugim riječima promjena pristupne
točke. Tada nastaju veliki gubici, povećanje kašnjenja i smanjenje propusnosti. Taj problem
se rješava grupiranjem trenutne pristupne točke korisnika i susjednih AP-a u multicast
skupinu. U svakoj od stanica multicast skupine pokreće se snoop agent tako da nova pristupna
točka u trenutku prebacivanja već ima kopije izgubljenih segmenata. Problem se javlja u
slučaju kada nova pristupna točka nije član multicast skupine pa je dio segmenata izgubljen za
vrijeme prelaženja. Jedina modifikacija protokolnog složaja je u mijenjanju mrežnog sloja u
pristupnoj točki. Snoop ''motri'' sve segmente koji prolaze kroz pristupnu točku u oba smjera
te radi potrebno pohranjivanje u spremnik. Kada novi segment stigne u pristupnu točku od
strane žičnog čvora snoop ga dodaje u spremnik te ga prosljeđuje kroz bežični kanal do
pokretnog čvora. Nadalje, snoop nadzire i sve potvrde, ACKs (engl. Acknowledgements)
poslane od primatelja (Balakrishnan et al. [1995]).
U slučaju gubitka segmenta u bežičnom kanalu što se otkriva istekom lokalnog brojača (engl.
local timeout) i dupliciranih potvrda (Sl. 2-2) radi se ponovno slanje izgubljenih segmenata.
Na taj način pristupna točka ''skriva'' gubitke segmenata od pošiljatelja te nema pokretanja
mehanizama za izbjegavanje zagušenja karakterističnih za protokol TCP.
Tablica (Tablica 2) prikazuje poboljšanja koja TCP-snoop donosi za problem handoff-a,
(Balakrishnan et al. [1995]). Bitno je uočiti da se unatoč učestalim promjenama pristupne
točke vrijednost propusnosti bitno ne mijenja, što ne bi bio slučaj za protokol TCP bez snoop
modula.
11
1
2
3
4
2
4
3
5
5
Pošiljatelj Primatelj
Prvo slanje
ack1
ack1
ack1
ack1
Duplicirane potvrde iponovno slanje
Sl. 2-2 Otkrivanje gubitka segmenta
Snoop održava visoku razinu propusnosti koja nije sklona naglim propadima. Nadalje,
poboljšanje protokola TCP-snoop u slučaju male učestalosti pogrešaka nije toliko izraženo.
Drugim riječima, uvođenje snoop modula svu svoju efikasnost pokazuje u uvjetima visoke
učestalosti pogrešaka bita - BER.
Tablica 2 Ovisnost propusnosti o vremenu prelaženja
Vrijeme potrebno za
handoff [s]
Propusnost [Mbit/s]
1 1.42
3 1.43
8 1.44
10 1.43
Razlog promjena u mrežnom sloju pristupne točke leži u činjenici da je to jedino mjesto u
WLAN-u gdje korisnik može imati potpunu kontrolu u radu protokola za usmjeravanje paketa
između žične i bežične mreže. U samoj pristupnoj točki mehanizmi transportnog sloja se ne
pokreću. Originalna zamisao rada snoop modula uključuje promjene i kod ostalih mrežnih
elemenata kao što su pokretni i stacionarni čvor. To se radi za slučaj slanja podataka od strane
pokretnog čvora, opisano u radu (Balakrishnan et al. [1995]). Međutim, zbog nedostatka opisa
istog u literaturi u ovom radu to neće biti razmatrano. Sam rad protokola TCP-snoop vezan je
uz dvije metode:
12
• 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 bežični kanal.
2.1. Metoda SnoopData()
Pojednostavljeni pseudokod ove metode prikazan je u nastavku:
ako (novi segment i u rastućem slijedu) {
stavi segment u spremnik;
proslijedi segment na odredište;
} inače ako (segment nije u slijedu a u spremniku postoji isti) {
ako (redni broj segmenta < rednog broja potvrde) {
proslijedi segment na odredište;
} inače {
ponovno pošalji segment;
}
} inače ako (segment nije u rastućem slijedu i u spremniku ne postoji isti) {
proslijedi segment prema pokretnom čvoru;
}
Postoje tri slučaja:
• Segment je u rastućem slijedu (novi segment). Segment se dodaje u spremnik te
prosljeđuje u bežični 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 slučaj je rijedak a
nastupa zbog isteka brojača na strani pošiljatelja ili u slučaju ubrzanog ponovnog slanja.
Postoje dva podslučaja:
o Redni broj segmenta < broja potvrde. Može nastupiti zbog gubitka prethodne
potvrde a rješava se prosljeđivanjem segmenta.
13
o Redni broj segmenta ≥ broja potvrde. Nastupa zbog gubitka segmenta između
pristupne točke i pokretnog čvora. Segment se prosljeđuje prema pokretnom
čvoru a retransmisija je posljedica isteka vremenskog brojača.
• Segment nije u slijedu i u spremniku ne postoji kao pohranjeni segment. U ovom slučaju
segment je izgubljen u žičnom dijelu mreže ili je isporučen u pogrešnom redoslijedu.
Segment se prosljeđuje prema pokretnom čvoru i označava se kao ponovno poslani.
2.2. Metoda SnoopAck()
Po potrebi ova metoda odbacuje pozitivno potvrđene segmente (ACK) i osvježava potvrdu
RTT-a. Pseudokod metode:
ako (nova potvrda) {
briši potvrđene segmente iz spremnika;
osvježi RTT;
proslijedi potvrdu prema stacionarnom čvoru;
} inače ako (spontana potvrda) {
odbaci tu potvrdu;
} inače ako (dvostruka potvrda) {
ako (segment nije u spremniku, izgubljen u žičnom dijelu mreže )
proslijedi potvrdu prema stacionarnom čvoru;
inače ako (neočekivana duplicirana potvrda)
ponovno pošalji segment uz najviši prioritet;
inače ako (očekivana duplicirana potvrda, AP zna da je segment izgubljen)
odbaci potvrdu;
}
Kao i za prethodnu metodu i ovdje postoje tri slučaja:
• Nova potvrda – ACK. Uobičajeni slučaj, brišu se potvrđeni segmenti iz spremnika,
osvježava se procjena RTT-a i prosljeđuje potvrda prema stacionarnom čvoru.
14
• Spontani (engl. spurious) ACK. Kada neočekivano stigne već viđena potvrda od strane
stacionarnog čvora. Ovaj slučaj je vrlo rijetko nastupa. Odgovor na ovakvo stanje je da se
takva potvrda odbacuje.
• Dvostruki ACK segment (DUPACK). Slučaj kada pristigne potvrda identična onoj
primljenoj prethodno. Opet postoji nekoliko podslučaja:
o Kada segment nije u spremniku iz razloga što je izgubljen na putu između
stacionarnog čvora i pristupne točke. Takva potvrda se jednostavno prosljeđuje
prema stacionarnom čvoru radi očuvanja stanja TCP-a.
o Neočekivani DUPACK nakon što je segment izgubljen. Odgovor na ovo stanje
je ponovno slanje segmenta u najviši prioritet. Za ovaj slučaj potrebna su dva
reda za slanje, jedan za segmente višeg a drugi za segmente nižeg prioriteta.
Nadalje snoop vodi računa i o maksimalnom broju dupliciranih potvrda za
segment.
o Očekivani DUPACK, koji stiže nakon što pristupna točka sazna da je segment
izgubljen. Takva potvrda se u pravilu odbacuje.
Slanje segmenata s višim prioritetom donosi poboljšanju performansi mreže u uvjetima
visokih pogrešaka bita. Na taj se način omogućuje da ponovno poslani segmenti stignu do
pokretnog čvora u što kraćem vremenu čime se smanjuje broj dupliciranih potvrda te tako
povećava propusnost mreže. Snoop vodi evidenciju o broju lokalnih retransmisija za svaki
segment i resetira brojač u slučaju da neki segment stigne ponovno od pošiljatelja uslijed
isteka brojača na pošiljateljovoj strani ili uslijed ubrzanog ponovnog slanja. Kao što je ranije
rečeno snoop radi i lokalnu retransmisiju za istek lokalnog brojača.
Za slučaj transfera podataka od pokretnog čvora prema stacionarnom, uvode se negativne
potvrde, (NACK) za traženje segmenata koji nedostaju. To se radi u slučaju isteka vremenske
kontrole kod pristupne točke i kada je primljen određeni broj segmenata. U ovom radu
naglasak je na proučavanju rada protokola TCP za smjer prema pokretnom čvoru (engl.
downlink) iz razloga što je za bežične mreže karakteristična asimetrija u prijemu podataka.
Drugim riječima prema klijentu se šalje puno veća količina podataka nego u odlaznom smjeru
prema poslužitelju. Podaci koji se šalju prema poslužitelju uglavnom su vezani uz zahtjeve
određenih resursa sa poslužitelja koji sadrže male količine podataka.
15
2.3. Odnos protokol TCP-snoop - protokol usmjeravanja
Kao što je ranije opisano princip rada protokola TCP-snoop temelji se na pohranjivanju
nepotvrđenih segmenata da bi se poboljšale performanse s kraja na kraj. U pravilu veličina
spremnika s pohranjenim segmentima proporcionalna je veličini klizećeg prozora na strani
primatelja. U nastavku je malo šire opisano ponašanje protokola TCP-snoop za slučaj
prelaženja koje je i ranije dijelom opisano ali u puno manjem opsegu. Pri promjeni pristupne
točke nova pristupna točka mora preuzeti sve nepotvrđene segmente od stare pristupne točke
kako bi se mogla izvršiti lokalna retransmisija. Kada pristupna točka primi zahtjev za
prelaženjem sadržan u poruci beacon, pridružuje se multicast skupini na ranije opisani način.
Nova pristupna točka prima sve segmente namijenjene toj multicast skupini i snoop modul
osvježava informaciju o novim TCP konekcijama u pristupnoj točki. Na taj način snoop
modul gradi novi spremnik s informacijama o svim aktivnim TCP konekcijama.
Kada nastupi prelaženje, pozitivno potvrđeni segmenti počinju prolaziti kroz novu pristupnu
točku. Prvi primljeni potvrdni segment određuje koji su segmenti primljeni na strani
pokretnog čvora do tog trenutka za tu TCP konekciju. Ova informacija služi za ažuriranje
stanja snoop modula i čišćenje spremnika u pristupnoj točki. U stvarnosti, stanje prije i nakon
navedene sinkronizacije nije nikada identično. Razlog tome leži u činjenici da nova pristupna
točka može imati vlastiti spremnik s nekoliko segmenata koji su izgubljeni tijekom samog
prelaženja. Upravo u ovom dijelu do izražaja dolazi sva snaga i robustnost protokola TCP-
snoop. Naime, kako snoop održava semantiku TCP konekcije s kraja na kraj i sakriva gubitke
od pošiljatelja ti se segmenti neće ponovno slati nego će se jednostavno ignorirati ili u slučaju
većih gubitaka zatražiti od prijašnje pristupne točke. U najgorem slučaju ovi segmenti će
uzrokovati kratki i neznatni pad mrežnih performansi koji se i ionako očekuje tijekom
postupka prelaženja. Praktična mjerenja pokazala su da je potrebno svega nekoliko
novoposlanih segmenata da bi snoop modul u novoj pristupnoj točki obnovio informaciju o
novonastalom stanju. Upravo zbog ranije opisanog načina nema uobičajenog preuzimanja
cjelokupnog stanja o TCP konekciji nego se radi nadziranje stanja stare pristupne točke od
strane nove pristupne točke i tako se postupak prelaženja skraćuje i rješava puno efikasnije.
Slika (Sl. 2-3) prikazuje klasičan način prelaženja.
16
segm1
beacon
forward request
segm3
segm4
stronger beacon
segm2
buffer request
segm5
Pristupna točka 1 Pokretni čvor Pristupna točka 2
handoffperiod
Sl. 2-3 Prikaz izmijenjenih poruka za vrijeme postupka prelaženja
2.4. Alternativna rješenja na sloju linka
Radi same usporedbe ukratko je i opisano rješenje 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 bežičnim sustavima kao što je WiMAX, standard IEEE 802.16a ili drugim
riječima WMAN. Asimetrija proizlazi iz činjenice da pokretni čvorovi imaju puno manju
snagu i slabiju mogućnost 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 težnja je
u ''postavljanju'' što više inteligencije u samu baznu stanicu te da se u pokretnim čvorovima
procesiranja svedu na minimum. Naglasak je u optimalnom iskorištenju prijenosnog pojasa
(engl. bandwith) od strane bazne stanice bez pokretanja nepotrebnih retransmisija te očuvanju
napajanja pokretnog čvora pomoću statusnih poruka izmijenjenih s baznom stanicom. FEC
kao tehnika ispravljanja grešaka kombinira se na razini bita, okteta i paketa. Kombinacija
navedenih triju razina provodi se kao ''kodiranje kanala'' (engl. channel coding) i to pomoću
adaptivnog algoritma temeljenog na automatu s konačnim brojem stanja opisanim u
(Ayanoglu et al. [1994]). Slika (Sl. 2-4) prikazuje tipično ustrojstvo bežične mreže 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.
17
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 veličina spremnika za
slanje (engl. maximum transmit buffer size) koja se računa na osnovu mjerenja RTT-a,
zahtijeva za ponovnim slanjem te dali ima još podataka za slanje. Paketi koji čekaju na
ponovno slanje imaju viši prioritet od ostalih. Kada pokretni čvor više nema paketa za
slanje on postavlja tzv. e-bit u zaglavlje zadnje poslanog paketa.
• Bazna stanica šalje poruke o svome stanju (engl. status messages) periodički kroz bežični
kanal. Te poruke ne nose informaciju o veličini spremnika za slanje kao što je to slučaj u
nekim drugim protokolima. Pomoću vremenskog brojača stanja (engl. status timer) koji
se pokreće prilikom slanja poruke stanja određuje se gubitak paketa u bežičnom kanalu.
Vremenski brojač nalazi se samo na strani bazne stanice. U slučaju da primljeni paket
sadrži e-bit brojač se ne pokreće 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 reći da da je veličina spremnika za slanje kod pokretnog
čvora veća nego veličina ''prozora'' kod bazne stanice i tako se rješavaju problemi vezani
uz gubitak statusnih poruka prema pokretnom čvoru.
Ova činjenica bitno utječe na propusnost koja je ovom slučaju definirana kao broj paketa koji
se prenesu za vrijeme trajanja RTT-a. Ovaj korak je najsloženiji 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 slučaju da je veličina prozora različita od nule, sve dok
dolaze zahtjevi za ponovnim slanjem te sve dok ne ponestane paketa za slanje. Kao i za
slučaj slanja pokretnog čvora ukoliko nema više paketa za slanje šalje se e-bit na način
opisan ranije. Vremenski brojač se pokreće 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 brojača. Pod pojmom bloka smatra se fiksni broja paketa određen
samim algoritmom AIRMAIL-a.
18
Sl. 2-4 Ćelijska organizacija mrežne 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 znači da je paket i
primljen a biti = 0 znači da nije primljen. Radi uštede predajne snage pokretni čvor ne
šalje poruke o statusu periodički 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.
• Slučaj kada bazna stanica ponovno šalje tražene 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 također i pokreće vremenski brojač radi otkrivanja dali je
pokretni čvor poslao poruku o statusu koja potvrđuje prijenos bloka paketa u nekom
vremenu intervalu određenim brojačem. Ukoliko poruka o statusu ne stigne prije isteka
brojača, 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 uštedi resursa i principu ponovnog slanja izgubljenih
paketa. Odluka o prisutnosti pogrešaka unutar paketa temelji se na dobro poznatom
mehanizmu CRC (engl. Cyclic Redudancy Check). Optimizacijom koda koji se dodaje na
pakete može se smanjiti broj retransmisija te ispraviti pogreške. Za stvarnovremenske
aplikacije kao što su audio i video mehanizam retransmisije nije dobar jer unosi prevelika
kašnjenja. U tom slučaju rabi se FEC koji osigurava dobar QoS. Dobrim podešavanjem
19
parametara FEC-a iskoristivost kanala raste kao što se i smanjuje kašnjenje tijekom promjene
bazne stanice. AIRMAIL je kao i snoop još jedna od inačica protokola za poboljšanje TCP-a
u bežičnom okruženju. Svoje djelovanje temelji na retransmisijama i uštedi prijenosnog
pojasa na razini sloja linka, bez zadiranja u transportni sloj. Međutim za promatranu
problematiku vezanu uz TCP u WLAN-u snoop daje puno bolje rezultate, osobito za
propusnost, nego AIRMAIL. Međutim za slučaj WMAN-ova AIRMAIL je jedno od najboljih
rješenja.
Prednost rješenja s retransmisijom na sloju linka su u tome da je rješenje nevidljivo od sloja
IP na više, te da protokol TCP zadržava svoj značaj 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 kašnjenja i kolebanja kašnjenja (engl.
jitter), problemi vezani uz duže periode prekida konekcije te problemi tzv. uskog grla
pristupne točke (engl. bottleneck) ili drugim riječima problem višestrukih TCP konekcija
između 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 pošiljatelja. Treba naglasiti da je
ovdje više naglasak na održavanju iznosa propusnosti konstantnim s obzirom na
karakteristiku bežičnog kanala.
20
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 mogućnosti realizacije pojedinih komponenata mrežne topologije. Cilj
diplomskog zadatke bio je pokazati poboljšanja koje unosi integracija snoop modula u
pristupnu točku u WLAN-u na neke od osnovnih komponenti protokola TCP kao što su
veličina prozora zagušenja, broj poslanih segmenata u jedinici vremena, propusnost, itd.
Komponente mrežne topologije sa slike (Sl. 2-1) implementirane su kao klase u simulatoru.
3.1. Model rješenja simulatora
Slika (Sl. 3-1) daje prikaz grafičkog sučelja prema korisniku – GUI (engl. Graphical User
Interface).
Sl. 3-1 Korisničko grafičko sučelje
21
Kao što je vidljivo sa slike (Sl. 3-1) grafičko sučelje sastoji se od nekoliko dijelova:
• Simulation Log. U ovom prozoru se pri početku i završetku simulacije ispisuje datoteka
log.txt koja opisuje tijek simulacije i bitne događaje vezane uz simulaciju (npr. da li je
uspostavljena konekcija između komunicirajućih entiteta, broj poslanih i izgubljenih
segmenata i sl.).
• Result options. Prikaz rezultat je dan kao funkcija vremena. Postoji mogućnost biranja
prikaza veličine prozora zagušenja, rednih brojeva segmenata te propusnosti sve u
ovisnosti o trenutku simulacije. Nadalje, u ovom dijelu je dio vezan za aktivaciju snoop
modula u pristupnoj točki kao poboljšanja u radu protokola TCP u bežičnom okruženju.
Naposlijetku, postoji mogućnost provedbe paralelne simulacije za razne algoritme i
mogućnost usporedbe rezultata na istom grafu. Ovdje je bitno za reći da se svi rezultati
ispisuju u tekstualnu datoteku u stupčastom obliku upravo radi lakše obrade rezultata. Za
prikaz rezultata može 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 predviđen za podešavanje karakteristika bežičnog kanala kao što je
model kanala, vrijeme propagacije kroz bežični kanal, vjerojatnost gubitaka segmenata.
• Server options. Najbitniji dio simulatora u kojem se unose parametri ključni 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 točka mogu primiti, obraditi te poslati samo jedan TCP segment. Svi TCP
segmenti koji se izmjenjuju između entiteta postavljeni su na korisnički zadanu vrijednost
MSS i kao takvi se šalju.
3.2. Parametri simulacije i komponente simulatora
Za izvođenje simulacije korištene su sljedeće vrijednosti TCP parametara:
• MSS je postavljen na 40 okteta;
• sstresh ima vrijednost 65536 okteta;
• vrijeme propagacije segmenata bežičnim kanalom iznosi 100 ms;
• veličina datoteke koja se prenosi je 1600 okteta;
• vrijeme propagacije segmenata po žičnom linku postavljeno je na 10 ms i pretpostavka je
da gubici segmenata na žičnom linku nisu mogući (engl. error free link).
22
Unutar simulatora sam žični link nije implementiran kao klasa nego se simulira na način da se
slanje svakog segmenta odgađa za period vremena od 10 ms. Tako se opisuje propagacija
žičnim linkom na putu do pristupne točke. Što se bežičnog kanala tiče, u simulatoru postoji
mogućnost biranja razdiobe gubitaka između tzv. Fritchmanovog modela kanala i uniformne
razdiobe gubitaka segmenata u bežičnom kanalu, (Kralj [2003]). Sve simulacije izvedene u
radu odnose se na Fritchmanov model kanala koji je ukratko opisan u nastavku rada i
predstavlja poopćeni Gilbertov model bežičnog kanala s gubicima. Slučaj s uniformnom
razdiobom ne preporučuje se za simulacije s aktivnim snoop modulom jer daje izrazito loše
rezultate i implementiran je u simulatoru samo radi usporedbe. Maksimalna veličina prozora
zagušenja i kod pošiljatelja i kod primatelja iznosi 65536 okteta. Također, definira se i
maksimalni broj retransmisija, nakon kojega se konekcija između 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 pošiljatelja šalje potvrdni segment s
rednim brojem segmenta kojeg sljedećeg očekuje. Prilikom ponovnog slanja segmenta ne
računa se RTT (koristi se pojednostavljeni mehanizam retransmisije) i to samo za
segmente koji iniciraju (SYN) odnosno raskidaju konekciju (FIN), (Kralj [2003]).
• Bežični kanal s gubicima. Implementiran kao zasebna klasa u Javi te povezuje klijenta s
poslužiteljem, odnosno s pristupnom točkom. Model kanala i način funkcioniranja opisan
je u nastavku rada.
• Pristupna točka. Bitna komponenta simulatora jer obavlja funkciju mosta (engl. bridge)
između dvaju domena. Za vrijeme uspostave konekcije između klijenta i poslužitelja
pristupna točka je transparentna ili drugim riječima svoju funkciju počinje obavljati tek
kod slanja podatkovnih segmenata i aktivnog snoop modula. Svi segmenti poslani od
poslužitelja kao i potvrdni segmenti, poslani od klijenta, prolaze kroz tu komponentu.
Nadalje, upravo je u pristupnoj točki implementiran snoop modul koji pohranjuje potvrde
i segmente lokalno u spremnik. Također, u slučaju aktivnog snoop modula računa se
vrijednost lokalnog vremenskog brojača za slučaj lokalne retransmisije. U originalnom
modelu protokola TCP-snoop uvode se prioriteti za pakete koji čekaju na ponovno slanje
u spremniku pristupne točke. Navedeni prioriteti za ponovno slanje paketa nisu
razmatrani u ovom radu.
23
• Poslužitelj – stacionarni čvor. Ima ulogu pošiljatelja i svi mehanizmi bitni za rad
protokola TCP, kao što su algoritmi kontrole zagušenja, dinamičko računanje
vremenskog brojača 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 korištenog u
simulaciji. Polje ‘’Duljina segmenta’’ odnosi se na podatkovni dio TCP segmenta i to u
oktetima. Prilikom prijema segmenta, dotični se odmah obrađuje bez pohranjivanja u
spremnik, osim u slučaju aktivnog snoop modula.
• Engine simulatora. Jedina klasa s main metodom. Kreira grafičko sučelje prema
korisniku, određuje razmještaj komponenti unutar grafičkog sučelja, omogućuje unos
korisničkih parametara za pojedine metode unutar simulatora te ispis bitnih događaja
vezanih uz simulaciju. Navedeno ne znači da se kompletan tijek simulacije ispisuje
unutar grafičkog sučelja, za to služi konzola (engl. console) unutar samog Java razvojnog
okruženja.
Sl. 3-2 TCP segment implementiran u simulatoru
3.2.1. Fritchmanov model bežičnog 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 bežičnog kanala na putu između pošiljatelja i primatelja,
odnosno između pristupne točke i bežičnog klijenta. Markovljev lanac ima stanja ON i OFF.
Dok je bežični kanal u stanju ON svi segmenti se ispravno prenose do bežičnog klijenta, a u
slučaju stanju OFF svi poslani segmenti su izgubljeni u kanalu. Gubici koji nastaju u
bežičnom kanalu su usnopljeni, što znači da se na segmente gleda kao na uzastopni niz koji
tvori jedinstveni tok podataka. Za Fritchmanov model bitno je reći 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 odsječka. Ovaj podatak
vezan je uz polje unutar simulatora ''Average Loss Length'' koje predstavlja duljinu snopa
gubitaka kao broj vremenskih odsječaka.
24
Prosječna vremena zadržavanja u stanjima opisana su varijablama Ton i Toff te se ravnaju po
geometrijskoj razdiobi. Za slučaj da je u slučajni broj između 0 i 1 i da je z vjerojatnost
napuštanja stanja, duljina zadržavanja x u jednom od stanja računa se kao:
xzu )1( −=
xzu )1log()log( −=
)1log()log( zxu −⋅=
)1log(
)log(
z
ux
−=
Prilikom pokretanja simulacije korisnik unosi vrijednost Toff i vjerojatnost pogreške Pb.
Varijabla Pb drugim riječima predstavlja stacionarnu vjerojatnost boravka bežičnog kanala u
stanju OFF. Vrijednost varijable Pb računa se na način:
offon
offb TT
TP
+=
Pošto je vjerojatnost Pb poznata iz navedenog izraza, lako je izračunati stacionarnu
vjerojatnost boravka u stanju ON, pomoću izraza:
bg PP −= 1
Bitno je još naglasiti da su uvjetima u kanalu izloženi ne samo segmenti nego i potvrde koje
klijent šalje poslužitelju. Uvjeti simulacije za slučaj kada je snoop modul aktivan u pristupnoj
točki i kada nije su isti upravo da bi se uočila poboljšanja koja unosi snoop modul na rad
protokola TCP u bežičnom okruženju. Ovdje je potrebno napomenuti da je problem
određivanja modela koji bi dobro opisivao bežični kanal poseban problem i opisan je s raznim
matematičkim 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 predočava poboljšanja
koje unosi aktivnost snoop modula u pristupnoj točki na veličinu prozora zagušenja. Jasno se
vidi poboljšanje vezano uz broj segmenata koje pošiljatelj može poslati u mrežu, a da ne mora
čekati prijem potvrdnog segmenta od strane primatelja. Poboljšanje je znatno jer u trenutku
oko 1500 milisekunde pošiljatelj može u slučaju aktivnog snoop modula poslati čak 70-ak
25
TCP segmenata, dok je u suprotnom slučaju taj broj nešto veći od 40 TCP segmenata.
Obzirom da veličina prozora zagušenja predstavlja na neki način trenutnu mjeru kapaciteta
mreže, navedeno poboljšanje dobiva još više na svome značaju. Kao što je vidljivo sa slike
(Sl. 3-3) nakon isteka vremenske kontrole započinje period sporog starta sve do perioda
izbjegavanja zagušenja. Trajanje vremena isteka vremenskog brojača isto je za slučaj bez
aktivnog snoop modula i s aktivnim snoop modulom. Može se uočiti 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 inačica protokola TCP u WLAN-u pokazuje najlošije
rezultate.
0
500
1000
1500
2000
2500
3000
3500
0 500 1000 1500 2000 2500 3000 3500
Vrijeme [ms]
CW
ND
[okt
et]
Regular TCP TCP Snoop
Sl. 3-3 Tahoe TCP – veličina prozora zagušenja
Iz svega navedenog može se zaključiti da protokol TCP-snoop sprječava istek vremenskog
brojača na strani pošiljatelja i održava povećanu vrijednost veličine prozora zagušenja u
svakom vremenskom trenutku simulacije. Upravo su ova dva čimbenika ključna za
održavanje konstantne vrijednosti propusnosti, što osobito dolazi do izražaja za vrijeme
prelaženja između susjednih pristupnih točaka. 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 prelaženja nije uzet u detaljnije
razmatranje, tj. nije predmet razmatranja diplomskog rada.
Obzirom da protokol TCP-snoop najbolje funkcionira u uvjetima učestalih pogrešaka,
poželjno je kod simulacije povećati vjerojatnost boravka bežičnog kanala u OFF stanju. U
simulaciji se ne razmatra BER, ali treba reći da je utjecaj snoop modula u slučaju malih iznosa
26
BER-a na performanse WLAN-a gotovo neznatan, čak i degradirajući, (Balakrishnan et al.
[1995]). Za primijetiti (Sl. 3-3) je da je poboljšanje vezano za veličinu prozora zagušenja u
simulaciji trenutno. U stvarnosti to nije slučaj zato što protokol TCP-snoop ima svojstvo spore
konvergencije na poboljšanje performansi unutar WLAN-a, te se smatra jednim od
nedostataka protokola.
Analizom simulacije utvrđeno je da je da u slučaju gubitaka većeg broja potvrda poslužitelj i
dalje nastavlja sa slanjem podatkovnih segmenata. Međutim, slučaj gubitka samo jednog
podatkovnog segmenta uslijed trenutnog stanja bežičnog kanala za posljedicu ima niz
retransmisija. Slika (Sl. 3-4) prikazuje ovisnost rednog broja segmenta (engl. sequence
number) o vremenu simulacije opet za dva slučaja, bez aktivnog snoop modula i s aktivnim
snoop modulom u pristupnoj točki. Uočava se nagli porast rednih brojeva poslanih TCP
segmenata oko trenutka t = 305 ms za slučaj aktivnog snoop modula što znači da pošiljatelj
''ne zna'' za gubitke u bežičnom kanalu i ne radi retransmisiju segmenata. Redni broj segmenta
računa se na način da je svaki sljedeći redni broj jednak zbroju maksimalne veličine 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 slučaju kada snoop
modul nije aktivan neki od segmenta s istim rednim brojem šalju se više puta, što znači da se
pokreću mehanizmi kontrole zagušenja koji izrazito degradiraju performanse WLAN-a. U
radu (Vangala [2002]) navedeni su podaci za ostale inačice protokola TCP, tako Tahoe, Reno,
New Reno pokazuju osjetno poboljšanje u broju poslanih segmenata u slučaju aktivnog snoop
modula dok najveće poboljšanja pokazuje TCP Vegas.
0200400600800
100012001400160018002000
0 1000 2000 3000 4000 5000 6000 7000 8000
Vrijeme [ms]
Red
ni b
roj s
egm
enta
[okt
et]
Regular TCP Snoop TCP
Sl. 3-4 Tahoe TCP – ovisnost rednog broja segmenta o vremenu simulacije
27
Zanimljivo je da protokol TCP SACK koji pokazuje najbolje rezultate bez prisutnosti snoop
modula, za slučaj njegove prisutnosti postaje najlošije rješenje za implementaciju u WLAN-u.
Slika (Sl. 3-5) predočava vrijednost veličine prozora zagušenja za slučaj kada se maksimalna
vrijednost lokalnog brojača u pristupnoj točki smanji. Uočava se manji broj TCP segmenata
koje pošiljatelj može poslati u mrežu, (Sl. 3-5). Način na koji se računa vrijednost lokalnog
brojača je dobro poznati Karnov algoritam, (Stevens [1995]). Princip određivanja vrijednosti
brojača opisan je slikom (Sl. 3-6). Isti se princip primjenjuje na poslužitelju kao i na
pošiljatelju i u pristupnoj točki. Ovaj pristup daje dobre rezutate i u uvjetima učestalih
pogreški što je karakteristično za bežični kanal. Ukratko, kada stigne potvrda za prvi sljedeći
segment koji nije ponovno poslan iznos vremenskog brojača računa se na način opisan slikom
(Sl. 3-6).
0
500
1000
1500
2000
2500
3000
0 500 1000 1500 2000 2500 3000 3500
Vrijeme [ms]
CW
ND
[ok
tet]
Regular TCP TCP Snoop
Sl. 3-5 Tahoe TCP – veličina prozora zagušenja
Kao što je ranije navedeno pristupna točka je transparentna za sve TCP segmente sve do
trenutka aktiviranja snoop modula. Razlog tome leži u pretpostavci da u žičnom dijelu mreže,
tj. na putu između poslužitelja i pristupne točke gubici nisu mogući. Također, pretpostavka je
da pristupna točka ne unosi dodatno kašnjenje ako snoop modul nije aktivan.
''Problem'' koji unosi snoop na rezultate simulacije je povećanje kašnjenja s kraja na kraj
(engl. end-to-end) uslijed spremanja segmenata u spremnik pristupne točke te uslijed
pretraživanja i usporedbe segmenta koji se obrađuje sa segmentima unutar spremnika. Bitno
je naglasiti problem proračuna vrijednosti lokalnog brojača na strani pristupne točke, koji se
često postavlja na fiksnu vrijednost, tako da su moguća i daljnja poboljšanja. U simulatoru je
pokušana realizacija s ugrađenom Java funkcijom random() koja bi računala vrijednost
28
vremenskog brojača u odnosu na neku maksimalnu vrijednost, međutim opisani postupak nije
se pokazao kao najbolji jer ne uzima u obzir vrijednost vremena propagacije TCP segmenta
kroz bežični kanal, ne sprječava istek vremenskog brojača na poslužitelju i ponekad daje
izrazito lošu razdiobu vrijednosti lokalnog brojača.
Sl. 3-6 Eksponencijalni backoff algoritam za proračun vremenskog brojača
Na slikama (Sl. 3-7, Sl. 3-8) dan je prikaz rezultata za jedan te isti simulacijski postupak, tj
analizirani su propusnost i veličinu prozora zagušenja za slučaj kada snoop modul nije
aktivan. Svi parametri simulacije ostaju isti za sve simulacijske postupke. Vrijednosti iznosa
propusnosti su apsolutne što znači da nemaju praktičnu vrijednost nego samo služe za prikaz
rezultata. Na grafu propusnosti uočava se da u pojedinim trenucima vrijednost propusnosti
pada na vrijednost nula.
0
1
2
3
4
5
6
0 2000 4000 6000 8000 10000
Vrijeme [ms]
Pro
pusn
ost
[se
gm
ent/m
s]
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 brojača podatkovni segmenti ne šalju ili je bežični kanal u stanju
OFF. To za klijenta u simulaciji znači da ne prima nikakve segmente jer su svi poslani
29
segmenti izgubljeni u bežičnom kanalu na putu do odredišta, npr trenuci simulacije od t = 790
ms do t = 2209 ms (Sl. 3-7). Nastavak slanja novih segmenata uvjetovan je stanjem u mreži i
na opisani način provodi se kontrola toka. Naime kako je ranije opisano i potvrdni segmenti
izloženi su gubicima u bežičnom kanalu, tada su svi segmenti koji se šalju izgubljeni i ovaj
slučaj u stvarnoj mreži nastupa samo kod izrazito izraženog fadinga odnosno iznenadnih i
snažnih propada radio signala.
0
50
100
150
200
250
300
0 2000 4000 6000 8000 10000
Vrijeme [ms]
CW
ND
[okt
et]
Sl. 3-8 Tahoe TCP – veličina prozora zagušenja
Slika (Sl. 3-9) prikazuje iznos propusnosti o vremenu uz napomenu da se razmatra protokol
TCP Reno i to samo radi usporedbe. Uočava se nešto bolja karakteristika grafa propusnosti
nego za slučaj Tahoe TCP. To se dešava zbog novog algoritma koji uvodi TCP Reno, a to je
algoritam ubrzanog oporavka (engl. fast recovery). Pomoću 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 zagušenja. Tako se efikasnije koriste
mrežni resursi jer se ne troši vrijeme na čekanje isteka vremenske kontrole, a vrijednost
veličine prozora zagušenja ne smanjuje se na 1 segment nego na polovicu čime je omogućen
brzi oporavak veze nakon gubitaka pojedinačnih segmenata, (Stevens [1995]).
Na kraju rada valja spomenuti još jednu manjkavost protokola TCP-snoop, a to je slučaj kada
je na pristupnu točku vezan veći broj bežičnih klijenata. Osobito je to izraženo za slučaj
istovremenog slanja veće količine podataka poslužitelju (engl. upload) kada je snoop modul
aktivan.
30
0
1
2
3
4
5
6
7
8
0 1000 2000 3000 4000 5000 6000
Vrijeme [ms]
Pro
pusn
ost
[se
gm
ent/m
s]
Sl. 3-9 Reno TCP - graf propusnosti na klijentskoj strani
Tada se zauzima više prijenosnog pojasa (engl. bandwith) u bežičnom kanalu zbog
retransmisija segmenata i zauzeće medija od pojedinog klijenta se produžuje, (Ho Ng et al.
[1997]). Međutim, ovakav slučaj rijetko nastupa, a postoje i posebni programski alati i
protokoli koji omogućuju i ispravljaju navedeni nedostatak protokola TCP-snoop.
31
Zaključak
Protokol TCP kao temeljni transportni protokol neizbježan je u svijetu modernih
komunikacijskih tehnologija. Bežične mreže danas zauzimaju sve veći postotak kao
najprihvatljivije i najisplativije rješenje vezano uz prijenos informacije. Osobito to dolazi do
izražaja u uvjetima kada instalacija žične infrastrukture nije moguća ili neisplativa. Svakim
danom javljaju se novi IEEE 802.11x standardi vezani uz WLAN-ove koji sa sobom donose i
nove usluge za korisnika.
Današnji WLAN-ovi uglavnom se ostvaruju kao bežične mreže s radioprijenosom i koriste
tehniku proširenog spektra DSSS (engl. Direct Sequence Spread Spectrum) na fizičkom sloju.
Naravno, za pouzdani prijenos podataka koristi se protokol TCP, ali u raznim inačicama
opisanim u radu. Najbitnija prednost protokola TCP je u prilagodljivosti koju posjeduje za
različite prijenosne sustave. Međutim neki njegovi temeljni principi nisu prilagođeni za rad u
bežičnom okruženju. Razlog tome su veliki gubici koji nastaju u bežičnom kanalu. Upravo
zato uvode se poboljšanja namijenjena isključivo radu protokola TCP u WLAN-u. U radu je
detaljno opisana jedna od takvih inačica protokola TCP, a to je TCP-snoop. Analiza samog
protokola TCP-snoop napravljena je koristeći vlastiti simulator razvijen u programskom
jeziku Java. Upravo je taj protokol u raznim radovima naveden kao najprihvatljivije rješenje
za WLAN-ove, (Vangala et al. [2002]). Kada se kaže najprihvatljivije, onda se misli na
performanse i isplativost rješenja. Protokol Tahoe TCP bio je predmet promatranja u radu sa i
bez snoop modula u pristupnoj točki. Isti na gubitke reagira smanjenjem veličine prozora i
manjim brojem segmenata koje pošiljatelj može poslati u jedinici vremena. S obzirom da
protokol TCP-snoop djeluje ispod transportnog sloja on ne pokreće algoritme kontrole
zagušenja. 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 bežičnom kanalu.
Simulacije izvedene u radu pokazale su neka od poboljšanja koja protokol TCP-snoop unosi
u poboljšanje rada protokola TCP u bežičnoj okolini. Prvenstveno se ta poboljšanja odnose na
činjenicu da nema smanjenja veličine prozora zagušenja na strani pošiljatelja u slučaju
gubitka segmenata i na to da se od pošiljatelja ''sakriju'' gubici nastali u bežičnom kanalu.
32
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.
[2] STEVENS, W.R. 1995. TCP/IP Illustrated: The protocols, Volume 1.Adisson Wesley Longman Inc.
[3] 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.
[4] 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.
[5] XYLOMENOS, G. POLYZOS, G. SAARANEEN, M. 2001. TCP Performance Issues over Wireless Links.IEEE Communications Magazine, Volume 39, pp. 52 - 58.
[6] ELAARAG, H. 2002. Improving TCP Performance over Mobile Networks. ACM Computing Surveys, Vol. 34, pp. 357 – 374, November 2002.
[7] SCHILLER, J. 2003. Mobile Communications 2nd edition.Adisson Wesley Inc.
[8] 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.
[9] 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.
[10] BAŽANT, A. i dr. 2003. Osnovne arhitekture mreža. Element, Zagreb.
[11] KRALJ, Z. 2003. Tehnike upravljanja zagušenjem u bežičnim lokalnim mrežama. Diplomski rad, ZZT – FER, Zagreb.
33
Skraćenice
ARQ Automatic Repeat reQuest
ATM Asynchronous Transfer Mode
BER Bit Error Ratio
BER Bit Error Ratio
B-ISDN Broadband ISDN
CRC Cyclic Redudancy Check
DSSS Direct Sequence Spread Spectrum
EBSN Explicit Bad State Notification
FDDI Fiber Distributed Data Interface
FEC Forward Error Corection
GBN Go-Back-N
GUI Graphical User Interface
HIPPI High Performance Parallel Interface
IP Internet Protocol
ISDN Integrated Services Digital Network
I-TCP Indirect TCP
MSS Maximum Segment Size
MTCP Mobile Host TCP
MTU Maximum Transfer Unit
OSI Open System Interconnection
PEP Performance Enhancing Proxy
PSTN Public Switched Telephone Network
QoS Quality of Service
RFC Request for Comments
RLP Radio Link Protocol
RTO Retransmission TimeOut
RTT Round Trip Time
SACK Selective Acknowledgement
TCP Transmission Control Protocol
WAP Wireless Application Protocol
WLAN Wireless Local Area Network
WMAN Wireless Metropolitan Area Network
34
Popis stranih izraza
ad hoc nezavisan, samostalan
bandwith širina prijenosnog pojasa
beacon poruka, zraka
bottleneck usko grlo
burst snop
congestion avoidance izbjegavanje zagušenja
congestion window prozor zagušenja
downlink dolazni smjer
end to end s kraja na kraj
engine jezgra simulatora
fast recovery ubrzani oporavak
fast retransmission ubrzano ponovno slanje
handoff prelaženje, prekapčanje
idle time vrijeme neaktivnosti
jitter kolebanje kašnjenja
link layer sloj linka
multicast višeodredišno razašiljanje
multipath propagation višestazno rasprostiranje signala
router usmjerivač
slow start spori start
splitting connection razdvajanje konekcije
three-way handshake trostruko rukovanje
throughput propusnost
uplink odlazni smjer
wireless link bežični link
35
Dodatak
Upute za korištenje programske podrške
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 grafičko sučelje u kojem korisnik unosi željene
parametre potrebne za simulaciju. Sama simulacija pokreće se klikom na dugme ''Start''. Po
završetku simulacije vidi se ispis događaja u Command prompt-u a u samom grafičkom
sučelju neki bitni podaci vezani uz simulaciju kako je prikazano slikom (Sl. 3-1). Treba
naglasiti da ovo vrijedi za slučaj kada je projekt već preveden (engl. compile) tj. postoje
.class datoteke za pojedine klase. Ukoliko to nije slučaj potrebno je prvo program prevesti u
byte codove (datoteke s ekstenzijom .class) i to pomoću naredbe javac.
Slika (Sl. 1) predočava internu blok-shemu simulatora i prikaz komunikacijskih ruta između
pojedinih objekata u simulaciji
Sl. 1 Arhitektura TCP-snoop simulatora
Primjer konfiguracije .bat skripte koja služi za pokretanje simulatora:
@ECHO OFF
java -cp C:\temp\TCPSnoop hr.fer.tel.jaksic.Engine
pause
Slijedi prikaz dijela događaja koji se ispisuju u konzolu:
Server: ESTABLISHED - Sending Data Segment Download burst length = 23 Download state = 0 // ON state of wireless channel
36
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