Simulaatiotutkimuksentarkoituksenaonsaadamahdollisimmantarkkaarvio
tietys-tä ulostulomuuttujasta. Simulaattori käyttää syötteenä satunnaislukua, jonka
pe-rusteellasimulaatiotapahtumatmääritellään.Mitälyhyempikäytettysimulaatioaika
on, sitä suurempi vaikutus tuloksiin on yksittäisillä simulaatiotapahtumilla.
Simu-laatiotutkimuksen kannalta on erittäin tärkeää optimoida simulaatioaika riittävän
pitkäksi,jottasaavutetaanriittäväluotettavuustaso.Tehokkaan simuloinninja
tut-kimuksen saavuttamiseksi tulee kuitenkin välttää liian pitkänsimulaatioajan
käyt-töä,sillätietynluotettavuustason saavuttamisenjälkeen eisimulaatioajanpidennys
tuo tutkimukseen enää lisäarvoa. Tulosten luotettavuutta voidaan lisätä
suoritta-malla useita simulaatioajoja samoja parametrejä käyttäen, mutta eri
satunnaislu-kugeneraattorinsiemenarvolla.
Tietynsimulaatioskenaarionajojenperusteella voidaanlaskeatunnusluku
X(n) ¯
,jokaonnnäytettäsisältävänotannan laskennallinenkeskiarvo(14).Simuloitujen
lä-pivientiarvojen tarkka keskiarvo tai keskihajonta eivät ole tiedossa.Näin ollen
kes-kihajonta n
σ
korvataan muuttujallas
, joka on estimoitu keskihajonta elistandar-divirhe. Näin määritelty jakauma voidaan kuvata t-jakaumana, jonka keskiarvo on
X(n) ¯
ja keskihajonta√ s
n f
. Keskihajonnassa käytettyn f
on vapausasteiden määrä, joka onyhtäkuin näytteiden määrävähennettynä yhdellä.Kaavassa 15 on luotettavuustaso keskiarvolaskelman
X(n) ¯
mukaan, jossaδ
onluotettavuusvälin pituuden puoliväli. Näin ollen
100(1 − α)
luotettavuus sijaitseeX ¯ ± δ
välillä.Tämän tutkimuksen simulaatioissa käytettiin 10-40 toistokertaa jokaiselle
ske-naariolle.T-jakaumanmäärittelemä0.025 kriittinenarvo yhdeksällä vapausasteella
ja 95% luotettavuustasolla on
t ∗ 0 . 025 = 2.26
[24℄. Kaava 17 määrittelee 95% luotet-tavuusalueen, jokariippuut-jakaumankriittisenarvonlisäksiestimoidustakeskiha-jonnasta sekä simulaatiokerroista.
X(n) ¯ ± t ∗ 0 . 025
√ s
n
(17)Simuloinnin suhteellinen tarkkuus kertoo kuinka paljon tulokset korkeintaan
poikkeavatkeskiarvosta tietyllätodennäköisyydellä (18). Yleisestisimulointien
suh-elitulospoikkeaatodellisestaarvostayliviisiprosenttiakorkeintaanviidenprosentin
todennäköisyydellä.
ε = s
X(n) ¯
(18)Ensimmäisen osion simulaatioskenaarioiden keskimääräinen suhteellinen
tark-kuusoli3,78%kunkäytössäoli95%luotettavuustaso.TCP Vegasintulokset
vaihte-livat selvästi eniten ja kymmenen simulaatioajonperusteella sen suhteellinen
tark-kuus on 7,6% kun kaikkien muiden protokollien tuloksien suhteellinentarkkuus oli
alle 3%. TCP Vegasin suhteellisen tarkkuuden tasoa voisi parantaa suorittamalla
lisää simulaatioita, mutta tarkkuuden parannus ei muuttaisi tutkittujen ilmiöiden
tuloksia. Tämän tutkimustyön päämääränä ei ole löytää mahdollisimman
tarkko-ja yksittäisiä arvioita tietyistä olosuhteista vaan tutkia protokollien käyttäytymistä
laajalla parametriskaalalla.
Taulukko6: TCP varianttien suhteelliset tarkkuudet ensimmäisenosion tuloksissa
RTT 4ms 10ms 20ms 30ms 40ms 50ms 60ms 70ms 80ms 90ms 100ms
Tahoe 2,3% 2,1% 2,1% 2,2% 2,1% 2,1% 2,4% 2,6% 2,7% 2,8% 2,8%
Reno 2,7% 2,7% 2,5% 2,6% 2,6% 2,5% 2,9% 2,9% 2,7% 2,9% 3,0%
Newreno 2,6% 2,5% 2,3% 2,2% 2,2% 2,3% 2,3% 2,5% 2,6% 2,7% 2,7%
Sak 2,5% 2,1% 2,1% 2,2% 2,2% 2,3% 2,6% 2,6% 2,7% 2,9% 2,9%
Vegas 7,8% 7,9% 7,3% 7,0% 6,3% 6,5% 6,4% 6,4% 6,9% 6,1% 7,5%
Tasapuolisuussimulaatioissa pyrittiin saavuttamaan vähintään viiden prosentin
suhteellinen tarkkuus 95% luotettavuustasolla. Simulaatiotoistoja jouduttiin
teke-mään 20-40 kappaletta jokaista algoritmiparia kohden. Näin pystyttiin
saavutta-maantavoiteltu suhteellinentarkkuus poislukien DCCP TFRC ja TCP Like -pari,
jonkasimulaatiotuloksissajäätiin6,1%suhteelliseen tarkkuuteen 95%
luotettavuus-tasolla.
Taulukko 7:Tasapuolisuussimulaatioidensuhteelliset tarkkuudet
Vegas Sak New Reno Reno TFRC TCP Like
Tahoe 1,9% 1,7% 2,0% 1,8% 3,0% 3,1%
TCP Like 4,7% 3,4% 4,1% 3,3% 6,1%
TFRC 4,7% 3,6% 2,5% 2,6%
Reno 2,5% 1,8% 2,0%
New Reno 2,4% 1,9%
Sak 2,3%
4.9 Vertailu aikaisempiin tutkimuksiin
Kuljetuskerroksen protokollia on tutkittu paljon aikaisemmissa tutkimuksissa
eri-Vuonna 2006 tehdyssä tutkimuksessa Alaa Seddik-Ghaleb et al. tutkivat
kuu-den eri TCP variantin energiatehokkuutta sekä läpivientiä ad ho -verkoissa [26℄.
Kyseisen tutkimuksen tuloksia voidaan osittain verrata myös tämän tutkimuksen
tuloksiin. Seddik-Ghalebet al.totesivatTCP New Renon tarjoavansuurimman
lä-pivientitason hyvin suurilla pakettihukan arvoilla. Sama ilmiöon havaittavissa
tä-män tutkimuksen kuvasta 8, jonka perusteella TCP New Reno saavuttaa parhaan
läpivientiarvonpakettihukanollessa yli 8%. Seddik-Ghalebintutkimuksen mukaan
pienilläpakettihukanarvoillaTCP Vegas tarjoaa parhaan läpivientitason.Tulos on
yhtenevätässä tutkimustyössä saatuihin tuloksiin.
TCP Tahoen ja Renon läpivientitasoistaon tehty useita tutkimuksia, joista
esi-merkiksi Anurag Kumarin tekemä Comparative Performane Analysis of Versions
of TCP in a Loal Network with a Lossy Link perehtyy Tahoen ja Renon
läpivien-tieroihinsimuloimallasekä analyyttisinmallein[27℄. Kumarintutkimuksen mukaan
TCPRenonsuorituskyky onTahoetapienempimikälilähetysikkunankokoonhyvin
pieni taipakettihukkakasvaasuureksi. Kyseinenilmiötulihyvin havainnollistettua
myös tämän tutkimuksen simulaatioissa, joiden perusteella pystytään huomaamaa
hyvin sekä pakettihukan että RTT:n vaikutus TCP Renon ja Tahoen
paremmuus-järjestykseen.
Tämän tutkimuksen tasapuolisuussimulaatiossa todettiin TCP Vegasin
suori-tuskyvyn kärsivän sen joutuessa kilpailemaan pullonkaulalinkin resursseista jonkin
toisen variantin kanssa. Osakan yliopistossa vuonna 2000 tehdyssä tutkimuksessa
todetaan TCP Vegasin kärsivän etenkin drop-tail jononhallinta-algortitmiä
käyttä-vissäruuhkaisissa verkoissa [28℄. Kyseisessätutkimuksessaolitestattu etenkinTCP
Vegasinja Renontasapuolisuutta.Tämän diplomityöntulostenperusteella voidaan
todeta ongelman ilmenevän myös TCP New Renon, Sak:n sekä DCCP TRRC:n
kanssa. Corkinyliopistossavuonna 2003tehdyssä tutkimuksessatodettiin TCP
Ve-gasin suorituskyvyn ongelmatTCP Renoa ja TCP Sak:ta kohtaan tutkimuksessa,
jossaperehdyttiineriTCPvarianttiensoveltuvuuteenSIP-liikenteen
kuljetuskerrok-sen protokollaksi[29℄.TCP Renon yleisyys Internetissä aiheuttaa heidänmukaansa
todella suuren haasteen TCP Vegasinmahdolliselle käytölle.
DCCP-varianttien tasapuolisuudesta on tehty joitakin tutkimuksia, joista
mai-nittakoonTransport Protool ThroughputFairness vuodelta2009. Kyseisessä
tutki-muksessaS.BhattisekäM.BatemanselvittivätCCID-3:ntasapuolisuuttamuutamia
TCP-varianttejakohtaan. HeidäntutkimuksensaperusteellaDCCP TFRCkohtelee
TCP-yhteyksiä varsin tasapuolisesti,muttaheidän mukaansatasapuolisuuson
riip-puvainenyhteydenviiveestä.TämäntutkimuksenTFRC-tasapuolisuussimulaatioiden
tulokset tukevat heidäntuloksiaan.
Tässä työssä ilmenneilleCCID-2:n suurilleongelmille
tasapuolisuussimulaatiois-sa ei löydy tukea aiemmista tutkimuksista. Esimerkiksi vuonna 2008 Brasiliassa
tehdyn tutkimuksen On the performane of TCP, UDP and DCCP over 802.11 g
networks mukaan kyseistä ilmiötä eiesiintynyt ainakaan heidän testeissään [31℄.
4.10 Johtopäätökset
Tutkimuksen päämääränä oli selvittää kuinka yleiset ruuhkanhallintaa käyttävät
kuljetuskerroksenprotokollatselviytyvätolosuhteissa,joissaverkon häiriötekijöiden
takia pakettihukka on suurta. Ruuhkanhallinta-algoritmien reagointi aina samalla
tavalla riippumatta paketin katoamisen syystä aiheuttaa suorituskykyongelmia
pa-kettihukan johtuessa esimerkiksi huonolaatuisesta radiotiestä.
Simulaatioidenensimmäisenosuuden perusteellavoidaanmääritelläkuinka
seit-semän eri tutkittua algoritmia suoriutuvat pakettihukan ja RTT:n eri arvoilla
ver-kossa, jossaei esiinny muun liikenteen aiheuttamaaruuhkaa. TCP Renon
suoritus-kykyongelmientaso jariippuvuusRTT:njapakettihukansuhteestapystyttiinhyvin
tuomaanesillesimulaatioissa.TCP NewRenonja Sak:nhyvintasavertainen ja
hy-väsuoritustasotulihyvinhavainnollistettua.TCPVegasinpoikkeavaluonnemuihin
algoritmeihinverrattunanäkyisimulaatiotuloksissasuoritustasonhyvin
voimakkaa-na vaihteluna. TCP Vegasin läpivienti oli simulaatioissa DCCP-algoritmien lisäksi
kaikkein vaihtelevinta ja kyseisille algoritmeille jouduttiinkin suorittamaan eniten
simulaatiotoistojariittävänluotettavuustasonsaavuttamiseksi.
Simulaatioidentoisessaosuudessa tutkittiineriruuhkanhallinta-algoritmien
tas-apuolisuuttapullonkaulalinkillä.Tulostenperusteella voidaan todetalinkillelisätyn
pakettihukan vaikuttavan merkittävästi algoritmien keskinäiseen tasapuolisuuteen.
Esimerkiksi TCP Reno pärjäsi hyvin pienellä pakettihukalla, mutta pakettihukan
kasvun myötä sen saamasuhteellinenosuus linkinläpiviennistälaski merkittävästi.
TCP Vegas osoittautui tasapuolisuussimulaatioissayllättävän passiiviseksi
skenaa-rioissa, joissapullonkaulalinkin pakettihukkaoli pieni.
Tulosten perusteella voidaan todeta TCP Vegasin tarjoavan parhaan tehollisen
läpivientitasonruuhkattomassalangattomassaverkossa,jossapakettihukkaon1-5%
välillä.TätäsuuremmillapakettihukanarvoillaTCPNewRenosuoriutuuparemmin.
Suuren pakettihukan ja pienen viiveen olosuhteissa TCP Sak osoittautui
parhaak-si TCP-variantiksi tehollisen läpiviennin osalta. Samanlaisissa olosuhteissa DCCP
TFRC pystyi saavuttamaankuitenkin huomattavastiTCP Sak:ta suurempia
läpi-vientiarvoja,jotenmikäliverkkosovellukseltaeiedellytetäehdotontaluotettavuutta
onDCCP TFRCläpivientitehokkuuden kannaltaparas valinta.Langallisessa
verk-koliikenteessä valitsevissa pienen pakettihukan ja kohtuullisen viiveen olosuhteissa
TCP Vegas suoriutuiparhaiten.
Taulukossa 8onsimulaatioidenensimmäisenosion perusteellaarvioitu
parhaim-man tehollisenläpiviennin tarjoavaTCP-varianttiverkon erilaisillapakettihukka ja
RTT arvoilla.
Taulukko 8:Optimaalinen TCP-varianttieripakettihukan ja RTT:n arvoilla
Olosuhteet Suurin läpivienti
Pakettihukka RTT Variantti
Pieni Pieni Vegas
Pieni Keskisuuri Vegas
Pieni Suuri Sak
Keskisuuri Pieni Vegas
Keskisuuri Keskisuuri Vegas
Keskisuuri Suuri Vegas
Suuri Pieni Sak
Suuri Keskisuuri New Reno
Suuri Suuri New Reno
5 Yhteenveto
Tämän tutkimuksen päämääränä oli perehtyä ruuhkanhallinta-algoritmien
toimin-taan verkoissa joiden pakettihukka on suuri. Työn kirjallisuuskatsauksessa
tutki-taan verkon ruuhkautumisen syitä sekä kuinka ruuhkautuminen on havaittavissa.
Yleisin indikaatio ruuhkautumisesta on lähetettyjen pakettien katoaminen
verkos-sa. Lähettäjä ei yleensä tiedä miksi paketti katoaa ja pakettihukkaan reagoidaan
yleensä samallatavalla.Näinollen todellinenruuhkautuminen javerkonvirheilystä
tairadiotienhäiriöistä johtuvat pakettien katoamisetja korruptoitumiset
aiheutta-vatmolemmatlähetysnopeuden pienentämisen.Kyseisentoimintamallintakia
lähe-tysnopeudenpienentäminenruuhkattomassamuttavirheilevässä
verkkoympäristös-sä aiheuttaa verkkoresurssien alikäyttöä ruuhkanhallinta-algoritmien tarpeettoman
suuren vasteentakia.
Kuljetuskerroksen protokollat ovat vastuussa tietoliikenneyhteyksien
ruuhkan-hallinnasta ja kyseinen ominaisuus löytyy TCP, SCTP sekä DCCP -protokollista.
Kirjallisuuskatsauksessa perehdytään viiden eriTCP-variantinsekäkahden
DCCP-version ruuhkanhallinnallisiin ominaisuuksiin. Tutkimukseen valittiin TCP:n
ver-siot Tahoe, Reno, New Reno, Sak sekä Vegas. TCP ja DCCP -protokollat
eroa-vat toisistaan useidenominaisuuksiensa osalta ja tärkeimpänä erona voidaan pitää
TCP:nluotettavaatiedonsiirtoaverrattunaDCCP:nvarmistamattomaan
tiedonsiir-toon.DCCP-protokollastaonsuunniteltuilmanruuhkanhallinnallisiaominaisuuksia
olevanUDP:n mahdollista korvaajaa sovelluksiin, joissa tiedonsiirrontehokkuus on
luotettavuutta tärkeämpää.
Diplomityössäkäytettiintutkimusmenetelmänäsystemaattistasimulointia,jonka
niin sanotussa Jain-mallissa tutkimus jaetaan kahdeksaan eri vaiheeseen.
Esiohjel-mallinenvaihe aloitetaanmäärittelemällätutkimusongelmasekä päämäärä.Tämän
lisäksi verkkomallin suunnittelu, dynaamisten sekä staattisten parametrien
valin-tasekä mitattavien suorituskykymetriikoiden määrittelykuuluvatesiohjelmalliseen
osuuteen.
Systemaattisensimuloinninohjelmallinenvaihesisältääsimuloitavan
verkkomal-linrakentamisen,varsinaisensimuloinninsekätulostenkeräämisenjatulkinnan.
Tä-män tutkimuksen simulaatiottoteutettiin ns2-simulaattorillaja tulosten
analysoin-nissa ja esittämisessä käytettiin itse koodattuja työkalujasekä Matlab-ohjelmistoa.
Tämätutkimuksensimulointityöjakautuukahteeneriosioon,joistatoisessa
tut-kittiin tehollisen läpiviennin tasoja ruuhkautumattomassa verkossa ja toisessa
lä-pivientien suhdetta kahden erikuljetusprotokollan kilpaillessa pullonkaulalinkin
re-sursseista.Simulaatioskenaarioissakäytettiin dynaamisinaparametreinäRTT:tä
se-kä pullonkaulalinkin pakettihukkaa. RTT sai simulaatiossa arvoja 2-100 ms ja
pa-kettihukka 0,1-10,0 %. Viiveen resoluutio oli 10 ms ja pakettihukan 0,1 % ja näin
ollen erilaisiaviive-pakettihukka pareja oli1100 kappaletta.
Simulaation ensimmäisen osan tuloksena syntyi useita kolmiulotteisia kuvaajia
eriTCP- ja DCCP-versioidentehollisten läpivientienarvoista virheilevän10
Mbps-linkin läpi. Kuvaajien perusteella pystyttiin analysoimaan protokollien
suoritusky-kyä erilaisillaviive-pakettihukka -yhdistelmilläverkossa, jossa ei esiintynyt muusta
hoen ja TCP Renon sekä TCP Sak:n ja TCP New Renon suorituskykyä toisiinsa
nähden. TCP Renon ongelmat suuren pakettihukan olosuhteissa pystyttiin hyvin
todentamaansekä rajaamaan, missä olosuhteissa ongelma aiheuttaa suorituskyvyn
laskun alle TCP Tahoen (Kuva 16). TCP Renon suorituskyky oli heikkoa
mikä-li pakettihukan arvo oli suuri, mutta myös RTT:n vaikutus oli merkittävää ilmiön
esiintymiselle.Syytähänonlähetysikkunankoonsuhdepakettihukkaaneriviiveillä.
TCP Sakja TCPNew Reno olivattutkimuksen kaikissaosissa erittäin
tasaver-taisia keskenään. TCP Sak pärjäsi kuitenkin hieman paremmin viiveen tai
paket-tihukanollessa pieni, mutta mikälimolemmat dynaamiset parametrit saivat suuria
arvoja, niinTCP New Reno pärjäsi vertailussaparemmin.
TCP Vegas poikkeaa tutkimuksen muista TCP-varianteista käyttämänsä
ruuh-kantunnistuksen sekä siihenreagointinsaosalta. Simulaationensimmäisenosion
tu-loksissa TCP Vegas sai kokonaisuutena selvästi suurimpialäpivientiarvoja
paketti-hukan pysyessä alle kuuden prosentin (kuva 18). TCP Vegasin läpivientikuvaajan
perusteellavoidaantodetasentarjoamanläpivienninolevankuitenkinvarsinherkkä
suurelleviiveelle ja pakettihukalle.
DCCP-simulaatioissaperehdyttiin TFRC:n ja TCP Like:n teholliseen
läpivien-tiin täysin samoilla verkkoparametreilla kuin TCP:lle suoritetuissa simulaatioissa.
Molemmatdatagrammipohjaisetprotokollatosoittautuivathyvinsuorituskykyisiksi
ruuhkautumattomassa verkossa. Erityisesti TFRC:n saamat arvot suuren
paketti-hukan ja pienen viiveen yhdistelmilläolivatäärimmäisen suuria verrattuna muihin
(kuva25).MyösTCPLikesailäheskokotutkiskelualueellanoin20%TCPTahoeta
suurempia läpivientiarvoja (kuva 26).
Simulaatioiden toisessa osuudessa selvitettiin tutkittujen seitsemän protokollan
tasapuolisuutta 1 Mbps:n pullonkaulalinkin läpi, jonka dynaamiset parametrit
oli-vatpakettihukanosaltasamatkuinensimmäisessäosuudessa, mutta RTT:narvoksi
määriteltiinvakio 50ms. Seitsemän eriprotokollan joukosta muodostettiin 21
kah-denprotokollanparia,joidensuhteellistaosuuttapullonkaulalinkinläpiviennistä
tut-kittiin.Näin pystyttiin arvioimaan protokollien suorituskykyä sekä tasapuolisuutta
verkossa,jossapakettihukkaaesiintyyruuhkautumisensekäjonkinmuunsyyntakia.
TCP Tahoen sekä Vegasin saavuttama suhteellinen osuus kasvoi lisätyn
paket-tihukan kasvun myötä (taulukko 4). TCP Vegasin saamat arvot olivat noin 40 %
luokkaa 0,1 % pakettihukalla, mutta paranivat pakettihukan kasvun myötä. Sama
ilmiöon havaittavissaensimmäisenosion tuloksista.TCP Reno saavuttihyviä
suh-teellisia osuuksia pienelläpakettihukalla,mutta pakettihukankasvun myötä Renon
ongelmatnäkyivät myöstässä simulaatiossa.
DCCPTFRCkohtelimuitaprotokolliapääsääntöisestihyvintasapuolisestijasen
saavuttamasuhteellinenosuusvaihtelipääsääntöisestivälillä50-55%.
Mielenkiintoi-nenilmiölöytyiTFRC:n aiheuttamistaongelmista TCPVegasille,jokajäijoissakin
olosuhteissa vainneljänneksen osuuteen kokonaisläpiviennistä.TFRCkäyttää
lähe-tysnopeuteen perustuvaaruuhkanhallintaalähetysikkunan sijaan.TCPLike
saavut-tierittäinpieniäosuuksiakokonaisläpiviennistäpakettihukanpienilläarvoilla.TCP
Like:n suhteellinenosuus kasvoi lähelle puoltapakettihukan arvolla4%.
Simulaatiotulosten luotettavuudeksi pyrittiin saamaan 5 % suhteellinen
tark-sen tarkkuuden tavoitellulla luotettavuustasolla, mutta TCP Vegasin sekä DCCP
-simulaatioidenosaltatarkkuusjäihiemantavoitellustasuhteellisentarkkuuden
jää-dessä kuitenkin kaikissa tapauksissa reilustialle 10%. DCCP-simulaatioita
toistet-tiinjoissakintapauksissa 40kertaayhtäskenaarioitakohden,jotta saavutettiin
tu-losten kelvollinenluotettavuustaso.
Simulaatiotulosten perusteella pystytään määrittelemään tutkittujen TCP- ja
DCCP-versioidensuorituskykyäerilaisillaviiveilläjapakettihukanmäärillä.Tämän
tutkimustyönperusteella pystytään määrittelemäänmikäruuhkanhallinta-algoritmi
tulisivalitaerilaistenverkko-olosuhteiden perusteella.
Viitteet
[1℄ Mamatas, L. Harks, T Tsaoussidis, V. Approahes to Congestion Control in
Paket Networks. Journal of Internet Engineering, Vol 1, No. 1 Tammikuu
2007.
[2℄ Welzl, M. Network Congestion Control - Managing Internet Tra , Wiley,
2005.
[3℄ Guizani,M. Wireless Communiation Systems and Networks , Kluwer, 2004.
[4℄ Hassan,M.Jain, R.High Performane TCP/IPNetworking ,PearsonPrentie
Hall,2004.
[5℄ Brakmo,L.S. etal.TCP Vegas: New Tehniques for CongestionDetetionand
Avoidane. Proeedings of the ACM SIGCOMM s. 24-35,1994.
[6℄ Brakmo, L.S. et al. TCP Vegas: End to End Congestion Avoidane on global
Internet. IEEE Journal on Seleted Areas in Communiations, 13(8) s.
1465-1480, 1995.
[7℄ M. Mathis, J. Semke, J. Mahdavi and T. Ott. The marosopi behavior of
the TCP ongestion avoidane algorithm. Computer Communiation Review
27 1997.
[8℄ J.Padhye,V.Firoiu,D.TowsleyandJ.Kurose.TModelingTCPthroughput:A
simplemodeland itsempirialvalidation.Proeedingsof theACM SIGCOMM
1998.
[9℄ Mathis, M. Mahdavi, J. Forward aknowledgement: Rening TCP ongestion
ontrol. Proeedings of the ACM SIGCOMM s.281-291, 1996.
[10℄ Jaobson, V. Congestion avoidane and ontrol. Symposium Proeedings on
Communiations Arhitetures and Protools ,s. 314-329,ACM Press, 1988.
[11℄ Tanenbaum, A.S. Computer Networks,4th Ed. ,Prentie Hall, 2002.
[12℄ Kohler e. et al. Datagram Congestion Control Protool(DCCP), Internet
En-gineering Task Fore, RFC4340, 2006.
[13℄ FloydS.etal.ProleforDatagramCongestionControlProtool(DCCP)
Con-gestionControlID2: TCP-like CongestionControl, Internet EngineeringTask
Fore, RFC4341, 2006.
[14℄ FloydS.etal.ProleforDatagramCongestionControlProtool(DCCP)
Con-gestionControlID3:TCP-FriendlyRateControl(TFRC),InternetEngineering
Task Fore, RFC4342, 2006.
[15℄ Matsson, Nils-Erik,ADCCP module forns-2. Examensarbete. Luleå Tekniska
[16℄ Ramadan, Wassim, Ns2 path from 2.31 ported to 2.34. Viitattu 11.4.2010.
Saatavissa: http://eugen.dedu.free.fr/n s2/d p-ns2 .34. pat h
[17℄ Stewart R. et al. Stream Control Transmission Protool, Internet Engineering
Task Fore, RFC2960, 2000.
[18℄ Transmission Control Protool, Internet Engineering Task Fore, RFC 793,
1981.
[19℄ Postel J. User Datagram Protool, Internet Engineering Task Fore, Internet
Engineering Task Fore, RFC768, 1980.
[20℄ Allman M. et al. TCP Congestion Control, Internet Engineering Task Fore,
RFC2581, 1999.
[21℄ FloydS.etal,The NewRenoModiationto TCP'sFastReoveryAlgorithm,
Internet Engineering Task Fore, RFC3782, 2004.
[22℄ MathisM.etal.TCPSeletiveAknowledgementOptions,InternetEngineering
Task Fore, RFC2018, 1996
[23℄ Floyds.etal.AnExtensiontotheSeletiveAknowledgement (SACK)Option
for TCP, Internet EngineeringTaskFore, RFC 2883, 2010.
[24℄ Kreyszig. Advaned EngineeringMathematis, 7th ed. ,Wiley, 1993.
[25℄ TheNetworkSimulator-ns2.Viitattu12.1.2010.Saatavissa:http://www.isi.
edu/nsnam/ns
[26℄ Seddik-Ghaleb A. et al, A performane study of TCP variants in terms of
energy onsumption and average goodput within a stati ad ho environment ,
Proeedings of the 2006 international onferene on Wireless ommuniations
and mobile omputing,2006.
[27℄ Kumar A., Comparative Performane Analysis of Versions of TCP in a Loal
Network with a Lossy Link ,IEEE/ACM Transations on Networking (TON)
arhive, Volume6 , Issue 4, 1998.
[28℄ KurataK., Hasegawa Go,Fairness Comparisonsbetween TCP Reno and TCP
Vegas forFutureDeployment of TCPVegas , Proeedingsof INET2000, 2000.
[29℄ Lulling M. VaughanJ., An investigation of TCP throughput variation for SIP
tra ,ACM International Conferene Proeeding Series;Vol. 49,2003.
[30℄ Bhatti S., Bateman M., Transport Protool Throughput Fairness ,Journal of
Networks, Vol.4, no. 9,November2009.
[31℄ de SalesL.M.etal.On theperformane of TCP,UDP and DCCPover802.11
g networks ,Proeedings of the 2008 ACM symposium on Applied omputing,