Ruuhkanhallinta-algoritmien toiminta haasteellisissa tietoverkoissa

Ruuhkanhallinta-algoritmien toiminta haasteellisissa tietoverkoissa

Elektroniikan, tietoliikenteen ja automaation tiedekunta

Diplomityö,jokaon jätettyopinnäytteenä tarkastettavaksi

diplomi-insinöörin tutkintoavartenEspoossa7.5.2010.

Työn valvoja:

Prof.Jukka Manner

Työn ohjaaja:

FMSebastianSiikavirta

A ’’ Aalto-yliopisto

Teknillinen korkeakoulu

Tekijä: Lasse Ropponen

Työnnimi: Ruuhkanhallinta-algoritmien toiminta

haasteellisissa tietoverkoissa

Päivämäärä:7.5.2010 Kieli: Suomi Sivumäärä:7+47

Elektroniikan, tietoliikenteen ja automaationtiedekunta

Tietoliikenne-ja tietoverkkotekniikan laitos

Professuuri:Tietoverkkotekniikka Koodi: S-38

Valvoja: Prof.Jukka Manner

Ohjaaja: FMSebastian Siikavirta

Tämä diplomityö käsittelee ruuhkanhallinta-algoritmien toimintaa erilaisilla pa-

kettienhukkatodennäköisyyksilläjakauttakiertoajoilla.Tutkimuksenkohteenaoli

seitsemän eri kuljetuskerroksen protokollaa, joista viisi kuuluvat TCP- ja kaksi

DCCP-protokolliin. Tutkimusmenetelmänä käytettiin systemaattista simulointia,

joka toteutettiin ns2-ohjelmistolla.

Ruuhkanhallinta-algoritmien tarkoituksena on välttää ruuhkautumistilanteita ja

saadaverkonresurssitmahdollisimmantehokkaastikäyttöön.Tämänlisäksiruuh-

kanhallinnaltaodotetaantasapuolista suhtautumistamuitaverkon käyttäjiä koh-

taan.Itsekäsjaaggressiivinenverkkoprotokollasaattaanäyttääkyseisenverkkoso-

velluksennäkökulmastavarsin tehokkaalta,mutta kokonaistehokkuuden kannalta

kyseisenlainen toimintaeiole järkevää.

Ruuhkanhallinta perustuu verkon ruuhkautumisen toteamiseen ja tästä aiheutu-

vaan lähetysnopeuden säätelyyn. Algoritmeilla on erilaisia menetelmiä ruuhkau-

tumisentoteamiseksi,muttakaikkianiitäyhdistääkyvyttömyys erottaaverkkolii-

kenteen häiriintymisensyy. Yleisinindikaatioverkon ruuhkautumisesta onpaket-

tien katoaminen, joka saattaajohtua monestakin eri syystä.Ruuhkautumisen tai

verkkohäiriöntakiaaiheutuneisiinkatoamisiinreagoidaan kaikkiinyleensä samal-

latavalla,jokasaattaajohtaajoissakintapauksissaverkonresurssientehottomaan

käyttöön.Näinkäyesimerkiksiruuhkattomissalangattomissaverkko-olosuhteissa,

joissaesiintyy runsaasti pakettihukkaa.

Tutkimuksen simulaatiotjakautuivatkahteen eriosaan, joistaensimmäisessätut-

kittiin eri algoritmien suorituskykyä ruuhkattomassa verkossa, jonka pullonkau-

laksi muodostui pakettihukkaa aiheuttava linkki. Simulaatioiden toisessa osiossa

pyrittiin selvittämään tutkittujen algoritmien tasapuolisuutta pullonkaulalinkil-

lä, jolle ohjattiin kaksi datavuota, joista molemmat olivat eri TCP- tai DCCP-

versioita.

Avainsanat: Ruuhkanhallinta-algoritmi,TCP,DCCP,SCTP,simulointi,ns2,pa-

Author: Lasse Ropponen

Title: CongestionControlAlgorithms inChallenging Networks

Date:7.5.2010 Language: Finnish Number of pages:7+47

Faulty ofEletronis, Communiations and Automation

Department of Communiations and Networking

Professorship: Computer Networks Code: S-38

Supervisor:Prof. Jukka Manner

Instrutor: FM Sebastian Siikavirta

Thefousofthis Master'sthesisistoresearhthebehaviorofdierentongestion

ontrol algorithms by dierent paket drop and lateny values. Seven dierent

transportlayerprotoolvariantswere researhed.FiveofthemwereTCPvariants

and two DCCP variants. Used researh method was systemati simulation that

was performedby Ns2-simulator.

Congestionontrolalgorithmstrytoavoidongestionandpermitaseientusage

of the network as possible. Congestion ontrol algorithms are also responsible

about thefairness between dierentnetwork users.Selshand aggressive network

protoolmay seem eient fromits own perspetive but for the overall eieny

suha behavior isquestionable.

Congestionontrolisbased onnotiingand reatingforongestion by tuningthe

transfer rate. There are many dierent methods to beome aware of ongestion

but all of them are inapable to distinguish the reason for the interferene at

the transmission.The most ommonindiationabout ongestion is apaketloss.

Unfortunately there is no mehanism to know exatly the reason for the paket

loss.All indiationsabout ongestionause sameongestion ontrolbehaviorand

thereforealgorithmsmay sometimes reatinorretly.A goodexample aboutthis

isan unongested wireless network whih has high paketdrop rate.

The simulations were divided into two parts. At the rst part the goodput of

dierent TCP and DCCP variants through an unongested bottlenek link was

researhed by omputer simulations. At the seond part of the simulations the

fairnessofdierentTCP andDCCP variantsatabottleneklinkwereresearhed.

Keywords: CongestionControl,CongestionAvoidane,TCP,DCCP,Simulation,

Esipuhe

Tämä diplomityö on tehty Aalto-yliopiston Teknillisen korkeakoulun tietoliikenne-

ja tietoverkkotekniikan laitoksella.

Haluan kiittää työni valvojana toiminutta professori Jukka Mannerta diplomi-

työaiheen antamisesta sekä työhön liittyneistä erinomaisista kommenteista. Kiitän

myös työn ohjaajana toiminutta FM Sebastian Siikavirtaa hyvästä tuesta työn te-

kemisenaikana.

Suuri kiitos myösläheisillenisekä etenkin vaimolleniSannalle kärsivällisyydestä

ja tuesta opiskeluaikanani.

Espoo, 7.5.2010

Lasse Ropponen

Sisältö

Tiivistelmä ii

Tiivistelmä (englanniksi) iii

Esipuhe iv

Sisällysluettelo v

Lyhenteet vii

1 Johdanto 1

2 Ruuhkanhallinta tietoverkoissa 2

2.1 Tietoverkkojen ruuhkautuminen . . . 2

2.2 Ruuhkan- ja vuonhallinta. . . 3

2.3 Palautetyypit . . . 3

2.4 Kiertoajan arviointi . . . 4

2.5 AIMD, AIAD, MIMD ja MIAD . . . 4

2.6 Hidas aloitusja ruuhkanvälttely . . . 7

2.7 Nopeauudelleenlähetys ja toipuminen. . . 8

2.8 TCP-ystävällisyys . . . 9

2.9 Teoreettinen maksimiläpivienti. . . 9

2.10 Ruuhkanhallinta-algoritmitlangattomissa verkoissa . . . 10

3 Kuljetuskerroksen verkkoprotokollat 11 3.1 TCP . . . 11

3.1.1 Tahoe . . . 12

3.1.2 Reno . . . 12

3.1.3 New Reno . . . 13

3.1.4 Sak . . . 13

3.1.5 Vegas . . . 14

3.2 DCCP . . . 16

3.2.1 TCP-like Congestion Control . . . 16

3.2.2 TCP Friendly Rate Control . . . 17

4 Simuloinnit 18 4.1 ns2-simulaattori . . . 18

4.2 Simulaationtopologia ja parametrit . . . 18

4.3 Pakettihukan vaikutus . . . 21

4.4 Kiertokulkuajan vaikutus. . . 21

4.5 TCP-varianttien vertailu . . . 22

4.6 DCCP-simulaatiot . . . 33

4.7 Protokollien tasapuolisuus . . . 36

4.8 Tulostenluotettavuustaso . . . 38

4.10 Johtopäätökset . . . 41

5 Yhteenveto 43

Viitteet 46

Lyhenteet

ACK Aknowledgement

AIAD AdditiveInrease, Additive Derease

AIMD AdditiveInrease, MultipliativeDerease

CWND Congestion Window

DACK DubliateAknowledgement

DCCP Datagram CongestionControlProtool

DupACK DupliateAknowledgement

FACK Forward Aknowledgement

IETF Internet Engineering Task Fore

IP Internet Protool

MIAD MultipliativeInrease, AdditiveDerease

MIMD MultipliativeInrease, MultipliativeDerease

RFC Request ForComments

RTO RetransmissionTimeout

RTT Round TripTime

RWND Reeiver's Advertised Window

SACK Seletive Aknowledgement

SCTP StreamControlTransmission Protool

SMSS Sender Maximum SegmentSize

SSTHRESH SlowStart Threshold

TCP Transmission ControlProtool

TFRC TCP Friendly Rate Control

UDP UserDatagram Protool

Ruuhkanhallintaonollutosana tietoverkkojen kehityksessä lähes nykyaikaisten tie-

toverkkojen syntyajoista lähtien. Jo 1980-luvulla Van Jaobson totesi ruuhkautu-

misenaiheuttavantodellisenriskintietoverkoille.Hänenmukaansaruuhkautuminen

ja etenkin käyttäjien välinpitämättömyys ruuhkaa kohtaan saattavat aiheuttaa ko-

koverkkoliikenteenromahtamisen.Tietoverkkojenkäyttäjämäärienvaltavankasvun

myötäverkkoliikenteensäätely ruuhkautumistilanteissaontullutvälttämättömäksi.

Ruuhkanhallinta-algoritmien päämääränä on mahdollistaa tietoverkkojen mah-

dollisimmantehokas ja tasapuolinen käyttö. Ruuhkanhallinta ominaisuus sijoittuu

kuljetuskerroksen protokollien tehtäviin, mutta esimerkiksi UDP-protokollassa ei

käytetä minkäänlaistaruuhkanhallintaa.Ruuhkanhallinta-algoritmientehtävänä on

säädellä tietoliikenneyhteyden lähetysnopeutta verkon ruuhkautumisasteen mukai-

sesti. Algoritmit pyrkivät arvioimaan verkon ruuhkautumista esimerkiksi pakettien

