EWOLUCJA OKNA PRZECI ENIOWEGO PROTOKO U TCP

Transkrypt

1 Agnieszka Chodorek Zak ad Telekomunikacji i Fotoniki Politechnika wi tokrzyska Al. 00-lecia P.P Kielce 2003 Poznañskie Warsztaty Telekomunikacyjne Poznañ grudnia 2003 EWOLUCJA OKNA PRZECI ENIOWEGO PROTOKO U TCP Streszczenie: W referacie zosta zaprezentowany mechanizm zapobiegania przeci eniom zaimplementowany w protokole TCP. Podano opis mechanizmu. Zaprezentowano analiz symulacyjn ewolucji okna przeci eniowego TCP oraz wydajno ci protoko u TCP w ró nych warunkach pracy. Symulacje zrealizowano w rodowisku symulatora zdarzeniowego ns WST P Protokó TCP (Transmission Control Protocol), jest obecnie najbardziej popularnym protoko em warstwy transportowej. ci le wspó pracuje z protoko em IP warstwy sieciowej (zarówno z IPv4, jak i z IPv6), tworz c wraz z nim stos protoko owy TCP/IP. Protokó TCP zapewnia niezawodn transmisj danych pomi dzy dwoma systemami ko cowymi. Realizuje (w miar mo liwo ci) transmisj zorientowan na optymalne wykorzystanie dost pnych zasobów sieciowych, z zachowaniem sprawiedliwego podzia u zasobów pomi dzy transmisje TCP charakteryzuj ce si identycznymi parametrami. Do tego celu protokó wykorzystuje szereg mechanizmów, takich jak: algorytm powolnego startu, retransmisji, sterowania przep ywem oraz tytu owy mechanizm zapobiegania przeci eniom. Pierwotnie, protokó TCP zestandaryzowany w roku 1981 dokumentem RFC 793 [2], nie zawiera mechanizmów zapobiegania przeci eniom sieci pakietowych. Co wi cej nie rozwa ano wówczas w ogóle problemów zwi zanych z przeci eniami, o czym mo e wiadczy fakt, e w 83-stronicowym dokumencie s owo przeci enie (ang. congestion) pojawia si tylko dwa razy (i to tylko w kontek cie mo liwych przyczyn powstawania strat pakietów, na równi z b dami transmisji). Jednak e ju w 1988 roku pojawi a si fundamentalna praca [3], w której zarówno wskazano na zagro enia dla sieci bazuj cej na stosie protoko owym TCP/IP, jakie nios ze sob przeci enia, jak równie zaproponowano wprowadzenie do TCP siedmiu nowych mechanizmów, w ród których znalaz y si równie mechanizmy zapobiegania przeci eniom. W ci gu ponad 20 lat, jakie up yn y od chwili opublikowania RFC 793, pojawia y si kolejne wersje protoko u TCP, uzupe niaj ce podstawow specyfikacj. Cz z nich wprowadza a równie uzupe nienia zwi zane z zapobieganiem przeci eniom: mechanizm powolnego startu, zapobiegania przeci eniom oraz algorytm szybkiej retransmisji (TCP Tahoe [4]), mechanizm szybkiego odtwarzania (TCP Reno [4]), mechanizm zapobiegania przeci eniom oparty na estymacji dost pnej przepustowo ci sieci (TCP Vegas [5]). Obecnie stosowana wersja TCP TCP SACK [6] stanowi rozszerzenie wersji TCP Reno o selektywne potwierdzenia (pojedyncze ACK mo e przenosi danie retransmisji N pakietów). Wersja SACK jest obecnie wykorzystywana w popularnych systemach operacyjnych (np. Windows XP, Linux j dro 2.4, Solaris 9.0). Wersja ta b dzie przedmiotem rozwa a przedstawionych w niniejszym referacie. Celem referatu jest zaprezentowanie mechanizmu zapobiegania przeci eniom zaimplementowanego w protokole TCP. Rozdzia drugi definiuje poj cie przeci enia sieci pakietowej. W rozdziale trzecim zosta zaprezentowany mechanizm zapobiegania przeci eniom zastosowany w protokole TCP. Rozdzia czwarty analizuje dzia anie mechanizmu zapobiegania przeci eniom na przyk adzie sieci realizuj cej pojedyncz transmisj TCP. Do ilustracji dzia ania mechanizmów protoko u TCP zosta wykorzystany symulator zdarzeniowy ns PRZECI ENIA SIECI PAKIETOWYCH RFC 3272 [7] definiuje przeci enie sieci pakietowej jako pewien stan zasobów sieciowych, w którym ruch podawany na dany zasób w pewnym przedziale czasu przekracza jego wyj ciow przepustowo. Przeci enie jest zjawiskiem chwilowym i mo e by interpretowane jako swoiste zak ócenie, wprowadzaj ce sie w stan nieustalony. Mo e by ono wynikiem np. w a ciwo ci statystycznych przenoszonego ruchu (w tym: samopodobie stwa), do czenia si nowych u ytkowników, b d te pewnych dzia a, podejmowanych przez aplikacje i/lub protoko y w celu maksymalizacji wykorzystania zasobów sieciowych. Jak podaje [7], typowo czas trwania przeci enia wynosi od pikosekund do minut. W tym czasie przeci enie powinno zosta roz adowane przez mechanizmy zapobiegania przeci eniom, zaimplementowane w protoko ach warstwy transportowej. Dzia ania

