UNIVERZITET U BEOGRADU ELEKTROTEHNIČKI FAKULTET

STANISLAV MIŠKOVIĆ

SIMULACIONO ISPITIVANJE PERFORMANSI TCP TEHNIKA KONTROLE ZAGUŠENJA U SLOJU

TRANSPORTA

MAGISTARSKA TEZA

MENTORI

Prof Grozdan Petrović Elektrotehnički fakultet Univerzitet u Beogradu

Prof Ljiljana Trajković School of Engineering Science

Simon Fraser University Canada

Beograd 2004 godine

Svima koji su neprestano ohrabrivali rad na ovoj tezi

u teškim trenucima nedoumice i

u vremenu kada su ideje postale stvarnost

Posebnu zahvalnost dugujem onima

čija me je vera uvek vodila

svojim roditeljima i

prof Grozdanu Petroviću

Stanislav Mišković

Sadržaj Lista slika iLista tabela i i i1 Uvod 1

11 Predmet teze 112 Organizacija izlaganja 1

2 Pregled TCP protokola i AQM tehnika 321 Osnovna svojstva Internet okruženja 322 Funkcije TCP protokola 323 Kontrola zagušenja procenom RTO intervala 424 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora 6

241 Slow Start i Congestion Avoidance 6242 Fast Retransmit i Fast Recovery 8243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem 9

25 NewReno 926 SACK 1027 Aktivno upravljanje redovima za čekanje (AQM) 1128 Slučajna preventivna detekcija ndash RED 1329 Eksplicitno obaveštenje o zagušenju ndash ECN 15

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja 1831 TCP model 1832 RTO estimacija 1833 TCP prozori 1934 TCP-prijateljsko ponašanje 2035 Primena zaštitnog kodovanja 2036 TCP protokol u bežičnim mrežama 2137 RED i ECN 2138 Analiza slične ciljevima ove teze 22

4 Postavke simulacije 2441 Načini proučavanja protokola 2442 NS-2 simulator 2443 Implementacija test scenarija 2644 Ciljevi proučavanja i posmatrane metrike performansi 26

441 TCP metrike 27442 RED i Drop Tail metrike 28

45 Opis test scenarija 28

5 Rezultati testova 3151 Performanse iskorišćenja mrežnih resursa 31

511 Testovi sa dva TCP toka 31512 Testovi sa šest TCP tokova 35513 Testovi sa osamnaest TCP tokova 37

514 Performanse iskorišćenja mrežnih resursa ndash zaključak 4052 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova 41

521 Pravičnost dve TCP konekcije 41522 Pravičnost u složenijim scenarijima 42523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti 46524 Pravičnost ndash zaključak 47

53 Uticaji razlike kašnjenja 49531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa 49532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK

konekcija 50533 Uticaji razlike kašnjenja - zaključak 52

54 Testovi na topologiji sa dva linka uskog grla 53541 Performanse iskorišćenja mrežnih resursa 53542 Ravnopravnost NewReno+ECN i SACK mehanizama 56543 Testovi na topologiji sa dva linka uskog grla ndash zaključak 56

6 Zaključak teze 57Dodatak A ndash Svojstva multifraktalnog saobraćaja 58Dodatak B ndash Promenljivi parametri testova 60Skraćenice 62Literatura 63

i

Lista slika

sl21 Prijem segmenta u izmenjenom redosledu 4

sl22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije 4

sl23 Odnos procena RTT i RTO vrednosti 5

sl24 Ilustracija samo-sinhronizacije potvrdama 6

sl25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora 7

sl26 Eksponencijalno cwnd uvećanje u toku slow start faze 7

sl27 Ilustracija ponašanja veličine cwnd 9

sl28 Parcijalni ACK10

sl29 TCP opcije za SACK 10

sl210 Primer SACK konekcije 11

sl211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s (c) 001s 12

sl212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora13

sl213 Ilustracija RED algoritma 14

sl214 Ponašanje RED algoritma14

sl215 RED modifikacije (a) gentle RED (b) adaptive RED15

sl 216 ECN markiranje 15

sl217 ECN u ToS polju IP zaglavlja16

sl218 ECN bitovi CWR i ECE u TCP zaglavlju 16

sl219 Uspostava TCP konekcije (a) obe strane podržavaju ECN (b) prijemnik ne podržava ECN (ECN se ne uspostavlja) 16

sl41 Prikaz ns-2 hijerarhije objekata 25

sl42 Test platforma korišćena u ovoj tezi27

sl43 (a) Topologija net10 (b) topologija netMultiC 28

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL32

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera32

sl 53 Dve TCP konekcije - Promena prozora zagušenja (cwnd) (a) RED (b) DropTail 33

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 34

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera35

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera36

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 36

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera37

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

Svima koji su neprestano ohrabrivali rad na ovoj tezi

u teškim trenucima nedoumice i

u vremenu kada su ideje postale stvarnost

Posebnu zahvalnost dugujem onima

čija me je vera uvek vodila

svojim roditeljima i

prof Grozdanu Petroviću

Stanislav Mišković

Sadržaj Lista slika iLista tabela i i i1 Uvod 1

11 Predmet teze 112 Organizacija izlaganja 1

2 Pregled TCP protokola i AQM tehnika 321 Osnovna svojstva Internet okruženja 322 Funkcije TCP protokola 323 Kontrola zagušenja procenom RTO intervala 424 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora 6

241 Slow Start i Congestion Avoidance 6242 Fast Retransmit i Fast Recovery 8243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem 9

25 NewReno 926 SACK 1027 Aktivno upravljanje redovima za čekanje (AQM) 1128 Slučajna preventivna detekcija ndash RED 1329 Eksplicitno obaveštenje o zagušenju ndash ECN 15

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja 1831 TCP model 1832 RTO estimacija 1833 TCP prozori 1934 TCP-prijateljsko ponašanje 2035 Primena zaštitnog kodovanja 2036 TCP protokol u bežičnim mrežama 2137 RED i ECN 2138 Analiza slične ciljevima ove teze 22

4 Postavke simulacije 2441 Načini proučavanja protokola 2442 NS-2 simulator 2443 Implementacija test scenarija 2644 Ciljevi proučavanja i posmatrane metrike performansi 26

441 TCP metrike 27442 RED i Drop Tail metrike 28

45 Opis test scenarija 28

5 Rezultati testova 3151 Performanse iskorišćenja mrežnih resursa 31

511 Testovi sa dva TCP toka 31512 Testovi sa šest TCP tokova 35513 Testovi sa osamnaest TCP tokova 37

514 Performanse iskorišćenja mrežnih resursa ndash zaključak 4052 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova 41

521 Pravičnost dve TCP konekcije 41522 Pravičnost u složenijim scenarijima 42523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti 46524 Pravičnost ndash zaključak 47

53 Uticaji razlike kašnjenja 49531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa 49532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK

konekcija 50533 Uticaji razlike kašnjenja - zaključak 52

54 Testovi na topologiji sa dva linka uskog grla 53541 Performanse iskorišćenja mrežnih resursa 53542 Ravnopravnost NewReno+ECN i SACK mehanizama 56543 Testovi na topologiji sa dva linka uskog grla ndash zaključak 56

6 Zaključak teze 57Dodatak A ndash Svojstva multifraktalnog saobraćaja 58Dodatak B ndash Promenljivi parametri testova 60Skraćenice 62Literatura 63

i

Lista slika

sl21 Prijem segmenta u izmenjenom redosledu 4

sl22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije 4

sl23 Odnos procena RTT i RTO vrednosti 5

sl24 Ilustracija samo-sinhronizacije potvrdama 6

sl25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora 7

sl26 Eksponencijalno cwnd uvećanje u toku slow start faze 7

sl27 Ilustracija ponašanja veličine cwnd 9

sl28 Parcijalni ACK10

sl29 TCP opcije za SACK 10

sl210 Primer SACK konekcije 11

sl211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s (c) 001s 12

sl212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora13

sl213 Ilustracija RED algoritma 14

sl214 Ponašanje RED algoritma14

sl215 RED modifikacije (a) gentle RED (b) adaptive RED15

sl 216 ECN markiranje 15

sl217 ECN u ToS polju IP zaglavlja16

sl218 ECN bitovi CWR i ECE u TCP zaglavlju 16

sl219 Uspostava TCP konekcije (a) obe strane podržavaju ECN (b) prijemnik ne podržava ECN (ECN se ne uspostavlja) 16

sl41 Prikaz ns-2 hijerarhije objekata 25

sl42 Test platforma korišćena u ovoj tezi27

sl43 (a) Topologija net10 (b) topologija netMultiC 28

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL32

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera32

sl 53 Dve TCP konekcije - Promena prozora zagušenja (cwnd) (a) RED (b) DropTail 33

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 34

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera35

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera36

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 36

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera37

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

Sadržaj Lista slika iLista tabela i i i1 Uvod 1

11 Predmet teze 112 Organizacija izlaganja 1

2 Pregled TCP protokola i AQM tehnika 321 Osnovna svojstva Internet okruženja 322 Funkcije TCP protokola 323 Kontrola zagušenja procenom RTO intervala 424 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora 6

241 Slow Start i Congestion Avoidance 6242 Fast Retransmit i Fast Recovery 8243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem 9

25 NewReno 926 SACK 1027 Aktivno upravljanje redovima za čekanje (AQM) 1128 Slučajna preventivna detekcija ndash RED 1329 Eksplicitno obaveštenje o zagušenju ndash ECN 15

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja 1831 TCP model 1832 RTO estimacija 1833 TCP prozori 1934 TCP-prijateljsko ponašanje 2035 Primena zaštitnog kodovanja 2036 TCP protokol u bežičnim mrežama 2137 RED i ECN 2138 Analiza slične ciljevima ove teze 22

4 Postavke simulacije 2441 Načini proučavanja protokola 2442 NS-2 simulator 2443 Implementacija test scenarija 2644 Ciljevi proučavanja i posmatrane metrike performansi 26

441 TCP metrike 27442 RED i Drop Tail metrike 28

45 Opis test scenarija 28

5 Rezultati testova 3151 Performanse iskorišćenja mrežnih resursa 31

511 Testovi sa dva TCP toka 31512 Testovi sa šest TCP tokova 35513 Testovi sa osamnaest TCP tokova 37

514 Performanse iskorišćenja mrežnih resursa ndash zaključak 4052 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova 41

521 Pravičnost dve TCP konekcije 41522 Pravičnost u složenijim scenarijima 42523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti 46524 Pravičnost ndash zaključak 47

53 Uticaji razlike kašnjenja 49531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa 49532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK

konekcija 50533 Uticaji razlike kašnjenja - zaključak 52

54 Testovi na topologiji sa dva linka uskog grla 53541 Performanse iskorišćenja mrežnih resursa 53542 Ravnopravnost NewReno+ECN i SACK mehanizama 56543 Testovi na topologiji sa dva linka uskog grla ndash zaključak 56

6 Zaključak teze 57Dodatak A ndash Svojstva multifraktalnog saobraćaja 58Dodatak B ndash Promenljivi parametri testova 60Skraćenice 62Literatura 63

i

Lista slika

sl21 Prijem segmenta u izmenjenom redosledu 4

sl22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije 4

sl23 Odnos procena RTT i RTO vrednosti 5

sl24 Ilustracija samo-sinhronizacije potvrdama 6

sl25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora 7

sl26 Eksponencijalno cwnd uvećanje u toku slow start faze 7

sl27 Ilustracija ponašanja veličine cwnd 9

sl28 Parcijalni ACK10

sl29 TCP opcije za SACK 10

sl210 Primer SACK konekcije 11

sl211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s (c) 001s 12

sl212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora13

sl213 Ilustracija RED algoritma 14

sl214 Ponašanje RED algoritma14

sl215 RED modifikacije (a) gentle RED (b) adaptive RED15

sl 216 ECN markiranje 15

sl217 ECN u ToS polju IP zaglavlja16

sl218 ECN bitovi CWR i ECE u TCP zaglavlju 16

sl219 Uspostava TCP konekcije (a) obe strane podržavaju ECN (b) prijemnik ne podržava ECN (ECN se ne uspostavlja) 16

sl41 Prikaz ns-2 hijerarhije objekata 25

sl42 Test platforma korišćena u ovoj tezi27

sl43 (a) Topologija net10 (b) topologija netMultiC 28

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL32

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera32

sl 53 Dve TCP konekcije - Promena prozora zagušenja (cwnd) (a) RED (b) DropTail 33

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 34

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera35

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera36

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 36

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera37

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

514 Performanse iskorišćenja mrežnih resursa ndash zaključak 4052 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova 41

521 Pravičnost dve TCP konekcije 41522 Pravičnost u složenijim scenarijima 42523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti 46524 Pravičnost ndash zaključak 47

53 Uticaji razlike kašnjenja 49531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa 49532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK

konekcija 50533 Uticaji razlike kašnjenja - zaključak 52

54 Testovi na topologiji sa dva linka uskog grla 53541 Performanse iskorišćenja mrežnih resursa 53542 Ravnopravnost NewReno+ECN i SACK mehanizama 56543 Testovi na topologiji sa dva linka uskog grla ndash zaključak 56

6 Zaključak teze 57Dodatak A ndash Svojstva multifraktalnog saobraćaja 58Dodatak B ndash Promenljivi parametri testova 60Skraćenice 62Literatura 63

i

Lista slika

sl21 Prijem segmenta u izmenjenom redosledu 4

sl22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije 4

sl23 Odnos procena RTT i RTO vrednosti 5

sl24 Ilustracija samo-sinhronizacije potvrdama 6

sl25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora 7

sl26 Eksponencijalno cwnd uvećanje u toku slow start faze 7

sl27 Ilustracija ponašanja veličine cwnd 9

sl28 Parcijalni ACK10

sl29 TCP opcije za SACK 10

sl210 Primer SACK konekcije 11

sl211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s (c) 001s 12

sl212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora13

sl213 Ilustracija RED algoritma 14

sl214 Ponašanje RED algoritma14

sl215 RED modifikacije (a) gentle RED (b) adaptive RED15

sl 216 ECN markiranje 15

sl217 ECN u ToS polju IP zaglavlja16

sl218 ECN bitovi CWR i ECE u TCP zaglavlju 16

sl219 Uspostava TCP konekcije (a) obe strane podržavaju ECN (b) prijemnik ne podržava ECN (ECN se ne uspostavlja) 16

sl41 Prikaz ns-2 hijerarhije objekata 25

sl42 Test platforma korišćena u ovoj tezi27

sl43 (a) Topologija net10 (b) topologija netMultiC 28

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL32

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera32

sl 53 Dve TCP konekcije - Promena prozora zagušenja (cwnd) (a) RED (b) DropTail 33

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 34

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera35

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera36

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 36

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera37

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

i

Lista slika

sl21 Prijem segmenta u izmenjenom redosledu 4

sl22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije 4

sl23 Odnos procena RTT i RTO vrednosti 5

sl24 Ilustracija samo-sinhronizacije potvrdama 6

sl25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora 7

sl26 Eksponencijalno cwnd uvećanje u toku slow start faze 7

sl27 Ilustracija ponašanja veličine cwnd 9

sl28 Parcijalni ACK10

sl29 TCP opcije za SACK 10

sl210 Primer SACK konekcije 11

sl211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s (c) 001s 12

sl212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora13

sl213 Ilustracija RED algoritma 14

sl214 Ponašanje RED algoritma14

sl215 RED modifikacije (a) gentle RED (b) adaptive RED15

sl 216 ECN markiranje 15

sl217 ECN u ToS polju IP zaglavlja16

sl218 ECN bitovi CWR i ECE u TCP zaglavlju 16

sl219 Uspostava TCP konekcije (a) obe strane podržavaju ECN (b) prijemnik ne podržava ECN (ECN se ne uspostavlja) 16

sl41 Prikaz ns-2 hijerarhije objekata 25

sl42 Test platforma korišćena u ovoj tezi27

sl43 (a) Topologija net10 (b) topologija netMultiC 28

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL32

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera32

sl 53 Dve TCP konekcije - Promena prozora zagušenja (cwnd) (a) RED (b) DropTail 33

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 34

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera35

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera36

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 36

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera37

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

ii

sl59 Osamnaest TCP konekcija Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED 38

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla39

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED39

sl 512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija43

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) šest TCP tokova i (b) osamnaest TCP tokova 44

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera 44

sl515 Agresivni gentle RED 18 TCP konekcija (a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03) 46

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija 47

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt50

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL=48pkt (b) QL=200pkt 52

sl519 Topologija netMultiC53

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije55

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

iii

Lista tabela

Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost 41

Tabela 52 Dve TCP konekcije - Uticaj RED +ECN mehanizama na pravičnost 41

Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost 42

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem 49

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem 50

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa konekcija u testovima sa različitim kašnjenjem 51

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji 54

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji 54

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC 55

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji 56

Tabela 511 27 TCP konekcija Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji 56

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

1

1 Uvod TCP protokol sloja transporta referentnog OSI modela je sačinjen kao pouzdan konekcijski orijentisan protokol opšte namene Procenjuje se da TCP rukovodi najvećim delom (oko 90) današnjeg Internet saobraćaja Praktična upotreba je pokazala da je protokol sposoban da podrži širok spektar aplikacija (HTTP FTP SMTP ) kao i izuzetnu heterogenost mrežnih mehanizama i arhitektura Stalni i nagli razvoj Interneta uslovljava neprestano unapređivanje i istraživanje ponašanja ovog protokola Rad u toj oblasti poseduje mnoge zahteve i ograničenja Pre konačne implementacije sva predložena poboljšanja se moraju detaljno ispitati u najrazličitijim okruženima i test scenarijima Distribuiranost širokih razmera nalaže da se čak i izuzetna poboljšanja dokazana na uskom opsegu scenarija ne razmatraju kao ozbiljna Postojeće stanje mreže zahteva da novi predlozi budu i inetroperabilni i efikasniji u odnosu na postojeće dominantne TCP verzije Konačno RFC preporuke postavljaju granice ponašanja za TCP implementacije

11 Predmet teze Ciljevi ovog rada su višestruki Polazni aspekat istraživanja je uspostavljanje dovoljno realne test platforme Raznolikost koja predstavlja osnovu distribuiranih sistema će biti uspostavljena na više slojeva OSI modela Testovi će se obaviti na nekoliko topologija sa različitim brojem aktivnih čvorova i konekcija Očekuje se da će se na taj način steći uvid u skalabilnost i konzistentnost ponašanja ispitivanih mehanizama

Na sloju mreže će se ispitivati saradnja tehnika aktivnog upravljanja redovima za čekanje (engl Active Queue Management AQM) sa mehanizmima kontrole zagušenja TCP protokola Konkretno biće proučna efikasnost i osetljivost na podešavanje parametara dva AQM mehanizma nazvana gentle RED i adaptive RED Na sloju transporta će se ispitivati pravičnost i efikasnost NewReno i SACK implementacija TCP protokola Više različitih TCP varijanti će u pojedinim scenarijima biti prisutno u topologiji kako bi se ispitala njihova interoperabilnost U testovima će biti prisutan i UDP tok čiji je saobraćaj neosetljiv na promene stanja u mreži usled zagušenja

Glavni doprinos ovog rada je razvoj metodologije ispitivanja Internet protokola i detaljna komparativna analiza savremenih TCP i AQM mehanizama Krajnji rezultati bi trebalo da daju uvid u sledeća pitanja

- Kakav je odnos performansi SACK i NewReno implementacija TCP protokola

- Kako se ove dve TCP modifikacije ponašaju pri različitim kašnjenjima prisustvu nekontrolisanih tokova i grešaka

- Kako se SACK i NewReno ponašaju kada su na određenoj putanji jednako zastupljeni i kada je njihova zastupljenost različita

- Kakve su performanse NewReno implementacije sa podrškom za ECN u odnosu na SACK implementaciju

- Da li gentle RED i adaptive RED varijante poseduju preosetljivost na parametre koju u nekim slučajevima ispoljava RED mehanizam

- Kakvi se efekti mogu pojaviti na granici između rutera sa podrškom za AQM i ruterа koji ne podržava AQM

- Postoji li kombinacija TCP i AQM mehanizama koja ispoljava optimalno ponašanje u širokom spektru parametara realnog okruženja

12 Organizacija izlaganja Teza je izložena u šest poglavlja Poglavlje 1 predstavlja kratak uvod koji navodi zastupljenost TCP saobraćaja na Internetu potrebu za stalnim istraživanjem svojstava protokola i konačno ciljeve i doprinos ove teze

Poglavlje 2 predstavlja detaljan pregled standarda i teorije TCP protokola i AQM mehanizama Na početku poglavlja je objašnjeno zašto Internet može postati izuzetno zanimljiv za široki opseg istraživanja Opisan je IP servis najboljeg pokušaja i uloga TCP protokola u formiranju pouzdanog servisa na IP platformi Zatim su

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

2

detaljno opisani mehanizmi kontrole zagušenja merenjem RTO intervala i upravljanjem veličinom prozora Nakon toga su opisane NewReno i SACK modifikacije TCP protokola Porast Interneta je uslovio uvođenje mehanizama kontrole zagušenja u sloj mreže OSI modela Tako je nastao koncept aktivnog upravljanja redovima za čekanje (engl active queue management AQM) U preostalom delu poglavlja je opisan AQM mehanizam slučajne preventivne detekcije (engl random early detection RED) i njegove varijante gentle RED i adaptive RED koje će biti ispitane u ovoj tezi Na kraju poglavlja je opisan ECN mehanizam koji predstavlja most između kontrole zagušenja na sloju mreže i sloju transporta OSI modela

Poglavlje 3 je osvrt na radove koji predstavljaju smernice unapređenja i ispitivanja TCPAQM platforme Navedene su neke oblasti koje nisu u direktnoj vezi sa ciljem istraživanja ove teze npr okvir TCP prijateljskog ponašanja uvođenje zaštitnog kodovanja na sloju transporta i ponašanje TCP protokola u bežičnim mrežama Time je postignut širi uvid u moguće polje istraživanja TCP protokola Preostali deo poglavlja 3 opisuje unapređenja i dosadašnja istraživanja u neposrednoj vezi sa predmetom ove teze

U poglavlju 4 je opisana metodologija ispitivanja Internet protokola Zatim su ukratko opisani neophodni detalji funkcionisanja ns-2 simulatora njegova ograničenja i način upotrebe pri ispitivanju TCP i AQM mehanizama Nakon toga su navedene posmatrane metrike performansi koje su praćene u ovoj tezi Konačno je naveden prikaz test platforme i opis test scenarija

U poglavlju 5 su navedeni rezultati testova Ispitivanja su obavljena na različitim topologijama različitom broju aktivnih konekcija različitim TCP mehanizmima i AQM tehnikama i različitim uslovima kašnjenja pojedinih konekcija

U poglavlju 6 su izloženi zaključak teze i smernice za dalji rad

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

3

2 Pregled TCP protokola i AQM tehnika 21 Osnovna svojstva Internet okruženja U poslednjih nekoliko godina Internet se znatno proširio Nove aplikacije razvoj sigurnosnih mehanizama otvaranje perspektiva mrežnog poslovanja rad na potpuno novim konceptima Internet arhitekture i stalno unapređivanje protokola su garancije da će Internet nastaviti da raste i privlači nove korisnike Ovakvo okruženje se sa pravom može nazvati najizazovnijim poljem za razvoj i istraživanje širokog spektra problema Rad u ovoj oblasti je specifičan jer postoji veoma malo svojstava za koje bi se moglo pretpostaviti da su nepromenljiva Stoga se kaže da je Internet ldquopokretna metardquo

Osnova današnjeg Interneta je paketski prenos zasnovan na TCPIP skupu protokola Iz perspektive sloja mreže saobraćaj se prenosi IP protokolom koji pruža servis najboljeg pokušaja (engl best effort) bez uspostave konekcije (engl connectionless CL) Takav prenos informacija omogućuje izuzetnu efikasnost Paketi mogu da koriste sav raspoloživi kapacitet mreže na svom putu do odredišta Komutacija paketa je veoma fleksibilna odn paketi različitih konekcija mogu da dele iste putanje i dostupan propusni opseg Još jedna prednost je robusnost pa se paketi lako preusmeravaju sa preopterećenih ili nedostupnih linkova i čvorova mreže

Ovakvo rešenje na sloju mreže ima cenu Mogućnost korišćenja različitih putanja za istu konekciju dovodi do promenljivog kašnjenja i promene redosleda paketa na putu do odredišta U servisu najboljeg pokušaja ne postoji rezervacija resursa pa je moguće odbacivanje paketa u slučaju nailaska na pune bafere komutacionih uređaja Na fizičkom sloju takođe postoji mogućnost nasumičnog odbacivanja paketa usled lošeg stanja linkova Danas se koriste dve klase kontrolnih arhitektura sa kraja na kraj za stvaranje pouzdanog servisa na IP platformi Jedno rešenje podrazumeva kontrolu na sloju transporta korišćenjem TCP protokola opšte namene Statistike pokazuju da se najveći deo saobraćaja na Internetu prenosi na ovaj način Drugo rešenje je izrada sopstvenih kontrolnih mehanizama na sloju aplikacije uz korišćenje UDP protokola na sloju transporta Popularnost takvog pristupa je porasla sa idejom o prenosu objedinjenih servisa preko Interneta UDP pored tradicionalnih servisa danas prenosi i saobraćaj aplikacija osetljivih na varijacije kašnjenja

TCPIP skup protokola je uz svoja unapređenja uspeo da se održi kao dominantno rešenje preko dvadeset godina Glavni razlog uspeha je prilagodljivost njegovih protokola otvorenost standarda koji ih definišu i spremnost IETF (Internet Engineering Task Force) [IETForg] organizacije da dovoljno brzo kreira i usvaja neophodne promene TCP mora da obezbedi pouzdan servis Da bi obavio tu funkciju on mora da proceni stanje mreže koja se u poslednjih dvadeset godina uvećala od POTS modemskih komunikacija do optičkih i satelitskih prenosa Upravo iz tog razloga se može reći da je održanje TCP protokola tokom pomenutog perioda fascinantno Svi TCP mehanizmi za estimaciju stanja mreže pripadaju mehanizmu kontrole zagušenja koji je glavni predmet ovog rada Pored prilagođenja topologiji TCP je uspeo da ostvari dovoljno dobre performanse za isporuku podataka najširem sloju aplikacija i protokola viših slojeva OSI modela

