2003

Poznañskie Warsztaty Telekomunikacyjne

Poznañ 11-12 grudnia 2003

Agnieszka Chodorek
Zak

áad Telekomunikacji i Fotoniki

Politechnika

ĝwiĊtokrzyska

Al. 1000-lecia P.P. 7
25-314 Kielce

EWOLUCJA OKNA PRZECI

ĄĩENIOWEGO PROTOKOàU TCP

Streszczenie: W referacie zostaá zaprezentowany
mechanizm zapobiegania przeci

ąĪeniom zaimplemento-

wany

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-2.

1. 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-2.

2. 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, zaimplemen-

towane w protoko

áach warstwy transportowej. Dziaáania

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 bezprzewodo-
wych, gdzie stopa b

áĊdów jest stosunkowo duĪa. Dlatego

te

Ī obecnie prowadzone są intensywne prace nad nowy-

mi wersjami protoko

áu TCP, posiadającymi udoskonalo-

ne mechanizmy estymacji dost

Ċpnych zasobów siecio-

wych nie bazuj

ące na stratach pakietów np. TCP West-

wood [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, zaimple-

mentowany w protokole TCP, jest z

áoĪeniem czterech

al.gorytmów [10]: algorytmu zapobiegania przeci

ąĪe-

niom, algorytmu powolnego startu, algorytmu szybkiej
retransmisji i algorytmu szybkiego odtwarzania. Dzia

áa-

nie 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Ĩ odcinkowo-

sta

á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:

x

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).

x

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:

1

k

cwnd

1

k

cwnd

,

(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

informacji o numerze sekwencyjnym ostatniego pakietu
z danego rozmiaru okna, rozmiar okna przeci

ąĪenio-

wego cz

Ċsto wyznaczany jest z chwilą odebrania

ka

Īdego potwierdzenia ACK, zgodnie z zaleĪnoĞcią:

k

k

1

k

cwnd

cwnd

cwnd

1

.

(2)

Specyfikacja protoko

áu TCP definiuje minimalny

rozmiar okna przeci

ąĪeniowego, nie definiuje jednakĪe

rozmiaru maksymalnego. Wraz z ka

Īdym odbiorem pot-

wierdzenia ACK, nadajnik zwi

Ċksza okno przeciąĪenio-

we 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):

rwnd

cwnd

w

,

min

.

(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:

x

po

áowy aktualnej wielkoĞci okna w:

w

cwnd

2

1

(4)

je

Īeli wykrycie straty pakietu nastąpiáo w

odbiorniku (na podstawie przerwy w numeracji
sekwencyjnej kolejnych,

nadchodz

ących

pakietów),

x

jedno

Ğci:

1

cwnd

(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:

w

sstresh

2

1

,

2

max

,

(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

Analiza symulacyjna zosta

áa przeprowadzona w

Ğrodowisku symulatora ns-2 [1]. Analizowano sieü o

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 100 Mb/s i opóĨnieniu
propagacyjnym 1

Ps. Ruter R1 poáączony jest z odb1

áączem o przepustowoĞci 10 Mb/s i opóĨnieniu W

p

(warto

Ğü domyĞlna W

p

wynosi 5 ms).

R1

nad1

odb1

100 Mb/s

1

Ps

10 Mb/s

W

p

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:

x

losowe o rozk

áadzie równomiernym,

x

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 ograni-

czenia 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 (+), 10 ms (), 100 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

1 10

4

1 10

3

0.01

0.1

1

10

100

100

200

300

400

(a)

Ğr

edni r

o

zmiar

okna cwnd (

w

pakietach)

1 10

4

1 10

3

0.01

0.1

1

10

100

500

1000

1500

(b)

liczba redukcji okna cwnd

1 10

4

1 10

3

0.01

0.1

1

10

100

0.01

0.1

10

100

1 10

3

1 10

4

1 10

5

(c)

Ğredni czas cyklu narastania (s)

1 10

4

1 10

3

0.01

0.1

1

10

100

10

(d)

b

áĊdy transmisji (%)

Ğrednia warto

Ğü

sstresh

(w p

ak

ietach

)

Rys. 2. Charakterystyki statystyczne cwnd i sstresh

w funkcji losowych b

áĊdów transmisji (róĪne RTT).

1 10

4

1 10

3

0.01

0.1

1

10

100

200

400

600

(a)

Ğredni rozmiar okna cwnd (w pakietach)

1 10

4

1 10

3

0.01

0.1

1

10

100

500

1000

(b)

liczba redukcji okna cwnd

1 10

4

1 10

3

0.01

0.1

1

10

100

0.1

10

100

1 10

3

1 10

4

1 10

5

(c)

Ğredni czas cyklu narastania (s)

1 10

4

1 10

3

0.01

0.1

1

10

100

10

(d)

b

áĊdy transmisji (%)

Ğrednia warto

Ğü

sstre

sh

(w p

ak

ie

ta

ch

)

Rys. 3. Charakterystyki statystyczne cwnd i sstresh

w funkcji losowych b

áĊdów transmisji (róĪne MSS).

1 10

4

1 10

3

0.01

0.1

1

10

100

5 10

6

1 10

7

(a)

pr

zep

áywno

Ğü

TCP (b/s)

1 10

4

1 10

3

0.01

0.1

1

10

100

500

1000

1500

2000

(b)

b

áĊdy transmisji (%)

straty [w pakietach]

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”), 1000 B (+), 1452 B (), 4312 B (o). WartoĞü

MSS = 1000 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 punkt-

punkt (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 10

-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 = 100 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 = 100
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 10

4

), szybko

spada

áa, aĪ do bardzo niskich wartoĞci (rzĊdu 10

1

) dla

du

Īych báĊdów.

1 10

4

1 10

3

0.01

0.1

1

10

100

5 10

6

1 10

7

(a)

pr

zep

áywno

Ğü

TCP (b/s)

1 10

4

1 10

3

0.01

0.1

1

10

100

500

1000

1500

(b)

b

áĊdy transmisji (%)

straty [w pakietach]

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 2y4%,

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 (10%), 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 = 100 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

1 10

4

1 10

3

0.01

0.1

1

10

100

10

100

(a)

Ğrednia zaj

Ċto

Ğü

bufora rutera R1

1 10

4

1 10

3

0.01

0.1

1

10

100

10

100

1 10

3

1 10

4

1 10

5

1 10

6

1 10

7

(b)

b

áĊdy transmisji (%)

war

iancja zaj

Ċto

Ğci bufora rutera R1

Rys. 6. Zaj

ĊtoĞü bufora rutera R1 w funkcji losowych
b

áĊdów transmisji (róĪne RTT).

(

d0,01% dla losowych i d0,5% dla cyklicznych),

sstresh stabilizowaá siĊ na poziomie 10 (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Ğü Ğred-

niego 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] http://www.isi.edu/nsnam/ns/
[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 3272. 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

[10] 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