2 te mog by wspomagane przez urz dzenia pracuj ce w warstwie sieciowej (rutery), dzi ki odpowiedniemu kolejkowaniu (np. zastosowanie kolejki RED) lub sygnalizacji (np. zastosowanie sygnalizacji ECN). Je eli przeci enie trwa d u ej (godziny, dni, miesi ce), mamy do czynienia z niedostosowaniem zasobów sieciowych do istniej cych potrzeb. Tego typu problemy nale y rozwi zywa z wykorzystaniem procedur rutingu (lub wr cz sta ej rekonfiguracji logicznej topologii sieci) [7] oraz odpowiedniej polityki zarz dzania zasobami realizowanej przez dostawc us ug sieciowych. Poniewa przeci enie jest de facto chwilowym wyczerpaniem si zasobów sieciowych, podstawowym objawem przeci enia s straty pakietów w buforach w z ów po rednicz cych, nie b d cych w stanie przej chwilowego wzrostu nat enia ruchu. Z tego wzgl du, wi kszo mechanizmów zapobiegania przeci eniom opiera si na pomiarze strat pakietów, jako na wiarygodnej metodzie detekcji przeci enia. Metoda ta bardzo dobrze sprawdza si w sieciach przewodowych, jest jednak bardzo zawodna w sieciach bezprzewodowych, gdzie stopa b dów jest stosunkowo du a. Dlatego te obecnie prowadzone s intensywne prace nad nowymi wersjami protoko u TCP, posiadaj cymi udoskonalone mechanizmy estymacji dost pnych zasobów sieciowych nie bazuj ce na stratach pakietów np. TCP Westwood [8] (estymacja opiera si na analizie strumienia potwierdze poddanego filtracji dolnoprzepustowej). Metoda detekcji przeci enia poci ga za sob metod sygnalizacji przeci enia. Typowo, informacja o wyst pieniu przeci enia jest to sama z informacj o utracie pakietu. W przypadku protoko u TCP, sygnalizacja taka odbywa si zgodnie z algorytmem szybkiej retransmisji (ang. Fast Retransmit), czyli przez wielokrotne (typowo: czterokrotne potwierdzenie plus jego trzy powtórzenia) wys anie potwierdzenia odbioru ostatniego poprawnie odebranego pakietu. Inn metod sygnalizacji przeci e jest tzw. sygnalizacja ECN [9], w której kolejka RED (zaimplementowana w ruterze) wykrywa ci g y wzrost zaj to ci bufora, o czym odbiornik jest informowany poprzez ustawienie odpowiednich znaczników w nag ówku protoko u IP. Odbiornik, z kolei, wysy a do nadajnika informacj sygnalizacyjn w nag ówku potwierdzenia ACK (pole ECN-Echo nag ówka protoko u TCP). 3. CHARAKTERYSTYKA MECHANIZMU ZAPOBIEGANIA PRZECI ENIOM ZAIMPLEMENTOWANEGO W PROTOKOLE TCP Mechanizm zapobiegania przeci eniom, zaimplementowany w protokole TCP, jest z o eniem czterech al.gorytmów []: algorytmu zapobiegania przeci eniom, algorytmu powolnego startu, algorytmu szybkiej retransmisji i algorytmu szybkiego odtwarzania. Dzia anie mechanizmu zapobiegania przeci eniom opiera si na zasadzie okna: w danej chwili czasu, w systemie nie mo e znale si wi cej pakietów, ni wynosi rozmiar okna. Sterowanie oparte o mechanizm okna zosta o zdefiniowane ju w RFC 793 jest to okno transmisyjne (ang. receiver window), wykorzystywane do sterowania przep ywem (ang. flow control). Zgodnie z tym mechanizmem, nadajnik TCP mo e bez potwierdzenia przes a co najwy ej tyle pakietów, ile wynosi rozmiar okna transmisyjnego. Sterowanie przep ywem pozwala na dostosowanie pr dko ci przep ywu danych do szybko ci odbiornika, dzi ki czemu unika si niebezpiecze stwa przepe nienia buforów nadajnika. Rozmiar okna transmisyjnego jest okre lany przez odbiornik i przesy any do nadajnika po raz pierwszy: podczas nawi zywania po czenia TCP, a nast pnie w ka dym pakiecie ACK (rozmiar startowy mo e by w ka dej chwili zmodyfikowany). W przeciwie stwie do okna transmisyjnego, okno przeci eniowe nie ma sta ego (b d odcinkowosta ego) rozmiaru, lecz podlega nieustannej inkrementacji. Tempo tej inkrementacji jest dostosowane do prawdopodobie stwa wyst pienia przeci enia. Algorytm inkrementacji okna przeci eniowego uwzgl dnia bowiem dwa obszary pracy mechanizmu zapobiegania przeci eniom: obszar o ma ym prawdopodobie stwie wyst pienia przeci enia jest to obszar dla okien przeci eniowych wi kszych lub równych 1 i mniejszych od pewnej, zadanej wielko ci progowej sstresh (ang. slow start treshold). obszar o du ym prawdopodobie stwie wyst pienia przeci enia jest to obszar dla okien przeci eniowych o rozmiarze wi kszym od wielko ci progowej sstresh. Algorytm inkrementacji okna przeci eniowego przedstawia si nast puj co: 1. W chwili pocz tkowej, rozmiar okna przeci eniowego cwnd jest równy IW. 2. Je eli mechanizm zapobiegania przeci eniom pracuje w obszarze o ma ym prawdopodobie stwie wyst pienia przeci enia, rozmiar okna przeci eniowego ro nie w tempie wyk adniczym. 3. Je eli mechanizm zapobiegania przeci eniom pracuje w obszarze o du ym prawdopodobie stwie wyst pienia przeci enia, rozmiar okna przeci eniowego narasta liniowo. Wielko IW nie powinna przekracza dwóch pakietów (zwykle przyjmuje si IW = 1), chocia nowsze standardy dopuszczaj równie wi ksze rozmiary [11]. Warto pocz tkowa sstresh powinna by dowolnie wysoka (zwykle jest równa wielko ci pocz tkowej rozmiaru okna transmisyjnego rwnd). Tempo wzrostu okna przeci eniowego jest regulowane poprzez odpowiednie procedury obs ugi odbioru potwierdze ACK. W fazie wzrostu wyk adniczego, rozmiar okna jest inkrementowany zgodnie z algorytmem powolnego startu (ang. Slow Start), tj. okno jest zwi kszane o 1 z chwil odebrania ka dego potwierdzenia ACK: cwnd k 1 cwnd k 1, (1) gdzie k jest numerem kolejnym okna przeci eniowego. W fazie wzrostu liniowego, rozmiar okna jest zwi kszany o 1 z chwil odebrania potwierdzenia ACK ostatniego pakietu nale cego do okna o bie cym rozmiarze. W praktyce, aby unikn przechowywania