22 Funkcije TCP protokola TCP je transportni protokol koji nudi pouzdan konekcijski orijentisan servis sa kraja na kraj [RFC793] Osnovne jedinice podataka ovog protokola su segmenti Svakom bajtu unutar segmenta se dodeljuje jedinstveni broj sekvence Prijemnik u toku razmene segmenata šalje kumulativne pozitivne potvrde (ACK) Svaki ACK u sebi nosi naredni broj sekvence kojeg odredište očekuje da primi u kontinuitetu odn ACK koji potvrđuje segment n potvrđuje i sve segmente pre njega Postoji mogućnost da segmenti ne stignu do odredišta u pravilnom redosledu U tom slučaju standard definiše da je prijemnik obavezan da generiše tzv ACK duplikat koji je identičan prethodno poslatom ACK-u (sl21) TCP poseduje mogućnost rada u režimu punog dupleksa

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

4

sl 21 Prijem segmenta u izmenjenom redosledu

TCP omogućuje pouzdan prenos korišćenjem mehanizama

bull kontrolnih suma

bull kontrole protoka

bull kontrole zagušenja

Kontrola protoka se bazira na numerisanju segmenata potvrdama klizećem prozoru i mehanizmu ldquovrati se za nrdquo Kontrola zagušenja koristi kontrolu protoka dodajući mehanizme za procenu stanja mreže odn procenu vremena obilaska (engl Round Trip Time RTT) i upravljanje veličinom klizećeg prozora (cwnd) Broj stanja kontrole zagušenja i njihovo ponašanje su se menjali u skladu sa razvojem TCP protokola TCP Reno je dugo bio dominantna TCP implementacija i posedovao je četiri stanja slow start congestion avoidance fast retransmit i fast recovery NewReno i SACK koji će biti detaljno ispitani u ovom radu su modifikacije Reno verzije TCP protokola

Kontrola zagušenja počinje da deluje u toku uspostave TCP konekcije Tada se u procesu trostrukog rukovanja (engl three-way handshake) razmenjuju inicijalni podaci za kontrolu zagušenja Jednostavan scenario uspostave konekcije je prikazan na sl22 Složenije uspostave su detaljno opisane u [Ste98] Svaka strana komunikacije u toku trostrukog rukovanja šalje svoj inicijalni broj sekvence veličinu prozora i najveću veličinu segmenta MSS koju je spremna da prihvati Odredište oglašava prozor rwnd koji odražava stanje prijemnog bafera odredišta a izvor oglašava inicijalni prozor IW koji po standardu ne sme biti veći od dva segmenta maksimalne veličina na strani izvora (2middotSMSS) Najveća veličina segmenta (MSS) se može odrediti na osnovu najveće jedinice slanja (MTU) ili na neki drugi način Korišćenje najveće MTU za odgovaraću putanju optimizuje efikasnost prenosa i upotrebu mrežnih resursa [RFC1191] definiše način za pronalaženje MTU vrednosti na odgovarajućoj putanji

sl 22 Podaci koji se razmenjuju u procesu uspostave TCP konekcije

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991

5

U intervalu trajanja konekcije izvor procenjuje zagušenje i na osnovu toga formira veličinu klizećeg prozora koji se u TCP terminologiji naziva prozor zagušenja cwnd Odredište i u toku konekcije nastavlja da oglašava rwnd Prozor veličine min (cwnd rwnd) rukovodi brojem segmenata koje izvor može poslati Svaka konekcija završava implicitnim ili eksplicitnim raskidanjem Implicitno raskidanje se obavlja pomoću tajmera praćenja aktivnosti (engl keepalive timer) Ovaj tajmer nije deo TCP specifikacije ali je prisutan u mnogim realnim implementacijama Detalji raskidanja konekcije su detaljno ilustrovani u [Ste98]

23 Kontrola zagušenja procenom RTO intervala Nakon otvaranja konekcije se aktivira RTO (engl retransmission timeout) mehanizam Stabilnost Interneta bitno zavisi od implementacije ovog mehanizma koji na početku funkcionisanja nailazi na potpuno nepoznato stanje mreže Da bi se sprečile učestale retransmisije segmenata preporučuje se da minimalna i početna RTO vrednost budu dovoljno velike (reda veličine sekunde) RTO estimacija se bazira na uzimanju uzoraka vremena obilaska (RTT) U današnjim implementacijama procene se obavljaju na osnovu prosečne RTT vrednosti (SRTT) i RTT varijacije (RTTVAR) (sl23)

sl 23 Odnos procena RTT i RTO vrednosti f(RTT) je gustina raspodele veličine RTT

Pri određivanju prve RTO procene standard preporučuje sledeći postupak

( ) 4max2

=sdot+larr

larr

larr

KRTTVARKGSRTTRTO

RRTTVAR

RSRTT

(21)

Vrednost R predstavlja prvu izmerenu RTT vrednost a G je fiksna vrednost granularnosti tajmera Kasnije RTO procene se obavljaju na sledeći način

( )( )

( ) 4 max1

41

811

=sdot+larr+minuslarr

==minus+minuslarr

KRTTVARKGSRTTRTORSRTTSRTT

RSRTTRTTVARRTTVAR

αα

βαββ

(22)

Vrednost parametra α određuje koliko će brzo SRTT moći da prati realnu RTT vrednost dok parametar β određuje interval RTT varijacije i poziciju RTO procene Ostali detalji implementacije su opisani u [RFC2988]

Pored jednačina za procenu RTO vrednosti bitan je i način uzimanja RTT odbiraka Procena RTO je u suštini odabiranje signala pozitivne vrednosti sa preklapanjem Preklapanje se može tolerisati do izvesnih granica jer RTO treba da bude procena gornje granice RTT vrednosti TCP konekcija mora izmeriti bar jedan RTT odbirak u toku procenjenog RTT intervala Pri tome se mora poštovati Karnov algoritam [KP87] koji navodi da se ne smeju uzimati RTT odbirci koji potiču od segmenata čije je slanje ponovljeno Karnov algoritam se ne mora koristiti ako se upotrebljavaju opcije vremenskih oznaka segmenata (engl timestamps) [RFC1323] koje otklanjaju dvosmislenost retransmisije [RFC1323] preporučuje da TCP konekcije koje koriste velike cwnd prozore (LFN Long Fat Networks) uzimaju nekoliko RTT odbiraka kako bi se izbeglo znatno preklapanje u spektru

6

RTO parametar je deo slow start mehanizma upravljanja cwnd prozorom Ako nova potvrda ne stigne unutar RTO intervala procena RTO tajmera se mora udvostručiti (engl back off) Udvostručenje RTO tajmera je bitan mehanizam pri pojavi naglih RTT promena Tako se sprečavaju sistematske greške u RTT estimaciji i nepotrebne retransmisije Učestalo ubacivanje segmenata u mrežu za koju se pretpostavlja da je zagušena bi rezultovalo kolapsom usled zagušenja (engl congestion collapse)

24 Mehanizmi kontrole zagušenja za upravljanje veličinom prozora U ovom radu će biti posvećena pažnja NewReno i SACK varijantama TCP protokola koje proističu iz Reno TCP implementacije Pored izbegavanja zagušenja upravljanje cwnd prozorom ima zadatak da postigne princip ldquokonzervacije paketardquo [JK88] odn stabilnu razmenu segmenata celom veličinom prozora Osnovna pretpostavka konzervacije paketa je samo-sinhronizacija potvrdama (engl ACK self- clocking)

Tb

Tb

I zvorpropusni

opseg

vreme

Odred ište

Tb Tb

Tb

Obradafiksnog trajanja

Obradafiksnog trajanja

podaci

potvrde

sl 24 Ilustracija samo-sinhronizacije potvrdama

Na sl24 je prikazan princip konzervacije paketa u idealnom slučaju funkcionisanja samo-sinhronizacije u jednom smeru Može primetiti da su ključni činioci ovog mehanizma propusni opseg i kašnjenja linkova Ove dve veličine određuju kapacitet linka Površina segmenata predstavlja broj bitova u segmentu i jednaka je proizvodu propusnog opsega i kašnjenja tog segmenta na datom linku Izvor šalje segmente u nizu (engl back-to-back) u skladu sa trenutnom cwnd vrednošću Kada se naiđe na usko grlo (engl bottleneck) broj bitova u segmentu ostaje nepromenjen pa će vreme slanja biti produženo Na sl24 je prikazano potpuno korišćenje resursa uskog grla na putanji podataka Segmenti na tom linku su razdvojeni minimalnim mogućim vremenskim intervalom Tb Baferisanje na prelazu sa užeg na širi propusni opseg čini da se Tb zadrži i na linkovima većeg propusnog opsega Ako se pretpostavi da odredište procesira pristigle segmente konstantnom brzinom interval Tb će predstavljati minimalno rastojanje i između ACK-ova Konačno kada ACK stigne do izvora moći će da se pošalju novi segmenti Tako je uspostavljena povratna sprega samo-sinhronizacije Proizvod propusnog opsega uskog grla i RTT kašnjenja (engl bandwidth delay product) u opštem slučaju određuje količinu podataka koja u potpunosti koristi raspoloživi kapacitet konekcije (engl fill the pipe) Ovaj parametar je izuzetno koristan za konfigurisanje kapaciteta bafera na putanji odgovarajuće konekcije 241 Slow start i Congestion Avoidance Graf prelaza stanja TCP kontrole zagušenja je prikazan na sl25 Da bi konekcija uspostavila idealni ekvilibrijum prikazan na sl24 mora se brzo doći do raspoloživih kapaciteta mreže To je osnovna uloga slow start mehanizma On se aktivira nakon uspostave TCP konekcije ili nakon isteka procenjenog RTO intervala

7

Slow Start

CongestionAvoidance

Fast Ret Fast Rec

novi ACK RTO

tri ACKduplikata

RTO

ACKduplikatnovi ACK

novi ACK

tri ACKduplikata

RTO

cwnd

gt ss

thres

h

sl 25 Graf prelaza stanja mehanizama za upravljanje veličinom prozora Suština sporog starta jeste postepeno utvrđivanje raspoloživog propusnog opsega mreže i uspostavljanje sinhronizacije potvrđivanja Standard definiše da u ovoj fazi cwnd može biti uvećan za maksimalno SMSS bajtova pri pojavi svakog novog ACK-a Ovaj rast je eksponencijalan pa se do raspoloživog propusnog opsega dolazi veoma brzo (sl26) O prelazu iz slow start faze u fazu congestion avoidance odlučuje vrednost ssthresh praga

fazu avoidance congestionu prelazssthresh cwnd fazastart slowssthresh cwnd

gtlt

(23)

Druga mogućnost izlaska iz slow start stanja jeste prijem tri ACK duplikata (videti fast retransmit) Konačno iz slow start stanja se može preći u novo slow start stanje ako dođe do isteka RTO intervala Pri tome cwnd smanjuje vrednost na SMSS udvostručuje se tajmer retransmisije (RTO) i ssthresh se postavlja na odgovarajuću vrednost (formula 25)

izvor odredište

seq 1

ack 1

seq 2 seq 3

ack 2 ack 3

seq 4 seq 5 seq 6 seq 7

cwnd = 1

cwnd = 2

cwnd = 4

t[s] t[s] sl 26 Eksponencijalno cwnd uvećanje u toku slow start faze

Congestion avoidance je stanje u kojem se konekcija nalazi blizu ekvilibrijuma prikazanog na sl24 Standard dozvoljava da se cwnd povećava za jedan SMSS u toku RTT intervala odn cwnd se povećava linearno

8

cwndSMSSSMSScwnd =+ (24)

U idealnim uslovima TCP konekcija bi trebalo da u ovom stanju provodi najviše vremena Reno TCP implementacija definiše da se iz ovog stanja može izaći na dva načina

1 Prijemom tri ACK duplikata se prelazi u fast retransmit

2 Istekom RTO intervala se prelazi u slow start Pri tome se cwnd smanjuje na jedan MSS RTO tajmer se udvostručuje (engl backoff) i ssthresh se postavlja na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (25)

242 Fast retransmit i fast recovery Fast retransmit i fast recovery su stanja specifična za TCP Reno implementaciju i najčešće se implementiraju zajedno Razlog korišćenja ovih algoritama proizilazi iz konvencije tretiranja prijema tri ACK duplikata kao prekretnice u funkcionisanju kontrole zagušenja ACK duplikati se generišu kao posledica dve vrste događaja

1 gubitka segmenata kojima su pridruženi niži brojevi sekvence u odnosu na segmente koji su stigli do odredišta i

2 prijema segmenata u izmenjenom redosledu

Izmena redosleda segmenata ne predstavlja gubitak Paketi koji su pristigli na taj način se prihvataju u bafer više ne koriste mrežne resurse i ne utiču na zagušenje mreže U tom slučaju izvor ne bi trebalo da deluje slow start mehanizmom koji je znak za ozbiljno zagušenje Fast retransmit omogućuje da se ne čeka istek RTO intervala kako bi se poslao odgovarajući segment Segment koji treba poslati je naveden u trostrukom ACK duplikatu Fast retransmit doprinosi

1 održavanju brzine razmene paketa i

2 očuvanju sinhronizacije potvrđivanja Algoritam je prikazan u sledećim tačkama

1 Po prijemu trećeg ACK duplikata ssthresh treba postaviti na vrednost

⌡

= SMSSFlightSizessthresh 2 2

max (26)

2 Poslati ldquoizgubljenirdquo segment

3 Privremeno povećati cwnd na vrednost

SMSSssthreshcwnd 3+= (27)

Ovo uvećanje pretpostavlja da su tri ACK duplikata posledica tri segmenta primljena van redosleda Kao što je rečeno ti segmenti su pohranjeni u baferu prijemnika i ne utiču na zagušenje mreže

4 U ovom koraku počinje fast recovery koji nije ništa drugo do congestion avoidance algoritam pokrenut u neobično vreme Takav sled događaja je omogućen postavljanjem vrednosti ssthresh u koraku 1

5 Pri pojavi svakog sledećeg ACK duplikata cwnd se prividno uvećava za SMSS ACK duplikat ukazuje da je prijemnik prihvatio u bafer još jedan segment pa izvor može poslati novi segment bez

9

izmene stanja zagušenosti mreže Tako se u perspektivi održava mehanizam sinhronizacije potvrđivanja

6 Kada se pojavi ACK koji potvrđuje novi segment cwnd se postavlja na vrednost ssthresh iz koraka 1 odn njegova vrednost se prepolovljava Ovaj proces se označava kao ispumpavanje privremeno povećanog prozora ACK novog segmenta bi trebalo da pristigne pre isteka RTT intervala koji je startovao u koraku 3

7 Congestion avoidance mehanizam se nastavlja sa novom cwnd vrednošću Fast retransmit fast recovery mehanizmi predstavljaju bitno poboljšanje u odnosu na stalnu izmenu stanja congestion avoidance i slow start Problemi koji se mogu pojaviti ipak nisu do kraja rešeni Jedna od osnovnih poteškoća nastaje kada je cwnd manji od četiri segmenta jer u mreži ne postoji dovoljno segmenata koji bi mogli da generišu tri ACK duplikata Učestanost pojave ove situacije nije zanemarljiva [LK98] pa je u dokumentu [RFC3042] predloženo rešenje nazvano limited transmit Fast recovery se loše ponaša i kada se izgubi više segmenata unutar jednog cwnd prozora Ovaj problem delimično rešava NewReno modifikacija dok se bolji očekuju od SACK implementacije 243 Upravljanje inkrementalnim povećanjem i multiplikativnim smanjenjem (AIMD) Kontrola zagušenja vođena navedenim stanjima promene cwnd prozora sledi logiku inkermentalnog povećanja i multiplikativnog smanjenja (engl additive increase multiplicative decrease AIMD) U radu [CJ89] je pokazano da je AIMD neophodan za stabilnost mehanizma kontrole zagušenja odn da ovaj algoritam konvergira bez obzira na početno stanje mreže Slika 27 ilustruje da TCP Reno i njegove varijante ne poseduju stabilno stanje brzine prenosa već u najboljem slučaju osciluju malom amplitudom oko njega u stanjima congestion avoidance fast retransmit i fast recovery Vrednost ssthrash parametra bi se mogla shvatiti kao vrednost procene stabilnog stanja

sl 27 Ilustracija ponašanja veličine cwnd Primenom potpuno drugačije logike upravljanja veličinom cwnd TCP varijanta nazvana Vegas [BOP94] delimično ublažava oscilatorno ponašanje prozora kontrole zagušenja Iako u određenim situacijama TCP Vegas ispoljava bolje ponašanje o njemu neće biti reči u ovom radu Ispitivanja objavljena u radu [MLAW99] su pokazala da su performanse Vegas implementacije inferiorne u prisustvu većeg broja Reno tokova a nedostatci su takođe prisutni na asimetričnim linkovima Ove činjenice ne bi bile značajne da TCP Reno i njegove modifikacije nisu najrasprostranjenije TCP implementacija 25 NewReno NewReno uvodi reakciju na parcijalne potvrde i unapređuje fast recovery mehanizam Parcijalnom potvrdom se naziva onaj ACK novog segmenta koji ne potvrđuje sve segmente koji su prethodili aktiviranju fast recovery algoritma (sl28) Predlozi poboljšanja koji se odnose na parcijalne potvrde su prvi put navedeni u pionirskim redovima [Hoe95] i [Hoe96] NewReno implementacija upotrebljena u ovom radu je definisana u [RFC2582]

10

sl 28 Parcijalni ACK

Običan fast recovery je podložan isteku RTO intervala u slučaju da se unutar istog prozora izgubi više segmenata [FF96] NewReno poboljšanje zaključuje iz parcijalne potvrde da je došlo do gubitka još nekog segmenta i u toku fast recovery faze šalje taj segment ali i nove podatke ako mu cwnd to dozvoljava Fast recovery se završava kada se potvrde svi segmenti koji su prethodili njegovom aktiviranju ili kada dođe do isteka RTO intervala Detalji NewReno implementacije su izloženi u dokumentu [RFC2582] Pojave intenzivnih spordičnosti (engl burst) pri upotrebi ovog algoritma su izbegnute ispumpavanjem cwnd prozora pri pojavi svake nove parcijalne potvrde Implementacija ostavlja i neka otvorena pitanja Jedno od njih je trenutak reseta RTO tajmera Rešenje ovog problema zavisi od broja izgubljenih segmenata i odnosa RTO i RTT vrednosti Rešenje koje je implementirano u ovom radu resetuje tajmer retransmisije samo nakon prve parcijalne potvrde koja se pojavi u toku fast recovery faze Na taj način se daje prednost izlasku u slow start i oporavku pomoću brzog uvećavanja cwnd vrednosti

26 SACK SACK [RFC2018] i [RFC2883] za razliku od NewReno mehanizma predstavlja potpuno proširenje TCP logike i otklanja mnoge nedoumice koje su postojale u Reno i NewReno implementacijama Razmenom dodatnih informacija odredište pruža mogućnost izvoru da napravi inteligentnu zaključak o izgubljenim segmentima i o retransmisiji SACK na taj način skoro u potpunosti otklanja nepotrebne retransmisije pri gubitku nekoliko segmenata iz istog prozora Cena poboljšanja je dvostruka Sa jedne strane SACK zahteva korišćenje polja TCP opcija

sl 29 TCP opcije za SACK (a) Opcije koje naglašavaju podršku za SACK (b) SACK opcije

SACK opcije (sl 29(b)) naglašavaju prijemniku granice blokova kontinualno primljenih segmenata u okviru istog prozora Ukupan dozvoljen prostor za TCP opcije iznosi 40 bajta pa SACK može oglasiti najviše četiri kontinualna bloka Ipak prostor TCP opcija se često koristi i za druga poboljšanja TCP performansi pa se najčešće mogu oglasiti tri SACK bloka Da bi se izbeglo učestalo slanje paketa sa obimnim TCP zaglavljem [RFC 2018] definiše da se SACK opcije prenose samo u onim ACK-ovima koji ne potvrđuju najveći broj sekvence u baferu prijemnika

11

sl 210 Primer SACK konekcije

Druga cena upotrebe SACK mehanizma jeste da obe strane moraju podržavati SACK (sl29 (a)) Ovo ne predstavlja problem za većinu savremenih operativnih sistema [PSC1] ali se upotreba SACK mehanizma najčešće mora eksplicitno oglasiti pri uspostavi konekcije

Konačno preporuka [RFC 2883] navodi proširenje ponašanja SACK opcija u slučaju slanja ACK duplikata (D-SACK) U D-SACK potvrdi prvi blok SACK opcija naglašava broj sekvence dupliciranog segmenta koji je pokrenuo potvrđivanje

27 Aktivno upravljanje redovima za čekanje (AQM) Porastom dimenzija Interneta i intenziteta saobraćaja unutar njega uvidelo se da kontrola koju pružaju krajnje tačke TCP konekcije nije dovoljna Zato su se u ruterima morali uspostaviti mehanizmi koji bi sprečavali zagušenje i ekstremno stanje ndash kolaps usled zagušenja Istraživanja koja se bave ovim problemom su napredovala u dva komplementarna smera Jedan je upravljanje redovima za čekanje (engl queue management) i bazira se na odbacivanju paketa u zavisnosti od popunjenosti bafera Druga vrsta rešenja je raspoređivanje (engl scheduling) koje odlučuje o redosledu prosleđivanja paketa različitih tokova i time upravlja raspodelom propusnog opsega Na prvi pogled oba ova koncepta izgledaju kao podloga za okvir kvaliteta servisa (QoS) Iako je to sasvim tačno potrebno je naglasiti da su raspoređivanje i upravljanje redovima za čekanje neophodni i van QoS arhitekture Koncept raspoređivanja je prilično širok i kreće se od najjednostavnijeg FIFO mehanizma do raspoređivanja grupa tokova različite složenosti (CBQ [FJ95] FQ [DKS90] SFQ [MK91] CSFQ [SSZ03] ) Složeniji algoritmi raspoređivanja uglavnom teže da uspostave pravičan (engl fair) odnos između tokova Iako je to svojstvo veoma poželjno njegova implementacija zahteva mnogo detaljniju obradu paketa i održavanje dodatnih varijabli stanja u ruterima U ovom radu će se podrazumevati upotreba još uvek najzastupljenijeg FIFO raspoređivanja Osnovna tehnika upravljanja redovima za čekanje je tzv DropTail To je veoma jednostavna tehnika koja prihvata pakete dok se bafer ne popuni Svi naknadno pristigli paketi se odbacuju DropTail je veoma rasprostranjen ali poseduje krupne nedostatke Jedan od nedostataka je favorizovanje agresivnih tokova koji mogu zauzeti veliki deo propusnog opsega (engl lock-out) Kontrola kašnjenja paketa u prisustvu DropTail bafera je komplikovana Ovi baferi ne poseduju mehanizam za predviđanje zagušenja pa stoga mogu ostati popunjeni dugo vremena Tako se pojavila potreba da se redovima za čekanje (baferima) upravlja na aktivan način (engl active queue management AQM) AQM tehnika treba da reši osnovni kompromis upotrebe bafera Kompromis se bazira na uspostavi optimalnog odnosa između smanjenja broja izgubljenih paketa i smanjenja kašnjenja u baferima Rešenje se uspostavlja određivanjem dužine bafera Dugački redovi predstavljaju problem za TCP mehanizme kontrole zagušenja usled mogućnosti pojava čestih isteka RTO intervala Tako se aktiviraju slow start i vrati se za n mehanizmi što može dovesti do izrazito nepovoljne pojave sporadičnosti (engl burst) paketa Stoga bi se

12

moglo pretpostaviti da je rešenje kompromisa smanjenje dužine redova za čekanje što dovodi do njihovog bržeg pražnjenja i smanjenja kašnjenja paketa Svojstva kao što su

bull ponašanje korisnika

bull ponašanje protokola

bull ponašanje Internet aplikacija i keširanja

bull svojstava sistema datoteka

čine ovo rešenje neadekvatnim Navedena svojstva su uzrok izrazite promenljivosti opsega sporadičnosti Internet saobraćaja koja zahteva duže redove za čekanje Izrazita promenljivost Internet saobraćaja bez obzira na interval posmatranja je učinila tradicionalno Poisson-ovo modelovanje neadekvatnim [PF95] Merenja [CB97] [LTWW94] i [RV97] su pokazala da Internet saobraćaj poseduje fraktalnu ili čak multifraktalnu prirodu (videti Dodatak A)

(a) (b)

(c)

sl 211 Prikaz izrazite promenljivosti Internet saobraćaja u intervalima (a) 100s (b) 1s i (c) 001s

Neadekvatna prosečna dužina bafera je uzrok povećanog odbacivanja paketa usled čega može doći do problema globalne sinhronizacije TCP tokova Sinhronizacija nastaje kada se više tokova ponaša na isti način u bliskim vremenskim intervalima Glavna odlika ove pojave je periodičnost promene stanja TCP mehanizama kontrole zagušenja Saobraćaj sačinjen od više sinhronizovanih tokova u jednom trenutku koristi sav raspoloživi propusni opseg linka dok u drugom koristi samo njegov mali deo To dovodi do izuzetno neefikasnog korišćenja mrežnih resursa

13

sl 212 Sinhronizacija dva TCP toka prikazana promenom cwnd prozora