katoamisten, viiveen vaihtelun sekätoteutuneen läpivienninperusteella.

Nykyisin yleisimmätkäytössä olevatkuljetuskerroksen protokollatonsuunnitel-

tu ennen langattomien verkkotekniikoiden aikakautta. Protokollat käyttävät pää-

sääntöisesti pakettihukkaaindikaationa verkon ruuhkautumisesta. Kyseinen oletta-

ma toimiivarsin hyvin perinteisissä kiinteissä tietoliikenneverkoissa, mutta langat-

tomien verkkojen yhteydessä pakettien katoaminen ei ole läheskään aina merkki

ruuhkautumisesta,silläsuuri osa pakettienepäonnistuneista siirroistajohtuu radio-

tielläolevista häiriötekijöistä.Näinollenyleisimmätkäytössä olevatkuljetuskerrok-

sen protokollat käyttävät ruuhkanhallintamekanismejaan usein virheellisesti tiput-

taessaan lähetysnopeuttaan radikaalisti myös häiriöllisten langattomien verkkojen

yhteydessä.

Tämän tutkimuksen päämääränäoli selvittää viiveen ja pakettihukanvaikutus-

ta eri ruuhkanhallinta-algoritmien suoritustasoon. Tutkimuksen kohteeksi valittiin

viisieriTCP- ja kaksi DCCP-versiota,joiden tehollisten läpivientien tasoja vertail-

tiin käyttäen systemaattista simulointia tutkimusmenetelmänä. Tutkimuksen tar-

koituksena oliselvittää mikäruuhkanhallinta-algoritmipystyy tarjoamaanparhaan

tehollisenläpivientitason ruuhkautumattomassa, mutta paketteja hukkaavassa ver-

kossa. Tutkimus tarkastelee olosuhteita, joissa pakettihukka vaihtelee välillä 0,1-

10,0 %, eli tutkitun pakettihukan alueelle sijoittuu mobiiliverkkojen pakettihuk-

katodennäköisyydet. Tutkimuksen tulosten perusteella pystytään määrittelemään

mikä ruuhkanhallinta-algoritmi pystyy tarjoamaan parhaan tehollisen läpiviennin

erilaisilla viiveen ja pakettihukan yhdistelmillä. Tämän lisäksi tutkimuksessa selvi-

tettiin kuinka eri ruuhkanhallinta-algoritmit suoriutuvat tasapuolisuuden suhteen.

Näiden kahden eri ominaisuuden perusteella voidaan arvioida eri ruuhkanhallinta-

algoritmiensuorituskykyä.

2 Ruuhkanhallinta tietoverkoissa

Tietoverkot koostuvatreitittimistäjaniitä yhdistävistälinkeistä, joiden molempien

kapasiteetit ovat rajallisia. Kun verkon resursseihin nähden liian suuri määrä lii-

kennettä pyrkii samanaikaisesti tietyn verkon osan läpi, syntyy ruuhkaa. Ruuhka

aiheuttaa reitittimien puskurien ylivuotoa, jolloin osa paketeista joudutaan tiput-

tamaan pois. Verkon ruuhkautumiseen tulee reagoida, jotta pystytään takaamaan

verkonstabiilisuus,verkonmahdollisimmantehokaskäyttösekäresurssienreilujaka-

minenkäyttäjienkesken.Mikäliruuhkautumiseeneireagoidaollenkaantaitarpeeksi

voimakkaasti, seurauksena voi ollajopaverkon totaalinen romahtaminen.

Ruuhkautumisen havainnointia varten on kehitetty useita erilaisia mekanisme-

ja. Tässä luvussa perehdytään niiden toimintaan sekä erilaisiin tapoihin reagoida

ruuhkautumistilanteisiin. Tämän lisäksi tutustutaan teoreettisen maksimiläpivien-

nin määrittelyynsekä siihen vaikuttaviinseikkoihin.

2.1 Tietoverkkojen ruuhkautuminen

Tietoliikenneverkkojen kuormittaminen verkon resursseja suuremmalla volyymillä

aiheuttaa ruuhkautumista. Se ilmenee käyttäjälle yhteysnopeuden pienentymisenä

ja vasteajan kasvuna. Verkkotasolla ruuhkautuminen aiheuttaa verkon reitittimien

puskureissa odottavienpakettien määränkasvua. Mikäliverkonkäyttäjäteivätpie-

nennä lähetysnopeuksiaan puskurien jonojen kasvaessa, on seurauksena pakettien

tippumista pois ylivuotavista puskureista. Paketti voi kadota matkalla myös muis-

takinsyistäkuinruuhkautumisentakia,esimerkiksilaite-tailinkkivianseurauksena

paketti voi korruptoitua taikadota.

Internet palveluntarjoajat (ISP) eivätaina mitoitaverkkojaan sen mukaan että

kaikille sen asiakkaillepystyttäisiin takamaan liittymäsopimuksen mukaisen maksi-

misiirtonopeuden samanaikaisesti. Sen sijaan esimerkiksi tuhatta neljän megabitin

liittymää kohden saatetaan joissakin tapauksissa varata runkoverkon kapasiteettia

yhdengigabitinverran,elivainneljäsosakaikkienliittymienmuodostamastamaksi-

mikapasiteetista.ISP säästää tällätavoin rahaakäyttämälläpienempikapasiteettis-