3 informacji o numerze sekwencyjnym ostatniego pakietu z danego rozmiaru okna, rozmiar okna przeci eniowego cz sto wyznaczany jest z chwil odebrania ka dego potwierdzenia ACK, zgodnie z zale no ci : 1 cwndk 1 cwndk. (2) cwndk Specyfikacja protoko u TCP definiuje minimalny rozmiar okna przeci eniowego, nie definiuje jednak e rozmiaru maksymalnego. Wraz z ka dym odbiorem potwierdzenia ACK, nadajnik zwi ksza okno przeci eniowe zgodnie ze wzorem (1) lub (2). Inkrementacja okna przeci eniowego trwa, dopóki odbiornik nie odbierze informacji sygnalizacyjnej o wyst pieniu przeci enia. Je eli w systemie nie wyst puj ani przeci enia, ani b dy transmisji, inkrementacja okna przeci eniowego mo e, teoretycznie, trwa w niesko czono. Nie oznacza to jednak, e pr dko bitowa ród a ruchu, jakim jest nadajnik TCP, równie b dzie ros a w niesko czono. Ze wzgl du na z o enie dwóch mechanizmów, w danej chwili czasu, w systemie nie mo e znale si wi cej pakietów, ni wynosi minimalny rozmiar okna (przeci eniowego lub transmisyjnego): w min cwnd, rwnd. (3) Oczywi cie, dla du ych okien transmisyjnych jest bardzo prawdopodobne, i przeci enie nast pi zanim okno przeci eniowe protoko u TCP osi gnie rozmiar okna transmisyjnego. W tej sytuacji istnieje mo liwo, i protokó TCP b dzie pracowa w stanie permanentnego przeci enia. Je eli w systemie wyst pi przeci enia i (lub) b dy transmisji, protokó TCP uruchamia algorytm przeciwdzia ania przeci eniom. Zgodnie z tym algorytmem, w chwili wykrycia straty pakietu, w zale no ci od metody detekcji, wielko okna przeci eniowego jest redukowana do: po owy aktualnej wielko ci okna w: 1 cwnd 2 w (4) je eli wykrycie straty pakietu nast pi o w odbiorniku (na podstawie przerwy w numeracji sekwencyjnej kolejnych, nadchodz cych pakietów), jedno ci: cwnd 1 (5) je eli wykrycie straty pakietu nast pi o w nadajniku (na podstawie przekroczenia maksymalnego czasu retransmisji RTO). Równocze nie, wielko sstresh jest redukowana do po owy aktualnej wielko ci okna w, nie mniejszej jednak, ni dwa: 1 sstresh max 2, w, 2 (6) Je eli po owa aktualnej wielko ci okna w nie jest liczb ca kowit, warto sstresh jest zaokr glana. 4. EWOLUCJA OKNA PRZECI ENIOWEGO I JEJ WP YW NA WYDAJNO TCP: ANALIZA SYMULACYJNA topologii przedstawionej na Rys. 1, sk adaj c si z jednego w z a nadawczego (nad1), jednego w z a odbiorczego (odb1) i jednego w z a po rednicz cego (ruter R1). W ze nadawczy jest po czony z ruterem R1 czem o przepustowo ci 0 Mb/s i opó nieniu propagacyjnym 1 s. Ruter R1 po czony jest z odb1 czem o przepustowo ci Mb/s i opó nieniu p (warto domy lna p wynosi 5 ms). 0 Mb/s Mb/s 1 s p R1 nad1 odb1 Rys. 1. Topologia wykorzystywana podczas analizy Za o ono, e wszystkie w z y posiadaj niesko czony bufor (dok adniej: 2000 pakietów), a wzgl dne procentowe straty pakietów w buforach b d realizowane jako b dy transmisji: losowe o rozk adzie równomiernym, deterministyczne, wyst puj ce okresowo. Losowe b dy transmisji modeluj przypadek, gdy przeci enie przy wspó udziale dodatkowego ruchu. B dy deterministyczne obrazuj sytuacj, gdy (ze wzgl du na ci g ewolucj okna przeci eniowego) nast puje cykliczne przepe nianie buforów sieci nieobci onej dodatkowym ruchem. Ró ny charakter b dów transmisji (a zatem: ró na przyczyna strat pakietów) poci gaj za sob ró nice w sposobie ewolucji okna przeci eniowego. W przypadku strat cyklicznych, pi okszta tny przebieg cwnd w funkcji b dów transmisji ma charakter okresowy. W przypadku strat losowych, czas trwania pojedynczego cyklu narastania okna przeci eniowego jest zmienn losow (tu: o rozk adzie normalnym). Jednak e, przy tej samej stopie b dów, liczba przedzia ów narastania okna przeci eniowego, liczona dla strat losowych i deterministycznych, jest bardzo zbli ona. Zgodnie z rozwa aniami przedstawionymi w [12][13], je eli okno transmisyjne nie stanowi ograniczenia wydajno ci protoko u, a jedyne ograniczenie stanowi przepustowo sieci, to przep ywno protoko u TCP zale y g ównie od rozmiaru pola danych MSS pakietu TCP oraz czasu RTT. Rys. 2 Rys. 5 przedstawiaj rodziny charakterystyk utworzone dla ró nych warto ci RTT (Rys. 2 i Rys. 4) oraz MSS (Rys. 3 i Rys. 5). Do celów analizy przyj to, i czas RTT b dzie rozumiany jako podwojony czas propagacji i b dzie wynosi : 0.1 ms (na Rys. 2, Rys. 4 oznaczony symbolem x ), 1 ms (+), ms ( ), 0 ms (o), co w du ym przybli eniu odpowiada odleg o ci pomi dzy stacjami zlokalizowanymi w: tym samym mie cie, dwóch ró nych miastach, dwóch ró nych pa stwach, na dwóch ró nych kontynentach. Rozmiar MSS z kolei Analiza symulacyjna zosta a przeprowadzona w rodowisku symulatora ns-2 [1]. Analizowano sie o