AQM mehanizmi daju rešenje problema adaptivnim (aktivnim) smanjenjem prosečne popunjenosti bafera AQM obuhvata nekoliko nezavisnih rešenja različite složenosti Idealno AQM rešenje bi bilo u stanju da sa jedne strane iz algoritma raspoređivanja dobije informaciju o tokovima dok bi sa druge strane vodilo obimnu statistiku saobraćaja i na osnovu toga donosilo inteligentne odluke o odbacivanju ili markiranju paketa Iako je takav pristup je moguć njegova implementacija bi bila veoma računarski zahtevna Autor nije susreo ni jedno rešenje ovog tipa U ovom radu će se ispitivati modifikacije veoma rasprostranjenog AQM mehanizma nazvanog RED 28 Slučajna preventivna detekcija - RED RED (Random Early Detection) [RFC2309] [FJ93] je AQM algoritam koji je najefikasniji pri radu sa protokolima za koje je gubitak paketa indikacija zagušenja Ovaj mehanizam ne pravi razliku između pojedinih tokova već probabilistički odbacuje pakete ukupnog dolaznog saobraćaja Aktivo upravljanje redovima za čekanje se odlikuje održavanjem male prosečne popunjenosti bafera dok njegova fizička dužina ostaje dovoljno velika da bi se kompenzovale povremene sporadičnosti RED zahteva pet parametara za konfiguraciju

bull QL - najveća dužina reda za čekanje

bull minth i maxth ndashpragovi dejstva RED algoritma

bull maxp ndash najveća vrednost verovatnoće odbacivanja u RED regionu

bull wq ndash koeficijent za proračunavanje prosečne dužine reda za čekanje Algoritam ima dve osnovne funkcije

bull procenu prosečne dužine reda za čekanje

bull odlučivanje o odbacivanju paketa Procena prosečne dužine reda za čekanje ndash RED sve svoje odluke bazira na prosečnoj dužini reda za čekanje (avg) Algoritam za proračun avg zavisi od težinskog koeficijenta wq trenutne popunjenosti bafera q (odn dužine reda za čekanje) i prethodne vrednosti avgi-1

avg i = (1 - wq) times avgi-1 + wq times q U zavisnosti od jedinice za avg RED može raditi u rdquobajtrdquo režimu i ldquopaketrdquo režimu Paketi različitih veličina uslovljavaju da se RED ne ponaša istovetno u ova dva režima [Floyd97]

Odluka o odbacivanju paketa ndash Odbacivanje zavisi od regiona u kojem se nalazi veličina avg

avg lt minth nema odbacivanja

14

minth lt avg lt maxth RED region preventivnog odbacivanja (engl early drop) sa verovatnoćom odbacivanja koja linearno varira od 0 do maxp

avg gt maxth odbacuju se svi paketi (engl forced drop)

sl213 Ilustracija RED algoritma

Kao što je ranije napomenuto odbacivanjem paketa u RED regionu (minth maxth) se omogućuje održavanje relativno male prosečne dužine redova za čekanje odn smanjuje se kašnjenje Trenutni skok popunjenosti u oblast ( )QLq th maxisin ne utiče na avg pa se sporadičnosti dužine QL mogu uspešno kompenzovati

sl214 Ponašanje RED algoritma

Još jedna prednost probabilističkog odbacivanja u RED regionu je sprečavanje globalne sinhronizacije Malo je verovatno da će u vremenski bliskim trenucima biti odbačeni paketi više tokova što znači da oni neće reagovati na isti način i uspostaviti sinhronizaciju Konačno u oblasti ( )QLavg th maxisin RED bafer gubi sve prednosti i počinje da se ponaša kao DropTail Zato je veoma bitno da se RED parametri usaglase sa karakteristikama saobraćaja RED je poslužio kao osnov mnogih rešenja koja su u fazi ispitivanja U ovom radu će biti ispitane bliske modifikacije RED algoritma nazvane su gentle RED [Floyd00] (sl215a) i adaptive RED (sl215b)

Polazna ideja za kreiranje adaptivnog RED algoritma je predložena u radu [FKSS99] Ovaj predlog je bio baziran na adaptivnosti koja koristi MIMD upravljanje parametrom maxp upotrebom koeficijenata α i β U drugom radu [FGS01] je predložena adaptivna RED varijanta sa AMID upravljanjem Pseudokocircd ovog algoritma je naveden u listingu 21

15

(a) (b)

sl 215 RED modifikacije (a) gentle RED (b) adaptive RED

Every interval [s ]if (avg gt target and max pge05)

increase max p max p larr maxp + αelseif (avg lt target and max pge001)

decrease max p max p larr maxp middot β

Fiksni parametriinterval = 05starget = [min th + 04middot(max th - min th ) min th

+ 06middot(max th - min th )]α = min(001 025middotmax p)β = 09

Listing 21 Adaptivni RED sa AMID upravljanjem Postoje i druge složenije modifikacije RED mehanizma kao što su FRED [LM97] i RED-PD [MF01] Ove RED modifikacije donose odluke na osnovu praćenja karakteristika odvojenih tokova ili grupa tokova Zbog povećanja broja praćenih stanja (merenih veličina) složene RED nadgradnje se još uvek smatraju neisplativim u realnim okruženjima 29 Eksplicitno obaveštenje o zagušenju - ECN ECN [RFC3168] (Explicit Congestion Notification) je nadgradnja ideje AQM mehanizama Poboljšanja performansi koja se mogu ostvariti upotrebom ECN-a zavise od efikasnosti AQM tehnike koja ga opslužuje ECN nije usko povezan sa IP platformom već je kao okvir bio ranije predložen za DNA arhitekturu pomoću DECbit-a [RJ90] FrameRelay pomoću FECN i BECN mehanizama i ATM pomoću EFCI bita IP platforma je preuzela iskustva vezana za ovaj koncept i prilagodila ih svojim potrebama IETF organizacija snažno podržava ECN tako da se on može smatrati izglednom dopunom TCPIP skupa protokola Novina koju ECN uvodi je markiranje paketa u cilju oglašavanja potencijalnog zagušenja Ruteri upisuju podatke o obavljenom markiranju u deo ToS polja unutar zaglavlja IP paketa što znači da se kontrola zagušenja čvrsto integriše u sloj mreže referentnog OSI modela Da bi rešenje bilo potpuno potrebno je modifikovati TCP mehanizme na krajnjim tačkama komunikacije Pored toga neophodno je izmeniti i neke mehanizme tuneliranja i sigurnosti [RFC3168] Pojednostavljena šema delovanja ECN markiranja je prikazana na sl 216

sl 216 ECN markiranje ndash zasenčeni paketi su markirani posredstvom ECN mehanizma

Marker zagušenja stiže do izvora u okviru jednog RTT intervala

16

Implementacija ECN-a u IP protokolu se obavlja standardizacijom dva bita u ToS polju čije su dozvoljene vrednosti prikazane na sl 217

sl217 ECN u ToS polju IP zaglavlja

Krajnje stanice šalju neki od ECT(0) ili ECT(1) markera da bi naznačile da njihovi transportni protokoli podržavaju ECN Ruter šalje CE marker kada pomoću nekog od AQM algoritama uoči postojanje zagušenja Naravno CE se ne može postaviti kada paket nailazi na pun bafer rutera On tada biva neizostavno odbačen Ispravnost manipulacije CE markerom je ključna za ECN mehanizam Ako ruteri iz nekog razloga izbrišu postavljenu CE kombinaciju paket koji je trebalo da bude preventivno odbačen će stići do odredišta Odredište neće znati da treba da obavesti izvor o zagušenju Konačno TCP neće reagovati na najavu zagušenja Ako se sa CE markerom postupa ispravno standard zahteva da se mehanizam kontrole zagušenja mora ponašati na isti način kao u slučaju gubitka odgovarajućeg paketa Ovaj zahtev sledi iz činjenice da ECN još uvek nije dovoljno rasprostranjena tehnologija Ako bi se CE obaveštenje tretiralo na drugačiji način verovatno bi došlo do nepravednog ponašanja u odnosu na tokove koji ne podržavaju ECN Implementacija ECN-a na nivou TCP protokola postavlja sve neophodne podatke u Reserved polje TCP zaglavlja [Ste98]

sl 218 ECN bitovi CWR i ECE u TCP zaglavlju Osnovna funkcija koja se očekuje od sloja transporta je dogovaranje podrške za ECN u toku uspostave konekcije Celokupno dogovaranje se obavlja kombinacijama CWR ECE SYN i ACK bita (sl 219)

značenje ECE iili CWR iili SYN iili ACK

ECN-setup SYN on i on i on non-ECN-setup SYN on ili on i on

ECN-setup SYN-ACK on i off i on i on non-ECN-setup SYN-ACK bilo koja druga kombinacija i on i on

(a) (b)

sl 219 Uspostava TCP konekcije sa ECN podrškom (a) Obe strane podržavaju ECN (b) Prijemnik ne podržava ECN (ECN se ne uspostavlja)

ECN-setup SYN

non-ECN-setup SYN-ACK

Host A Host BHost A Host B

ECN-setup SYN

ECN-setup SYN-ACK

17

Nakon uspostave TCP konekcije sa ECN podrškom TCP izvor treba da signalizira IP protokolu upis ECT(0) ili ECT(1) markera u IP zaglavlje Tako će usputni ruteri znati da je moguće obavljati markiranje odgovarajućeg paketa Kada paket sa CE markerom stigne do odredišta TCP ima zadatak da postavi ECE (ECN-Echo) i tako signalizira indikaciju o zagušenju Da bi se obezbedila robusnost markiranja odredište šalje ECE markere sve dok ne dobije potvrdu reakcije na zagušenje od izvora Ako na ACK putanji ne postoje gubici informacija o zagušenju će do izvora stići u RTT intervalu Bitno je napomenuti da je to vreme najčešće kraće od RTO intervala ili od vremena potrebnog za dostavljanje tri ACK duplikata To znači da se informacija o nailasku zagušenja brže prosleđuje u odnosu na izolovano dejstvo TCP mehanizama ili AQM tehnika ECN markiranje nema negativnih uticaja na RTO mehanizme TCP protokola dok su prednosti njegove upotrebe očigledne Do prijemnika stižu paketi koji bi u suprotnom bili preventivno odbačeni Tako se ublažava uticaj gubitka paketa u aplikacijama osetljivim na kašnjenje Izvor koji primi ECE marker je obavezan da reaguje kao da je u pitanju gubitak paketa U takvoj situaciji se aktivira fast retransmit Izvor je obavezan da postavi CWR (cwnd Reduced) i tako obavesti prijemnik da je reakcija na marker zagušenja obavljena Da bi se sprečilo učestalo ponavljanje ulaska u fast retransmit standard naglašava da se na ECE može reagovati samo jednom u toku procenjenog RTT intervala Standard takođe definiše da se u pakete koji su rezultat retransmisije ne sme postavljati ni ECT(0) ni ECT(1) Ovo je preventivna reakcija na mogućnost DoS (engl denial of service) napada

18

3 Pregled postojećih radova u oblasti TCP i AQM kontrole zagušenja Suvišno je reći da je broj radova posvećenih TCPIP kontroli zagušenja zaista veliki Stoga će ovaj deo teze pokušati da prikaže mali deo rezultata koji se bave

bull bazičnim odnosima svojstava kontrole zagušenja

bull postojećim analizama i test platformama na kojima su one izvedene

bull opštim trendovima razvoja u ovoj oblasti

bull i konačno nekim kontradiktornim rezultatima koji otvaraju put novim istraživanjima 31 TCP model Da bi se shvatili osnovni odnosi TCP kontrole zagušenja potrebno je stvoriti model U radu [PFTK99] je opisan model brzine slanja (B) stabilnog stanja TCP Reno protokola u funkciji

bull verovatnoće gubitka paketa p (koju model smatra konstantnom)

bull RTT vremena (koje model smatra konstantnim)

bull isteka RTO intervala T0

bull i ograničenosti cwnd prozora Wmax tokova sa neograničenom količinom podataka za slanje (engl bulk transfer) Iako ovaj model ne tretira veliki deo ponašanja kontrole zagušenja on danas važi za jednu od najpreciznijih procena Model je opisan jednakošću

( ) ( ) ( )

++sdotasymp

sbit

ppbpTbpRTTRTTWMSSpB

28

303

2

max

3213 1min1 min (31)

U jednakosti (31) b predstavlja broj paketa potvrđenih pristiglim ACK-om Iz navedenog modela se vidi da osnovne performanse kontrole zagušenja zavise parametara fizičkog okruženja tj od proizvoda raspoloživog propusnog opsega B(p) i RTT vremena (engl bandwidth-delay product) Ovaj proizvod je veoma bitan za projektovanje optimalnog kapaciteta bafera jer određuje maksimalnu količinu podataka koju jedan TCP tok može poslati zaredom tj MSSmiddotWmax Iz modela se može naslutiti znatna kompleksnost i nelinearnost mehanizma TCP kontole zagušenja Stoga se realno ponašanje ovog mehanizma ispituje ili simulacijom ili testovima na realnim implementacijama Pored razumevanja osnovnih odnosa TCP kontrole zagušenja modelovanje u poslednjih nekoliko godina ima bitnu ulogu u formiranju okvira za TCP-prijateljsko (engl TCP friendly) ponašanje 32 RTO estimacija Jedan od elementa TCP protokola jeste funkcionisanje mehanizama za procenu RTO i RTT vremena Osnovna uloga ovih mehanizama je uspostava kompromisa između nepotrebnih retransmisija i predugog čekanja na neophodne retransmisije Proučavanjem performansi estimatora u odnosu na mrežno okruženje se može bitno unaprediti kontrola zagušenja Rezultati koji proizilaze iz detalja implementacije estimatora svakako nisu konačni pa je neobično da je u poslednjih nekoliko godina objavljeno relativno malo radova u toj oblasti Trenutno važeća preporuka za proračun RTO intervala je opisana u prethodnom poglavlju teze a detalji se mogu naći u [RFC2988] Detaljnija studija RTO i RTT estimatora bazirana na praćenju uzoraka realnog saobraćaja iz 1995 god se može naći u radu [AP99]

19

Rad je proučavao nekoliko predloga za unapređenje trenutno standardizovanog RTO estimatora

bull upotrebu manje minimalne moguće vrednosti za vreme retransmisije RTOmin

bull upotrebu finije granularnosti tajmera G

bull neophodnost adaptivnosti estimatora

bull procenu RTT-a za skoro svaki segment (umesto česte implementacije uzimanja RTT procene za samo jedan segment u toku RTT intervala)

Uočeno je da RTOmin najdirektnije utiče na kompromis između smanjenja ukupnog čekanja na neophodne isteke RTO intervala i povećanje prosečnog broja nepotrebno pokrenutih RTO isteka U ispitivanju se nije došlo do rezultata koji bi se mogao proglasiti za opšte optimalno rešenje Bitan rezultat je i da konstantno postavljeni RTO intervali dovode do oko deset puta većeg procenta nepotrebnih tajmauta u poređenju sa standardnim adaptivnim estimatorima sa istim RTOmin vrednostima Pri proučavanju granularnosti G lt 100ms je uočeno da ona ne utiče bitno na intervale neophodnih RTO isteka ali povećana finoća granularnosti utiče na smanjenje učestanosti nepotrebnih RTO isteka Za granularnost G gt 100ms ovakvo ponašanje prestaje i počinje da deluje kompromis između smanjenja ukupnog čekanja na neophodne RTO isteke i povećanje prosečnog udela broja nepotrebnih RTO isteka Zanimljivo je da interval od oko 100ms predstavlja granicu između fraktalnog i multifraktalnog ponašanja mrežnog saobraćaja Autori rada nisu obratili pažnju na tu činjenicu pa bi ona mogla da bude izvor za buduća istraživanja Pri ispitivanju učestanosti obnavljanja RTT i RTO procena na uzorcima sa relativnom malom veličinom cwnd prozora je primećeno da procene bazirane na skoro svakom segmentu ne dovode do bitnih prednosti Dodatno [RFC2988] navodi da neadekvatnu RTT estimaciju može proizvesti kombinacija standardnih koeficijenata estimatora i višestruke procene u toku RTT intervala RTO i RTT estimacija u suštini jeste problem obrade signala pa su ovakvi rezultati neočekivani Veća učestanost odabiranja bi trebalo da proizvede bolju predstavu RTO i RTT signala [RFC1323] Problem bi se verovatno mogao rešiti usložnjavanjem čitavog procesa estimacije npr postavljanjem adaptivnih koeficijenata estimatora i proširenjem njegove memorije Ovo je još jedno od pitanja koje zavisi od realnog saobraćaja i predstavlja otvorenu oblast za istraživanje Delimično rešenje ovog problema je ispitivano u [AP99] variranjem koeficijenata osetljivosti estimatora od konstantne RTO vrednosti do brzo promenljive RTO procene Uočeno je da koeficijenti kojima se povećava osetljivost bitno povećavaju broj aktivacija nepotrebnih RTO isteka Takođe je primećeno da se rezultati razlikuju u zavisnosti od fizičkih svojstava konekcije Premošćavanjem problema nepotrebnih RTO isteka se bavi Eifel algoritam čija je osnovna implementacija [LK00] proširena u radu [GL03] Eifel algoritmu IETF trenutno posvećuje dosta pažnje i on je trenutno je u procesu proglašenja za RFC standard Algoritam koristi opciju vremenskih oznaka (engl timestamps) i modifikuje samo ponašanje izvora TCP konekcije Ograničeno slanje (engl limited transmit) [RFC3042] takođe pokušava da reši problem nepotrebnih RTO isteka ali na konekcijama koje se odlikuju malim cwnd prozorima 33 TCP prozori Sledeći mehanizam upravljanja zagušenjem su TCP prozori koji upravljaju kontrolom zagušenja u tzv TCP stabilnom stanju Zato se za TCP prozore može reći da predstavljaju najvažniji elemenat kontrole zagušenja U preporuci [RFC2414] je predloženo da konekcije startuju sa većim inicijalnim prozorima (do 4middotMSS) Prednosti dobijene korišćenjem ovog predloga su izbegavanje RTO isteka na početku slow start faze pri upotrebi zakašnjenih potvrda ubrzavanje slow start faze koje može biti izuzetno korisno za konekcije sa velikim kašnjenjem i konačno slanje kratkih transfera u toku samo jednog RTT intervala Posmatranjem izolovanih i konkurentnih TCP konekcija sa velikim kašnjenjem je ustanovljeno da ovaj

20

predlog uglavnom skraćuje ukupno vreme transfera uz relativno malo povećanje broja odbačenih paketa Nedostaci ove ideje su pojava dodatne sporadičnosti koja može predstavljati problem za zagušene linkove ili linkove sa nedovoljnim kapacitetom bafera U širem smislu sporadičnost veličine uvećanog inicijalnog prozora je uobičajena za današnji Internet pa njeni efekti ne bi trebalo da bitno pogoršaju opšte stanje zagušenosti Detaljnija simulacija predloga povećanih inicijalnih prozora se može naći u [RFC2415] Test scenariji su obavljeni na topologiji sa jednim uskim grlom nekoliko mrežnih čvorova i kombinovanjem nekoliko skupova HTTP i FTP konekcija U pojedinim testovima tog rada je utvrđeno da rezultati povećanja inicijalnih prozora ne daju stabilno poboljšanje performansi Provera validnosti cwnd prozora (engl Congestion Window Validation CWV) je još jedna smernica razvoja TCP protokola Potreba za ovim algoritmom je izražena pri transferima ograničenim od strane aplikacije tj onim konekcijama za koje se ne koristi ceo raspoloživi cwnd prozor U takvim situacijama je moguće da se cwnd neadekvatno ažurira Ako se aplikacija osloni na neažurirani prozor i poveća količinu podataka za slanje doći će do pojave sporadičnosti Mreža koja je u međuvremenu možda postala više zagušena neće biti u stanju da apsorbuje tu količinu istovremeno poslatih paketa Preporuka [RFC2861] predlaže CWV algoritam koji polovi cwnd u svakom RTT intervalu u kojem konekcija nije koristila raspoložive resurse mreže dok ssthresh pamti prethodno stanje Površni testovi na modemskim linijama su pokazali da CWV može ubrzati transfere do 30 Sličan problem pokretanja neaktivne TCP razmene razmatra i RBP (engl Rate Based Pacing) [VH97] koji umesto grupe paketa šalje mali broj segmenata u skladu sa predodređenom učestanošću Proširenje ideje uspostave informacija o realnom stanju mreže je predmet preporuke [RFC2140] koja predlaže CBI (engl Control Bock Independence) mehanizam Kontrolni blok TCP konekcije pamti stanje konekcije RTT procenu ssthresh MSS i dr Nove konekcije mogu da steknu uvid u stanje mreže upotrebom informacija iz kontrolnih blokova drugih konekcija Jedan od bitnih pozajmljenih podataka je ssthresh granica koja bi na početku konekcije sprečila nepotrebno premašenje bafera usputnog rutera 34 TCP-prijateljsko ponašanje Multimedijalni servisi konvergentnih mreža često obavljaju kontrolu protoka na nivou aplikacije bez upotrebe TCP-a Kako TCP predstavlja najviše korišćen transportni protokol bitno je da novi servisi ne ugroze prenose kojima on rukovodi Danas se TCP prijateljskim [PSC2] smatraju aplikacije koje usklađuju brzinu slanja u odnosu na kvadratni koren učestanosti (odn verovatnoće) gubitka paketa kao što navodi jednakost (31) U radovima [VRC98] i [WC98] se mogu videti neki od predloga za TCP-prijateljski protokol sa višestrukim usmeravanjem (engl multicast) dok su u radovima [PKTK98] [WC98] i [FHPW00] dati predlozi za rešenja sa jednostrukim usmeravanjem (engl unicast) Rad [FF99] daje pregled detekcije TCP-prijateljskog ponašanja ravnopravnog odnosa tokova i prevencije kolapsa usled zagušenja Autori su naveli nekoliko smernica za implementaciju mehanizama za kontrolu saobraćaja u ruterima Bitno je napomenuti da se ne ohrabruje izolovano dejstvo naizgled ispravne ideje kombinovanja UDP transporta i algoritma za zaštitnog kodovanja (FEC) na nivou aplikacije Pokazano je da takvo rešenje ne može zameniti kontrolu zagušenja Pored toga je navedeno nekoliko bitnih eksperimenata Pokazno je da algoritmi ravnopravnog raspoređivanja (WRR i FQ) u ruterima ne mogu eliminisati kolaps usled zagušenja u prisustvu složenije mešavine UDP i TCP tokova Ovo je veoma bitan rezultat koji dokazuje da raspoređivanja kompleksnija od FIFO algoritma ne donose uvek očekivane rezultate U mreži sa servisom najboljeg pokušaja i implementiranom kontrolom zagušenja FIFO u odnosu na FQ i WRR smanjuje rep raspodele kašnjenja Između ostalog to znači da FIFO dozvoljava da paketi pristigli unutar male sporadičnosti budu isporučeni na isti način umesto da se rastave i dodatno zakasne dejstvom raspoređivanja Takođe je pokazano da i kompleksnija raspoređivanja zahtevaju implementiranje i saradnju sa AQM tehnikama 35 Primena zaštitnog kodovanja Pomenuti koncept integracije zaštitnog kodovanja (engl Forward Error Correction FEC) u kontrolu zagušenja je bio predmet ispitivanja nekoliko radova o TCP protokolu preko bežičnih linkova Ova tema prevazilazi okvire ovog rada ali je zanimljiva kako jedna od smernica razvoja TCP protokola Osnovna ideja

21

ovog koncepta je smanjenje broja retransmisija na kanalima sa izraženom učestanošću pojave grešaka U radu [LK02] su opisani zahtevi za uvođenje kodovanja koji se odnose na

bull moguće vrste kodova

bull adaptivnost

bull kodni količnik i efekte premašaja dodatnih informacija u paketima

bull usklađivanje koda sa krajnje nepredvidljivim svojstvima kodnog kanala sa kraja na kraj

bull usklađivanje koda sa ponašanjem TCP mehanizama Rezultati rada su pokazali da FEC može da poboljša performanse nekih prenosa sa velikim kašnjenjem i učestanošću greške Sa druge strane FEC implementiran pomoću jednostavnih kodova može dovesti do pogoršanja TCP performansi naročito za konekcije sa malim kašnjenjem Pokazano je i da zaštitno kodovanje može biti uzrok neravnopravnosti u odnosu na TCP konekcije koje ne implementiraju FEC 36 TCP protokol u bežičnim mrežama Polazna pretpostavka dizajna TCP protokola je bila da će on raditi na fiksnim žičanim mrežama gde su osnovni problemi optimalna iskorišćenost propusnog opsega i izbegavanje zagušenja Stoga TCP mehanizmi koji rešavaju ove probleme shvataju svaki gubitak segmenta kao posledicu zagušenja Greške promenljivo kašnjenje i slabljenje kanala su dodatni efekti bežičnog okruženja Ipak osnovna TCP specifikacija nije u stanju da razlikuje efekte ovih pojava i zagušenja pa se pri prenosima u bežičnom okruženju mogu očekivati česti nepotrebni RTO isteci i neadekvatno korišćenje raspoloživog propusnog opsega U poslednjih nekoliko godina su intenzivirana istraživanja sa ciljem poboljšanja TCP performansi u ovakvom okruženju U radovima [BSAK95] i [Vai99] je navedena klasifikacija predloženih arhitektura za bežične TCP konekcije Postoje tri osnovne grupe Prvoj grupi se svi problemi bežičnog okruženja rešavaju na sloju povezivanja podataka OSI modela Ovo rešenje ne zahteva modifikacije sloja transporta Pri učestalim greškama procesiranje na sloju 2 traje duže što može dovesti do RTO isteka u TCP protokolu Da bi se ovakvi problemi prevazišli predloženo je da se ustanovi komunikacija između sloja povezivanja podataka i sloja transporta Druga grupa rešenja se bazira na uvođenju PEP (engl Performance Enhancing Proxy) uređaja na prelazima između žičane i bežične mreže Nedostatak ovog rešenja je prekid semantike komunikacije sa kraja na kraj Konačno treća grupa rešenja predlaže rešavanje svih efekata bežičnog okruženja na sloju transporta Teze [Gur00] i [Kuh00] su razmatrane performanse SACK i NewReno implementacije sa nekoliko dodatnih poboljšanja predloženih u RFC dokumentima Efekti upotrebe AQM mehanizama nisu razmatrani kao ni uticaji pozadinskog saobraćaja Podloga ispitivanja je bila zasnovana na emuliranom bežičnom okruženju skromnog propusnog opsega Test okruženje se sastojalo od laboratorijske Linux mreže i namenski razvijenog Seawind emulatora Teza [Gur00] proučava gubitke usled zagušenja i usled grešaka svojstvenih bežičnom okruženju Zaključeno je da neograničena veličina bafera ugrožava proces oporavka od iznenadnog gubitka podataka Utvrđeno je da postoje situacije u kojima gubitak samo jednog paketa može dovesti do pojave RTO isteka Potvrđeno je da SACK pruža nadmoćne performanse Pri niskim učestanostima odbacivanja paketa i većim kapacitetima bafera (oko 20 paketa) je utvrđeno da se bolje performanse mogu dobiti isključivanjem NewReno implementacije odn prelazom na Reno Pojava grupnih grešaka loše utiče na RTO procenu U takvim situacijama je utvrđeno da se konekcije lakše oporavljaju ako su baferi na usputnim ruterima kraći Teza [Kuh00] proučava 100kB prenose na bežičnim linkovima sa greškama ili na linkovima koji ne unose greške ali se odlikuju promenljivim kašnjenjem Testovi su pokazali da su na bežičnim linkovima nepotrebni RTO isteci daleko nepovoljniji od efekata odbacivanja pojedinih paketa Uočeno je da posledice nepotrebnih RTO isteka postaju manje ozbiljne sa porastom učestanosti odbacivanja paketa 37 RED i ECN Prednosti upotrebe AQM mehanizama su objašnjenje u delu teze koji se bavio pregledom TCP i AQM tehnika U dokumentu RFC 2309 se navodi postoje izvesni slučajevi u kojima RED neće doneti nikakva