ta linkkiä asiakkaidensa Internet -yhdyskäytävään [2℄. Näin voidaan toimia, koska

asiakkaatkuormittavatverkkoahyvin harvointäydelläkapasiteetillasamanaikaises-

ti. Kyseisenlainenrunkoverkon alimitoittaminen aiheuttaa kuitenkin ennemmin tai

myöhemmin tilanteita, jolloin verkon kapasiteetti ei riitä tyydyttämään siltä vaa-

dittua suoritustasoa ruuhkapiikeissä. Edellä kuvailtu tapa mitoittaa runkoverkko

säästösyihinvedotenonkuitenkinjäänytsuureltaosin historiaan.NykyisinISP:den

kannalta tehokkain tapa on ylimitoittaa (overprovisioning) runkoverkon linkit, eli

resursseja on riittävästi vaikka kaikki asiakkaat samanaikaisesti käyttäisivät liitty-

miään täydellä kapasiteetilla. Syitä ylimitoitukseen siirtymiseen ovat runkoverkon

linkkikapasiteetin halpahinta,ylimitoitetunverkonylläpidon helppous sekä verkon

helpompi muuntuminen tulevaisuuden haasteisiin. Runkoverkkojen ylimitoitus on

tarkoittanut myös ruuhkautumisen siirtymistä pois runkoverkon linkeiltä asiakkai-

den ja ISP:n yhdyskäytävän välille[2℄.

nasen hetkisistärunkoverkon jatoisaaltaliityntäverkonteknologioista.Esimerkiksi

ISDN-yhteyksien yleistyttyä olirunkoverkoissa käytetyt framerelay -verkotselvästi

alimitoitettujaliityntäverkkojen nopeuksiin verrattuna [2℄. Nykyiset optiset runko-

verkotpystyvät hyvin tyydyttämään resurssitarpeet, mutta uusien nopeiden liityn-

täverkkojenmyötäsaatetaan taasjokupäiväsiirtyätilanteeseen,jossarunkoverkoja

joudutaanalimitoittamaan.

2.2 Ruuhkan- ja vuonhallinta

Ruuhkanhallinta ja vuonhallinta ovat tietoliikennetekniikan mekanismeja, joiden

avulla pyritään estämään verkon komponenttien ylikuormittumista. Ruuhkanhal-

linnan päämääränäon suojella verkon ruuhkautumista sen perusteella, minkälaista

palautetta verkosta tulee esimerkiksi kadonneiden pakettien tai viiveajan kasvun

perusteella. Vuonhallinnalla pyritään puolestaan estämään vastaanottajan resurs-

sien ylikuormittumista, kun vastaanottaja ilmoittaa palautteella kuinka nopeaan

vastaanottonopeuteen sepystyy.

Verkkosovelluksen olisi hyvä suojella sekä verkkoa että vastaanottajaa ylikuor-

mittumiselta samanaikaisesti,joten lähettäjäntulisi säätää maksimi lähetysnopeus

sen mukaan kumpi vuon- vai ruuhkanhallintamekanismi antaa pienemmän sallitun

lähetysnopeuden.

2.3 Palautetyypit

Systeemiäjokakäyttääsaamaansapalautetta toimintansasäätelyynkutsutaanniin

sanotuksilosed-loop-kontrolloiduksisysteemiksi.Vastaavastiopen-loopkontrolloi-

duissa systeemeissä ei saada järjestelmän tilasta mitään palautetta. Kaikki tässä

diplomityössä tutkittavat tietoliikenneprotokollatkäyttävät losed loop -kontrollia.

Openloop-systeemeissävoidaanmääritelläjärjestelmäntoimintaajoennaltatiedos-

sa olevien ominaisuuksien perusteella. Esimerkiksi jotkin sovellukset määrittelevät

lähetys- ja vastaanottonopeuksia sen perusteella kuinka nopeaksi Internet-liittymä

onmääriteltysovelluksenasennuksenyhteydessä.Tällaisensovelluksenvoidaankat-

soa käyttävän alkeellista open loop -ruuhkanhallintaa.

Tietoverkkoonlähetetty paketti voivastaanottajannäkökulmasta tullanormaa-

listiperille, kadota, tulla perille epänormaalin viiveen jälkeen taikorruptoitua.Ka-

toaminen voi johtua esimerkiksi ruuhkautumisesta, laiteviasta tai häiriöistä radio-

tiellä. Samoinviiveelle voiollauseita syitä.

Palaute on yksinkertaisimmillaan binaarista, eli palautteella pystytään ilmoit-

tamaan kaksi eri tilaa. Esimerkiksi binäärinen palaute tietoverkosta sisältää kaksi

eritilaa: 0paketti meni perille, 1 paketti kadonnut. Palautteen perusteella tehdään

tulkinta, josta seuraa mahdolliset jatkotoimet palautteesta riippuen. Esimerkiksi

paketin katoaminen voidaan tulkita verkon ruuhkautumiseksi, jonkaperusteella lä-

hetysnopeutta pienennetään verkon pahemman ruuhkautumisen välttämiseksi. Bi-

näärinenpalautevoiusein aiheuttaamyösvirhetulkintojaverkontilasta, jolloinsen

aiheuttamavaste saattaaollatilanteeseen sopimaton.Tästähyvänä esimerkkinäon

TCP-ruuhkanhallinnan reagointi tilanteeseen, jossa paketti katoaa mobiiliverkossa

heikonSINR-tason vuoksi.

2.4 Kiertoajan arviointi

RoundTripTime(RTT) elikiertoaikakertookuinka kauan signaalinkestää kulkea

tietoliikenneyhteyden päästäpäähänja takaisin.RTT määritteleeminimiajanmikä

kuluu paketin lähettämisestä ACK-kuittauksen vastaanottoon. Useat ruuhkanhal-

lintamekanismitkäyttäväthyödykseen kiertoajallelaskemaansaarviota pystyäkseen

mahdollisimmantehokkaasti huomaamaan pakettien katoamiset. Mikäli lähetetylle

paketille ei saada kuittaustatietyn ajan kuluessa, lähettäjä toteaa sen kadonneeksi

jauudelleenlähettääsen.KyseistämekanismiakutsutaannimelläAutomatiRepeat

Request (ARQ).

Retransmission Timeout (RTO) on aika joka odotetaan ennen kuin paketti to-

detaan kadonneeksi. Sen mahdollisimman tarkka määrittely tasoon, jossa se rajaa

mahdollisimmantarkastiajanhetken jokaerottaaonnistuneetjaepäonnistuneetsiir-

rot, on äärimmäisen tärkeää systeemin tehokkuuden kannalta. RTO:n määrittely

liianpieneksi aiheuttaauseiden pakettien virheellisentulkinnankadotetuiksi, jonka

seurauksena aiheutuumahdollisestiturhiauudelleenlähetyksiä jakäytettävänruuh-

kanhallintamekanisminmukaisialähetysnopeuden pienennyksiä.VastaavastiRTO:n

määrittelyliiansuureksiaiheuttaasuoritustasonlaskua,koskapakettienkatoaminen

todetaanoptimaalista hetkeä myöhemmin [3℄.

2.5 AIMD, AIAD, MIMD ja MIAD

Lähetysikkunaa käyttävät kuljetuskerroksen protokollatjaetaan eri ryhmiin niiden

ikkunan säätelymekanismien perusteella. Nämä niin sanotut palautekontrollialgo-

ritmit(feedbak ontrolalgorithms)koostuvatadditiivisestataimultiplikatiivisesta

ikkunan suurentamisesta sekäpienentämisestä. Esimerkiksi TCP-protokollissa ylei-

sesti käytetyn mekanismin nimi Additive Inrese Multipliative Derease (AIMD)

kuvastaa hyvin kuinka lähetysikkunan kokoa säädellään.

Tyypillisesti lähetysikkunan kokoa kasvatetaan aina kun vastaanotetaan kuit-

tauksiaperille menneistäsegmenteistä,eikäruuhkautumisestaolemitäänmerkkejä.

Vastaavastilähetysikkunan kokoapienennetään mikäliverkko tulkitaanruuhkautu-

neeksi. Lähetysikkunan additiivinenkasvatus tarkoittaa ikkunan koonkasvattamis-

ta yhden segmentin verran jokaista vastaanotettua ACK-viestiä kohden. Multipli-

katiivinen lähetysikkunan pienennys tarkoittaa esimerkiksi TCP-Renon yhteydessä

ikkunankoonpuolittamista.AIMD-algoritmilletunnusomaistaonikkunankoonsa-

halaitainen käyttäytyminen.

Kuvissa1ja2nähdään vektoridiagramminakahdensamanlinkinjakavanyhtey-

den resurssiosuuksien muutoksia eri algoritmeilla.X ja Y -akselit kuvaavat kahden

erikäyttäjänsaamaaosuuttayhteisen linkinkapasiteetista.Vasemmastaalanurkas-

taoikeaanylänurkkaanmeneeniinsanottutasavertaisuuslinja,elikyseisellälinjalla

käyttäjätsaavatyhtäsuurenosuudenresursseista.Vasemmastaylänurkastaoikeaan

laskettukuormahyödyntääkokolinkinkapasiteetin.Mitälähempänäkyseistälinjaa

ollaan,sitä parempionsysteemin hyötysuhde [3℄.

Kuvasta 1voidaan huomatakuinkaperinteinenAIMD-algoritmihakeutuukohti

tasavertaisuuslinjaa.Tämänjälkeensiirrytäänedestakaisin tehokkuuslinjaneripuo-

lin ja eikä stabiilia tilaa saavuteta koskaan. Tämä johtuu palautteen binaarisesta

luonteesta.

Kuva1: AIMD [2℄

EnsimmäinenyleisestitunnettuAIAD-algoritmiäkäyttäväkuljetuskerroksenpro-

tokollaonTCPVegas.Kuvasta2voidaanhuomatakuinkaAIAD:n vektori on45as-

teenkulmassa,jossatilameneeedestakaisinkyseistä linjaa.Ilmiöjohtuu käyttäjien

lineaarisesta ikkunan koon kasvattamisesta ruuhkautumistilanteeseen asti. Tämän

jälkeenikkunankokoapienennetäänsamassasuhteessakuinsitäkasvatettiinkin.Sa-

mailmiötoistuuMIMD:n tapauksessa, muttatälläkertaa kuljetaan vektoria, jonka

jatke lävistää origon. Origon lävistävillä ns. equi fairness -linjoilla käyttäjien saa-

ma suhteellinen osuus pysyy koko ajan samana. AIAD:n vektori ei osoita origoon

ja näin ollen kuvan 2 tapauksessa x-akselin saama suhteellinen osuus kasvaa mitä

lähempänä origoaollaan.

tajossa alunperin suuremmanosuuden saanut vie pian kaikki resurssit. Tilanneon

juuri päinvastainen verrattuna AIMD:hen, jossa kaikista alkutilanteista hakeudu-

taan kohti tehokkuus- ja tasavertaisuuslinjojenleikkauspistettä.

Kuva2: AIAD,MIAD ja MIMD [2℄

Edelläkäsiteltyjenalgoritmienmatemaattinenkuvausbinäärisenpalautteenval-

litessaja mikälivainyhtäkomponentinarvoavoidaanmuuttaakerrallaanonnistuu

seuraavasti. Yhtälö 1 määrittelee lähetysnopeuden x(t) ajan hetkellä t. y(t) kuvas-

taa verkosta saatua binaarista palautetta verkon tilasta, jonka arvo nolla kuvastaa

ruuhkautumatonta tilaaja arvo yksi ruuhkaa. Vakiot

a i

b i

a d

b d

joiden avulla määritelläänfunktion additiiviset ja multiplikatiiviset ominaisuudet.

x(t + 1) =

a i + b i x(t)

y(t) = 0

a d + b d x(t)

y(t) = 1

• a i > 0; a d = 0; b i = 1; 0 < b d < 1

Additive Inrease, MultipliativeDerease (AIMD)

• a i > 0; a d < 0; b i = 1; b d = 1

• a i = 0; a d < 0; b i > 1; b d = 1

MultipliativeInrease, AdditiveDerease (MIAD)

• a i = 0; a d = 0; b i > 1; 0 < b d < 1

MultipliativeInrease, MultipliativeDerease (MIMD)

2.6 Hidas aloitus ja ruuhkan välttely

Hidas aloitus (Slow Start) -algoritmi on yksi Van Jaobsonin vuonna 1988 esit-

telemistäruuhkanhallintatoiminnoista[10℄. Se perustuu TCP-yhteyden segmenttien

lähetysnopeuden säätelyyn saapuvien ACK -kuittauksienperusteella. Hidas aloitus

määritteleelähettäjälleuudenlähetysikkunan,jokaonnimeltäänongestionwindow

(wnd). Cwnd on lähettävän pään rajoitin datan määrälle, joka verkkoon voidaan

lähettää ennen kun on vastaanotettu kuittauksia perille menneistä segmenteistä.

Vastaavasti vuonhallinnassa käytetty reeiver's advertised window (rwnd) on vas-

taanottavanpäänilmoittamarajoitinlähettäjälle,jollasekertookuinkanopeastise

onvalmisvastaanottamaandataa.TCP-lähettäjämääritteleelähetysikkunankooksi

sen muuttujista wnd tairwnd kumpi niistä saa pienemmän arvon.

wnd = min(cwnd, rwnd)

Cwnd:n alkuarvo (initial value, IW) on korkeintaan kaksi kertaa SMSS:s koko

tavuinaeikäsesaaollaenempääkuinkaksisegmenttiä.Onolemassajoitainepästan-

dardeja TCP-versioita,joissa IW voisaada suurempia arvoja. TCP-yhteyden muo-

dostuksen jälkeen wnd:n arvoa kasvatetaan jokaista vastaanotettua ACK -viestiä

kohdenyhdelläsegmentillä.Lähetysikkunakasvaatässävaiheessahyvinnopeastiai-

naniinkauan kunnes vastaanottaja eisaa ACK-kuittausta kaikistalähetysikkunan

segmenteistä.

Uudelleenlähetysajastimen laukeaminentulkitaansignaaliksiverkonruuhkautu-

misesta.Tämä aiheuttaawnd:n arvonpalauttamisentakaisin alkuarvoonsa. Tästä

alkaa wnd:n kasvatus uudelleen yhdellä jokaista vastaanotettua ACK-viestiä koh-

den.

TCP-yhteydenmuodostuksenalussaeilähettäjälläolemitääntietoaverkonomi-

naisuuksistajohondataaollaanlähettämässä.Hitaanaloituksentapaaloittaadatan

lähetys hyvin pienellä lähetysikkunan koollamahdollistaa lähettäjän sopeutumisen

verkon resursseihin siten ettei mahdollisesti ruuhkauteta verkkoa liian aggressiivi-

sella lähetysnopeudella. Myös verkon ruuhkaannuttua ja RTO:n lauettua wnd:n

tiputtaminen takaisin yhteen segmenttiin estää lähettäjää kuormittamasta ruuh-

kautunutta verkkoaentisestään.

Ruuhkanvälttelyäkäytetäänwnd arvonollessasuurempi kuinslowstart thres-

hold (ssthresh). Ssthresh määrittelee onko TCP-yhteys hitaan aloituksen vai ruuh-

kanvälttelyn tilassa.Ssthresh parametrinalkuarvoon 64kilotavua.

Ruuhkan välttely tilassa wnd:n kokoa ei enää kasvateta yhtä aggressiivisesti

kuinhitaanaloituksentilassajawnd:täkasvatetaankorkeintaanyhdelläsegmentillä

cwnd = cwnd + SMSS ∗ SMSS/cwnd/BaseRT T

KunTCP protokollahuomaasegmentinkadonneentuleessthresh määritelläuu-

delleen, jolloin sen maksimiarvo määritellään kaavan x mukaisesti. Flight size on

lähetettyjen pakettien määrä joitaei olevieläkuitattu.

ssthresh = max[2 ∗ F lightSize, 2 ∗ SMSS ]

Segmenttien katoaminen aiheuttaa wnd:n asettamisen takaisin alkuarvoonsa myös

siinä tapauksessa että TCP-yhteys onruuhkan välttelymoodissa.

2.7 Nopea uudelleenlähetys ja toipuminen

Perinteinen TCP-algoritmi käyttää pakettien katoamisten havaitsemiseen niin sa-

notunuudelleenlähetysajastimenlaukeamista(retransmissiontimeout,RTO).TCP

asettaa jokaiselle lähetetylle paketille ajan, jonka kuluessa lähettäjä odottaa saa-

vansa kuittauksen paketin perille menosta. TCP ei tiedä pakettien mahdollisista

katoamisista mitäänennen kuin RTO laukeaa janäin ollenjokaisen katoamisen to-

teamiseen kuluu paljonaikaa.

RTO:n laukeamiseen perustuva uudelleenlähetysmekanismi toimii tehottomasti

etenkin suurilla lähetysikkunoilla. Tämän takiaTCP-algoritmiinon lisätty niinsa-

nottunopeauudelleenlähetys -mekanismi(fastretransmit), jokakäyttääpakettihu-

kan toteamisessahyödykseen saapuvia ACK-viestejä.TCP-yhteyden vastaanottaja

kuittaa jokaisen vastaanotetun segmentin ACK-viestillä, jossa se ilmoittaa seuraa-

vaksiodottamansasegmentinnumeron. Näinollenpaketin katoaminenverkossa saa

vastaanottajan kuittaamaan kadonneesta paketista seuraavat segmentit kadonneen

paketinsegmenttinumerolla.Tätätietoahyväksikäyttäenlähettäjävoihuomatapa-

ketin kadonneen tainiiden saapuneen perille poikkeavassa järjestyksessä. Jotta pa-

ketin katoaminenvoitaisiinerottaajärjestyksenmuutoksesta,vastaanottajaodottaa

useamman duplikaatin ACK-viestin vastaanottamista ennen kuin paketti todetaan

kadonneeksi. Nopea uudelleenlähetys ei aina pysty toteamaan paketin katoamista

RTO:nlaukeamistaaiemminjanäinollen molempiamekanismejakäytetäänsaman-

aikaisesti.Esimerkiksipienillälähetysikkunan koillanopeauudelleenlähetyseitoimi

ja tällöinjoudutaan toimimaantäysinRTO:n varassa.

Nopea uudelleenlähetys aiheuttaa TCP Tahoessa siirtymisen hitaaseen aloituk-

seen sekä wnd:n pienentämisen alkuarvoonsa, eli täysin samat toimenpiteet jotka

seuraavat RTO:n laukeamisesta. Kyseisillä toimilla tyhjennetään yhteys lähetyk-

sessä olevista paketeista, joka aiheuttaa turhan voimakkaan suoritustason laskun.

TCPReno:ssasekäsitäuudemmissaTCP-varianteissakäytetäänkolmenduplikaatin

ACK-viestin vastaanottamisen jälkeen nopean toipumisen -mekanismia (fast reo-

very). Nopeassa toipumisessa lähetysikkunaa ei pienennetä yhteen vaan sen sijaan

toimitaanseuraavasti:

2 Lähetetään puuttuva segmentti uudelleen

3 Asetetaanwnd = ssthresh +3 (kolme segmenttiäon mennyt perille)

4 Kasvatetaan wnd:tä yhdellä jokaistaduplikaattia ACK:ta kohden

5 Kunvastaanotetaan kuittausuudelleenlähettämättömästäsegmentistä, asete-

taan wnd= ssthresh

2.8 TCP-ystävällisyys

Nykyajan tietoverkoissa protokollan tasapuolisuus määritellään usein niin sanotul-

la TCP-ystävällisyydellä (TCP friendliness). Käytännössä tämä ominaisuus kertoo

kuinkaaggressiivisestikyseinen protokollakohtelee muita TCP:ntavoinruuhkautu-

miseenreagoiviadatavirtoja.MikäliprotokollaonTCP-vihamielinen,voiseuraukse-

naollamuiden TCP:n tavoin käyttäytyvien yhteyksien tukahtuminenpoiskyseisen

röyhkeän verkkosovelluksen tieltä. Esimerkiksi User Datagram Protool (UDP) on

hyvinyleinenkuljetuskerroksenprotokolla,jokaeisääteleelähetysnopeuttaanruuh-

kautumistilanteissa millään tavalla. Seurauksena voi olla TCP:n totaalinen tukah-

tuminenUDP-yhteyksien tieltä ja täten verkon toiminnanvakava häiriintyminen.

2.9 Teoreettinen maksimiläpivienti

Tietoliikenteessäkäytetäänlinkinliityntänopeudestatermiäkaistanleveys(bandwidth).

Sekuvastaakanavansiirtokapasiteetinmaksimiajaseilmoitetaanyleensämuodossa

bittiä sekunnissa (bps).

Läpiviennillä (throughput) tarkoitetaan verkon läpi kuljetetun fyysisen datan

siirtonopeutta. Läpivienti pitää sisällään kaiken mitä verkon läpi kulkee, eli varsi-

nainenlähetettävädatasekäesimerkiksiprotokollienkehykset jauudelleenlähetetyt

segmentit.Läpivientiei voiylittääkaistanleveyden nopeutta.

Tehollinen läpivienti (goodput) määrittelee kuinka paljon alkuperäistä lähetet-

tävää tietoa saadaan siirrettyä yhteyden yli aikayksikköä kohden. Yleisin tapa il-

moittaatämäkin siirtosuure onmuodossabittiä sekunnissa.

Analogisen tietoliikennekanavan maksimaalisen läpiviennin perusyhtälönä voi-

daan pitääniinsanottua Shannon-Hartley-teoreemaa, joka määritteleekuinkapal-

jon virheetöntä tietoa onmahdollista kuljettaa yhteyden läpi tietyllä kaistanlevey-

delläjasignaali-kohinasuhteella(Signaltonoiseratio,SNR).Shannoninteoreeman

antamaatulostaeipystytäylittämäänmissäänolosuhteissajaonkysesysteeminte-

hokkuudesta kuinka lähellesen arvoakäytännössä päästään. Yhtälössä 5

V s

tikaistanleveys(bittiä/sekunti),

B

S/N

V s = B ∗ log ² (1 + S/N )

Kaistanleveys-viivetulo (Bandwidth-delay Produt, BDP) kertookuinkapaljon

esimerkiksi TCP yhteydelle mahtuu kuittaamattomiasegmenttejä, eli kuinkasuuri

mahdollisimmansuurenhyötysuhteentuleeverkkoollamahdollisimmansuurenosan

ajasta niin sanotusti täynnä. Hyvin suuria BDP arvoja saavia linkkejä kutsutaan

termillä "long fat pipes"(LFP). Hyvä esimerkki tällaisesta on satelliittilinkit,joilla

RTT sekä kaistanleveys voivat saada hyvinkin suuria arvoja.

BDP = Kaistanleveys ∗ RT T

Ikkunointiinperustuvaa vuon-ja ruuhkanhallintaakäyttävienprotokollienmak-

similäpivientiinvaikuttaamaksimiikkunankoko.EsimerkiksiTCP-protokollanmak-

simivastaanottoikkunan kokoon 65535 tavua,jokamääritellään 16-bittisessäTCP

WindowSize-kentässä.Nykyisinonmahdollistakäyttäämyössuurempiarwnd:nar-

voja käyttämällä skaalautuviaikkunoita (RFC1323).Perinteinen 64 kilotavun vas-

taanottoikkuna rajoittaa esimerkiksi 10millisekunninviiveen omaavan linkinmak-

simi läpivienniksi 52 Mbps kaavan 7 mukaisesti. Näin ollen kauttakiertokulkuajan

kasvun voidaantodetapienentävänsuurimmanmahdollisenläpivienninarvoalinea-

risesti.

Maksimilapivienti 0 RW IN

RT T

Pakettien katoaminen aiheuttaa läpiviennillemyös ylärajan. Niin sanottu Mat-

hiksen approksimaatio (kaava 8) antaa arvion TCP:n läpiviennistätietyllä paketti-

hukan todennäköisyydellä

P l

p 3/2b

Yhtälössä käytetty

b

viesti kuittaa kerralla. Perinteinen TCP kuittaa yhden segmentin jokaista ACK-

viestiä kohden, mutta uudemmat viivästetyn kuittauksen algoritmit voivat saada

b

uudelleenlähetyksenmekanismit[7℄.

B (RT T, p l ) M = C RT T √

P l

(8)

MathiksenapproksimaatiotamonimutkaisempijatarkempimallionPadhyemal-

li(kaava9).SeottaahuomioonmyösnopeanuudelleenlähetyksensekäRTO:nruuh-

kanvälttämis mallissaan[8℄.

B(RT T, p l ) P = min { W m

RT T , 1

RT T q

2 bp l

3 + T ⁰ min(1, 3 q

3 bp l

8 )p l (1 + 32p ² _l ) }

2.10 Ruuhkanhallinta-algoritmit langattomissa verkoissa

Kuljetuskerroksen TCP -protokollaon kehitetty kauan ennen nykyisiä langattomia

lähiverkkoja ja mobiileja verkkoyhteyksiä. TCP:n ruuhkanhallintaominaisuudet on

suunniteltu toimimaanoptimaalisestikaapeleidenvälityksellätapahtuvassa tiedon-

siirrossa. Tiedonsiirrossa tapahtuva segmenttien katoaminen on varsin harvinaista

kiinteissä verkoissa verrattuna langattomiin verkkoihin, joissa vaimentuminen, häi-

segmenttien korruptoitumistaja katoamista. Perinteiset ruuhkanhallinta-algoritmit

eivät pysty erottamaan radiotielläsattuvia siirtovirheitä ruuhkautumisesta ja näin

ollen ne virheellisen tulkinnan takia aiheuttavat vastaavat toimet kuin ruuhkautu-

minen.Radiotienerilaisuussiirtotienäaiheuttaalinkkikapasiteetinalikäyttöä,koska

esimerkiksi TCP-yhteys tulkitsee verkonruuhkautuneeksi jo pienestäkin pakettihu-

kasta[3℄. Kyseisenilmiönvaikutuksensuuruutta erikuljetuskerroksenalgoritmeihin

tutkitaantarkemmintämän diplomityönsimulaatioissa.

3 Kuljetuskerroksen verkkoprotokollat

Tietoliikennetekniikassa kuljetuskerroksella tarkoitetaanjoukkoaprotokolliaja me-

kanismeja, joiden tehtävänä on kapseloida sovellustason data segmentteihin ja da-

tagrammeihin ja näin mahdollistaa tiedon siirron sovellukselta toiselle. Kuljetus-

kerroksen tehtäviin kuuluvat myös esimerkiksi ruuhkan- ja vuonhallintasekä taata

mahdollisestiluotettavatiedonsiirto yhteyden päästäpäähän.

Yleisesti tunnettuja kuljetuskerroksen protokolliaovat muun muassa Transmis-

sionControlProtool(TCP), UserDatagramProtool(UDP)sekäDatagram Con-

gestion Control Protool (DCCP). Nykyisissä tietoverkoissa käytetään pääasiassa

TCP- ja UDP-protokollia [11℄. Tämän tutkimuksen kohteena ovat ruuhkanhallin-

nallisiaominaisuuksia sisältävätTCP sekä DCCP.

Taulukko 1:Kuljetuskerroksen protokollat

TCP UDP DCCP

Paketin tyyppi Segmentti Datagrammi Datagrammi

Luotettava siirto Kyllä Ei Ei

Vuonhallinta Kyllä Ei Ei

Ruuhkanvälttely Kyllä Ei Kyllä

Tässä luvussa perehdytään TCP- ja DCCP-protokollien toimintaan sekä viiden

eriTCP-jakahdenDCCP-versionominaisuuksiin.Tutkimuksenkohteeksi onvalittu

yleiset TCP-variantitTahoe, Reno, New Reno, Sak sekä Vegas. DCCP-variantteja

onkehitetty useitaerilaisiajane nimetään ruuhkanhallinnallistenominaisuuksiensa

perusteellaeriCongestionControlIdentier(CCID) -tunnuksella.Tähäntutkimuk-

seen onvalittuCCID-2 (TCP Like)sekä CCID-3(TFRC).

3.1 TCP

TransmissionControlProtool(TCP)onyksialkuperäisistäInternetinprotokollista.

Setakaaluotettavan(reliable)tiedonsiirronepäluotettavan(unreliable)IP-pohjaisen

verkon yli,eli se huolehtii siirrossa kadonneiden pakettien lähettämisestäuudelleen

kunnes ne saadaan onnistuneesti perille[18℄. TCP-protokollasta on kehitetty useita

eriversioita, jotka poikkeavat toisistaan esimerkiksi ruuhkanhallintamekanismiensa

3.1.1 Tahoe

TCPTahoekäyttäähidastaaloitusta,ruuhkanvälttämistäsekänopeaauudelleenlä-

hetystä.Ruuhkaikkunaa kasvatetaaneksponentiaalisestikunnes sen kokosaavuttaa

ssthresh:n arvon. Tämän jälkeen siirrytään ruuhkan välttely -tilaan, jossa wnd:n

kokokasvaayhdellä jokaista RTT:täkohden.TCP-yhteyssiirtyy nopean uudelleen-

lähetyksen -tilaan, mikäli lähettäjä vastaanottaa kolme samaa kuittausta. Sen ai-

kana lähetetään kadonnut segmenttiuudelleen ja siirrytään takaisin hitaaseen aloi-

tukseensekäasetetaan wndtakaisinalkuarvoonsa, jokaonyleensäyksi.Ssthreshin

koko asetetaan puoleen wnd:n arvosta ajanhetkellä kun verkon ruuhkautuminen

havaittiin [19℄.

3.1.2 Reno

TCPRenopoikkeaa Tahoestasiihenlisätynnopean toipumisen-mekanisminosalta.

TCP-lähettäjän vastaanottaessa tietyn määrän (yleensä 3) duplikaatteja kuittauk-

siase siirtyy nopean toipumisen tilaanhitaan aloituksen sijaan.Nopea toipuminen

aloitetaan asettamalla ssthreshin arvoksi puolet wnd:stä ja wnd saa arvokseen

uuden ssthreshin lisättynä vastaanotettujen duplikaattien ACK-viestien määrällä.

TCP Reno pysyy nopean toipumisen -tilassa,niinkauan kunnes nopean uudelleen-

lähetyksen laukaissut segmenttisaadaan kuitattuaperille menneeksi.

VastaanottajansaadessauusiaACK-viestejäsesiirtyynopeantoipumisen-tilasta

takaisiinruuhkanvälttelyyn ja wnd muutetaan samaan arvoon ssthreshin kanssa.

Nopeantoipumisenavullawndpysyy keskimäärinsuurempanakuinTCPTahoella,

jonka myötä yhteyden suorituskyky onparempi.

Kuva 3: Cwnd:n kehittyminen TCP Tahoella ja Renolla[1℄

TCPRenotoimiihyvin,mikälisegmenttejäkatoaamelkoharvoin.Yhteydenlaa-

dun ollessa hyvin huono paketteja voi kadotakuitenkin useampiakin saman lähety-

vain yhden segmentin katoamisen kerralla. Yhden paketin kadottua lähettäjä vas-

taanottaa useampia kuittauksiasamalla segmenttinumerolla.Mikälikadoksissaole-

van segmentin ja jo vastaanotettujensegmenttien välistä puuttuu yksi taiuseampi

segmentti,niintästäsaadaantietävastasen jälkeenkunensimmäisenäkadonneesta

segmentistä saadaan kuittaus. Näinollen toisenakadonneesta segmentistä saadaan

tieto vähintään RTT:n pituisen viiveen jälkeen. Usean segmentin katoaminen sa-

masta lähetysikkunasta voi aiheuttaa myös wnd:n pienentämisen useammin kuin

yhden kerran. Tämä nopean toipumisen ja nopean uudelleenlähettämisen toistuva

vaihtelu huonontaa TCP Renon toimintaahyvin radikaalisti .

TCP Reno tarvitsee nopean uudelleenlähetyksen toimintaan tarpeeksi suuren

lähetysikkunan, koska lähettäjän tulee vastaanottaa tarpeeksi monta duplikaattia

ACK-viestiä huomatakseen jonkin segmentin kadonneen. Näin ollen pienen lähety-

sikkunan tapauksessa lähettäjä joutuu odottamaan RTO:n laukeamistaennen kuin

se toteaa segmentinkadonneeksi. Tämä ominaisuus yhdistettynä wnd:n mahdolli-

seen pienentämiseen useita kertoja yhden ikkunan aikana aiheuttaa sen että TCP

Reno eitoimitehokkaasti mikälisegmenttejä katoaa hyvin paljon[3℄.

3.1.3 New Reno

New Reno onparanneltu versio TCP Reno:sta. New Reno:ssasiirrytään Renon ta-

paan nopeaan uudelleenlähetykseen, mikäli vastaanotetaan tarpeeksi monta dupli-

kaattiaACK-viestiä.UutenaominaisuutenaNew Reno:ssapoistutaannopeastatoi-

pumisesta vasta kun kaikkiin segmentin katoamisen aikana lähetettyinä olleisiin

segmentteihin saadaan kuittaukset. New Renon nopea toipuminen siirtyy ruuhkan

välttely -tilaan, mikäli lähettäjä vastaanottaa ACK-viestin, joka kuittaa kaikki lä-

hetyksessä olleet segmentit. Mikäli vastaanotettu ACK on niin sanottu osittainen

kuittaus,niinseuraavaksilähetetään ensimmäinenkuittaamatonsegmentti.Tällöin

myös wnd:tä pienennetään ACK:n kuittaamalla datamäärällä ja erotukseen lisä-

tään vielä yksi SMSS. Tämän jälkeen jatketaan toipumisvaihetta. Tällä mekanis-

millavältytäänReno:ssaesiintyvältäongelmalta,jossawnd:tä saatetaanpienentää

useita kertoja samanlähetysikkunan aikana[21℄.

New Renon ongelmanaonettä jokaisenkadotetunpaketin huomaaminenkestää

yhden RTT:n verran. Vasta sen jälkeen kun ensimmäinen kadotettu paketti saa-

daan uudelleenlähetettyä perille, voidaan huomata mikä on seuraava mahdollisesti

kadotettu segmentti.

3.1.4 Sak

TCP with Seletive Aknowledgements (SACK) käyttää ns. SACK-optiota ACK-

viesteissään, jonka avulla lähettäjälle ilmoitetaan pakettihukan tai muun syyn ta-

kia epäjärjestyksessä saapuneista segmenteistä. Selektiivinenkuittaus mahdollistaa

useanpuuttuvansegmentinidentioinninkullakintoistokuittauksella.Lähettäjä yl-

läpitää taulukkoa, joka sisältää tiedon normaalisti vastaanotetuista sekä epäjär-

jestyksessä vastaanotetuista segmenteistä. Taulukon sisältämän tiedon perusteella

Vastasen jälkeenkuntaulukossaolevatkuittaamattomataukotontäytetty,voidaan

lähettäätäysin uusia segmenttejä[23℄.

TCP SACK ylläpitää kuittaamattomien segmenttien määrää muuttujassa ni-

meltäänpipe

Nopean toipumisen aikana lähetetään uusia tai uudelleen lähetettäviä

segmenttejä vainjos pipen arvo onwnd:tä pienempi. Pipen arvoa kasvatetaan yh-

dellä segmentinlähetyksen yhteydessä ja pienennetään yhdellä kun vastaanotetaan

duplikaatti ACK-viestiSACK-optiolla.OsittaisenACK:nvastaanottopienentää pi-

pen arvoakahdella.FastreoverytilastapoistutaankunvastaanotetaanACK-viesti,

joka kuittaa kaikki lähetettyinä olleet segmentit siirryttäessä nopean toipumisen -

tilaan.

TCP SACK eroaa TCP Reno:sta/New Reno:sta lähinnä nopean toipumisen -

mekanisminosalta.TCPSACKpystyy käsittelemäänuseidenpakettienhukkumisen

samastalähetysikkunasta New Renoa paremmin[4℄.

3.1.5 Vegas

TCPVegasesiteltiinjovuonna1994,eliennenNewReno:njaSACK:nkehittämistä[5℄.

TCP Vegas poikkeaa kaikista muista TCP-varianteista mekanismillajollase toteaa

pakettien hukkuneen. Vegas ei odota RTO:n laukeamista pienentääkseen wnd:tä

vaan se tarkkailee odotetun ja toteutuneen läpiviennin suhdetta. Mikäli verkkoon

alkaa kehittyä ruuhkaa, niin toteutunut läpivienti alkaa saada odotettua läpivien-

tiäpienempiäarvoja.Odotettu läpivientilasketaan kaavan10mukaisesti,jossa Ba-

seRTT on pieninmitattu RTT:n arvo.

Odotettu lapivienti = cwnd

BaseRT T

Toteutunut läpivienti lasketaan mittaamalla segmentin RTT ja laskemalla ky-

seisenäaikanalähetettyndatanmäärä.Toteutuneenjaodotetunläpivienninerotus-

ta varten käytetään muuttujaa Di jonka arvoa vertaillaan parametreihin

α

β

Mikäli Di on pienempi kuin

α

β

wnd:tä pienennetään lineaarisesti. Parametrit

α

β

ja4,jotkamäärittelevätkuinkapaljonverkossa onkuittaamattomiasegmenttejä[4℄.

TCP Vegas käyttäämuunneltuahitaan aloituksen-algoritmia.Alkuperäinenhi-

das aloitus ja ruuhkan välttely-mekanismit tarvitsevat segmenttien katoamisia to-

detakseen ruuhkautumisen alkaneen. TCP Vegasin hidas aloitus pyrkii löytämään

oikean wnd:n koon ennen kuin segmenttien katoaminen alkaa. Tämä toteutetaan

lisäämällä wnd:n kokoa eksponentiaalisesti joka toisella RTT:llä ja mittaamalla

muuttujan Di arvo korotusten välissä. Vegas siirtyy hitaasta aloituksesta ruuh-

kanvälttelytilaan ennenkuintoteutunutläpivientisaavuttaa odotetun läpiviennin

arvon.

Vegas käyttää myös hieman muunneltua segmenttien uudelleenlähetysstrategi-

aa.Segmenttilähetetäänuudelleen joyhden duplikaatinACK-viestinjälkeenmikä-

li RTT:n estimaatio on suurempi kuin RTO. Tämä auttaa niissä tilanteissa jolloin

Kuva 4:TCP Vegasin hidas aloitus ja ruuhkanvälttely

merkiksisilloinkunlähetysikkunastakatoaauseitasegmenttejätaiikkunan kokoon

hyvin pieni.

3.2 DCCP

Kuljetuskerroksen protokollatvoidaanjaotellaluotettaviinja epäluotettaviinproto-

kolliin, joista jälkimmäisenä mainitut eivät takaa pakettien perille menoa. On kui-

tenkin olemassa useita verkkopalveluita, joiden käyttö on enemmän riippuvainen

pakettien nopeasta perille viennistä pienellä viiveellä kuin siitä että kaikki paketit

saadaan toimitetuksi. Esimerkiksi IP-puheluiden ja videoiden streamauksen palve-

lutaso eivätjuurikaan kärsi vaikka osa yhteyden paketeista katoaisikin.

User Datagram Protool (UDP) on yleisesti käytetty kuljetuskerroksen proto-

kollamultimediasovelluksille.Seeitarjoaminkäänlaisiaruuhkanhallintaominaisuuk-

sia,jotensovelluksen konservatiivinen (ns. TCP-friendly)käyttäytyminen ontäysin

kiinni sovelluksen kehittäjästä. UDP kehitettiin aikoinaan hyvin lyhyiden datavoi-

den käyttöön, kuten esimerkiksiDNS-kyselyihin.Tästä johtuen ruuhkanhallintaa ei

otettu aikoinaan huomioon kyseistä protokollaa kehitettäessä. UDP on hyvin pal-

jon käytetty protokollaesimerkiksi VoIP, musiikki-ja video-sovellusten yhteydessä.

UDP:nreagoimattomuusverkonruuhkautumiseenaiheuttaasen ettäTCP-yhteydet

jäävätoman ruuhkanhallintansa myötä UDP-liikenteen dominoimaksi.

IETF on kehittänyt UDP:lle korvaajaa, joka täyttäisi nykyisten UDP:ta käyt-

tävien sovellusten vaatimukset, mutta samalla sisältäisi myös ruuhkanhallinnallisia

ominaisuuksia.Työntuloksenaonsyntynyt DatagramCongestionControlProtool

(DCCP) [12℄.

DCCP:n voidaan katsoa olevan käytännössä UDP:n kaltainen protokolla,johon

onlisättyruuhkanhallinta,kättelyja ACK-kuittaukset. DCCP aloittaasessionaina

yhteyden muodostuksella(setup) japäättääsen yhteyden purkamiseen(teardown).

Näin toimitaansiitäkinhuolimattaettä DCCP ei takaa luotettavuutta, koska tällä

tavoinmahdollistetaanläpipääsyuseistapalomuureista,jotkanormaalistihylkäävät

UDP-liikenteen [2℄.

DCCP:tä varten onkehitetty joukko erilaisiaruuhkanhallintamekanismeja,joil-

leonannettu tunnisteeksi niinsanottu Congestion ControlIndentiation(CCID).

TällähetkelläonolemassamuutamiaeriCCID-mekanismeja, joistatämäntyönpii-

riinonvalittuCCID-2:TCP-LikesekäCCID-3:TCPFriendlyRateControl(TFRC).

NäidenlisäksiIETF onstandardoinutCCID-4:n joka onnimeltäänVoIPVariantof

TFRC.

3.2.1 TCP-like Congestion Control

TCP-Like Congesstion Control (CCID-2) on nimensämukaisesti hyvin TCP:n kal-

tainenruuhkanhallintamekanismija sekäyttääAIMD-tyylistäsäätelyälähetysikku-

nan kokoon. Suurimpana erona TCP:n ja CCID-2:n välillä voidaan pitää sitäettei

TCP-Like koskaan uudelleenlähetä paketteja. Tämän lisäksi protokollan paramet-

rit,kuten ikkunoiden koot, määritelläänCCID-2:ssa paketteina eikä tavuina kuten

TCP-Like soveltuu erityisen hyvin sovelluksiin, joiden liikenne on hyvin purs-

keista ja vastaanotettu data puskuroidaan ennen sen käyttöä sovellustasolla [13℄.

Esimerkkeinä tällaista sovelluksista mainittakoontilausvideo-palvelut (VoD) ja In-

ternet radiot.

3.2.2 TCP Friendly Rate Control

TCP Friendly Rate Controlonruuhkanhallintamekanismi,jota voidaankäyttääeri

kuljetuskerroksen protokollien kanssa. DCCP:n ja TFRC:n yhdistelmää kutsutaan

CCID-3:si. TFRC pyrkii olemaan UDP:tä tasapuolisempi verkon TCP-yhteyksiä

kohtaan.TähänpyritäänsäätelemällälähetysnopeuttaPadhyen-yhtälönmukaisesti

(yhtälö9).

TFRC:ssävastaanottajantehtävänä onlaskeaniinsanottu"losseventrate", jo-

ka tarkoittaa todennäköisyyttäettä RTT:n aikana sattuu vähintään yhden paketin

katoaminen. TFRC:n yhteydessä lähettäjä kasvattaa jokaisen lähetettävän paketin

järjestysnumeroa yhdellä. Näin toimitaan myös niillä protokollillajoilla uudelleen-

läetykset ovat mahdollisia. Vastaanottaja tulkitsee paketin kadonneeksi mikäli se

vastaanottaapaketin, jonkajärjestysnumeroonvähintäänkolmenumeroasuurempi

kuinvielävastaanottamaton mahdollisestikadotetun paketin järjestysnumero.Vas-

taanottaja tehtävänä on määritellä pakettihukan perusteella loss event rate, jota

vartensen tulee tietääRTT:n saamaarvomahdollisimmantarkasti. Loss eventrate

saapakettihukkaapienempiäarvojajatämäerokasvaapakettihukankasvunmyötä.

Tämä johtuu siitä että usean paketin hukkuminen yhden RTT:n aikana tulkitaan

yhdeksihukkatapahtumaksi.RTTmääritelläänyhteydenlähettäjänpäässä,jostase

sitten toimitetaansäännöllisin päivitysvälein vastaanottajalle[14℄.

4 Simuloinnit

Simulointiontutkimusmenetelmäjonkatarkoituksenaonsuorittaatodellistasystee-

miäkuvaavallamallillakoe,jostavoidaantehdäjohtopäätöksiätodellisensysteemin

toiminnasta.

Suorituskykymittauksia voidaan tehdä kolmella eri tavalla: simuloimalla, ana-

lyyttisillämalleilla sekä mittauksilla.Simulointion yleinen tapa tutkia algoritmien

ja protokollien suorituskykyä ja toimintaa. Sen etuina muihin menetelmiin nähden

voidaan pitää seuraavia ominaisuuksia[4℄:

- Mikälivarsinaistatutkittavaaverkkoaeiolevielätoteutettutaisitäeimuuten

päästä mittaamaan, niin simuloinnin avulla pystytään kuitenkin tehokkaasti

arvioimaansen ominaisuuksia.

- Simuloinnin avulla voidaan helposti ja tehokkaasti testata verkon toimintaa

erikuormituksillaja verkko-olosuhteissa.

- Simulointi mahdollistaa eri verkon ominaisuuksien pysymisen täsmälleen sa-

mana kerrasta toiseen mikä ei aina ole mahdollista verkon suorassa mittauk-

sessa. Tämä oneduksi erialgoritmien ja protokollien vertailussa.

- Simuloinninavullasaadaanenemmänyksityiskohtaistatietoaverrattunaana-

lyyttiseen mallinnukseen.

- Analyyttistenmallien tulokset voidaan usein vahvistaa simuloimalla.

Systemaattistasimulointiavartenonuseitaeritapojasuorittaatehtävä.Niinsa-

nottuJain-mallionsuorituskykymittauksiavartenkehitettyprojektimalli.Kyseinen

mallijakaatehtävänkahdeksaan osavaiheeseen (kuva5),joistapuoletkuuluvatniin

sanottuun esiohjelmalliseen vaiheeseen ja toinen puolisko ohjelmalliseen vaiheeseen

[4℄.

4.1 ns2-simulaattori

Simulaatiotsuoritettiinns2-simulaattorilla,jokaonC++sekäObejtOrientedTCL:llä

(oTl)toteutettusimulaatio-ohjelma [25℄.C++ käytetään protokollientoteutuksiin

jauusienmoduulienluontiin.VarsinainensimulaationkongurointitehdäänoTl:llä.

Ns2:llapystytään simuloimaanesimerkiksi tietoverkkojen reitityksiä ja kuljetusker-

roksen protokolliasekälangallisissaettä langattomissa ympäristöissä.

4.2 Simulaation topologia ja parametrit

Simuloituverkkokoostuureitittimistä,palvelimistasekälinkeistä,joistayksionmui-

ta pienempi kapasiteettinen pullonkaulalinkki. Simulaatioiden ensimmäisessä vai-

heessa tutkitaan yksittäisten protokollien suorituskykyä pullonkaulalinkin yli olo-

suhteissajoissaneeivätjoudujakamaanverkonresurssejamuidenkäyttäjienkesken

Ongelman ja päämäärän määrittäminen

Suorituskykymetriikoiden valinta

Verkkomallin suunnittelu ja parametrien valinta

Tulosten esittäminen ja tulkinta

Suorituskykyyn liittyvän datan määrittäminen

Simulointi ja datan kerääminen

Verkkomallin rakentaminen ja parametrien asettaminen

Muuttuvien parametrien valinta

Esiohjelmallinen vaihe Ohjelmallinen vaihe

Kuva5: Jain-mallinmukainen systemaattinensimulointi

Kuva 6:Ns2-simulaattorinobjektit ja niiden yhteydet

Kuva7: Simulaationtopologia

pullonkaulalinkillä kun kahden eri kuljetuskerroksen protokollan yhteydet jakavat

saman pullonkaulalinkinresurssit (kuva8).

Simulaatiota varten pitää määritellä useita parametrejä, jotka pysyvät vakioi-

na kaikissa simulaatioissa. Yksi simulaation tärkeimmistä ominaisuuksista on sen

kesto. Liianlyhyt simulaatioaikaaiheuttaa tuloksienepäluotettavuutta,sillätällöin

jo pienet sattumat aiheuttavat suuria muutoksia tuloksissa. Toisaalta liian pitkä

simulaatioaika aiheuttaa turhaa simulaatiotyön pitkittymistä tuomatta kuitenkaan

mitäänlisäinformaatiotalopputuloksiin.Tätätyötävartensimulaatioajaksivalittiin

600 sekuntia,jossaajassapienet satunnaisuudettasoittuvatja varsinainen simulaa-

tio saadaan ajettua läpi tehokkaasti. Tätä työtä varten suoritettiin lähes 100 000

simulaatioajoa,jotentehokkuus oli varsin tärkeässä asemassa.

Verkonliityntälinkkienkaistanleveydeksivalittiin100Mbpsjaviiveeksiyksimil-

lisekunti.Pullonkaulalinkinkaistanleveysoli10Mbpsjaviivesekäpakettihukkaoli-

vatdynaamisiamuuttujia.Verkossaolevienpuskurienkokovaikuttaapaljonsensuo-

rituskykyyn.Hyvinsuuretpuskuritaiheuttavatylikuormitustilanteissapitkiäviivei-

tä,mutta toisaaltaniiden avulla pakettihukkasaadaan pidettyä pienenämikäli yli-

kuormitus on purskeluonteista. Suuret puskurit hidastavat myös kuljetuskerroksen

protokollienreagointikykyäruuhkautumistilanteissa[2℄.Yleisenäsääntönäpidetään

että puskurit olisi hyvä pitää melko pienenä. Tarkempaa määritystä varten löytyy

useampiakinerisuosituksia,muttayksi yleisimmistäohjeistaonettä puskurintulisi

ollakaistanleveys-viive-tulon kokoinen.Simuloitavanverkon tapauksessa tämätar-

koittaa että esimerkiksi kymmenen millisekunninviiveellä puskurin koon tulee olla

noin10kilotavua.Näinollensimulaationpuskurienvakiokooksivalittiinkymmenen

pakettia.

Puskurin tapa käsitellä ylikuormitustilanteita tulee myös määritellä suoritus-

kykysimulointiavarten.NS2-simulaattoritukee useitaerijononhallinta-algoritmejä,

kutendrop-tail,RandomEarlyDetetion(RED)sekäRandomEarlyDetetionwith

Expliit Congestion Notiation (RED-ECN). RED on aktiivinen jononhallinta-

algoritmi, joka pudottaa paketteja tietyn todennäköisyysmallin mukaisesti jo en-

nen kuin puskuri vuotaa yli. Näin pyritään säätelemään puskuriin saapuvan datan

määrääjavälttämäänpahat ruuhkautumistilanteet.Näinollen REDonmyösruuh-

kanvälttämisalgoritmi.RED:n yhteydessä voidaan käyttää myös ECN-mekanismia,

jolloinpakettientiputtamisensijaanREDmerkkaakyseistenmuutoinpudotettavien

pakettienIP-kehyksienECP-kenttääntiedonettäverkkosaattaaollaruuhkautumas-

sa.Näinpystytääninformoimaanlähettäjääjavastaanottajaamahdollisistaylikuor-

mitustilanteista jo ennalta ilman että joudutaan tiputtamaan paketteja. Drop-tail

on hyvin yleisesti reitittimissä käytetty jononhallinta-algoritmi joka nimensä mu-

kaisesti pudottaa kaikki puskuriin saapuvat paketit, jotka eivät sinne enää mahdu.

Drop-tailkohtelee kaikkiapakettejasamanarvoisestijasekäyttääniinsanottuarst

in-rst out(FIFO)jonotusmallia.Tämändiplomityönsimulaationjononhallintaan

valittiin käytettäväksi drop-tail.

Simulointityössä tarvitaan vakioparametrien lisäksi muuttuvia tekijöitä, joiden

vaikutusta systeemiin tutkitaan. Tämän diplomityön tavoitteiden saavuttamiseksi

muuttuviksiparametreiksivalittiinverkonpullonkaulalinkinviive,pakettihukkasekä

Taulukko 2:Simulaationvakioparametritja niiden arvot

Simulaatioaika 600 s

Linkkien kaistanleveys 100 Mbps

Pullonkaulalinkinkaistanleveys 10 Mbps

Linkkien viive 1 ms

Puskurien koko 10pakettia

Jononhallinta-algoritmi Drop-tail

Max. wnd 64KB

DCCP paketin koko 1000 B

Taulukko3: Simulaationmuuttuvat parametritja niiden arvot

RTT 1 ms->100 ms, resoluutio 10ms

Pakettihukka 0.000-> 0.150,resoluutio 0.001

Protokollat TCP: Tahoe,Reno, NewReno, Sak, Vegas

DCCP: TFRC, TCP-Like

4.3 Pakettihukan vaikutus

Pakettien hukkuminen aiheuttaa TCP:n lähetysikkunan koon pienentymistä ja pa-

kettien uudelleen lähetyksiä. Eri TCP-versiot reagoivat eri tavoin pakettihukkaan.

Tämänsimulaationtarkoitusolitutkiakuinkaerialgoritmitsuoriutuvatläpiviennin

osaltakunpakettihukkavaihteleevälillä0.01ja0.10,muttaRTTpysyyvakioarvossa

50ms.

Kuvan 9 perusteella voidaan todeta TCP Vegasin tehollisten läpivientiarvojen

olevan vertailujoukon suurimpia pakettihukan ollessa alle 4 %. Tätä huonommis-

sa olosuhteissa TCP Vegasin suoritustaso heikkenee dramaattisesti muihin TCP-

variantteihinverrattuna.TCPRenonjaTahoenjärjestysläpivientitasonosaltavaih-

tuupakettihukankasvaessaylipuolenprosentin.MyösTCKSakjaNewRenovaih-

tavat paremmuusjärjestystään tämänsimulaationperusteella.

4.4 Kiertokulkuajan vaikutus

RTTvaikuttaasuoraanteoreettisenläpivienninsuuruuteenkaavan7mukaisesti.Eri

ruuhkanhalinta-algoritmienreagointikykyverkonominaisuuksiinriippuupakettihu-

kanlisäksiRTT:nsuuruudesta. Simulaationavullatutkittiinalgoritmienläpivientiä

kun RTT vaihteli välillä1 ja 100 millisekuntia.Pakettihukka asetettiin tässä simu-

laatiossavakioksi, joka oli 0,1%.

Kuvan10 perusteella voidaan todeta TCP Renon saavan muista poikkeavia ar-

voja pienilläRTT:narvoilla.TCPRenonruuhkanhallintatoimiitunnetusti huonos-

ti olosuhteissa, joissa saman lähetysikkunan aikana katoaa useita paketteja. Myös

wnd:nhyvinpienikokoaiheuttaaongelmiaTCP Renonnopealle uudelleenlähetyk-

selle,silläpieniikkunankokoestäätarpeeksiuseanduplikaatinACK:nvastaanoton.

TCP:n lähetysikkuna on erittäin pienillä RTT:n arvoilla hyvin pieni. Kaavojen 11

0.1 % 1 % 2 % 3 % 4 % 5 % 6 % 7 % 8 % 9 % 10 % 1,000 Kbps

2,000 Kbps 3,000 Kbps 4,000 Kbps 5,000 Kbps 6,000 Kbps 7,000 Kbps 8,000 Kbps 9,000 Kbps 10,000 Kbps

Tahoe Reno NewReno Sack Vegas

Kuva 9:Läpivienti pakettihukan arvoilla0,1 ->10prosenttia

läpivienninja RTT:n arvoilla.TCP Renon wnd keskimääräinen koko kahden mil-

lisekunnin RTT:llä on vain 1.5 kilotavua.Näin ollen nopea uudelleenlähetys ei voi

toimiahalutulla tavallaja pakettihukka todetaan aina RTO:n laukeamisesta.

T CP siirtonopeus = cwnd

RT T (pakettia/s)

cwnd = RT T ∗ T CP siirtonopeus

4.5 TCP-varianttien vertailu

EdellistenlukujensimulaatioidenperusteellavoidaantodetaettäTCP-variantitsuo-

riutuvateritavoinriippuenmm.verkonpakettihukastajakauttakiertoajasta.Kuvan

9 perusteella huomataan että TCP Vegas saa parhaat läpivientiarvot aina reiluun

neljän prosentin pakettihukkaan asti. Tämän jälkeen sen suorituskyky huononee

merkittävästimuihinvariantteihinverrattaessa.Kuvassa10nähdäänkuinkaRTT:n

vaikuttaa eri varianttien läpivienteihin pakettihukan pysyessä yhden prosentin va-

kioarvossa. Kuvanperusteellavoidaantodeta Vegasin pärjääväänedelleen kaikkein

parhaiten,mutta samallavoidaantodeta RTT:n kasvunmuuttavanTCP Tahoen ja

Renon tehollisten läpivientien paremmuusjärjestystä kun RTT kasvaa yli 20 milli-

0 ms 10 ms 20 ms 30 ms 40 ms 50 ms 60 ms 70 ms 80 ms 90 ms 100 ms 1,000 Kbps

2,000 Kbps 3,000 Kbps 4,000 Kbps 5,000 Kbps 6,000 Kbps 7,000 Kbps 8,000 Kbps 9,000 Kbps 10,000 Kbps

Tahoe Reno NewReno Sack Vegas

Kuva 10:LäpivientiRTT:n suhteen eriTCP-varianteilla

ollen herääkin kysymys mikä varianteista pystyy tarjoamaan parhaan läpiviennin

erilaistenverkko-olosuhteiden vallitessa.

Tutkimuksen kohteena oleville viidelle TCP-variantille suoritettiin simulaatiot

käyttäen pakettihukalle arvoja 0,1-10,0 % sekä RTT:lle arvoja 1-100 ms. Simulaa-

tioiden resoluutio pakettihukanosalta oli 0,1prosenttia ja RTT:lläkymmenen mil-

lisekuntia. Simulaatiotoistoja suoritettiin tutkimuksessa 10-40 kertaa jokaista ske-

naariota kohden. Näin ollen yksittäisiä simulaatioajoja tehtiin tätä osuutta varten

lähes 100 000 kappaletta.

Simulaatiostasaaduistatrae-tiedostoistakäyilmikaikkienverkossaliikkuneiden

pakettien liikkeet solmujen välillä. Tämän informaation avulla pystytään analysoi-

maan simulaatiossatapahtuneitailmiöitä ja laskemaanesimerkiksi läpivienti,jitter

ja keskimääräinen viive.NS2-simulaattorieitarjoavalmistatyökalua simulaatioda-

tankäsittelyyn,jotensitävartentäytyy käyttäämuitakäytettävissäoleviatyökaluja

taitehdäne itse.Tämäntyönsimulaatioaineistonkäsittelytoteutettiinkäyttämällä

awk-skriptiä,jonkaavullatiedostostaparsittiinerilleenvastaanotetutsegmentit,joi-

den joukosta poistettiin protokollien hylkäämät sekä duplikaatit segmentit. Jäljelle

jääneidenpakettienmäärälläkerrottiinyhden paketin hyötykuorman koko ja saatu

tulojaettiinsimulaatioajalla.Näinsaatiinselvillesimulaatioajonprotokollientehol-

lisetläpiviennitelinopeusjollahyötykuormaasaatiinsiirrettyäverkonläpisekuntia

kohden.

Trae-leistäselvitetyttehollisetläpivientiarvotsiirrettiinedelleenMatlab-ohjelmaan,

jossaluotiin11x101 matriisi(11 eriviivettä,101 eripakettihukkaa) jokaiselletutki-

mienparametreintuottama läpivientikyseisellä protokollalla.Esimerkiksimatriisin

solu

V egas ¹⁰ , 25

lisätylläpakettihukalla.

Kuvassa 11 nähdään TCP Tahoen tehollisialäpivientiarvoja simulaationperus-

teella. Pakettihukan vaikutus näkyy tasaisena läpivientiarvojen alenemana siirryt-

täessä kohti suurempaa pakettihukkaa. Vastaavasta Z/X-tasolla nähdään viiveen

vaikutus pakettihukan ollessa 0,1 prosenttia. Kuvaajan lopputuloksena on keskeltä

hiemanalas painunutliukumäki.

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva 11:TCP Tahoe

TCPRenonruuhkanhallintamekanisminsuurimpiaongelmakohtiaonsen selviy-

tyminentilanteista,joissapakettejakatoaauseampia kappaleitasamanlähetysikku-

nan aikana. Kyseinen ilmiötulee hyvin esille kuvasta 12, jossa Renon läpivientiar-

vot laskevathyvin jyrkästisiirryttäessäkohtisuuriapakettihukka-arvoja.Kuvaajan

perusteella voidaan toisaalta todeta Renon toimivat varsin tehokkaasti pienillä pa-

kettihukillaverrattuna TCP Tahoeen.

TCPNewRenossaonRenoonverrattunaparanneltunopeantoipumisen-mekanismi,

jonkaansiosta wnd:tä eipuolitetasuurenkaan pakettihukansattuessa kahteen ker-

taan yhden lähetysikkunan aikana. TCP New Renon kuvaajan perusteella voidaan

todeta sen saavan selvästi parempia läpivientiarvoja kauttaaltaan, mutta etenkin

suuren pakettihukan aiheuttama dramaattinen suorituskyvyn heikentymä on kor-

jaantunuttäysin verrattuna TCP Renoon.

TCPSakkäyttäänimensämukaisestiselektiivistäsegmenttienkuittausta.Tällä

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva 12:TCP Reno

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps

6,000 Kbps

8,000 Kbps

10,000 Kbps

lukienkadonneenpaketinjälkeenperillemenneitäsegmenttejä.Tälläominaisuudella

pyritään parantamaan TCP-yhteyden mahdollisuutta uudelleenlähettää enemmän

kuin yksi segmentti yhden RTT:n aikana. Kuvan 14 perusteella pystyy näkemään

Sak:n saavan ainakin silmämääräisesti parempia läpivientiarvoja ainakin pienillä

RTT:narvoilla.Tarkempiinvertailuihinryhdytäänmyöhemmintässädokumentissa.

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva 14:TCP Sak

TCPVegaspoikkeaauseidenominaisuuksiensaperusteellamuistaTCP-varianteista.

Se käyttää AIAD-palautekontrollialgoritmiäkun muut tässä työssä tutkitut proto-

kollat käyttävät AIMD:tä. TCP Vegas käyttää ruuhkanhallinnassaan myös muista

poikkeavaa mekanismia, jossa seurataan odotetun ja toteutuneen läpiviennin suh-

detta. Kuvan 15 perusteella voidaan huomata kuinka TCP Vegas tarjoaa erittäin

suuria läpivientiarvoja pakettihukan pysyessä alle viiden prosentin ja RTT alle 50

millisekunnin. Tätä huonommissa verkko-olosuhteissa löytyy parempia suoritusar-

voja tarjoavia TCP-versioita.

TCP-protkollien keskinäinen vertailuei onnistu kovin tarkastisuoraan kuvien -

perusteella. Heikompienverkko-olosuhteiden läpiviennitovatpieniäverrattunasuo-

tuisten olosuhteiden tapauksiinja näin ollen kyseisten arvojen erot on vaikeahah-

mottaasamasta kuvaajasta.

Kuvaajissa 16-18 on esitetty mikä TCP-varianteistä sai simuloinneissa suurim-

man läpivientiarvon koko simulaatiomuuttujien kentässä. Kuvassa 16 voidaan sel-

västinähdä TCP Renon kykenemättömyys selviytyä hyvin suuristapakettihukista.

Kuvaajan avulla voidaan lisäksi huomata kuinka kyseinen ilmiö on sitä radikaa-

limpimitä pienempiä arvoja RTT saa. Voidaan siis todeta että TCP Renon suori-

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva15:TCP Vegas

pienehkön pakettihukan ja pienen viiveen olosuhteita.

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva 16:TCP Tahoe (sininen)ja TCP Reno (keltainen)

Kuvaajissa19-22 vertaillaanTCPRenon,New Renon,Sak:njaVegasinteholli-

sialäpivientejäsuhteessaTCP Tahoen läpivientiinkyseisen x-y -koordinaatin mää-

rittelemilläpakettihukkaja RTT -arvoilla.Arvoton laskettu kaavan13 mukaisesti.

V ertailtu T CP vs T CP T ahoe (x, y) = V ertailtuT CP (x, y) − T ahoe(x, y) T ahoe(x, y)

TCP Renon tehollinen läpivienti on pienillä RTT:n arvoilla jopa 60 prosenttia

TCP Tahoeta pienempi. Erittäinpienellä lähetysikkunan koollailmenevä TCP Re-

non nopean uudelleenlähetyksen ongelmatkatoavat simulaationperusteella RTT:n

ollessayli40millisekuntia.PienilläpakettihukkatodennäköisyyksilläTCPRenosuo-

riutuu kauttaaltaanTCP Tahoeta paremmin.

TCP New Reno onparanneltu versio TCPRenosta. New Renon paranneltuno-

peantoipumisenmekanismitmahdollistavatuseankadonneenpaketinhuomaamisen

samastalähetysikkunasta.Kuvasta20nähdäänkuinkaTCPRenonkanssailmenneet

ongelmat pienillä RTT:n arvoilla ovat kadonneet lähes kokonaan ja läpivientiarvot

ovat kauttaaltaan 10-20 prosenttiasuurempia kuin TCP Tahoella.

TCP Sak pystyy Reno:sta ja New Reno:sta poiketen huomaamaan useamman

kuin yhden segmentin katoamisen samasta lähetysikkunasta. Tämän lisäksi Sak

pystyy uudelleenlähettämään useita segmenttejä yhden RTT:n aikana. Selektiivis-

ten ACK-viestien avulla saavutetaan huomattavasti TCP New Renoa suurempia

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps 6,000 Kbps 8,000 Kbps 10,000 Kbps

Kuva17: TCP Sak (vihreä) ja TCP NewReno (punainen)

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 % 2,000 Kbps

4,000 Kbps

6,000 Kbps

8,000 Kbps

10,000 Kbps

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 %

−0.5 0 0.5

Kuva 19:TCP Reno

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 %

−0.5

0

0.5

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 %

−0.5 0 0.5

Kuva 21:TCP Sak

Saksaavuttaa kokotutkitulla alueellanoin 10-20prosenttiaparempia läpivientiar-

voja TCP Tahoeen verrattuna.

0 ms 20 ms 40 ms

60 ms 80 ms

100 ms 0.1 %

2 %

4 %

6 %

8 %

10 %

−0.5 0 0.5

Kuva22:TCP Vegas

TCP Vegas saa simulaatioiden perusteella kaikkein suurimpia läpivientiarvoja

suurimmassa osassa simulaatioita. Vegas saavuttaa 1-4 prosentin pakettihukan ar-

voilla jopa50 prosenttiasuurempia läpivientejäkuin TCP Tahoe. Kuvan 22perus-

teella voidaan todeta TCP Vegasin suorituskyvyn huonontuvan merkittävästi pa-

kettihukan ollessaerittäin suuri ja RTT:n ollessa samallahyvin pieni.

Taulukko 4:TCP-varianttien tehollisialäpivientiarvoja eriolosuhteissa

RTT 10ms 100 ms

Pakettihukka 0.2% 3.0% 6.0 % 0.2% 3.0 % 6.0%

Tahoe 7788 kbps 3001 kbps 1690 kbps 1773 kbps 355 kbps 234 kbps

Tahoe 100 100 100 100 100 100

Reno 106 77 65 105 107 102

New Reno 116 117 114 105 121 112

Sak 115 126 117 106 119 108

Vegas 126 143 93 106 171 139