4 redni rozmiar okna cwnd (w pakietach) redni rozmiar okna cwnd (w pakietach) liczba redukcji okna cwnd 00 liczba redukcji okna cwnd (c) 1 5 (c) 1 5 redni czas cyklu narastania (s) redni czas cyklu narastania (s) rednia warto sstresh (w pakietach) (d) rednia warto sstresh (w pakietach) (d) Rys. 2. Charakterystyki statystyczne cwnd i sstresh w funkcji losowych b dów transmisji (ró ne RTT). Rys. 3. Charakterystyki statystyczne cwnd i sstresh w funkcji losowych b dów transmisji (ró ne MSS).

5 przep ywno TCP (b/s) 5 6 przep ywno TCP (b/s) straty [w pakietach] 1 00 straty [w pakietach] 00 Rys. 4. Wydajno TCP w funkcji losowych b dów transmisji (ró ne RTT). wynosi : 256 B (na Rys. 3, Rys. 5 oznaczony symbolem x ), 00 B (+), 1452 B ( ), 4312 B (o). Warto MSS = 00 B jest warto ci ustawian domy lnie w symulatorze ns-2. Warto ci MTU: 256 B, 1452 B i 4312 B odpowiadaj warto ciom MTU cza punktpunkt (protokó SLIP), sieci Ethernet (802.3/802.2) i sieci FDDI, pomniejszonych o 40 B (20 B nag ówka TCP plus 20 B nag ówka IP). Przyj to równie, i rozmiar okna transmisyjnego rcwnd = 20 pakietów, co jest wielko ci domy ln symulatora ns-2, stosowan w wielu publikacjach. Dla ró nych RTT, wraz ze wzrostem (losowych) procentowych strat pakietów od -4 % do 90%, redni rozmiar okna cwnd (Rys. 2a) zmienia si od ok. 328 pakietów do 1,5 pakietu dla ma ych i rednich RTT oraz od 134 pakietów do 1,5 pakietu dla RTT = 0 ms. W tych samych warunkach, maksymalne rozmiary okna cwnd waha y si od 490 do 2 pakietów dla ma ych i rednich RTT oraz od 200 do 2 pakietu dla RTT = 0 ms. Dla b dów rz du 0,01% rozmiar cwnd praktycznie nie zale a ju od RTT. W przypadku strat cyklicznych, zarówno warto ci rednie, jak i maksymalne by y o ok. 2/3 mniejsze i nie zale a y od RTT w ca ym zakresie badanych zmian stopy b dów. Wariancja okna przeci eniowego, pocz tkowo du a (rz du 4 ), szybko spada a, a do bardzo niskich warto ci (rz du 1 ) dla du ych b dów. Rys. 5. Wydajno TCP w funkcji losowych b dów transmisji (ró ne MSS). Liczba redukcji okna cwnd (Rys. 2b) pocz tkowo wzrasta, osi gaj c maksimum dla b dów rz du 2 4%, po czym stosunkowo szybko opada. Najmniejsza ilo redukcji okna wyst puje dla du ych RTT, gdzie ca kowita liczba przesy anych pakietów jest o rz d wielko ci mniejsza, ni w przypadku transmisji charakteryzuj cych si najwi ksz liczb redukcji (RTT: 0,1 ms i 1 ms). W przypadku b dów cyklicznych, maksimum wszystkich charakterystyk jest w tym samym punkcie (%), a maksymalna liczba redukcji okna silniej zale y od RTT (dla du ych RTT jest zbli ona, dla RTT = 0,1 ms wzros a o rz d wielko ci). Jak mo na si by o spodziewa, redni czas cyklu narastania by odwrotnie proporcjonalny do liczby redukcji okna, jednak tutaj zale no od RTT by a s absza. Na Rys. 2c mo na praktycznie wyró ni dwie grupy krzywych: charakterystyki dla ma ych i rednich RTT oraz dla du ych RTT (RTT = 0 ms). W przypadku b dów cyklicznych, zale no od RTT jest silniej zarysowana. W ca ym obserwowanym zakresie zmian pakietowej stopy b dów, rednia warto wielko ci progowej sstresh tylko w minimalnym stopniu zale y od RTT dla b dów losowych (Rys. 2d) i w ogóle nie zale y od RTT dla b dów cyklicznych. Parametr sstresh osi ga wi ksze warto ci w przypadku b dów o charakterze losowym. Dla niewielkich b dów