22

poboljšanja ali se takođe napominje da njegova upotreba ne stvara negativne posledice Postoji nekoliko radova koji tvrde drugačije [MBDL99] i [CJOS01] Najdrastičniji protivnik primene RED mehanizma je verovatno rad ldquoRazlozi zbog kojih ne treba primenjivati REDrdquo [MBDL99] Testovi su obavljeni na realnoj test mreži sa kombinovanim HTTP FTP i UDP saobraćajem U test scenarijima su varirani svi bitni RED parametri Glavni zaključci ovog rada su da RED ne može pomoći ruterima sa malim baferima da DropTail (u njihovoj test topologiji) agresivnije kažnjava nekontrolisane UDP tokove da su RED parametri veoma osetljivi na podešavanja i da RED ne stvara pravičnu raspodelu propusnog opsega Slične rezultate su prikazali autori rada [CJOS01] Oni su takođe obavili testiranja na laboratorijskoj mreži sa ciljem da ispitaju uticaj RED mehanizma na parametre bitne za krajnjeg HTTP korisnika Autori tvrde da iz perspektive HTTP korisnika RED nema očiglednih prednosti u odnosu na DropTail do 90 opterećenja linka Kada je test mreža bila veoma zagušena RED parametri koji obezbeđuju najbolje iskorišćenje linka su pružali lošija vremena odziva Pokazalo se da je optimalna vrednost za maxp osetljiva na broj aktivnih konekcija Još jedan bitan rezultat radova [MBDL99] i [CJOS01] jeste da je u realnim mrežama veoma teško konfigurisati parametre koji omogućuju da RED najveći deo vremena provodi u tzv RED regionu

U nekoliko radova [PB02] [Fen99] i [LM97] je potvrđeno da RED ne može garantovati potpuno ravnopravnu podelu propusnog opsega linka U većini slučajeva se pokazalo da su konekcije sa manjim RTT vremenom u prednosti

I pored svih navedenih nedostataka većina radova se slaže u tome da RED mehanizam uspeva dao izbegne globalnu sinhronizaciju odn da uspešno koristi raspoloživi kapacitet linka RED takođe smanjuje prosečan broj odbačenih paketa U eksperimentalnom delu ove teze će biti ispitano da li dve jednostavne RED modifikacije donose poboljšanja primećenih negativnih efekata Osim ovih modifikacija predloženo je i nekoliko drugih AQM rešenja koja teže da isprave nedostatke RED algoritma Neki od njih su REM [ALLY01] BLUE i SFB [FKSS99] SRED [OLW99] FRED [LM97] RED-PD [MF01] BRED [AT99] i LRU-RED[SR01]

U radu [PB02] je obavljen veći broj simulacija dejstva DropTail RED i RED+ECN mehanizama na mreži sa jednim serverom jednim uskim grlom i nekoliko klijenata U nekim slučajevima su obavljeni testovi pretpostavljali scenarije koji su nerealni za današnji Internet Npr u jednoj seriji testova je pretpostavljeno da svi čvorovi podržavaju ECN i da startuju u isto vreme Ipak rad je pokazao nekoliko značajnih i neočekivanih rezultata Jedan od njih je da i DropTail i RED ispoljavaju neravnopravnost podele kapaciteta linka čak i kada link dele dva istovremeno pokrenuta TCP toka istovetnih svojstava Pri tome RED ponekad poboljšava pravičnost dok je ponegde nepotrebno ugrožava ranim odbacivanjem paketa Utvrđeno je da se korišćenjem ECN-a pravičnost poboljšava ECN takođe smanjuje ukupan broj odbačenih paketa

Mnogo povoljniji rezultati su objavljeni u radu [RFC2884] Testovi su obavljeni na laboratorijskoj mreži sa jednim serverom jednim uskim grlom i nekoliko različitih klijentskih računara Pri ispitivanju velikih FTP transfera je uočeno da ECN korisnicima pruža veći raspoloživi propusni opseg u periodu intenzivnog zagušenja u odnosu na AQM koji ne koristi ECN Takođe je primećeno da se pri upotrebi ECN-a retransmisije skoro uopšte nisu pojavljivale ali brojni rezultati i intenzitet zagušenja nisu navedeni U slučaju relativno kratkih HTTP transfera je ustanovljeno da se pozitivni efekti korišćenja ECN-a postižu pri povećanju zagušenosti i povećanju maxp vrednosti RED mehanizma Povećanjem količine podataka u HTTP transferu se smanjuju ECN prednosti jer takvi tokovi imaju dovoljno paketa za aktivaciju Fast Retransmit stanja 38 Analize slične ciljevima ove teze SACK se kao ideja nadgradnje TCP protokola pojavio 1990 god ali je početak njegove implementacije odložen do 1996 god U radu [FF96] je objavljeno nekoliko simulacija kojima je početak SACK konekcije upoređen sa implementacijama Tahoe Reno i NewReno Testovi su obavljeni u ns-2 simulatoru na jednostavnoj topologiji od dva čvora i rutera između njih DropTail bafer rutera je bio relativno mali Od jednog do drugog čvora su pokrenute samo tri konekcije od kojih je jedna predstavljala cilj posmatranja a preostale dve su poslužile za pozadinski saobraćaj Zaključeno je da se SACK lakše oporavlja od višestrukih

23

gubitaka Početkom razmene u TCP konekcijama se bavi i teza [Hoe95] U njoj prikazani nedostaci Reno implementacije osnovu kojih je kasnije formirana NewReno verzija TCP protokola

U tezi [Win99] je proučavana pravičnost TCP konekcija Testiranje je obavljeno na laboratorijskoj mreži sačinjenoj od nekoliko Cisco rutera i računara sa AIX Linux i Windows operativnim sistemima Testovima su obuhvaćeni DropTail i RED mehanizmi Rezultati su pokazali poznatu činjenicu da TCP tokovi sa većim RTT vremenom dobijaju manje propusnog opsega Uočeno je da postoji pozitivna korelacija između RTT porasta i porasta cwnd prozora Za poboljšanje problema nepravičnog odnosa je predložena upotreba linearnog ili konstantnog povećanja cwnd prozora ali je uočeno da takvo rešenje stvara nove probleme

Teza [Fen99] se bavila AQM mehanizmima u okruženjima koja zahtevaju bolji servis od trenutno dominantnog servisa najboljeg pokušaja Jedan deo eksperimenata je obavljen na ns-2 simulatoru na različitim topologijama dok su preostali testovi obavljeni na jednostavnoj test mreži sačinjenoj od izvora odredišta i jednog uskog grla Rezultati testova su pokazali da RED u veoma zagušenim mrežama nije u stanju da obezbedi adekvatnu zaštitu od kolapsa usled zagušenja Ustanovljeno je da ECN može bitno poboljšati performanse ali ta poboljšanja ponekad nisu dovoljna Jedan od predloga za prevazilaženje uočenih problema je adaptive RED algoritam koji će biti detaljnije proučen u ovoj tezi

24

4 Postavke simulacije 41 Načini proučavanja protokola Internet protokoli se mogu izučavati u više aspekata počevši od detalja implementacije do funkcionisanja u zavisnosti od topologije interakcije sa drugim protokolima i karakteristikama saobraćaja Metode za ispitivanje se mogu podeliti na

bull matematičko modelovanje

bull simulaciju i emulaciju

bull merenje i eksperimente na realnim implementacijama Postupci ispitivanja protokola koji predstavljaju okosnicu današnjeg Interneta nisu u potpunosti definisani [PF97] ali postoje izvesni okviri [AF99] [BFF00] i [FP01] koji omogućuju da se dođe do upotrebljivih rezultata Pored navedenih metoda ispitivanja složenost mrežnog okruženja često nalaže i formiranje pravila najbolje prakse koja ponekad proizilaze samo iz iskustva Modelovanje podrazumeva potpunu kontrolu nad dešavanjima u pretpostavljenoj apstrakciji To često nije realna i primenljiva pretpostavka pa se može reći da je ključna uloga ovog načina istraživanja otkrivanje bazičnih pojava i odnosa U prethodnim delovima teze je objašnjeno da je modelovanje realnih uzoraka Internet saobraćaja dovelo do saznanja o njegovoj fraktalnoj ili multifraktalnoj prirodi na nivou paketa U domenu TCP protokola modelovanje je poslužilo za formiranje okvira TCP prijateljskog ponašanja Simulacija i emulacija ne proizvode egzaktnu analitičku formulaciju pojava ali u odnosu na modelovanje omogućuju proučavanje daleko šireg polja problema Simulacija takođe zanemaruje pojedine realne pojave Tako se pri proučavanju protokola često zanemaruju detalji implementacije na operativnom sistemu a detaljna pažnja se pridaje algoritmima i parametrima Bitne uloge simulacije su provera rezultata modelovanja razvijanje intuicije proučavanje pojava u relativno kompleksnim topologijama [CDZ97] [ZCB96] uočavanje i otklanjanje bitnih nedostataka protokola i otkrivanje boljih postupaka koji će u perspektivi biti implementirani i standardizovani Emulacija povezuje određenu pojavu sa realnim okruženjem Ona je veoma korisna pri finalnom ispitivanju protokola pre njihove konačne implementacije Simulacija i emulacija daju mogućnost ispitivanja potencijalnih budućih mrežnih rešenja Od izuzetnog je značaja mogućnost posmatranja saobraćaja na svim tačkama u mreži što je veoma teško postići u realnom okruženju Merenje i eksperimenti se ostvaruju na realnim platformama različitih veličina Ispitivanja ove vrste mogu biti veoma skupa ali rezultati dobijeni na taj način često predstavljaju konačne potvrde istraživanja Bitan nedostatak ovakvog načina istraživanja jeste nemogućnost praćenja svih efekata u test okruženju Zbog stalne promenljivosti Interneta je neophodno je obnavljati saznanja dobijena eksperimentima čak i kada je u pitanju realna implementacija 42 NS-2 Simulator Istraživanje izloženo u ovom radu je obavljeno u celosti na ns-2 simulatoru [ns2] koji predstavlja de facto standard za ispitivanje ponašanja TCP protokola AQM tehnika višestrukog usmeravanja (engl multicast) bežičnih mreža veb keširanja itd Ns-2 poseduje više implementiranih protokola od bilo kog drugog simulatora Ispravnost rezultata simulacije je potvrđena upotrebom simulatora u mnogim RFC [RFCi] dokumentima i naučnim radovima Simulator je baziran na praćenju diskretnih događaja U svojoj drugoj izvedbi ns je napisan kao objektno orijentisani softver otvorenog kocircda koji je raspodeljen na dve jezičke platforme Delovi simulatora koji zahtevaju rad u realnom vremenu (osnovni raspoređivač mrežni čvorovi protokoli) su napisani u jeziku C++ Svi scenariji testova i topologije se programiraju u jeziku OTcl čime se otklanja potreba za prevođenjem i pojednostavljuje se izmena parametara Veza između dve hijerarhije objekata se uspostavlja posebnim hijerarhijom OTcl linkovanih objekata (sl41)

25

sl41 Prikaz ns-2 hijerarhije objekata

Kao i svaki drugi simulator i ns-2 ne implementira ili zanemaruje pojedine detalje protokola pa se stoga prethodno mora konsultovati dokumentacija [nsD1] [nsD2] a naročito dokument [nsD3] Ovde će biti navedena samo ograničenja koja se odnose na temu ove teze Ograničenja TCP implementacije

bull jednosmerne konekcije - ispravne i proverene implementacije varijanti TCP protokola podržavaju samo jednosmernu razmenu tj odredište konekcije može da šalje samo ACK-ove prema izvoru To znači da se efekti svojstveni dvosmernoj komunikaciji (kompresija potvrda i sinhronizacija suprotnih faza [ZSC91]) ne mogu proučavati U trenutku pisanja ove teze Tahoe Reno New Reno i SACK poseduju i implementacije za dvosmerne konekcije ali one nisu do kraja ispitane

bull dinamičko oglašavanje veličine prozora nije podržano ndash u realnim implementacijama odredište može da oglašava veličinu rwnd prozora i tako utiče na cwnd U ns-2 simulatoru cwnd prozorom se upravlja samo posredstvom ACK-ova i RTO mehanizma

bull ne postoji SYNFIN inicijalizacija i raskidanje veze ndash ovi elementi TCP protokola su jasno određeni i predstavljaju predmet realne implementacije a detalji se mogu naći u [Ste98]

bull veličina TCP segmenta je fiksna ndash i određuje se kao jedan od parametara pre početka simulacije

bull segmenti podataka i potvrda su numerisani u jedinicama paketa ndash ovo ne predstavlja realno ograničenje ali se razlikuje od većine realnih implementacija koje obavljaju numeraciju u bajtovima

ECN implementiran na jednosmernim konekcijama je ograničen nemogućnošću izvora da proveri da li odredište podržava ECN Promenljive koje označavaju ECN bitove se razlikuju u imenima u odnosu na preporuku RFC 3168 (videti [nsD2]) Ns-2 modeli odbacivanja paketa na jednosmernim TCP konekcijama deluju samo na putanji podataka odn ni jedan ACK se ne može odbaciti Pouzdanost ACK putanje se podrazumeva u mnogim radovima To se opravdava činjenicom da su potvrde kumulativne pa bi se gubitak jednog ACK-a nadoknadio prolazom sledećeg Realni gubici ACK-ova su mnogo kompleksniji Fast Recovery zavisi od prijema tri dvostruka ACK-a a prelaz iz kontrole zagušenja prozorom na kontrolu istekom RTO intervala zavisi od trenutaka pristizanja ACK-ova Sa druge strane ns-2 nudi veliki broj modela odbacivanja paketa Odbacivanje se može obavljati po zadatoj listi što je veoma korisno za ispitivanje detalja algoritama kontrole zagušenja Paketi se takođe mogu odbacivati sa verovatnoćama koje pripadaju uniformnoj eksponencijalnoj Pareto i dr raspodelama To je veoma korisno pri simulaciji realnih kanala sa jednostavnim modelom greške Simulator nudi i mogućnost da korisnik zada parametre kanala sa više stanja greške Pri ispitivanju protokola na slojevima transporta ili aplikacije OSI modela u ns-2 simulatoru potrebno je navedenim redosledom programski zadati sledeće detalje bull topologiju čvorova i linkova bull konfiguraciju topologije

26

bull propusne opsege i kašnjenja linkova bull kapacitete bafera čvorova bull modele grešaka na linku bull tehniku upravljanja redovima za čekanje

bull konfiguraciju protokola na sloju transporta bull pridruživanje protokola transporta formiranim čvorovima bull parametre protokola sloja transporta bull povezivanje tačaka izvora i odredišta na sloju transporta

bull uspostavu praćenja (engl tracing) parametara TCP protokola na odgovarajućoj konekciji bull konfiguraciju saobraćaja ili aplikacionih protokola

bull pridruživanje izvora saobraćaja na transportni protokol bull parametre saobraćaja

bull praćenje (engl tracing) na željenim linkovima ili opšte praćenje simulacije Primeri i organizacija test programa se mogu videti u ~tcltest i ~tclex poddirektorijumima ns-2 instalacije Predefinisane vrednosti parametara svih protokola implementiranih na ns-2 simulatoru se mogu videti u datoteci ~tcllibns-defaultstcl 43 Implementacija test scenarija U prethodnom izlaganju je objašnjeno da ne postoji jednostavan način simulacije Internet protokola Osnovna pretpostavka uspešne simulacije jeste formiranje više test scenarija Istraživači koji su detaljno proučavali ovu oblast su uspeli da postave okvir metodologije ispitivanja U ovom radu je posvećena posebna pažnja implementaciji tih preporuka [AF99] [FP01] Uspešna i primenljiva istraživanja zahtevaju da test scenariji sadrže

bull veći broj test topologija skupova parametara i saobraćaja bull DropTail RED ili neku od rasprostranjenih tehnika upravljanja redovima za čekanje bull nekoliko različitih TCP ili UDP tokova koji dele zajednički link bull više različitih veličina segmenata i paketa bull dovoljan kapacitet bafera izvora koji obezbeđuje da se konekcijom najčešće upravlja pomoću cwnd

prozora bull poređenja jedne osnovne i jedne ili više eksperimentalnih TCP verzija bull bar neko od perspektivnih TCP poboljšanja (SACK ECN timestamps PAWS) bull testove veoma rasprostranjenih protokola viših slojeva (HTTP FTP) bull scenarije u kojima se saobraćaj generiše iz prethodno sakupljenih praćenja generisanih od strane

aplikativnog sloja Da je većina navedenih preporuka implementirana može se videti na šemi upotrebljene test platforme (sl42) Platforma ilustruje upotrebu raznovrsnosti na sloju aplikacije transporta i mreže OSI modela kao i raznovrsnost topologija 44 Ciljevi proučavanja i posmatrane metrike performansi Ciljevi ove teze su nagovešteni u uvodnom delu Iz ranijeg izlaganja se može napraviti nekoliko zaključaka koji otvaraju put istraživanju ove teze SACK i NewReno će uskoro postati dominantne TCP implementacije SACK poseduje očigledne prednosti u pogledu oporavka od grešaka ali zahteva intenzivnije procesiranje i poseduje veći premašaj kontrolnih podataka u zaglavlju paketa Postojeća ispitivanja nisu istražila da li NewReno sa dodatnim poboljšanjima kao što je ECN može dostići performanse SACK implementacije U

27

ovoj tezi će biti provereno da li je to moguće i ako jeste navešće se okvir pri kojem su takvi rezultati dobijeni Takođe će biti ispitano ponašanje RED modifikacija nazvanih gentle RED i adaptive RED

Da bi se dobili primenljivi rezultati svaka od navedenih vrsta testova će biti obavljana na različitim topologijama različitim parametrima topologija različitom broju aktivnih konekcija i različitim parametrima posmatranih mehanizama

Svi opisani ciljevi istraživanja se odnose na TCP i AQM performanse bitne iz perspektive krajnjeg korisnika ili iz perspektive optimalne upotrebe mrežnih resursa Stoga će i posmatrane metrike najvećim delom biti takve

FTP CBRConstant Bit Rate

UDPSloj Transporta

gentleRED+ECNadaptiveRED+ECN

gentle REDadaptive REDDropTail

100Mbs

Topologija

100M

bs 15Mbs

40ms

r0 r1

s0

s9 d9

d015Mbs

100Mbs

40mss0

s9

d0

d13

r0 r2 r1

s10 s11 s12 s13

Topologijerazlicite slozenosti

kasn

jenj

e Parametri

linkova

Kanal samodelomgreske

Sloj mreze

NewReno +ECN SACK

Saobracaj

sl42 Test platforma korišćena u ovoj tezi

441 TCP metrike Jedna od osnovnih metrika ispitivanja mrežnih sistema je iskorišćenost propusnog opsega (engl throughput) Ona ipak neće biti prikazana u većini testova ove teze Razlog za tu odluku je proizašao upravo iz rezultata uvodnih testova koji su pokazali da su TCP mehanizmi dovoljno adaptivni i da u svim test scenarijima koriste skoro ceo propusni opseg Ispitivanja su takođe pokazala da je efektivna brzina razmene podataka (engl goodput) bolja metrika za praćenje efikasnosti različitih AQM i TCP mehanizama Ova metrika je jedini bitan pokazatelj performansi za krajnjeg korisnika u scenarijima velikih FTP prenosa

Da bi se TCP i AQM mehanizmi mogli uporediti bitno je posmatrati učestanost odbacivanja paketa Poređenje ovog parametra sa efektivnom brzinom razmene podataka je od presudnog značaja

28

Četvrti bitan parametar za opis svojstava TCP tokova će biti indeks pravičnosti (engl fairness index) [J91] Ovaj parametar određuje metriku pravičnosti u smislu različitosti brzine razmene podataka za posmatrani broj tokova u više korisničkom sistemu Iako je moguće definisati i mnoge druge metrike indeks pravičnosti je jedan od najrasprostranjenijih i definisan je jednakošću

⌠

⌠

=

=

⌡

= n

ii

n

ii

xn

xFI

1

2

2

1 (41)

U izrazu (41) promenljive xi predstavljaju neko merilo brzine razmene podataka (goodput ili throughput) FI vrednosti variraju u rasponu 0 do 1 pri čemu vrednost 1 označava potpunu ravnopravnost xi protoka Pri detaljnom proučavanju pojedinih test scenarija će se umesto FI vrednosti koristiti kumulativan proces pristizanja ACK potvrda i tako će se steći bolji uvid u dešavanja u toku trajanja testa 442 RED i DropTail metrike Prethodno navedena metrika učestanosti gubitaka oslikava i ponašanje RED i DropTail mehanizama Pored nje će biti prikazana i promena efektivne iskorišćenosti propusnog opsega uskog grla u odnosu na promenu dužine reda za čekanje Efikasnost RED tehnika će biti grafički prikazana uz pomoć odnosa trenutne (redQ) i prosečne (avgQ) popunjenosti bafera Posmatranjem tih dijagrama se može uočiti učestanost pojave prelaska iz RED ponašanja u DropTail ponašanje Takođe se može zaključiti da li su RED parametri pravilno usaglašeni sa saobraćajem 45 Opis test scenarija Detaljan opis test scenarija će biti priložen uz opis svakog konkretnog testa u poglavlju 5 Svi bitni test parametri su navedeni u dodatku B Ovde su navedene zajedničke osobine svih testova Osnova svakog ispitivanja je izbor topologije Na sl 43 su prikazane dve vrste upotrebljenih topologija Bitno je napomenuti da ns-2 simulator pruža mogućnost nezavisne konfiguracije svakog od slojeva OSI modela Stoga će se načinom povezivanja saobraćaja učiniti da u nekim testovima bude upotrebljeno manje čvorova nego što je prikazano na sl 43(a) odn sl 43(b) Čvorovi označeni sa si predstavljaju izvore saobraćaja ri modeluju rutere dok su di odredišta posmatranih tokova Najveći deo ispitivanja će biti obavljen na topologiji net10 dok će topologija netMultiC poslužiti za testiranje spoja bdquoDropTail mreželdquo i mreže koja podržava ECN i savremene AQM tehnike Između rutera r0 i r1 u topologiji net10 odn rutera r0 i r2 u topologiji netMultiC će u različitim testovima biti konfigurisane ili DropTail ili gentle RED ili adaptive RED discipline reda za čekanje Kada na linku bude postavljen neki od RED mehanizama variraće se samo dužina bafera (QL) Težinski koeficijent usrednjavanja RED bafera će uvek biti wq=0002 Granice RED regiona će biti postavljene u skladu sa najčešćim preporukama i to maxth = 3minth a minth = 025QL U zavisnosti od postavke verovatnoće maxp posmatraće se agresivan gentle RED (maxp=01) i konzervativan gentle RED (maxp=002) U saglasnosti sa radovima [MBDL99] i [CJOS01] bi se moglo reći da je ovakav izbor nedovoljan za podešavanje optimalnih RED performansi Ipak ciljevi ispitivanja se odnose na širok spektar situacija pa se ovakva odluka može opravdati Kada na linku bude postavljen adaptive RED ovakva odluka će npr omogućiti procenu eventualnog poboljšanja nastalog upotrebom adaptivnosti Takođe se može reći da u realnim uslovima stalno praćenje i optimizacija RED parametara nisu mogući U simulacionom okruženju se ispituju NewReno sa ECN podrškom i SACK Pretpostavlja se da će ECN umanjiti broj odbačenih NewReno segmenata dok će se SACK oslanjati samo na sopstvene mehanizme za oporavak od gubitaka Tako se istovremeno mogu ispitivati efekti zagušenja i odbacivanja paketa Konačno mogući izbor promene više parametara bi bio ograničen prostorom za prikaz i smisaonu analizu rezultata

29

U svim test scenarijima čvorovi će biti podeljeni u dve grupe Na jednu grupu će biti priključen NewReno mehanizam sa podrškom za ECN dok će druga grupa čvorova koristiti SACK Obe grupe čvorova će prenositi FTP saobraćaj Čvorovi s10 s11 s12 i s13 će biti isključivo zaduženi za formiranje dodatnog opterećenja na linku r2 ndash r1 i prenosiće FTP saobraćaj uz pomoć NewReno mehanizma bez podrške za ECN U svim scenarijima će se između čvorova s9 i d9 prenositi UDP saobraćaj konstantne učestanosti

(a) (b)

sl43 (a) Topologija net10 (b) topologija netMultiC

Parametri linkova uskog grla koji će u svim testovima biti konstantni su propusni opseg 15Mbs i kašnjenje 40ms Razlozi za izbor ovih vrednosti su višestruki Promena propusnog opsega sa 100Mbs na 15Mbs omogućava jasno posmatranje svih efekata kontrole zagušenja Ovaj izbor takođe omogućuje da relativno mali broj tokova stvori zagušenje što je veoma bitno za obradu rezultata testova Konačno savremene tehnike WAN prenosa imaju sličan propusni opseg Kašnjenje od 40ms je izabrano kao rezultat kompromisa Kašnjenje današnjih konekcija može biti nešto kraće ali i višestruko duže npr satelitski linkovi Granularnost tajmera svih TCP tokova je 100ms Ovakva postavka se podudara sa implementacijama u mnogim realnim operativnim sistemima Maksimalna veličina segmenta (MSS) je 1460 bajta što odgovara najvećoj realnoj veličini segmenta Posledice ovakve odluke su dvostruke Sa jedne strane razmena podataka najvećom MSS vrednošću omogućuje potencijalno najkraće trajanje razmene Sa druge strane ovakav izbor povećava verovatnoću da segment u realnoj mreži bude fragmentiran ili čak odbačen Fragmentacija može dovesti do rutiranja delova paketa po različitim putanjama što se može odraziti na izmenjen redosled pristizanja paketa ili na RTO mehanizam kontrole zagušenja U simuliranoj postavci se ovi efekti ne mogu pojaviti a izučavanje takvih pojava može biti cilj narednih istraživanja Inicijalni prozor koji oglašava odredište rwnd za svaku konekciju iznosi 30 segmenata (odn 438 kB) Odnos ovog parametra i proizvoda propusni opseg middot kašnjenje je veoma bitan za sve konekcije Iako je posmatrana topologija dovoljno jednostavna i iako se vrednost ovog proizvoda može precizno izračunati pretpostavićemo da on iznosi 15kB

kBbit

mssMbdelaybandwidth