6 rednia zaj to bufora rutera R1 wariancja zaj to ci bufora rutera R Rys. 6. Zaj to bufora rutera R1 w funkcji losowych b dów transmisji (ró ne RTT). ( 0,01% dla losowych i 0,5% dla cyklicznych), sstresh stabilizowa si na poziomie (b dy losowe) lub 4 pakietów (b dy cykliczne). Charakterystyki statystyczne cwnd i sstresh w funkcji losowych b dów transmisji, wyznaczone dla ró nych MSS (Rys. 3), wskazuj na podobne zale no ci jak rodziny charakterystyk wyznaczonych dla RTT (Rys. 2). Mo na zaobserwowa jedynie siln zale no redniego rozmiaru okna cwnd od MSS (Rys. 3a) dla ma- ych warto ci b dów (poni ej 0.1%). Tak e redni czas cyklu narastania (Rys. 3c) jest silnie zale ny od MSS dla stosunkowo ma ych warto ci b dów (poni ej 3%). Wydajno protoko u TCP (Rys. 4, Rys. 5) spada wraz ze wzrostem procentowych strat pakietów. Jednak e obserwowany spadek przep ywno ci jest znacznie wi kszy, ni wynika oby to tylko ze strat pakietów oraz retransmisji. Spadek wydajno ci wi e si z, opisywan powy ej, znaczn redukcj okna przeci eniowego cwnd. W skrajnym przypadku, dla analizowanych b dów losowych powy ej 70% i cyklicznych powy ej 50%, TCP nie by o w stanie realizowa transmisji. Straty pakietów nie s funkcj liniow b dów transmisji, lecz raczej (Rys. 4b, Rys. 5b) odzwierciedlaj liczb redukcji okna cwnd (Rys. 2b, Rys. 3b). Mechanizm zapobiegania przeci eniom w sposób naturalny d y do zmniejszenia redniej zaj to ci bufora (Rys. 6a). Jest to jednak okupione zwi kszon wariancj (Rys. 6b). W przypadku du ych b dów (a zatem równie ma ych warto ci cwnd) zarówno rednia zaj to bufora, jak i wariancja, malej. Jest to zwi zane ze spadkiem redniej liczby przesy anych pakietów. 5. ZAKO CZENIE Dla ma ych strat pakietów, na ewolucj okna przeci eniowego TCP silny wp yw maj rozmiar pola danych MSS pakietu TCP i czas RTT. Zjawisko to jest silniejsze w przypadku b dów cyklicznych, ni losowych. Wraz ze wzrostem strat pakietów, wp yw MSS i RTT zaczyna male, a w ko cu zupe nie zanika. Ewolucja okna przeci eniowego silnie wp ywa na wydajno protoko u TCP. W przypadku du ych b dów, okno przeci eniowe znacznie ogranicza osi gan przep ywno, a, w skrajnym przypadku, proces transmisji zupe nie zamiera. SPIS LITERATURY [1] [2] J. Postel, Transmission Control Protocol, RFC 793, September 1981 [3] V. Jacobson, Congestion Avoidance and Control, Proceedings of SIGCOMM'88, Stanford, CA., August 1988 [4] W. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, RFC 2001, January 1997 [5] L. S. Brakmo, L. L. Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communications, Vol. 13, No. 8, October 1995 [6] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective Acknowledgement Options, RFC 2018, October 1996 [7] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao, Overview and Principles of Internet Traffic Engineering, RFC May 2002 [8] R. R. Chodorek, A. G owacz, Behaviour of TCP Westwood in Wireless Networks, Proceedings of ATAMS 2002, Kraków, grudzie 5-7, 2002 [9] S. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, September 2001 [] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, RFC 2581, April 1999 [11] M. Allman, S. Floyd, C. Partridge, Increasing TCP's Initial Window, RFC 3390, October 2002 [12] M. Mathis, J. Semke, J. Mahdavi, T. Ott, The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, Computer Communication Review, Vol. 27, No. 3, July 1997 [13] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP Throughput: A Simple Model and its Empirical Validation, Proc. of SIGCOMM'98