15 000 120

)402(51

==

sdotsdot=times

Ova vrednost proizvoda omogućuje da mreža u jednom trenutku pohrani približno 10 segmenata To znači da u slučaju da kroz usko grlo prolazi samo jedna konekcija optimalna dužina bafera (QL) bi bila rwnd ndash bandwidth x delay = 30 seg ndash 10 seg = 20 seg U tom slučaju se u mreži ne bi pojavljivali gubici a resursi bi bili optimalno iskorišćeni U realnim situacijama granice rwnd prozora i bandwidth x delay proizvoda mogu dovesti do tri uzroka gubitaka segmenata i zagušenja

1 zagušenje koje uzrokuje mreža

delaybandwidthQL timesle

30

2 zagušenje koje uzrokuje veličina prozora ( u slučaju da usko grlo deli n tokova)

⌠=

len

iirwndQL

1

3 gubici paketa usled grešaka ili dejstva AQM tehnika

⌠=

gttimes+n

iirwnddelaybandwidthQL

1

U testovima će biti ispitivane dužine bafera od 4 12 36 48 72 i 108 segmenata čime će biti obrađena dešavanja u bar prva dva nabrojana područja zagušenja Pregled svih ostalih izmenljivih parametara je naveden u dodatku C

31

5 Rezultati testova 51 Performanse iskorišćenja mrežnih resursa Ovaj deo ispitivanja bi trebalo da proveri koliko efikasno različite discipline upravljanja baferima koriste propusni opseg uskog grla Testiranje je obavljeno na topologiji net10 (sl 43) u rasponu od 2TCP+1UDP do 18TCP+1UDP aktivnih konekcija Broj konekcija je ravnomerno raspodeljen između NewReno+ECN i SACK implementacija TCP protokola Svi tokovi su startovali ili istovremeno ili unutar intervala trajanja 1s Testovi sa manje aktivnih tokova su trajali 150s ili 180s (odn od oko 940 do 1125 RTT intervala) Testovi sa 19 tokova su trajali 350s ili 380s (odn oko 2190 ili 2375 RTT intervala) Kašnjenja od izvora si do rutera r0 i od odredišta di do rutera r1 su jednaka i iznose 1ms Za poređenje iskorišćenja mrežnih resursa su korišćene metrike

bull efikasnost efektivne brzine razmene podataka GEff - metrika je jednaka odnosu zbira svih efektivnih brzina razmene (engl goodput) i propusnog opsega linka uskog grla

sMb

igoodputGEff i

51

)(=

Optimalna vrednost ovog parametra je 09533 i označava da TCP tokovi koriste sav propusni opseg (umanjen za propusni opseg UDP toka) za razmenu novih podataka bez retransmisije

bull Procenat odbacivanja paketa (Drop ) ndash metrika je jednaka odnosu broja odbačenih paketa na linku

uskog grla i ukupnog broja paketa koji se pojavljuju na tom linku

sum

sum

+=

i

i

iratedropithroughput

iratedropDrop

)(_)(

)(_[]

Zbog ograničenosti prostora za prikaz veći deo rezultata će biti prikazan samo grafički 511 Testovi sa dva TCP toka Da bi se shvatili osnovni odnosi posmatranih mehanizama testiranje je započeto upotrebom dve aktivne TCP konekcije i jednog UDP toka koji stvara pozadinski saobraćaj Pored procene ponašanja nastalog usled promene dužine bafera ova testiranja će poslužiti i kao referenca poređenja efekata koji nastaju porastom broja aktivnih konekcija

0 8

0 8 2

0 8 4

0 8 6

0 8 8

0 9

0 9 2

0 9 4

4 1 2 3 6 4 8 7 2 1 0 8

Q L [ p k t ]

Goo

dput

Effi

ciec

y

D r o p T a i lR E D 2 R E D 1 0 a d a p t R E D

(a)

32

005

115

225

335

445

4 12 36 48 72 108

QL[pkt]D

rop

[]

DropTailRED 2RED 10adapt RED

(b)

sl 51 Dve TCP konekcije (a) ukupan GEff u zavisnosti od dužine bafera QL (b) ukupan procenat odbacivanja paketa u zavisnosti od dužine bafera QL

Posmatranjem grafika sl 51a i sl 51b se lako mogu uočiti dve zone U oblasti u kojoj je QLlt 36pkt resursi mreže se koriste nedovoljno efikasno Najveće razlike između posmatranih mehanizama upravljanja baferima se uočavaju pri dužini QL= 4pkt U skladu sa uvodim izlaganjem može se zaključiti da je ova dužina bafera manja od bandwidth-delay proizvoda i stoga nije u stanju da opslužuje fizičke karakteristike linka uskog grla Kada se u takvoj situaciji primeni DropTail mehanizam bafer biva brzo popunjen pa se novi paketi odbacuju u grupama Determinističko funkcionisanje DropTail discipline dovodi do toga da paketi obe TCP konekcije budu istovremeno odbačeni To dovodi do učestale aktivacije SACK i New Reno mehanizama izbegavanja zagušenja pa se propusni opseg uskog grla ne može efikasno koristiti Takođe je zanimljivo primetiti da RED mehanizmi nešto bolje koriste propusni opseg Razlika GEff vrednosti između RED i DropTail disciplina iznosi oko 23kbs odn oko 115kbs po svakoj konekciji Bitno je uočiti i činjenicu da pri QL=4pkt sve RED discipline poseduju skoro potpuno jednake GEff vrednosti Obe primećene pojave imaju isti uzrok ali je bitno objasniti rezultat takvog ponašanja Iz jedne perspektive bi se moglo pretpostaviti da trenutna popunjenost RED bafera (redQ) osciluje brzo velikom amplitudom i relativno pravilno U tom slučaju bi dejstvo RED zone (minth maxth)=(13)[pkt] bilo relativno kratkotrajno I pri tako kratkom dejstvu paketi bi bili odbacivani slučajno i pojedinačno a ne u grupama kao u slučaju DropTail discipline To bi objasnilo razliku performansi između ove dve klase mehanizama Druga mogućnost je da redQ učestalo izlazi iz RED zone što bi značilo da RED neadekvatno obaveštava TCP mehanizme o mogućem nivou zagušenja U tom slučaju intervali agresivnog i konzervativnog ponašanja TCP mehanizama imaju veću ulogu u izbegavanju zagušenja od primenjenih AQM tehnika Slika sl52 uglavnom potvrđuje drugu mogućnost

sl 52 Dve TCP konekcije - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Procesi koji nastaju u slučaju krajnje neadekvatnog kapaciteta bafera se najlakše mogu pratiti poređenjem sl52 i sl53a Na početku obe konekcije agresivno startuju (slow start) i premašuju kapacitet bafera na linku uskog grla Zatim konekcije smanjuju cwnd međutim ne dobijaju dovoljno novih ACK-ova da bi

33

povećale svoje prozore u fazi congestion avoidance odn fast recovery U naredne tri sekunde obe konekcije su naizgled sinhronisane u congestion avoidance fazama pa bafer biva periodično prepunjen i nedovoljno iskorišćen Zatim u intervalu (38s 47s) konekcija sa SACK mehanizmom pokazuje bolje sposobnosti oporavka od gubitaka paketa dok Newreno konekcija prolazi kroz RTO interval Bafer je nedovoljno iskorišćen jer SACK konekcija u congestion avoidance fazi šalje jedan po jedan paket Nakon ovog intervala RED mehanizam uspeva da spreči sinhronizaciju tokova Bitno je uočiti da u daljem toku testa SACK konekcija ne zadržava stalnu dominaciju u korišćenju resursa mreže Pri upotrebi DropTail discipline posmatrana konfiguracija mreže stvara optimalne preduslove za formiranje globalne sinhronizacije Posmatranjem sl53b se uočava da je ovaj efekat ipak izbegnut

(a)

(b)

sl 53 Dve TCP konekcije - Promena veličine prozora zagušenja (cwnd) (a) RED (b) DropTail Iako je većina testova ove teze pokretala TCP konekcije istovremeno globalna sinhronizacija se nije pojavila ni u jednom od njih U radu [ZSC91] su prvi put obrađeni razni efekti sinhronizacije paketskog saobraćaja U vremenu objavljivanja tog rada Reno je bio još uvek ekpsrimentalni TCP mehanizam pa su testovi bili obavljeni upotrebom TCP Tahoe varijante koja je posedovala samo stanja slow start i congestion avoidance U savremenim TCP implementacijama broj stanja kontrole zagušenja je povećan Pored toga New Reno sa osobinom parcijalnog potvrđivanja i izlaska u slow start i SACK sa mogućnošću precizne identifikacije izgubljenih paketa smanjuju verovatnoću sinhronisanih reakcija na zagušenje Takođe je evidentna činjenica da sinhronizacija nije uočena ni u novijim radovima u ovoj oblasti Stoga bi se sa velikom pouzdanošću moglo pretpostaviti da TCP Reno i njegovi derivati mogu da izbegnu globalnu sinhronizaciju i bez saradnje sa AQM mehanizmima Glavni zaključak ovog dela izlaganja je određen slikama sl52 i sl53 koje ukazuju na to da usamljeno dejstvo AQM mehanizma ne može bitno unaprediti performanse značajne za krajnjeg korisnika u slučaju izuzetno malih kapaciteta bafera Neposredno iznad granice zagušenosti uslovljene fizičkim parametrima mreže (QLasymp10 pkt) sve posmatrane discipline znatno bolje koriste propusni opseg uskog grla Na sl54 je navedena ilustracija promene

34

popunjenosti bafera za agresivni gentle RED (maxp=01) i adaptive RED pri fizičkoj dužini bafera QL=36pkt Slike ilustruju da RED parametri nisu optimalno postavljeni jer redQ i dalje učestalo izlazi iz zone (minth maxth) = (9 27) [pkt] Slučaj na sl54a ilustruje da je verovatnoća preventivnog odbacivanja paketa suviše velika pa se redQ često nalazi ispod RED zone Mnogo zanimljivije je ponašanje adaptive RED mehanizma koji u prvih 50s pruža zadovoljavajuće upravljanje Analizom eksperimentalnih rezultata je utvrđeno da u šestdesetoj sekundi nastupa nepravedna raspodela propusnog opsega (engl lockout) Praćenjem promene veličine cwnd je ustanovljeno da postoje intervali u kojima obe TCP konekcije pokušavaju da šalju pakete sličnim intenzitetom i time brzo popunjavaju bafer uskog grla Slika sl 54b ilustruje da u takvim situacijama adaptive RED nije u stanju da se adekvatno prilagodi RedQ relativno retko ulazi u zonu (maxth QL) ali su izleti ispod RED zone učestali Ova pojava se može objasniti na sledeći način Prosečna popunjenost RED bafera (avgQ) je uglavnom relativno visoka (18pkt do 20pkt) Pri povećanju redQ vrednosti iznad avgQ granice konstanta usrednjavanja wq suviše precizno prati povećanje što dovodi do naglog skoka učestanosti odbacivanja paketa Posledica toga je ulaz TCP mehanizama u stanja fast retransmitfast recovery što dovodi do nedovoljne popunjenosti RED bafera Značajno je napomenuti da je izabrana wq vrednost u skladu sa trenutno važećim preporukama i ažurira avgQ u intervalima dužim od vremena obilaska (RTT) Nastalo podbacivanje RED zone je stoga posledica malog broja tokova koji se u pojedinim trenucima mogu slično ponašati Ispravnost ove tvrdnje će biti proverena u sredinama sa većim brojem tokova gde se očekuje da će povećanje nivoa multipleksiranja popraviti stabilnost avgQ procene Ilustrovani primeri preliminarno potvrđuju da postoje okolnosti pod kojima i usavršeni RED mehanizmi ispoljavaju znatnu osetljivost na postavke parametara

(a)

(b)

sl54 Dve TCP konekcije - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

35

512 Testovi sa šest TCP tokova Na sl 55a i sl 55b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa šest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

088

089

09

091

092

093

094

4 12 36 48 72 108

QL[pkt]

Goo

dput

Effi

cien

cyDrop TailRED 2RED 10Adapt RED

(a)

0

1

2

3

45

6

7

8

9

4 12 36 48 72 108

QL[pkt]

Dro

p [

]

Drop TailRED 2RED 10adaptive RED

(b)

sl55 Šest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafer (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Test sa šest aktivnih konekcija je nešto realniji u odnosu na testiranja obavljena u naslovu 511Stoga se iz rezultata sa sl55 mogu izvesti dovoljno dobri zaključci koji porede posmatrane AQM mehanizme Rezultati prikazani na ovoj slici ukazuju da se najbolje performanse dobijaju upotrebom adaptivnog RED i agresivnog gentle RED mehanizma Kroz testiranja koja će biti obavljena u nastavku ove teze će biti pokazano da konzervativna gentle RED varijanta ima uglavnom slično ponašanje kao DropTail mehanizam pa se stoga njena upotreba ne može opravdati Rezultati dobijeni povećanjem broja tokova (sl55) u relativnom smislu pokazuju slične rezultate kao u slučaju scenarija sa dve TCP konekcije I dalje su uočljive dve zone u kojima se merene performanse bitno razlikuju Razlozi postojanja ovih zona su objašnjeni u prethodnom izlaganju Takođe u slučaju premalog kapaciteta bafera (QL=4pkt) AQM mehanizmi nude primetno poboljšanje u odnosu na DropTail posmatrano iz perspektive krajnjeg korisnika Razlike nastale povećanjem broja konekcija su primetne u apsolutnim iznosima U oblasti nedovoljnog kapaciteta bafera (QLlt 36pkt) vrednost efikasnosti efektivne brzine razmene podataka (GEff) je bitno povećana ali je povećan i procenat odbacivanja paketa Posmatranjem promena popunjenosti bafera se uočava da su obe pojave posledica povećanog intenziteta multipleksiranja TCP tokova koje rezultuje povećanjem efektivne agresivnosti slanja paketa u RED bafer Poređenjem sl52 i sl56 se lako može uočiti da je broj vremenskih intervala popunjenosti gornjeg dela kapaciteta bafera bitno povećan

36

sl 56 Šest TCP konekcija - Ponašanje RED mehanizma pri veoma kratkoj dužini bafera

Kao i u slučaju dve aktivne konekcije na sl 57a i sl57b su prikazana dešavanja u RED baferu pri dužini QL=36pkt

(a)

(b)

sl57 Šest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

Poređenje sl54 i sl57 donosi sledeće bitne zaključke U slučaju šest aktivnih TCP konekcija i gentle RED mehanizma verovatnoća maxp je skoro optimalno prilagođena u smislu upotrebe mrežnih resursa Adaptivni RED mehanizam je takođe unapredio upravljanje veličinom redQ koja sada ne izlazi toliko često i intenzivno u oblast (0 minth) U ovom trenutku je važno uočiti još jednu izuzetno pozitivnu osobinu adaptivnog algoritma Za razliku od agresivne gentle RED varijante čija se avgQ vrednost skoro udvostručila povećanjem broja TCP konekcija adaptivni RED je uspeo da održi avgQ na polovini RED

37

zone Ova osobina se direktno odražava na ravnomerniju raspodelu kašnjenja što predstavlja značajnu podršku za QoS koncept koji se može smatrati nadgradnjom AQM mehanizama Zanimljivo je da ova činjenica nije dovoljno naglašena u originalnom radu [FGS01] koji je uglavnom ispitivao brzinu adaptacije i uticaj izbora parametara adaptivnog RED algoritma Konačno treba naglasiti da primena adaptive RED algoritma dovodi do kratkih intervala oscilacija avgQ vrednosti (oko 70s 100s 160s) ali oni nisu toliko učestali i intenzivni kao u slučaju prikazanom na sl54 Ovime je potvrđena teza da se u uslovima povećanog multipleksiranja smanjuje mogućnost istovetnog ponašanja više konekcija Stoga i oscilacije avgQ vrednosti postaju manje izgledne 513 Testovi sa osamnaest tokova Na sl 58a i sl 58b su prikazane metrike iskorišćenja mrežnih resursa u scenariju sa osamnaest aktivnih TCP tokova i jednim UDP tokom koji formira pozadinski saobraćaj

0905

091

0915

092

0925

093

0935

094

4 12 36 48 72 108 200

QL[pkt]

Goo

dput

Effi

cien

cy

Drop TailRED 2RED 10adapt RED

(a)

0

2

4

6

8

10

12

14

4 12 36 48 72 108 200

QL [pkt]

Dro

p [

]

Drop TailRED 2RED 10adapt RED

(b)

sl58 Osamnaest TCP konekcija (a) ukupan GEff u funkciji kapaciteta bafera (b) ukupan procenat odbačenih paketa u funkciji kapaciteta bafera

Prikazane slike ilustruju da povećanjem broja konekcija RED mehanizmi mogu da izgube prednosi u odnosu na DropTail u posmatranim aspektima Obe testirane metrike pokazuju da je DropTail mehanizam iskazao nešto bolje ponašanje u situacijama u kojima je kapacitet bafera bio srazmerno mali (QLle48pkt) Ovakav ishod se delimično može objasniti posmatranjem sl59 Pri malom kapacitetu bafera ni jedan od RED mehanizama nije uspeo da održi avgQ vrednost unutar RED zone Usled toga RED baferi su ispoljavali izrazita DropTail svojstva Paketi koji nisu naišli na premašaj bafera su mogli biti odbačeni sa velikom verovatnoćom usled dejstva RED mehanizma u gorenjem delu RED zone Za razliku od situacije sa dve aktivne konkcije ovakvo delovanje RED mehanizma ne fokusira avgQ u RED zonu što znači da je odacivanje paketa može dovesti samo do pogoršanja u pogledu iskorišćenja mrežnih resursa

38

(a)

(b)

sl59 Osamnaest TCP konekcija - Promena popunjenosti RED bafera (a) gentle RED (maxp=01) (b) adaptive RED

U posmatranom test okruženju najzanimljivije ponašanje poseduje adaptive RED mehanizam koji u opsegu 12leQLle108 [pkt] ima najmanje oscilacije GEff vrednosti Preplitanje GEff vrednosti ostalih mehanizama ilustruje njihovu veću osetljivost na tok dešavanja u mreži sa velikim brojem istovremenih FTP konekcija Na sl58b se može primetiti da adaptive RED mehanizam naglo povećava procenat odbacivanja paketa za QL=72pkt i QL=108pkt Ovakvo ponašanje je navelo autora da obavi dodatne testove usled sumnje u ispravnost rezultata i nedostatka sličnih referenci u radovima drugih autora Dodatna testiranja su izvedena uz povećanje trajanja testova i upotrebu manjih koraka promene dužine bafera u intervalu QL=36pkt do QL=108pkt Svi dodatni testovi su upoređivani sa agresivnim gentle RED varijantama (maxp=01 maxp=02) Značajni rezultati su prikazani na sl510 i sl511

(a)

39

(b)

sl510 Osamnaest TCP konekcija dužina bafera QL=72pkt adaptive RED (a) promene u adaptive RED baferu (b) učestanost odbacivanja paketa na linku uskog grla

Za razliku od gentle RED mehanizama koji u scenarijima sa nedovoljnim kapacitetom bafera imaju tipično DropTail ponašanje adaptive RED poseduje sposobnost konvergencije prema RED zoni Konvergencija se ostvaruje konstantno povećanim procentom odbacivanja paketa (sl510b) Ipak merenja su pokazala da to svojstvo zavisi i od fizičkog kapaciteta bafera i od dešavanja u mreži Pri QL=36pkt je utvrđeno da se konvergencija ne može uspostaviti ni nakon 1000s pri QL=48pkt vrednost avgQ je ušla u RED zonu nakon 800s pri QL=55pkt za oko 200s za QL=60pkt za oko 80s za QL=62pkt za oko 100s a za QL=72pkt za oko 40s U svim scenarijima u kojima je uspostavljena konvergencija vrednost avgQ je uspostavljena blizu sredine RED zone

Procenat odbacivanja paketa pri QL=108pkt je takođe rezultat pozicioniranja avgQ vrednosti na sredinu RED zone do čega je došlo nakon svega nekoliko sekundi Pri ovoj dužini bafera je i agresivni gentle RED posedovao AQM svojstva tako da ni avgQ ni redQ vrednost nije izlazila iz zone (minth maxth) Razlika u intenzitetu odbacivanja paketa (sl511) dve RED discipline je posledica relativne pozicije avgQ vrednosti

(a)

(b)

sl511 Osamnaest TCP konekcija dužina bafera QL=108pkt Učestanost odbacivanja paketa za (a) adaptivni RED (b) gentle RED

40

Skoro slučajno primećena pojava povećanog odbacivanja adaptive RED mehanizma dovodi do nekoliko bitnih zaključaka Autor smatra da se promena pozicije avgQ vrednosti nakon više stotina sekundi može opisati kao promena stanja u mreži a ne samo kao adaptacija na uslove mreže kao što je navedeno u radovima [FGS01] i [CC02] Različita vremena i neizvesnost uspostave avgQ konvergencije navode na zaključak da ova pojava nije uslovljena samo kapacitetom bafera već i stanjem mreže Drugi bitan zaključak je da u slučaju pojave konvergencije adaptive RED teži da postavi avgQ na sredinu RED zone Ispravnost ovakvog ponašanja zavisi namene posmatranog linka Ako se na linku zahteva manja varijacija kašnjenja adaptive RED će postojanim redQ i avgQ vrednostima prikazati pozitivne efekte Ako je efikasan prenos ciljna performansa posmatranog linka potrebno je obaviti pažljivu konfiguraciju adaptive RED parametara u skladu sa predviđenim intenzitetom i tipom saobraćaja a ne u skladu sa važećim preporukama QL= 4middotminth maxth =3middotminth Takva podešavanja mogu biti skupa i naporna jer je u pojedinim situacijama precizno predviđanje karakteristika saobraćaja teško ostvarivo 514 Performanse iskorišćenja mrežnih resursa ndash zaključak U ovom delu teze su praćene metrike iskorišćenja mrežnih resursa i to ukupna efikasnost efektivne brzine razmene podataka i ukupan procenat odbačenih paketa Uslovi testiranja su bili u potpunosti ravnopravni a test scenariji su se razlikovali samo u broju aktivnih konekcija kapacitetima bafera i primenjenim mehanizmima upravljanja redovima za čekanje Osnovni zaključak je da pri razumnim kapacitetima bafera TCP mehanizmi ostvaruju zavidno iskorišćenje propusnog opsega linka uskog grla Svi prikazani testovi su obavljeni upotrebom FTP izvora Za posmatrane metrike ovakav izbor se može smatrati konfiguracijom najgoreg slučaja Razlog ove tvrdnje proističe iz činjenice da svi izvori u svakom trenutku pokušavaju da proslede podatke boreći se za resurse mreže Povećanje broja takvih konekcija dovodi do izuzetno agresivnog pristupa baferu na linku uskog grla Takvo ponašanje se može shvatiti kako DoS (engl denial of service) napad upravljivim tokovima Upravo je to razlog zbog kojeg su AQM mehanizmi popustili u scenariju u kojem je aktivirano osamnaest TCPFTP tokova Na osnovu uočenih karakteristika se može pretpostaviti da bi AQM mehanizmi prikazali bolja svojstva u slučaju razmene ograničenih količina podataka i povremenih isključenja pojedinh izvora Ns-2 simulator pruža mogućnost simulacije ovakvih situacija upotrebom web servera i keša sa odgovarajućom raspodelom veličine objekata (datoteka web stranica elemenata web stranica ) Pokretanjem takvih simulacija prostor postavki parametara raste skoro eksponancijlno Stoga je neophodno obaviti dosta obimna preliminarna merenja realnog ponašanja nekoliko web servera i uneti izmerene statistike u simulacionu konfiguraciju Rezultati takvih merenja su retko javno dostupni dok je sam poduhvat tih razmera izazov dostojan angažovanja jednog solidno opremljenog istraživačkog tima Zato će istraživanja takvog okruženja ostati predmet nekog budućeg rada Konačno za razliku od originalnih radova [FGS01] i [FKSS99] je uočeno da se adaptivni RED mehaizam ne može uvek adaptirati na uslove saobraćaja Ista tvrdnja važi i za gentle RED varijante pa se može reći da oba RED unapređenja i dalje zavise od konfiguracije parametara Takođe je uočeno da adaptive RED može izmeniti stanje mreže i postaviti avgQ u RED zonu u uslovima u kojima se gentle RED ponaša kao DropTail Konačno pokazano je da se povećanjem broja konekcija gube prednosti AQM tehnika u odnosu na DropTail u smislu posmatranih metrika

41

52 Pravičnost ndash metrika ravnopravne koegzistencije TCP tokova Ispitivanje pravičnosti je obavljeno upotrebom nekoliko scenarija različite složenosti i korišćenjem nekoliko metrika Sva testiranja su obavljena na topologiji net10 Ključni deo ovog dela ispitivanja je takođe baziran na glavnoj grupi testova čiji su ostali rezultati prikazani na sl51 sl55 i sl58 521 Pravičnost dve TCP konekcije Scenarijo sačinjen aktiviranjem samo dve TCP konekcije i jednog UDP toka se ne može smatrati realnim okruženjem za formiranje čvrstih zaključaka u ovoj tezi Ipak u daljem izlaganju će biti navedeno nekoliko rezultata koji upotpunjuju sliku proučavanih mehanizama U prethodnom izlaganju je pokazano da RED mehanizmi mogu unaprediti performanse bitne za krajnjeg korisnika i iskorišćenje mrežnih resursa Ova činjenica je bila naročito izražena u scenarijima sa malim kapacitetom bafera Zato je obavljeno nekoliko testova koji bi trebalo da objasne da li povećanje pravičnosti utiče na bolju ukupnu Geff vrednost svih posmatranih konekcija U testovima je kapacitet bafera konfigurisan na QL= 12pkt Ova konfiguracija može uspešno da opslužuje fizičke karakteristike linka uskog grla (QLgt bandwidth x delay) čime je omogućeno da TCP i AQM mehanizmi upravljaju izbegavanjem zagušenja Uticaj AQM tehnika na pravičnost je izolovan postavkom jednakih TCP mehanizama (NewReno) na obe konekcije U tabeli 51 su dati rezultati testiranja

Ukupan broj primljenih bajtova DropTail RED

(maxp = 2) RED

(maxp = 10) Adaptive RED

Konekcija 1 12883040 11653720 13550260 11877100

Konekcija 2 12831940 14176600 12090260 13865620

GEff 091431 0918411 0911663 0915297 Tabela 51 Dve TCP konekcije - Uticaj RED mehanizama na pravičnost

Posmatranjem vrednosti u tabeli 51 se može zaključiti da postoje situacije u kojima RED mehanizmi mogu dovesti do narušavanja pravičnosti Takođe se može zaključiti da manja pravičnost ne dovodi do smanjenja ukupne Geff vrednosti Ovaj rezultat govori da su TCP mehanizmi dovoljno adaptivni da prepoznaju dostupne resurse mreže U toku ispitivanja je primećen još jedan zanimljiv efekat Ovi i slični testovi su takođe pokazali da pri upotrebi RED mehanizma postoji veliki broj slučajeva u kojima se narušena pravičnost teško obnavlja ako se za resurse mreže nadmeće mali broj konekcija Za ovu pojavu se verovatno može izvesti precizan matematički model ali se i intuitivno može pretpostaviti da pravičnost kontrolisana RED upravljanjem zavisi i od količine multipleksiranja u posmatranoj mreži Time se smanjuje mogućnost da konekcija sa manjim protokom bude dodatno usporena preventivnim odbacivanjem Konačno treba naglasiti da iz dobijenih rezultata ne treba zaključiti da RED uvek pogoršava pravičnost već da povoljni efekti RED mehanizma ne slede samo iz pravične raspodele mrežnih resursa U tabeli 52 su navedeni rezultati nastali dodavanjem ECN mehanizma na prethodnu simulacionu platformu Ukupan broj primljenih bajtova DropTail RED + ECN

(maxp = 2) RED + ECN

(maxp = 10) Adaptive RED

+ECN

Konekcija 1 12883040 12954580 12804200 12198300

Konekcija 2 12831940 12861140 12874280 13561940

GEff 091431 0917892 0913013 091592

Tabela 52 Dve TCP konekcije - Uticaj RED+ECN mehanizama na pravičnost Vrednosti iz tabele 52 pokazuju da ECN može da zadrži svojstvo pravičnosti što bi se moglo objasniti smanjenim brojem odbačenih paketa i bržim obaveštavanjem krajnjih tačaka konekcije o nastupajućem zagušenju U tabeli 52 jedino adaptive RED mehanizam narušava održanje pravičnosti Takav rezultat je posledica nepovoljnog trenutka zaustavljanja testa Produžavanjem trajanja testova je utvrđeno da sve RED

42

varijante sa ECN podrškom uspešno otklanjaju povremene intervale smanjene pravičnosti Detaljnije ispitivanje uočenih pojava sledi u testovima sa većim brojem konekcija Nakon ispitivanja uticaja AQM tehnika postavilo se pitanje da li se nastali poremećaji pravičnosti mogu kompenzovati primenom SACK ili NewReno+ECN kombinacije na konekciju koja se našla u neravnopravnom odnosu Rezultati navedeni u tabeli 53 potvrđuju da primena ovih tehnika na sloju transporta ili ublažava neravnomernu podelu resursa ili čak daje prednost sporijoj konekciji

Ukupan broj primljenih bajtova RED 2 NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11653720 13617420 12542860

Konekcija 2 14176600 12230420 13297680

RED 10 NewReno NewReno NewReno NewReno + ECN SACK NewReno

Konekcija 1 13550260 12364740 12874280

Konekcija 2 12090260 13297680 12685940

Adapt RED NewReno NewReno NewReno + ECN NewReno SACK NewReno

Konekcija 1 11877100 13170660 12440660

Konekcija 2 13865620 12631920 13294760 Tabela 53 Dve TCP konekcije - Uticaj ECN i SACK mehanizama na pravičnost

Pored navedenih testova su obavljeni testovi koji su na sloju transporta koristili samo kombinacije NewReno+ECN i SACK mehanizama Svi dobijeni rezultati su potvrdili poboljšanje pravičnosti upotrebom naprednih TCP tehnika 522 Pravičnost u složenijim scenarijima Pravičnost će u ovom delu ispitivanja biti procenjivana na osnovu nekoliko metrika Osnovna metrika na koju se oslanjaju mnogi autori je indeks pravičnosti (FI) Merenja su ipak pokazala da ova veličina ne odražava egzaktno ponašanje grupe tokova Osnovni razlog ove konstatacije jeste činjenica da indeks pravičnosti daje sliku stanja raspodele brzina prenosa u samo jednom trenutku vremena Takođe indeks nije u stanju da prikaže intenzitet odstupanja pojedinih tokova od zajedničke prosečne vrednosti Druga upotrebljena metrika neće biti numerička već će se prikazati kao kumulativni proces pristizanja novih potvrda (ACK) u funkciji vremena Ovime se dobija mnogo jasnija slika raspodele pravičnosti u toku test intervala Konačno za poređenje performansi SACK i NewReno + ECN tehnika će se koristiti i količnik procenta odbacivanja paketa i razliku efektivnih brzina prenosa podataka (engl goodput) posmatranih grupa konekcija 5221 Ukupni indeks pravičnosti u funkciji promene kapaciteta bafera i broja konekcija Na slikama 512a i sl512b su navedene vrednosti indeksa pravičnosti (FI) dobijene u testovima čiji su ostali rezultati prikazani na sl55 i sl58 Izmerene FI vrednosti vrednosti pokazuju dve bitne osobine

43

091092093094095096097098099

1101

4 12 36 48 72 108

QL[pkt]Fa

irnes

s In

dex

DropTailRED 2RED 10adapt RED

(a)

075

08

085

09

095

1

4 12

QL[pkt]

Fairn

ess

Inde

x

0950955

0960965

0970975

0980985

0990995

1

36 48 72 108 200

QL[pkt]

Fairn

ess

Inde

x

Drop TailRED 2RED 10adapt RED

(b)

Sl512 Indeks pravičnosti u scenarijima sa (a) šest i (b) osamnaest TCP konekcija Prvo povećanjem kapaciteta bafera dolazi do ravnomernije rasporele resursa mreže Ovaj rezultat je očekivan i posledica je osnovnog koncepta primene bafera Mnogo važniji su relativni odnosi tehnika upravljanja redovima za čekanje Pri dovoljnim kapacitetima bafera RED mehanizmi su prikazali znatno ravnopravniju raspodelu mrežnih resursa u odnosu na DropTail mehanizam Ovo je veoma bitan rezultat jer se posmatranjem metrika prikazanih na sl55 i sl58 prednost upotrebe RED mehanizama ne može u potpunosti sagledati i opravdati Takođe je primetno da adaptive RED mehanizam sporije i sabilnije konvergira ka većim FI vrednostima U skladu sa prethodnim rezultatima bi se moglo zaključiti da je dominantna uloga ove RED varijante fokusiranje avgQ vrednosti unutar (minth maxth) zone što ne dovodi uvek ni do smanjenja broja odbačenih paketa ni do optimalnog pravičnog odnosa TCP tokova Posmatranjem rezultata na sl512 se uočava da sve tehnike upravljanja redovima za čekanje pogoršavaju stanje pravičnosti pri povećanju broja konekcija i nedovoljnim kapacitetima bafera Ilustracija na sl513 prokazuje da FI nije baš uvek optimalan pokazatelj pravičnosti Naime FI vrednost slike sl513a je veća od FI vrednosti slike sl513b iako je na sl513a primetno razdvajanje dve grupe tokova

(a)

44

(b)

sl513 Efektivna brzina razmene podataka pri upotrebi adaptive RED algoritma za (a) 6 TCP tokova i (b) 18 TCP tokova

5222 Odnos ravnopravnosti NewReno+ECN i SACK mehanizama U ovom poglavlju će početi razrada poređenja dve vrste kontrolnih TCP mehanizama Na početku izlaganja će biti prikazani rezultati testova čije su ostale metrike performansi prikazane na slikama sl55 sl58 i sl512

-130

-80

-30

20

70

4 12 36 48 72 108

QL[pkt]

Goo

dput

(NR

-SA

CK

)

DropTailRED 2RED 10adapt RED

-120

-70

-20

30

80

130

180

4 12 36 48 72 108QL[pkt]

Goo

dput

(NR

-SA

CK

)[kb

s]

DropTailRED 2RED 10adapt RED

(a) (b)

-550

-450

-350

-250

-150

-50

50

150

4 12 36 48 72 108 200QL[pkt]

Drop TailRED 2Red 10adapt RED

(c)

sl514 Razlike efektivnih brzina slanja NewReno+ECN i SACK konekcija pri različitom broju aktivnih tokova i različitim kapacitetima bafera

(a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Merenja prikazana na sl514 ne daju mogućnost formiranja jasnih zaključaka kada su kapaciteti bafera relativno mali u odnosu na broj konekcija Ranije je napomenuto da takve postavke dovode do nepredvidljive i neravnomerne podele resursa mreže Međutim primetno je da u skoro svim situacijama razlike efektivnih brzina razmene podataka ostaju u granicama plusmn150kbs odn plusmn10 propusnog opsega linka uskog grla U mnogim situacijama ovaj odnos je dosta povoljniji Iz tih činjenica se može izvesti zaključak da pri dovoljnom kapacitetu bafera NewReno+ECN i SACK mogu deliti mrežne resurse dosta ravnopravno

45

Zanimljiv rezultat je da u realnijim situacijama (sa većim brojem aktivnih konekcija) i pri zadovoljavajućim kapacitetima bafera NewReno+ECN uvek pokazuje prednost u odnosu na SACK Ovakav rezultat se mogao očekivati posmatrano iz perspektive povećanih mogućnosti kompenzacije burst-ova i ECN svojstva smanjenja procenta odbačenih paketa Ipak takođe se moglo pretpostaviti da će povećanje broja konekcija dovesti do prednosti SACK mehanizma usled mogućeg porasta učestanosti odbacivanja paketa Ovakva razmišljanja su dovela do obavljanja serije dodatnih testova U prvoj grupi testova je za sve posmatrane kapacitete bafera verovatnoća ECN markiranja (mark_p) povećana iznad (0 maxp) zone Ovakva postavka može biti delotvorna samo ako se primenjuje gentle RED jer običan RED algoritam iznad navedene zone odbacuje pakete kao DropTail Na sl 515 je ilustrovan primer odnosa koji nastaju pri ovakvoj konfiguraciji mark_p parametra Slika prikazuje situaciju nastalu upotrebom agresivnog gentle RED mehanizma (maxp = 01) i malog kapaciteta bafera QL=12pkt Sl515a i sl515b se odnose na scenario u kojem je mark_p = 01 i pri kojem SACK konekcije ostvaruju bolju efektivnu brzinu razmene podataka

(a)

(b)

(c)

46

(d)

sl515 Agresivni gentle RED 18 TCP konekcija

(a) NewReno+ECN konekcije (mark_p = 01) (b) SACK konekcije (mark_p = 01) (c) NewReno+ECN konekcije (mark_p = 03) i (d) SACK konekcije (mark_p=03)

Na sl515c i sl515d je prikazan odnos NewReno+ECN i SACK konekcija nakon povećanja verovatnoće markiranja na mark_p = 03 Promena je izazvala tri bitna efekta Konekcije koje koriste ECN su postigle bolju efektivnu brzinu razmene podataka Njihova pravičnost raspodele mrežnih resursa je bitno poboljšana u celom intervalu trajanja testa Konačno proširenjem zone delovanja ECN mehanizma je bitno smanjen protok SACK konekcija Dugoročno posmatrano ovakvo ponašanje se ne može shvatiti kao potpuno pozitivno Naime u teorijskom delu teze je navedeno da se AQM mehanizmi i QoS koncept nadopunjuju ali nemaju iste osnovne ciljeve Prikazano ponašanje ECN konekcija može da stvori povlašćenu klasu saobraćaja što bi trebalo da bude uloga QoS-a Treba naglasiti da ECN još uvek nije dovoljno zastupljena tehnologija što znači da bi u vremenu njenog širenja moglo da dođe do ugrožavanja pravičnosti u odnosu na postojeće TCP mehanizme Konačno postoji efekat koji se koji je primećen u skoro svim testovima a zbog ograničenosti prostora nije prikazan u rezultatima Pokazalo se da povećanje mark_p vrednosti ne rezultuje konstantnim povećanjem prednosti ECN konekcija već postoji zasićenje Npr u scenariju prikazanom na sl515 jednaki rezultati se dobijaju kada je mark_p=03 i kada je mark_p=05 Druga grupa dodatnih testova je trebalo da uporedi NewReno+ECN i SACK u uslovima lošeg linka i tako ispita SACK prednosti Uslovi lošeg linka su simulirani upotrebom generatora greške sa dva stanja čiji su parametri menjani u širokom opsegu Upotrebljeno je okruženje sa 18 TCP konekcija a kapaciteti bafera su bili postavljeni na QL=12pkt i QL=36pkt kako bi se obezbedilo okruženje koje je dovoljno zagušeno Obavljena ispitivanja nisu prikazala da u ovakvim situacijama SACK konekcije stiču prednost Jedini primećen efekat je pogoršanje pravične podele resursa na svim tipovima konekcija U teorijskim izlaganjima je pak navedeno da u odnosu na Reno SACK može lakše da se oporavi od gubitka grupe paketa iz istog cwnd opsega Ipak sva testiranja obavljena u ovoj tezi su pokazala da NewReno sa ECN podrškom i SACK imaju slične performanse 523 Efikasnost upotrebe mrežnih resursa ispitivanih TCP varijanti Ova tema je mogla da bude obrađena i ranije ali je njeno izlaganje odloženo zbog detaljne razrade odnosa NewReno+ECN i SACK mehanizama U glavnoj grupi testova (sl51 sl55 sl58 sl512) je između ostalog za svaku od ovih TCP varijanti praćena učestanost odbacivanja paketa efektivna brzina razmene paketa (engl goodput) i iskorišćenost propusnog opsega (engl throughput) Na sl516 je prikazan broj odbačenih NewReno+ECN paketa u odnosu na broj odbačenih SACK paketa

47

0

02

04

06

08

1

12

4 12 36 48 72 108

QL[pkt]

Dro

p (N

R

SAC

K)

Drop TailRED 2RED 10adapt RED

002040608

1121416

4 12 36 48 72 108QL[pkt]

Dro

p (N

R

SAC

K)

DropTailRED 2RED 10adapt RED

(a) (b)

002040608

11214

4 12 36 48 72 108 200QL[pkt]

Dro

p (N

R

SAC

K)Drop TailRED 2RED 10adapt RED

(c)

sl516 Broj odbačenih paketa grupe NewReno+ECN u odnosu na grupu SACK konekcija za (a) dve TCP konekcije (b) šest TCP konekcija i (c) osamnaest TCP konekcija

Ključno svojstvo koje sledi iz testova prikazanih na sl516 jeste izuzetno smanjenje broja odbačenih paketa nastalo primenom ECN mehanizama Pored poboljšanja pravičnosti ovo je ključna karakteristika koja opravdava inicijativu širenja ECN platforme Važno je uočiti da se u mnogim radovima drugih autora ne navodi da povoljno dejstvo ECN mehanizma zavisi od stanja mreže kao što je prikazano na sl516c gde ECN konekcije intenzivno odbacuju pakete sve do kapaciteta bafera QL=108pkt Rezultati koji su dobijeni u testovima ove teze govore da je ispravna konfiguracija fizičkih parametara mreže bitan preduslov za ostvarenje pozitivnih efekata savremenih TCP i AQM mehanizama Poređenje rezultata sa sl514 i sl516 dovodi do nekoliko bitnih zaključaka Osnovni zaključak jeste da efektivna brzina razmene podataka (engl goodput) i broj odbačenih paketa nisu uvek međusobno redundantne metrike Npr testovi pokazuju da manje odbacivanje paketa ne znači da će efektivna brzina razmene paketa biti povećana To se vidi iz primera sa šest aktivnih TCP konekcija kapacitetom bafera QL=4pkt i adaptive RED mehanizmom kao i iz gotovo svih primera sa osamnaest TCP konekcija i QL=4pkt i primera sa osamnaest TCP konekcija i mehanizmom gentle RED (maxp=002) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka manji jesu posledica pojave neravnomerne raspodele resursa mreže (engl lockout) kao i TCP mehanizma dupliranja vrednosti RTO tajmera (engl backoff) Situacije u kojima su i odbacivanje paketa i efektivna brzina razmene podataka veći nastaju kao posledica agresivnosti TCP tokova koji su stekli prednost u korišćenju propusnog opsega Konačno u ovom trenutku bi trebalo napraviti konačno poređenje konzervativne i agresivne gentle RED varijante U većini rezultata glavne grupe testova se vidi da agresivni gentle RED (maxp=01) pokazuje bolje efekte Konzervativni gentle RED (maxp=002) se pokazao kao bolje rešenje jedino u pogledu procenta odbacivanja paketa u nerealnom scenariju sa dve TCP konekcije Rezultati sa sl 516 konačno potvrđuju da je upotreba agresivnog RED mehanizma bolja u slučaju velikih FTP transfera Zato su testovi koji će biti obrađeni do kraja teze poredili DropTail agresivni gentle RED i adaptive RED algoritam 524 Pravičnost ndash zaključak U ovom delu teze su ispitivane različite metrike ukupne pravičnosti i pravičnosti grupa tokova Testovi su u okruženju koje je ravnopravno tretiralo NewReno+ECN i SACK konekcije Početna ispitivanja u testovima

48

sa dve aktive konekcije su pokazala da RED mehanizmi mogu narušiti pravičnost Povećanjem broja konekcija su primećeni suprotni rezultati pa se može zaključiti da RED može imati veoma povoljan uticaj na okosnicama interneta (engl backbone) Takođe je primećeno da produženje zone ECN markiranja koje omogućuje gentle RED varijanta omogućava bolju pravičnost u velikom broju scenarija Delimično nepovoljan efekat ovakvog ponašanja je delimično smanjenje protoka i pravičnosti konekcija koje ne podržavaju ECN Testiranja su potvrdila i da primena ECN tehnologije uvek rezultuje boljom pravičnošću Ipak za razliku od dosadašnjih radova utvrđeno je da intenzitet odbacivanja paketa ECN konekcija u velikoj meri zavisi od ispravne konfiguracije mreže i broja aktivnih konekcija Pri ispitivanju uticaja TCP mehanizama na pravičnost utvrđeno je da NewReno+ECN i SACK modifikacije uvek popravljaju ovu metriku u odnosu na običan NewReno Verovatno najznačajniji zaključak ovog dela testiranja jeste potvrda na NewReno+ECN pruža jednake ili čak bolje performanse od SACK mehanizma u širokom spektru test scenarija

49

53 Uticaji razlike kašnjenja Prethodna testiranja su sačinjena sa ciljem da se uporede performanse naprednih TCP i AQM algoritama pod relativno ravnopravnim uslovima Na osnovu zaključaka iz tih testova je stvorena platforma za testiranje u neravnopravnim uslovima Scenariji koji će proučavati grupe TCP konekcija sa različitim kašnjenjima će biti obavljeni sa

bull osamnaest različitih TCP konekcija (zbog realnosti test scenarija)

bull dva kapaciteta bafera linka uskog grla (QL=48pkt i QL=200pkt)

bull topologijom net10

bull razlikom kašnjenja od 20ms 50ms i 100ms

bull algoritmima DropTail gentle RED (maxp=01) i adaptive RED Sve posmatrane konekcije su startovale istovremeno a testovi su trajali 380s Merenja su počela u tridesetoj sekundi čime su zanemareni tranzijentni efekti koji su nebitni za ovu vrstu ispitivanja Kao i u prethodnim testovima praćene metrike su efektivna brzina razmene podataka učestanost odbacivanja paketa propusnost (engl throughput) i indeks pravičnosti Zbog količine dobijenih rezultata samo neki od njih će biti objavljeni 531 Uticaj razlike kašnjenja na iskorišćenost mrežnih resursa Rezultati zbirne efektivne brzine razmene podataka (engl goodput) ove grupe testova neće biti objavljeni jer je utvrđeno da se oni malo razlikuju od scenarija u kojima je kašnjenje svih linkova jednako Ovim se potvrđuje da AMID upravljanje može dobro da proceni propusni opseg mreže i u neravnopravnim situacijama Druga bitna metrika iskorišćenosti resursa mreže je ukupna učestanost odbacivanja paketa U tabeli 54 su prikazani rezultati merenja ove veličine U testovima sa kapacitetom bafera QL=48pkt adaptive RED mehanizam odbacuje najviše paketa Ovime je još jednom potvrđeno da primena ovog algoritma ne rezultuje smanjenjem broj odbačenih paketa Upotreba gentle RED algoritma je pokazala da se povećanjem razlike kašnjenja smanjuje broj odbačenih paketa To je u skladu sa činjenicom da konekcije sa dužim RTT intervalom sporije dobijaju obaveštenja o zagušenosti čime se smanjuje njihova agresivnost Upravo ovakav rezultat potvrđuje da testovi sa sl51 sl55 i sl58 predstavljaju scenarije bdquonajgoreg slučajaldquo upotrebe FTP prenosa Ipak rezultati navedeni u tabeli 54 govore da broj odbačenih paketa zavisi i od stanja mreže i od primenjene tehnike upravljanja baferima

QL=48pkt QL=200pkt Drop rate [Mbs] adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0135257 0146537 0146674 00331543 00252343 00337714

NR 0ms SACK 50ms 0159086 0131074 0141737 002688 00233829 00340114

NR 0ms SACK 100ms 0134126 0115406 0129257 00268457 00205372 00330514

NR 20ms SACK 0ms 0152331 0142457 0142183 00329828 00264 00320571

NR 50ms SACK 0ms 0154766 012768 0138617 002976 00262286 00340457 NR 100ms SACK 0ms 0159017 0113383 0123497 00307543 00258171 00326743

Tabela 54 Osamnaest TCP konekcija - Učestanost odbacivanja paketa u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash

kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

50

Povećanje kapaciteta bafera očekivano rezultuje smanjenom količinom odbačenih paketa u svim test konfiguracijama Uvećanje bafera takođe smanjuje razlike vrednosti odbacivanja paketa koje nastaju pri povećanju razlike kašnjenja Adaptive RED algoritam i dalje intenzivnije odbacuje pakete u odnosu na gentle RED dok DropTail mehanizam odbacuje najviše paketa U tabeli 55 su navedene vrednosti ukupnog indeksa pravičnosti testova sa različitim kašnjenjem

QL=48pkt QL=200pkt Fairness Index (FI) adaptRED RED 10 DropTail adaptRED RED 10 DropTail

NR 0ms SACK 20ms 0981575 0989452 0907053 0994599 0993374 0966084

NR 0ms SACK 50ms 0961447 0960979 0901795 0990082 0979904 0972592

NR 0ms SACK 100ms 0938145 0919146 0810653 0983933 0974033 0983052

NR 20ms SACK 0ms 0992002 0994446 0918191 0996431 099618 0965855

NR 50ms SACK 0ms 0989443 0990012 0880885 0993628 0996269 0902772

NR 100ms SACK 0ms 0965447 0966514 0812337 099203 0985328 0885317

Tabela 55 Osamnaest TCP konekcija - Ukupan indeks pravičnosti u testovima sa različitim kašnjenjem NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom

10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Za razliku od rezultata učestanosti odbacivanja paketa rezultati za indeks pravičnosti (FI) poseduju pravilnije ponašanje Osnovna odlika ovih rezultata je smanjenje indeksa pravičnosti sa porastom razlike kašnjenja između tokova Pored toga se može zaključiti da indeks ima veće vrednosti pri povećanju kapaciteta bafera Obe navedene pojave su u skladu sa očekivanjima teorijom TCP mehanizama i osnovnom namenom bafera Poređenjem mehanizama upravljanja baferima se uočava da DropTail pokazuje izrazito loše performanse pravičnosti Adaptive RED algoritam ne postiže uvek najbolje vrednosti posmatranog indeksa ali je primetno da se primenom ovog algoritma pravičnost manje menja sa porastom razlike kašnjenja Ista pojava je uočena i objašnjena pri testovima sa različitim kapacitetima bafera različitim brojem TCP konekcija i jednakim kašnjenjem Prikazani rezultati takođe pokazuju da su FI vrednosti veće i manje menjaju pri povećanju kašnjenja konekcija koje podržavaju ECN mehanizam Detaljno ispitivanje ove pojave će biti obrađeno u posebnom delu ove teze 532 Uticaj razlike kašnjenja na međusoban odnos NewReno+ECN i SACK konekcija Rezultati koji će biti objavljeni u ovom naslovu su dobijeni u istoj grupi testova kao i rezultati iz naslova 531 Na sl517 su prikazane razlike efektivne brzine razmene podataka grupe NewReno+ECN konekcija i grupe SACK konekcija pri razlici kašnjenja od 20ms 50ms i 100ms

-08

-06

-04

-02

0

02

04

06

08

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

-05

-04

-03

-02

-01

0

01

02

03

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Goo

dput

(NR

-SA

CK

) [M

bs]

adapt REDRED 10Drop Tail

(a) (b)

sl517 Razlika efektivne brzine razmene podataka grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt (b) QL= 200pkt

51

Osnovni zaključak koji sledi iz sl517 jeste da se povećanjem kapaciteta bafera smanjuju razlike u efektivnoj brzini razmene podataka Prikazani rezultati ponovo pokazuju da DropTail mehanizam poseduje najveću amplitudu promene ponašanja u scenarijima sa različitim kašnjenjem Jedini slučaj u kojem je ova disciplina uspela da nadmaši AQM mehanizme je nastao pri QL=200pkt i kašnjenju SACK konekcija od 100ms Detaljnim proučavanjem rezultata je uočeno da je ovaj slučaj nastao kao posledica većeg odbacivanja paketa i nešto lošijeg indeksa pravičnosti NewReno+ECN konekcija Stoga ovakvu situaciju treba shvatiti kao rezultat stanja mreže a ne kao povoljan efekat DropTail mehanizma AQM mehanizmi u skladu sa očekivanjima smanjuju razliku posmatrane metrike sa smanjenjem razlike kašnjenja Pri QL=200pkt i povećanom kašnjenju NewReno+ECN konekcija se pokazalo da te konekcije mogu postići bolje performanse od SACK konekcija Takve pojave nisu posledica stanja mreže kao u slučaju DropTail mehanizma Ispitivanjem rezultata je utvrđeno da u posmatranom slučaju ni jedan paket NewReno+ECN konekcija nije odbačen i da su indeksi pravičnosti obe grupe konekcija imali vrednost veću od 0995 Stoga se može reći da je ovakav relativno neočekivan rezultat posledica efikasnog delovanja ECN mehanizma Konačno treba primetiti da su vrednosti razlike efektivne brzine razmene podataka primetno manje kada ECN konekcije imaju veće kašnjenje U tabeli 56 je prikazana učestanost odbacivanja paketa grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima Rezultati navedeni u tabeli 56 pokazuju da povećanje fizičkog kapaciteta bafera najdominantnije utiče na smanjenje broja odbačenih paketa U skladu sa kapacitetom bafera se menja i uticaj AQM tehnika na proces odbacivanja paketa Za QL=48pkt obe AQM tehnike su više odbacivale pakete agresivnijih tokova odn tokova sa manjim kašnjenjem Takođe je primetno da je adaptive RED tehnika u pojedinim slučajevima odbacivala znatno više paketa Kada je kapacitet bafera povećan na QL=200pkt ECN mehanizam je uspeo da drastično smanji odbacivanje paketa NewReno konekcija bez obzira na vrednost kašnjenja Najbolji rezultati su dobijeni upotrebom algoritma gentle RED (maxp=01) Konačno i ova merenja potvrđuju da je glavni cilj adaptivnog algoritma postavljanje avgQ vrednosti blizu sredine RED zone

Q=48pkt Drop Rate [kbs] adapt RED RED 10 DropTail

NR 0ms SACK 20ms 68537 66720 76114 70423 71931 74743 NR 0ms SACK 50ms 93189 65897 69840 61234 75874 65863 NR 0ms SACK 100ms 79406 54720 64183 51223 72891 56366 NR 20ms SACK 0ms 75771 76560 68057 74400 78651 63531 NR 50ms SACK 0ms 69429 85337 54720 72960 70731 67886 NR 100ms SACK 0ms 63703 95314 39360 74023 56160 67337

Q=200pkt adapt RED RED 10 DropTail

NR 0ms SACK 20ms 5554 27600 0000 25234 13680 20091 NR 0ms SACK 50ms 2469 24411 0000 23383 13989 20023 NR 0ms SACK 100ms 4423 22423 0000 20537 15566 17486 NR 20ms SACK 0ms 4423 28560 0000 26400 18309 13749 NR 50ms SACK 0ms 1543 28217 0000 26229 19783 14263 NR 100ms SACK 0ms 2846 27909 0000 25817 17623 15051

Tabela 56 Osamnaest TCP konekcija - Učestanost odbacivanja paketa NewReno+ECN i SACK grupa TCP konekcija u testovima sa različitim kašnjenjem

NR ndash konekcije sa NewReno mehanizmom i ECN podrškom SACK ndash konekcije sa SACK mehanizmom 10ms ndash kašnjenje na linku od izvora do najbližeg rutera iznosi 10ms

Pri nedovoljnom kapacitetu bafera (QL=48pkt) ponašanje DropTail mehanizma je određeno stanjem mreže To se najbolje vidi u testovima u kojima konekcije sa većim kašnjenjem odn manjom agresivnošću imaju veći broj odbačenih paketa Takva situacija je ostvarena u scenarijima u kojima su NewReno+ECN konekcije zakašnjene za 20ms i 50ms i u testu u kojem su SACK konekcije zakašnjene za 20ms

52

Ispitivanje indeksa pravičnosti pri različitim kašnjenjima i kapacitetima bafera je prikazano na sl518a i sl 518b

096

0965

097

0975

098

0985

099

0995

1

1005

-100 -50 -20 20 50 100

delay(NR-SACK)[ms]

Fairn

ess

inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

097

0975

098

0985

099

0995

1

-100 -50 -20 20 50 100

delay(NR-SACK) [ms]

Fairn

ess

Inde

x

NR adapt REDSACK adapt REDNR RED 10SACK RED 10NR drop tailSACK drop tail

(a) (b)

sl518 Indeksi pravičnosti grupe NewReno+ECN i grupe SACK konekcija pri različitim kašnjenjima i kapacitetima bafera (a) QL= 48pkt i (b) QL= 200pkt

FI vrednosti AQM mehanizma ostaju velike (FIgt099) u svim testiranim okolnostima Pri upotrebi ovih mehanizama većina obavljenih testova je pokazala da povećanje kašnjenja grupe konekcija ne rezultuje smanjenjem indeksa pravičnosti U slučaju malog kapaciteta bafera (QL=48pkt) adaptive RED mehanizam je ponovo pokazao da poseduje najmanje varijacije svih FI vrednosti Ovaj mehanizam takođe pokazuje najmanju razliku indeksa pravičnosti za NewReno+ECN i SACK konekcije Upotreba DropTail mehanizma je dala veoma čudne rezultate Naime ovaj mehanizam je imao slične FI performanse kao AQM tehnike pri nedovoljnom kapacitetu (QL=48pkt) i razlikama kašnjenja od 20ms i 50ms Nepredviđeno ponašanje se dogodilo povećanjem kapaciteta bafera U tom slučaju bi smanjeno odbacivanje paketa trebalo da pruži bolje uslove za pravičnu raspodelu propusnog opsega Ipak raspodela trenutaka odbacivanja paketa je uspela da formira neravnopravnost (engl lockout) različitog intenziteta Ovime je još jednom potvrđeno da pri upotrebi DropTail mehanizma skoro sve performanse zavise od stanja mreže 533 Uticaj razlike kašnjenja ndash zaključak U ovom delu teze su po prvi put ispitivane okolnosti koje nastaju pro neravnopravnom odnosu grupe NewReno i grupe SACK konekcija Neravnopravnost je izazvana povećanjem kašnjenja jedne od grupa konekcija za 20ms 50ms i 100ms Rezultati ukupnih pokazatelja performansi mreže su pokazali da ukupan indeks pravičnosti opada sa povećanjem razlike kašnjenja Ovaj pad je međutim dosta manji pri upotrebi AQM tehnika i većih kapaciteta bafera Posmatranjem ukupne učestanosti odbacivanja paketa je utvrđeno da adaptivni RED uvek odbacuje nešto više paketa u odnosu na gentle RED mehanizam Ovakvo ponašanje je uočeno i ranije i predstavlja posledicu težnje adaptivnog RED mehanizma da fokusira avgQ vrednost na RED zone Poređenjem NewReno+ECN i SACK grupa konekcija je utvrđeno da promena kašnjenja utiče manje nepovoljno na konekcije koje podržavaju ECN Takođe je prikazano da svi AQM mehanizmi u odnosu na DropTail daleko bolje održavaju visoku vrednost indeksa pravičnosti Konačan zaključak ovog dela ispitivanja je da je DropTail mehanizam veoma osetljiv na neravnopravnost izazvanu različitim kašnjenjem Ova osetljivost se ne ogleda samo u većim razlikama pravičnosti već i u veoma nepredvidljivom ponašanju u pogledu svih metrika Takođe je bitno još jednom naglasiti da ECN mehanizam u zavidnoj meri kompenzuje neravnopravnost izazvanu kašnjenjem

53

54 Testovi na topologiji sa dva linka uskog grla Testovi obavljeni na topologiji sa dva linka uskog grla predstavljaju završne testove ove teze Kao što je ranije napomenuto SACK RED i ECN još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Pored toga mnogi posrednici servisa (engl Internet Service Providers ISP) konsultujući dosadašnja istraživanja odbijaju da podrže AQM i ECN koncepte zbog neizvesnih rezultata njihove primene Takođe ako različiti ISP-ovi na svojoj opremi konfigurišu različite AQM parametre moglo bi doći do problema sličnog uspostavljaju konzistentnog QoS-a Treba naglasiti da taj problem danas nema tehničko rešenje već se za uspostavu jedinstvenog QoS-a preporučuje zaključivanje pravnih ugovora (engl Service Level Agreement SLA) Da bi se problemi sveli na tehnički nivo bitno je shvatiti da AQM mehanizmi teže poboljšanju opšteg stanja mreže a ne garantovanom i dosta često plaćenom poboljšanju servisa što je cilj QoS koncepta Glavni cilj testova u ovom delu teze je proučavanje efekata koji nastaju na granici domena koji podržavaju i ne podržavaju AQM tehnologiju Topologija na kojoj su obavljeni svi testovi ovog dela teze je prikazana na sl519

sl519 Topologija netMultiC

Na osnovu iskustava stečenih u prvoj fazi ispitivanja ove teze postavke testove na netMultiC topologiji će koristiti

bull 27 TCP konekcija i to 9 SACK i 9 NewReno+ECN konekcija koje prolaze kroz oba linka uskog grla i 9 običnih NewReno konekcija koje prolaze kroz usko grlo r2-r1

bull dva kapaciteta bafera linka uskog grla (QL=72pkt i QL=300pkt)

bull adaptivni RED gentle RED (maxp=01) i DropTail mehanizam

bull sledeće redoslede mehanizama upravljanja redovima za čekanje RED ndash DropTail (RED-DT) DropTail ndash RED (DT-RED) i DropTail ndash DropTail (DT-DT)

Pri koncipiranju ove grupe testova je postojala ideja da se konekcije pokrenu unutar intervala 1s 3s ili 5s Međutim preliminarna ispitivanja su utvrdila da ne postoji velika razlika u rezultatima u slučajevima kada se konekcije pokrenu istovremeno i u različitim trenucima Stoga su u testovima sve konekcije startovane u istom trenutku i čime je otklonjen uticaj početnih uslova Svi testovi su trajali 380s dok je početak merenja postavljen u trenutak t=30s 541 Performanse iskorišćenja mrežnih resursa Za razliku od prethodnih celina ove teze broj testova na složenijoj topologiji je nešto manji U tabeli 57 su prikazani rezultati merenja ukupne efektivne brzine razmene paketa za konekcije koje prolaze kroz jedan i dva linka uskog grla Početni rezultati navedeni u tabeli 57 su u saglasnosti sa radom [MBDL99] u čijem završnom delu je pokazano da performanse mreže veoma zavise od redosleda DropTail i RED linkova Ipak za razliku od tog rada ispitivanja obavljena u ovoj tezi su dosta detaljnija i pokazuju neke nove efekte

54

QL=72pkt QL=300pkt Total goodput [Mbs] Red 10 adapt RED Red 10 adapt RED

end nodes 136713 136069 115812 115812 RED-DT inter nodes 00390446 00430825 0222588 0222588 end nodes 0854475 0882741 0899927 0915178 DT-RED inter nodes 0495899 0466166 0488458 0469502 end nodes 13738 115812 DT-DT inter nodes 00276316 0222588

Tabela 57 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima i netMultiC topologiji

end nodes ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Značaj uočene zavisnosti performansi u odnosu na redosled DropTail i RED mehanizama je mnogo manji u poređenju sa izuzetno nepravičnim stanjem mreže koje nastaje kada DropTail ruter upravlja većinom konekcija (odn kada je DropTail mehanizam postavljen na linku r2-r1) U tom slučaju se dešava da NewReno konekcije središnjih čvorova sa manjim RTT intervalom postižu od 25 do 20 puta manju efektivnu brzinu razmene podataka u odnosu na konekcije sa boljim TCP algoritmima i dvostruko većim RTT intervalom Ovakvo ponašanje ne može intuitivno pretpostaviti Ipak detaljnim proučavanjem test rezultata se došlo do logičnog objašnjenja koje će biti kasnije izloženo U ovom delu izlaganja je još potrebno napomenuti da povećanje kapaciteta bafera delimično popravilo pravičnost Takođe kada su na linku r2-r1 postavljeni RED mehanizmi odnos pravičnosti je mnogo bolji bez obzira na kapacitet bafera

Kao i u prethodnim ispitivanjima sledeća posmatrana metrika je učestanost odbacivanja paketa Rezultati su prikazani u tabeli 58

QL=72pkt QL=300pkt Total Drop Rate [kbs] Red 10 adapt RED Red 10 adapt RED

end r0-r2 13920 15326 0000 0000 end r2-r1 21600 22663 17074 17074 RED-DT inter nodes 17040 21051 17143 17143 end r0-r2 0000 0000 0000 0000 end r2-r1 104503 98331 16629 26983 DT-RED inter nodes 64869 62606 18514 23006 end r0-r2 24000 0000 end r2-r1 14263 17074 DT-DT inter nodes 11863 17143

Tabela 58 27 TCP konekcija - Ukupna efektivna brzina razmene podataka u različitim scenarijima na netMultiC topologiji

end ndash NewReno+ECN i SACK konekcije inter nodesndash NewReno konekcije

Rezultati u tabeli 58 pokazuju da u većini posmatranih scenarija pri QL=72pkt sve tehnike upravljanja redovima za čekanje daju približno jednake performanse za NewReno+ECN i SACK konekcije Jedina razlika se primećuje u odbacivanju paketa NewReno konekcija koje ostvaruju optimalne rezultate pri DT-DT kombinaciji Međutim takvo stanje ne rezultuje boljom brzinom razmene NewReno konekcija Naprotiv smanjena količina odbačenih paketa je rezultat izuzetno smanjenog protoka ovih konekcija (sl520)

(a)

55

(b)

sl520 Prikaz kumulativnog potvrđivanja u DT-DT rasporedu netMultiC topologije za (a) NewReno+ECN i SACK konekcije (b) NewReno konekcije

Sl520 ilustruje da konekcije sa dužim RTT vremenom (NewReno+ECN i SACK) počinju razmenu sporije Sa druge strane NewReno konekcije startuju znatno agresivnije zahvaljujući manjem RTT intervalu Nakon prvih nekoliko sekundi ove konekcije prepunjuju bafer na linku r2-r1 To znači da nastupa odbacivanje paketa u grupama što trajno usporava agresivne konekcije U tom intervalu konekcije sa većim kašnjenjem trajno preuzimaju veći deo propusnog opsega linka uskog grla zahvaljujući manjoj agresivnosti pristupa baferu brojnosti konekcija i SACK mehanizmu kojeg koristi jedna grupa tokova Sličan redosled dešavanja je primećen i pri RED-DT scenarijima što potvrđuje činjenicu da je primena DropTail mehanizma na linku r2-r1 glavni uzrok neravnopravnosti Još jedan interesantan scenario nastaje pri QL=72pkt i DT-RED redosledu linkova U toj situaciji RED ruter u potpunosti preuzima upravljanje TCP konekcijama (videti tabelu 58) Ukupna učestanost odbacivanja paketa svih tipova konekcija se utrostručuje ali se time stvara pravična raspodela propusnog opsega linka uskog grla (videti tabelu 57) Ovakvi rezultati još jednom potvrđuju da učestanost odbacivanja paketa i efektivna brzina razmene podataka nisu redundantne metrike Konačno treba naglasiti da ovolika učestanost odbacivanja paketa možda ne bi odgovarala kraćim HTTP konekcijama Kao što je ranije napomenuto ova testiranja će biti obavljena u nekom od budućih radova Ovom prilikom će biti navedena samo pretpostavka da bi raznovrsnija mešavina saobraćaja verovatno smanjila agresivnost pristupa baferu a time i učestanost odbacivanja Povećanje kapaciteta bafera na QL=300pkt je dovelo do očekivanog smanjenja učestanosti odbacivanja paketa Takođe se primećuje da ruter r2 preuzima celu funkciju upravljanja zagušenjem Ovakav rezultat je razumljiv s obzirom da udaljene konekcije mogu da prođu kroz usko grlo r0-r2 koristeći skoro maksimalnu veličinu cwnd prozora U poređenju sa testovima sa kraćim baferom odbacivanje paketa je smanjeno dva do tri puta Kao i u prethodnim grupama testova ispitivanje performansi iskorišćenja mrežnih resursa će biti zaključeno rezultatima ukupnih indeksa pravičnosti (tabela 59)

QL=72pkt QL=300pkt Fairness Index Red 10 adapt RED Red 10 adapt RED

end nodes 099229 0993193 0989203 0989203 RED-DT inter nodes 0533823 0803208 0984169 0984169 end nodes 098294 0991884 0991322 098732 DT-RED inter nodes 0994613 0993914 0994806 0995022 end nodes 0985197 0989203 DT-DT inter nodes 0427537 0984169

Tabela 59 27 TCP konekcija - Ukupni indeksi pravičnosti u testovima na topologiji netMultiC

56

FI vrednosti su u skladu sa prethodnim zaključcima ali sledeće rezultate treba naglasiti

bull ukupni indeksi pravičnosti se povećavaju sa povećanjem kapaciteta bafera

bull kada dominantnu ulogu u kontroli zagušenja imaju AQM mehanizmi ukupna pravičnost je bitno bolja

bull pri malom kapacitetu bafera (QL=72pkt) i dominantnoj ulozi DropTail mehanizma adaptivni RED uspeva da obezbedi dosta bolju pravičnost u odnosu na gentle RED

542 Ravnopravnost NewReno+ECN i SACK mehanizama Grupa testova koja je obavljena na složenijoj netMultiC topologiji nije otkrila gotovo ni jedan novi efekat u odnosu na prethodna ispitivanja Zato će u ovom odeljku zbog kompletnosti izlaganja biti navedeni samo rezultati metrika efektivne brzine razmene podataka i indeksa pravičnosti

QL=72pkt QL=300pkt RED 10 adapt RED RED 10 adapt RED Goodput

[Mbs] NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK

RED-DT 0694226 0672902 0699432 0661255 0565279 0592844 0565279 0592844

DT-RED 0446042 0408433 0465832 0416909 0468368 0431559 0494898 042028

DT-DT 0699699 0674103 0565279 0592844

Tabela 510 27 TCP konekcija - Efektivna brzina razmene podataka NewReno+ECN i SACK konekcija na netMultiC topologiji

QL=72pkt Q=300

RED 10 adapt RED RED 10 adapt RED Fairness Index

NR+ECN SACK NR+ECN SACK NR+ECN SACK NR+ECN SACK RED-DT 0990353 0994861 0996373 0991305 0996445 0983766 0996445 0983766

DT-RED 0975133 0996681 0995603 0994092 0997941 09872 0991013 0997891

DT-DT 098701 0983959 0996445 0983766

Tabela 511 27 TCP konekcija - Indeks pravičnosti NewReno+ECN i SACK konekcija na netMultiC topologiji

543 Testovi na topologiji sa dva linka uskog grla ndash zaključak U ovom delu ispitivanja je testiran spoj mreže koja podržava napredne AQM tehnike i DropTail mreže Simulacije su pokazale verovatno najlošije ponašanje DropTail mehanizma u odnosu na sve prethodne testove Bitno je naglasiti da uočene pojave ne bi bile primećene bez posmatranja središnjih NewReno konekcija povezanih na ruter r2 Upravo takva greška je učinjena u redu [MBDL99] čiji autori su zaključili da DropTail može biti superiorniji u odnosu na RED mehanizme Glavni nedostatak primene DropTail discipline na ruteru r2 je verovatno posledica zaista velikog broja konekcija Rezultat dejstva ovog mehanizma je izuzetno nepravedan odnos prema NewReno konekcijama sa kraćim RTT intervalom Primena RED mehanizma na najviše opterećenom ruteru r2 je uspostavila gotovo savršenu pravičnost sve tri grupe konekcija Cena te pravičnosti je izuzetno povećanje broja odbačenih paketa pri malom kapacitetu bafera Postavljanje RED rutera na ovom mestu pokazuje još jedan efekat koji će biti detaljnije proučen u nekom od sledećih radova Rezultati su pokazali da RED mehanizam može da preuzme celokupno upravljanje TCP konekcijama bez obzira na kapacitet bafera Ovo se može odraziti na neslaganje posrednika Internet servisa u smislu uvođenja ove tehnologije

57

6 Zaključak teze Teza bdquoSimulaciono ispitivanje TCP mehanizama kontrole zagušenja u sloju transportaldquo je imala za cilj ispitivanje savremenih TCP i AQM mehanizama koji još uvek nisu dovoljno rasprostranjeni u današnjem Internetu Testiranja su obavljena na dovoljno raznolikoj platformi pa se dobijeni rezultati mogu smatrati realnim i primenljivim Pojedinačni zaključci su navedeni nakon svake grupe obavljenih testova u naslovima 514 524 533 i 543

Poređenja TCP implementacija su dovela do sledećih zaključaka SACK nije pokazao bitne prednosti u odnosu na NewReno+ECN kombinaciju koja je čak u velikom broju slučajeva pokazala nešto bolje performanse Inicijalna ispitivanja su potvrdila da su NewReno i SACK implementacije međusobno kompatibilne Potvrđeno je da ove implementacije TCP protokola ne ugrožavaju jedna drugu bez obzira na brojnost konekcija na zajedničkom linku Rezultati simulacija sa različitim RTT intervalima ukazuju da se grupa NewReno konekcija zahvaljujući ECN podršci bolje ponaša u situacijama sa većim kašnjenjem Iz ispitivanja pri povećanoj verovatnoći odbacivanja paketa je zaključeno da se obe TCP implementacije ponašaju loše Ovo je veoma bitan zaključak iz aspekta upotrebe SACK mehanizma koji bi trebalo da bude robustan u pogledu višestrukih gubitaka paketa

Unapređeni RED mehanizmi gentle RED i adaptive RED su pokazali osetljivost na postavke parametara koji zavise od stanja mreže Ipak čak i u uslovima u kojima ovi RED mehanizmi ne daju optimalno ponašanje njihove ukupne posmatrane performanse su bolje u odnosu na DropTail Pri ispitivanjima na granici DropTail i AQM domena se došlo do zaključaka koji su u suprotnosti sa radom [MBDL99] Autor ove teze tvrdi da su nastale razlike posledica posmatranja veće grupe pojava u simulacijama obavljenim u ovoj tezi Simulalcije su pokazale da RED mehanizmi otklanjaju drastičnu neravnopravnost nastalu upotrebom DropTail mehanizma Takođe je ustanovljeno da u ovakvom okruženju RED mehanizmi mogu potpuno preuzeti funkciju upravljanja svim TCP tokovima U pojedinim situacijama ovaj efekat je praćen znatnim povećanjem učestanosti odbacivanja paketa

Ispitivanja su potvrdila da u realnim situacijama DropTail ima slične performanse kao gentle RED sa verovatnoćom preventivnog odbacivanja paketa maxp=002 Agresivni gentle RED (maxp=01) u odnosu na adaptive RED uglavnom pruža nešto bolju ukupnu pravičnost Ove dve RED implementacije se u opštem slučaju ponašaju slično mada je utvrđeno da adaptive RED može da postavi prosečnu popunjenost bafera u RED zonu i kada gentle RED to ne može Fokusiranje prosečne popunjenosti bafera u RED zonu u ovakvim situacijama nije trenutno i zavisi od fizičkog kapaciteta bafera broja konekcija i stanja mreže Takođe je primećeno da je fokusiranje praćeno povećanom učestanošću odbacivanja paketa koja nema bitan uticaj na pravičnost raspodele propusnog opsega TCP konekcija Očekuje se da bi ova osobina povoljno uticala i na metriku varijacije kašnjenja Konačno treba navesti i neke smernice za dalja istraživanja Jedan od logičnih nastavaka ovog rada je poređenje ispitanih tehnika na većim topologijama sa bogatijim mešavinama saobraćaja Idealno bi bilo da se takva ispitivanja obave na realnoj mreži što bi zahtevalo angažovanje većeg broja ljudi i sredstava Takođe bi bilo zanimljivo ispitati opšte stanje mreže koja koristi mehanizme koji pomažu AQM tehnikama kao što su bolje tehnike raspoređivanja npr fair queuing generalized processor sharing virtual queues Od fundamentalnog značaja je i unapređenje mehanizama estimacije stanja mreže Kao što je navedeno u teorijskom delu teze estimacija se danas obavlja veoma jednostavnim mehanizmima čije poboljšanje verovatno ne bi bitno opteretilo savremene procesore mrežnih uređaja Jedno od zanimljivih rešenja bi bilo i uvođenje estimacije dobijene na sloju transporta u rutiranje sa više metrika Za takvo rešenje neophodno obaviti veoma obimna preliminarna testiranja koja bi u perspektivi rezultovala standardom Pored unapređenja estimacije uvođenje zaštitnog kodovanja na sloju transporta bi moglo biti veoma korisno u sredinama sa povećanom verovatnoćom greške Ipak takvo rešenje bi možda donelo nove probleme adaptacije zaštitnog kocircda na krajnje nepredvidljive uslove ekvivalentnog kodnog kanala kao i izbora segmenata kojima treba dodati zaštitni kocircd Rad u bilo kojoj od ovih oblasti bi doprineo boljem iskorišćenju zagušenih mreža i pružio pouzdaniju platformu novim Internet aplikacijama

58

Dodatak A - Svojstva fraktalnog i multifraktalnog saobraćaja Fraktalna svojstva

U opštem slučaju fraktali predstavljaju objekte koji zadržavaju isti oblik bez obzira na razmeru (odn skaliranje) u kojoj se posmatraju Kada je u pitanju komunikacioni saobraćaj to znači da će njegovi uzorci u intervalima različitog trajanja izgledati samo-slično (engl self similar) Samo-sličnost je osnovo svojstvo fraktalnog (odn unifraktalnog) procesa Znatna promenljivost i pojava sporadičnosti (burstiness) mrežnog saobraćaja u širokim intervalima posmatranja su ključni razlozi uvođenja fraktala u ovu oblast istraživanja [WP98] Ovakvo ponašanje saobraćaja na nivou paketa bitno utiče na ponašanje i logiku dizajna mreže [FP95] koji bitno odstupaju od tradicionalne teorije zasnovane na Poisson-ovom modelu

Fraktalni proces se može definisati pomoću svojstva samo-sličnosti Za ovo svojstvo postoje mnoge definicije koje nisu u potpunosti ekvivalentne Za teoriju mrežnog saobraćaja je bitna ona definicija koja se odnosi na samo-sličnost u smislu raspodele Intuitivno jasna postavka takve definicije se dobija posmatranjem vremenski diskretnog procesa ( )321 == tXX t koji je stacionaran i ima nultu srednju vrednost Definišimo ( )321)()( == kXX m

km čiji su članovi jednaki srednjim vrednostima procesa X na

disjunktnim intervalima veličine m Moglo bi se reci da X(m) predstavlja vremenski grublju reprezentaciju procesa X

111)1(

)( gt= +minus=

kXm

Xkm

kmtt

mk (B1)

Za X se kaže da je potpuno samo-sličan sa parametrom skaliranja Hisin [051) ako za svako pozitivno m X(m) ima istu raspodelu kao X skaliranu sa m H (videti Hurstov parametar)

XmX Hm 1)( minusasymp (B2)

Pored potpune samo-sličnosti proces može ispoljavati manje stroge uslove za samo-sličnost Opis takvih slučajeva prevazilazi okvire ovog rada a detalji se mogu pronaći u [B95]

Posledica samo-sličnosti je pojava zavisnosti širokog opsega (engl long range dependance LRD) koja se može opisati autokorelacionom funkcijom oblika

100~)( ltltinfinrarrgtminus βαα β kkkr (B3)

Primećuje se da ovakva autokorelacija opada srazmerno stepenoj funkciji a ne eksponencijalnoj kao u slučaju tradicionalnih modela saobraćaja Stoga suma autokorelacionih koeficijenata divergira ka beskonačnosti

Hurstov parametar

Ponašanje fraktalnog (unifraktalnog) procesa se može opisati samo jednim parametrom To je Hurstov parametar koji opisuje brzinu opadanja autokorelacione funkcije

2

1 βminus=H (B4)

Procesi koji poseduju svojstvo samo-sličnosti se odlikuju intervalom vrednosti Hurstovog parametra

121 ltlt H (B5)

Svojstvo samo-sličnosti se može statistički testirati na nekoliko načina Neki od njih su RS metoda [B95] periodogram [B95] metoda apsolutnih vrednosti [B95] i wavelet analiza [FGHW99]

59

Pareto raspodela

Funkcija gustine verovatnoće fraktalnog procesa se odlikuje dugačkim repom (engl heavy-tailed distribution) Jedna od najjednostavnijih raspodela ovog tipa je Pareto raspodela Gustina verovatnoće Pareto raspodele je opisana sa

kxkxkxp gegt= +minus 0)( )1( αα αα (B6)

a funkcija raspodele

( )a

xkxXPxF

minus=le= 1)( (B7)

Parametar k predstavlja najmanju moguću vrednost slučajne promenljive

Može se pokazati da za 2leα raspodela ima beskonačnu varijansu dok za 1leα ima i beskonačnu srednju vrednost To znači da smanjenje parametra α utiče na ldquokoličinurdquo verovatnoće u repu raspodele

Multifraktalna svojstva

Fraktali predstavljaju osobine globalnih svojstava skaliranja stohastičkog procesa Detaljnijim ispitivanjem mrežnog saobraćaja [RV97] [FGHW99] se došlo do zaključka da se on u ldquolokalnomrdquo pogledu ponaša kompleksije u odnosu na fraktalni model Stoga je Hurstov parametar više nije dovoljan za opisivanje pojedinih pojava Na scenu su stupili multifraktali koji predstavljaju proširenje fraktalnog modela

Posmatrajmo procese X i )(mX definisane pri objašnjavanju samo-sličnosti Za proces X se kaže da poseduje multifraktalna svojstva ako u smislu raspodele važi jednakost

XmX mHm )()( asymp (B8)

Razlika u odnosu na unifraktalno ponašanje je to što H(m) predstavlja slučajnu funkciju skale m pa Hurstov parametar neće biti dovoljan za opis ovakve pojave

Gornja definicija je formalna iako je intuitivno jasna Praktična upotreba multifraktala se ogleda u sledećem Da bi se posmatrale lokalne varijacije saobraćaja u okolini trenutka t0 potrebno je posmatrati broj paketa ili bajtova u intervalu [t0 t0 + δt] Za saobraćaj se kaže da poseduje lokalni eksponent skaliranja α(t0) u trenutku t0 ako učestanost paketa (ili bajtova) ima ponašanje ( ) )( 0tt αδ kada 0rarrtδ Saobraćaj je multifraktalan ako se α(t0) menja u zavisnosti od trenutka posmatranja Unifraktalan (odn fraktalan) saobraćaj se odlikuje konstantnom vrednošću α(t0) = H za sve trenutke t0

Matematički preciznija definicija multifraktala se može naći u [MFC97]

60

Dodatak B ndash Promenljivi parametri testova Nazivi parametara ne odgovaraju nazivima ns-2 promenljivih Promena naziva je obavljena zbog intuitivno lakšeg razumevanja

Opšti parametri set use_topology net10 mogu ći izbor net 10 netMultiC

set use_interNodes false upotreba konekcija direktno povezanih na ruter r2

set use_TTproc 17 šeme aktivnih čvorova 13 23 17 19

set connectivity ata na čini povezinanja oto (one-to-one) ata (all-to-all)

set use_udp true upotreba UDP konekcije

set tcpType(1) Newreno tip TCP konekcije grupe čvorova Newreno Sack1

set trafType(1) FTP tip saobra ćaja FTP CBR Pareto Trace

set ecn(1) 1 TCP podrška za ECN

Parametri topologije link izme đu rutera

set rrQtype DropTail vrsta reda za čekanje (DropTail ili RED)set rrQsize 50 kapacitet reda za cekanjeset rrLbw 15Mb propusni opsegset rrLdelay 100ms kašnjnjenje

set lossyLink false da li link unosi namerne greške

Kašnjenja izme đu izvora i ruteraset base_delay(1) 100 in [ms] do not append ms to the numberset inc_delay(1) 0 in [ms] do not append ms to the number

RED parametri

set redMinth [expr $rrQsize(1) 4] minth ndash donjni pragset redMaxth [exp r 3 $rrQsize(1) 4] maxth ndash gronji pragset redLinterm 10 inv vrednost max verovatno će odbacivanja max_p

set redMeanPktSize 100 gruba procena srednje veli čine paketa

set redBytes false da li RED radi u bajt režimuset redQinBytes false da li se red za čekanjje meri u bajtima

RED sa ECN podrškomset redSetBit false true da bi se uklju čio ECNset redMark_p 01 kada je p lt mark_p markiraj pakete

kada je p gt mark_p odbaci pakete adaptive RED

set redAdaptive 0 uklju čivanje adaptive RED algoritmaset redAlpha 001 aditivni parametar za max_pset redBeta 09 multiplikativni parametar za max_p

61

set redTop 05 gornja granica za max_pset redBottom 001 donja granica za max_p

TCP parametri Podrazumevane vrednosti TCP parametara ndash dva skupa

set packetSize(1) 1000 veli čina paketa u (bajt)

set window(1) 20 gornja granica prozora koji oglašava Rxset windowInit(1) 1 inicijalna vrednost za cwnd

set ecn(1) 0 da li se koristi ECN

set timestamps(1) false upotreba timestamps opcije

set newreno_changes(1) 0 NewReno promene koje je predlozila Janey Hoe

set newreno_changes1(1) 0 RFC 2582 podrškaset partial_window_deflation(1) 0 RFC 2582 podrška

Parametri saobraćaja Application parameters ======================

CBR - two sets

1 setset cbr_rate(1) 448Kb u čestanost slanja CBR generatoraset cbr_packetSize(1) 210 veli čina generisanog paketaset cbr_maxpkts(1) 268435456 maksimalan broj gener paketa

62

Skraćenice ACK ndash paket potvrde TCP protokola

ACK self-clocking ndash samo-sinhronizacija TCP protokola upotrebom potvrda

AIMD ndash aditivni porast multiplikativno opadanje (engl additive increase ndash multiplicative decrease)

AQM ndash aktivno upravljanje redovima za čekanje (engl active queue management)

avgQ ndash prosečna popunjenost RED bafera

bandwidth delay product ndash proizvod propusnog opsega linka uskog grla i procenjenog RTT intervala

bottleneck ndash link uskog grla

burst ndash sporadičnost slanje grupe paketa za redom ldquorafalnordquo slanje paketa

CBR ndash generator saobraćaja konstantne učestanosti (engl constant bit rate)

congestion collapse ndash kolaps usled zagušenja

CSFQ ndash ravnopravno raspoređivanje bez održavanja stanja na okosnici

cwnd ndash prozor kontole zagušenja (engl congestion window)

ECN ndash eksplicitno obaveštenje o zagušenju (engl explicit congestion notification)

FI ndash indeks pravičnosti (engl fairness indeks)

FQ ndash ravnopravno raspoređivanje (engl fair queuing)

IW ndash inicijalna veličina klizećeg (cwnd) prozora (engl initial window)

lock-out - pojava pri kojoj mali broj TCP tokova zauzima veliki deo propusnog opsega

MIMD ndash multiplikativni porast mulltiplikativno opadanje (engl multiplicative increase ndash multiplicative decrease)

MSS ndash segment najveće veličine (engl maximum segment size)

MTU ndash najveća jedinica slanja

QL ndash dužina befera (engl queue length)

redQ ndash trenutna vrednost popunjenosti RED bafera

RTO ndash interval tajmera retransmisije (engl retransmission timeout)

RTT - vreme obilaska (engl round trip time)

RTTVAR ndash procena varijacije vremena obilaska

rwnd ndash veličina prozora koju oglašava odredište

SFQ ndash stohastičko ravnopravno raspoređivanje

SMSS ndash segment najveće veličine kojeg oglašava izvor

SRTT ndash procena prosečnog vremena obilaska

ssthresh ndash vrednost praga slow start stanja TCP protokola

WRR ndash ravnopravno kružno raspoređivanje sa težinskim koeficijentima

63

Literatura [AF99] M Allman A Falk ldquoOn the effective evaluation of TCPrdquo ACM Computer Communication Review okt 1999

[ALLY01] S Athuraliya V H Li S H Low Q Yin (2001 maj) REM Active Queue Management IEEE Network [Online] Dostupno na httpnetlabcaltechedunetlab-pubcbefpdf

[AP99] M Allman V Paxon ldquoOn estimating end-to-end network path propertiesrdquo Proc of the ACMSIGCOMM `99 avg 1999

[AR99] A Acharya A Rangarajan ldquoEarly regulation of unresponsive flowsrdquo UCSB Tech Report TRCS99-26 jul 1999

[B95] J Beran ldquoStatistics for Long-Memory Processesrdquo New York Chapman amp Hall 1995

[BFF00] L Breslau K Fall S Floyd S i dr ldquoAdvances in network simulationrdquo IEEE Computer str 59-67 maj 2000

[BOP94] L S Brakmo S W OrsquoMalley L L Peterson ldquoTCP Vegas New techniques for congestion detection and avoidancerdquo Proceedings of ACM SIGCOMM okt 1994 str 24ndash35

[BSAK95] H Balakrishnan S Seshan E Amir R H Katz ldquoImproving performance of TCPIP over wireless networksrdquo Proc of ACM MOBICOM 95 1995 str 2ndash11

[CB97] M E Crovella A Bestavros ldquoSelf-similarity in World Wide Web traffic Evidence and possible causesrdquo IEEEACM Trans on Networking 5(6) str 835-846 dec 1997

[CC02] J Chung M Claypool ldquoAnalysis of RED-family Active Queue Management over a wide-range of TCP loadsrdquo Worcester Polytechnic Institute Technical Report WPI-CS-TR-02-05 feb 2002

[CDZ97] K Calvert M Doar E W Zegura ldquoModeling Internet topologyrdquo IEEE Communications Magazine str 160-163 jun 1997

[CJ89] D M Chiu R Jain ldquoAnalysis of increase and decrease algorithms for congestion avoidance in computer networksrdquo Journal of Computer Networks and ISDN Vol 17 No 1 jun 1989 str 1-14

[CJOS01] M Christiansen K Jeffay D Ott FD Smith ldquoTuning RED for web trafficrdquo IEEEACM Trans on Networking 9(3) jun 2001 str 249 ndash 264

[DKS90] A Demers S Keshav S Shenker ldquoAnalysis and Simulation of a Fair Queuing Algorithmrdquo J Internetworking Research and Experiance okt 1990 str 3-26

[Fen99] W C Feng ldquoImproving Internet congestion control and queue management algorithmsrdquo PhD Thesis University of Michigan Ann Arbor MI 1999

[FF96] K Fall S Floyd ldquoSimulation-based comparisons of Tahoe Reno and SACK TCPrdquo ACM Computer Communication Review jul 1996

[FF99] S Floyd K Fall (1999 avg) Promoting the use of end-to-end congestion control in the Internet IEEEACM Trans on Networking [Online] Dostupno na httpwwwicirorgfloydpaperscollapsemay99pdf

[FGHW99] A Feldmann A Gilbert P Huang W Willinger ldquoDynamics of IP traffic A study of the role of variability and the impact of controlrdquo Proc of the ACMSIGCOMM `99 avg 1999

[FGS01] S Floyd R Gummadi S Shenker (2001 avg) Adaptive RED An Algorithm for Increasing the Robustness of REDrsquos Active Queue Management [Online] Dostupno na wwwicirorgfloydpapersadaptiveRedpdf

[FJ95] S Floyd V Jacobson ldquoLink-sharing and resource management models for packet networksrdquo IEEEACM Trans on Networking avg 1995

[FKSS99] W Feng D Kandlur D Saha K Shin ldquoA Self-Configuring RED Gatewayrdquo IEEE INFOCOM 99 mart 1999

[Floyd97] S Floyd (1997 mart) RED Discussions of Byte and Packet Modes [Online] Dostupno na httpwwwicirorgfloydREDaveragingtxt

64

[Floyd00] S Floyd (2000 mart) Recommendation on using the gentle_ variant of RED [Online] Dostupno na httpwwwicirorgfloydredgentlehtml

[FP01] S Floyd V Paxon ldquoDifficulties in simulating the Internetrdquo IEEEACM Trans on Networking vol9 no4 avg 2001

[GL03] A Gurtov R Ludwig (2003 apr) Responding to spurious timeouts in TCP IEEE INFOCOM 2003 [Online] Dostupno na httpwwwieee-infocomorg2003papers56_03pdf

[Gur00] A Gurtov ldquoTCP performance in the presence of congestion and corruption lossesrdquo MSc Thesis University of Helsinki dec 2000

[Hoe95] J Hoe ldquoStart-up dynamics of TCPs congestion control and avoidance schemesrdquo MSc Thesis MIT 1995

[Hoe96] J Hoe ldquoImproving the start-up behavior of congestion control scheme for TCPrdquo ACM SIGCOMM avg 1996

[IETForg] Internet Engineering Task Force httpwwwietforg

[J91] R Jain ldquoThe Art of Computer Systems Performance Analysisrdquo John Wiley and Sons 1991

[JK88] V Jacobson M J Karels ldquoCongestion avoidance and controlrdquo ACM SIGCOMM avg 1988

[KP87] P Karn C Partridge ldquoImproving round-trip-time estimates in reliable transport protocolsrdquo ACM SIGCOMM 87 1987

[Kuh00] P Kuhlberg ldquoEffect of delays and packet drops on TCP-based wireless data communications rdquo MSc Thesis University of Helsinki dec 2000

[LK98] D Lin H Kung ldquoTCP recovery strategies Analysis and improvementsrdquo IEEE INFOCOM 98 mart 1998

[LK00] R Ludwig R H Katz ldquoThe Eifel algorithm Making TCP robust against spurious retransmissionsrdquo ACM Computer Communication Review vol 30 (1) jan 2000

[LM97] D Lin R Morris ldquoDynamics of Random Early Detectionrdquo ACM SIGCOMM sep 1997

[LTWW94] W E Leland M Taqqu W Willinger D V Wilson ldquoOn the self-similar nature of Ethernet traffic (extended version)rdquo IEEEACM Trans on Networking vol2 no1 feb 1994

[MBDL99] M May J Bolot C Diot B Lyles ldquoReasons not to Deploy REDrdquo Proc of 7th Int Workshop on Quality of Service (IWQoS99) London 1999

[MF01] R Mahajan S Floyd ldquoControlling high-bandwidth flows at the congested routerrdquo ICSI Tech Report TR-01-001 apr 2001

[MFC97] B Mandelbrot A Fisher L Calvet ldquoA multifractal model of asset returnsrdquo Yale University Cowles Foundation Discussion Paper 1164

[MK91] P McKenny ldquoStochastic Fairness Queuingrdquo Internetworking Research and Experience Vol 2 str 113-131 jan 1991

[MLAW99] J Mo R J La V Anantharam J Walrand (1999 mart) Analysis and Comparison of TCP Reno and Vegas INFOCOM 99 New York [Online] Dostupno na httpwwwieee-infocomorg1999papers11c_02pdf

[MSMO97] M Mathis J Semke J Mahdavi T Ott ldquoThe macroscopic behavior of the TCP congestion avoidance algorithmrdquo ACM Computer Communication Review 27(3) July 1997

[ns2] Network simulator ndash ns-2 Dostupno na httpwwwisiedunsnamns

[nsD1] ldquoThe ns Manualrdquo Dostupno na httpwwwisiedunsnamnsdocns_docpdf

[nsD2] ldquoNs Limitationsrdquo Dostupno na httpwwwisiedunsnamnsns-limitationshtml

[nsD3] ldquons Change Historyrdquo Dostupno na httpwwwisiedunsnamnsCHANGEShtml

[PSC1] rdquoEnabling High Performance Data Transfersrdquo Dostupno na httpwwwpscedunetworkingperf_tunehtml

65

[PSC2] rdquoThe TCP-Friendly Websiterdquo Dostupno na httpwwwpscedunetworkingtcp_friendlyhtml

[PF95] V Paxon S Floyd ldquoWide-area traffic The failure of Poisson modeling rdquo IEEEACM Trans on Networking 3(3) str 226-244 jun 1995

[PFTK98] J Padhye V Firoiu D Towsley J Kurose ldquoModeling TCP throughput A simple model and its empirical validationrdquo ACM SIGCOMM 98 1998

[FHPW00] S Floyd M Handley J Padhye J Widmer ldquoEquation-based congestion control for unicast applications the extended versionrdquo International Computer Science Institute Tech report TR-00-003 mart 2000

[OLW99] T J Ott T V Lakshman L Wong ldquoSRED Stabilized REDrdquo IEEE INFOCOM lsquo99 mart 1999

[PB02] K Pentikousis H Badr ldquoAn evaluation of TCP with Explicit Congestion Notificationrdquo Annals of Telecommunications 2002

[PF97] V Paxon S Floyd ldquoWhy we dont know how to simulate the Internetrdquo Proc of the 1997 Winter Simulation Conference dec 1997

[PKTK98] J Padhye J Kurose D Towsley R Koodli ldquoA TCP-friendly rate adjustment protocol for continuous media flows over best effort networksrdquo University of Massachusetts UMass-CMPSCI Technical Report TR 98-04 okt 1998

[RED93] S Floyd V Jacobson ldquoRandom Early Detection gateways for congestion avoidancerdquo IEEEACM Trans on Networking str 397-413 avg 1993

[RFC793] J B Postel ldquoTransmission Control Protocolrdquo RFC 793 sep 1981

[RFC1323] V Jacobson R Barden D Borman ldquoTCP Extensions for High Performancerdquo RFC 1323 maj 1992

[RFC1191] J Mogul S Deering ldquo Path MTU Discoveryrdquo RFC 1191 nov 1990

[RFC2018] M Mathis J Mahdavi S Floyd A Romanow ldquoTCP Selective Acknowledgement Optionsldquo RFC 2018 okt 1996

[RFC2140] J Touch ldquoTCP Control Block Independencerdquo RFC 2140 apr 1997

[RFC2309] B Braden D Clark J Crowcroft B Davie S Deering D Estrin S Floyd V Jacobson G Minshall C Partridge L Peterson K Ramakrishnan S Shenker J Wroclawski L Zhang ldquoRecommendations on queue management and congestion avoidance in the internetrdquo RFC 2309 april 1998

[RFC2414] M Allman S Floyd C Partridge ldquoIncreasing TCPrsquos Initial Windowrdquo RFC 2414 sep 1998

[RFC2415] K Poduri K Nichols ldquoSimulation Studies of Increased Initial TCP Window Sizerdquo RFC 2415 sep 1998

[RFC2582] S Floyd T Henderson ldquoThe NewReno Modification to TCPs Fast Recovery Algorithmrdquo RFC 2582 apr 1999

[RFC2861] M Handley J Padehye S Floyd ldquoTCP Congestion Window Validationrdquo RFC 2861 jun 2000

[RFC2883] S Floyd J Mahdavi M Mathis M Podolsky ldquoAn Extension to the Selective Acknowledgement (SACK) Option for TCPrdquo RFC 2883 jul 2000

[RFC2988] V Paxon M Allman ldquoComputing TCPrsquos Retransmission Timerrdquo RFC 2988 nov 2000

[RFC3042] M Allman H Balakrishnan S Floyd ldquoEnhancing TCPs Loss Recovery Using Limited Transmitrdquo RFC 3042 jan 2001

[RFC3168] K Ramakrishnan S Floyd S Black ldquoThe Addition of Explicit Congestion Notification (ECN) to IPrdquo RFC 3168 sep 2001

[RFCi] Indeks RFC dokumenata Dostupno na httpwwwietforgrfchtml

[RJ90] K Ramakrishnan R Jain ldquoA binary feedback mechanism for congestion avoidance in computer networksrdquo ACM Trans on Computer Systems 8(2) maj 1990

66

[RV97] RH Riedi J L Veacutehel ldquoMultifractal properties of TCP traffic A numerical studyrdquo INRIA Rocquencourt Technical Report 3129 mar 1997

[SR01] A L Smitha N Reddy ldquoLRU-RED An active queue management scheme to contain high bandwidth flows at congested routersrdquo MSc Thesis Texas A amp M University maj 2001

[SSZ03] I Stoica S Shanker H Zhang ldquoCore-Stateless Fair Queuing A scalable architecture to approximate fair bandwidth allocations in high speed networksrdquo IEEEACM Trans on Networking vol 11 no1 feb 2003

[Ste98] W R Stevens ldquoTCPIP Illustrated Volume 1rdquo Addison-Wesley 1998

[Vai99] N Vaidya (1999) Tutorial on TCP for Wireless and Mobile Hosts [Online] Dostupno na httpwwwcrhcuiuceduwirelesstalkstcp-wireless-tutorialppt

[VH97] V Visweswaraiah J Heidemann ldquoImproving restart of idle TCP connectionsrdquo University of Southern California Tech Report 97-661 nov 1997

[VRC98] L Vicisano L Rizzo J Crowcroft ldquoTCP-like congestion control for layered multicast data transferrdquo IEEE INFOCOM rsquo98 1998

[WC98] B Whetten J Conlan ldquoA rate based congestion control scheme for reliable multicastrdquo GlobalCast Communications Technical White Paper okt 1998

[Win99] N P Wing ldquoAn empirical study of TCPrsquos fairnessrdquo MSc Thesis The Hong Kong Polytechnic University apr 1999

[WP98] W Willinger V Paxon ldquoWhere mathematics meets the Internetrdquo Notices of American Mathematical Society vol 45 no 8 pp 961-970 avg 1998

[ZCB96] E W Zegura K Calvert S Bhattacharjee ldquoHow to model an Internetworkrdquo Proc of IEEE Infocom lsquo96 mart 1996

[ZSC91] L Zhang S Shenker D D Clark ldquoObservations of a congestion control algorithm The effects of two way trafficrdquo ACM SIGCOMM rsquo91 sep 1991