S-38.188 Tietoliikenneverkot Luento 6: Liikenteenhallinta Historiaa Internet reitittimien ruuhkanhallinta sai alkunsa Ford yhtymän sisäisen verkon ongelmista. Nämä ongelmat ilmenivät, koska silloinen ARPANET perustui identtisiin linkkeihin, joita hallittiin erillisellä vuonohjauksella. Näin mitään ruuhkatilanteita ei ollut päässyt syntymään, ainakaan siinä määrin, että niihin olisi reagoitu. Fordin verkko vastaavasti oli heterogeeninen, yhdistäen useita tuotantolaitoksia eri puolilla USAta sekä sateliitin kautta laitoksen Englannissa. Heterogeenisuus syntyi siitä, että laitoksien sisällä käytettiin ethernet verkkoa ja laitoksien välillä vuokrajohtoja, joilla liikennöintinopeus oli alhaisimmillaan 1,2kbit/s. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 2
Historiaa Mitä ongelmia havaittiin? Ensimmäiset ongelmat liittyivät TCP:n sisäiseen vuonhallintaan. Pienet paketit, joita syntyy esimerkiksi merkkipohjaisessa tiedonsiirrossa, 40 tavua otsikkoa ja yksi tavu hyötykuormaa, johti verkkojen ylikuormittumiseen turhalla informaatiolla. Toinen ongelmatiikka syntyi, kun verkkojen käyttö kasvoi ja aiheutti mahdollisuuden yhteyden äkillisiin viiveiden kasvuihin; mikäli yhteyden kiertoaikaviive kasvaa nopeammin kuin lähettävän TCP-prosessin mittaama kiertoaikaviive, syntyy uudelleen lähetyksiä, jotka vastaavasti kuormittavat lisää reitittimiä aiheuttaen yhä pitemmän kiertoaikaviiveen. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 3 Historiaa Ongelmiin pyrittiin ratkaisemaan TCP-prosessin modifioinnilla sekä ns Source Quench toiminnolla, jossa ruuhkautunut reititin pyytää edellistä reititintä pakottamaan lähdettä pienentämään nopeutta. Tämä informointi tapahtuu vastavuohon aina lähteeseen saakka, joka riippuen riippuen toteutuksesta pienentää nopeuttaan tai ei. Kuten saattaa arvata lähderiippuvat ratkaisut reitittimen ruuhkanhallintaan ovat aina ehdollisia; mikäli lähde ei noudata reitittimen ohjeita mitään ei tapahdu. Näin ollen kehitys johti reitittimien sisäisiin ruuhkanhallintamekanismeihin. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 4
Mitä ja Miksi liikenteenhallintaa Reitittimet jakavat yhteisiä resursseja Verkon siirtokapasiteettia Reitittimen puskurointikapasiteettia Reitittimen prosessointikapasiteettia Resurssit ovat rajallisia ja yhdenkin loppuminen johtaa toiminnan rajoittumiseen 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 5 Contend vs Congest Contend, viivästyminen Kun verkon siirtokapasiteetti hetkellisesti ylittyy ja paketit asetellaan jonoon, josta ne palvellaan ajallaan. Congest, ruuhkautuminen Kun verkon siirtokapasiteetti ylitetään tarpeeksi pitkän aikaa, vuotaa puskurit yli ja paketteja katoaa 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 6
Resurssien jako ja ruuhkanhallinta Kolikon kaksi puolta Resurssienjako: Yhteydelle määritellään ennaltakäsin rajoja Ruuhkanhallinta: Yhteydelle määritellään rajoja ruuhkautumisen tapahduttua Ääripäissä Ei ruuhkanhallintaa --> resurssit on jaettu ennaltakäsin (vrt puhelinverkko) Ei resurssienjakoa --> yhteydet kilpailevat samasta kaistasta ja ruuhkatlanteissa algoritmi ratkaisee resurssien jaon 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 7 Resurssien jako ja ruuhkanhallinta 100% Resurssien varaus Ruuhkanhallinta 0% 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 8
Liikenteenhallinta Liikenteenhallinta on laajempi kokonaisuus kuin pelkkä resurssienjako ja ruuhkanhallinta mutta sisältää käsitteenä molemmat osa-alueet. Liikenteenhallinta on monisäikeistä (hajautettua): verkossa on useita laitteita laitteiden toiminnot on jaettu useille protokollakerroksille usiden laitteiden sisäiset resurssit on jaettu 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 9 Liikenteen hallinnan aikatasoja Vuonhallinta Paketti IP-kytkentä Yhteys Reititys Verkonhallinta 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma Verkonrakennus 10
Ruuhkanhallinta vs vuonhallinta Ruuhkanhallinta pyrkii estämään lähdettä ylittämästä verkon resursseja Vuonhallinta pyrkii estämään lähdettä ylittämästä vastaanottajan resursseja 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 11 Vuo (eri kuin vuonhallinta) Yhteydellinen kytkentä, jokainen paketti kulkee ennalta määrättyä reittiä Yhteydetön kytkentä, jokainen paketti reititetään omana kokonaisuutena Käytännössä paketit kulkevat samoja reittejä pitkin ja muodostavat siten VUON. Vuo ei ole kongreettinen reunaehto vaan abstractio, joka helpottaa liikenteenhallintaa 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 12
Vuon tila Ei tilaa: puhdas yhteydetön kytkentä Pehmeä tila: reititin ylläpitää tietoa kyseisen yhteyden kytkennästä välimuistissa jonkinlaista tietoa yhteyden puskurointiviiveestä jonkinlaista tietoa yhteyden resurssitarpeesta Kova tila: reititin ylläpitää tarkkaa tietoa yhteyden kytkennästä yhteyden resurssitarpeesta yhteyden olemassaolosta 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 13 Palvelumalli Best Effort Ei takuuta kaistasta Ei takuuta viiveestä Ei takuuta hukasta Taattu palvelu Takuu kaistan tietylle arvolle Rajoitettu viive Taattu hukka tietyllä aikavälillä Harmaa alue 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 14
Lähestymistapoja liikenteenhallintaan Reititin - lähde keskeinen Varaus - vaste pohjainen Ikkuna - nopeus pohjainen 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 15 Reititin - lähde keskeinen Reititin keskeiset menetelmät perustuvat reitittimen tekemään päätökseen, mitkä paketit saavat palvelua ja mitkä eivät Lähde keskeisissä menetelmissä lähteet sopeutuvat verkon tilaan lähettämällä sopivan määrän informaatiota verkkoon Nämä kaksi menetelmää eivät ole toisiaan poissulkevia Vaikka reititin suorittaa pakettien karsintaa tarvitaan lähdepohjaista hallintaa mukautumaan verkon tilaan Vaikka lähde kontrolloisikin liikennettä tarvitaan reitittimiin mekanismeja turvaamaan niiden toimintaa ruuhkatilanteissa 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 16
Varaus - vaste pohjainen Varauspohjaisissa järjestelmissä lähde pyytää verkolta tiettyä määrää resursseja yhteyden ajaksi. Jokainen reititin täyttää tämän pyynnön tai hylkää yhteyden. Vastepohjaisissa järjestelmissä lähteet aloittavat lähettämisen heti ja säätävät nopeuttaa saamansa vasteen perusteella. Ekspilisiittisesti; reititin informoi lähdettä Implisiittisesti; lähde havainnoi verkon tilaa uudelleen lähetyspyyntöjen kautta HUOM!!! Varauspohjainen toiminta edellyttää reititin keskeistä toimintaa 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 17 Ikkuna - nopeus pohjainen Lähteelle kerrotaan kuinka paljon informaatiota lähde saa lähettää Tietyssä aikaikkunassa (purskeinen) Millä nopeudella (tasainen) Nopeuspohjainen lähestymistapa soveltuu varauspohjaisiin järjestelmiin 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 18
Internet Best effort verkko Vastepohjainen toiminta (ei varausta) Lähdepohjainen toimintatapa Käyttää ikkunapohjaista lähteenhallintaa Tulevaisuudessa taattuja palveluita Varauspohjaisia palveluita Vaatii paljon reitittimiltä Luonnostaan nopeuspohjainen lähteenhallinta 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 19 Liikenteenhallinnan vertailumenetelmiä Liikenteenhallinnan menetelmiä vertaillaan usein niiden suhteessa Verkon resurssien hyödyntämiseen Lähteiden reiluun käsittelyyn 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 20
Resurssiteho Resurssiteho optimoi kahta keskeistä parametria läpäisyä viivettä Optimoinnin tavoite on saada mahdollisimman suuri läpäisy mahdollisimman pienellä viiveellä Teho Läpäisy Viive Teho Optimi 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma Kuorma 21 Reiluus Reiluus on määritelmä sille, miten oikeudenmukaisesti eri yhteyksiä kohdellaan ruuhkautuvassa reitittimessä. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 22
Sosialistinen näkökanta Kaikkia palvellaan tasapuolisest Kaikki resurssit ovat kaikkien vapaasti hyödynntettävissä Kaikilta odotetaan kunnioitusta toisia kohtaan. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 23 Kapitalistinen näkökanta Yhteyksiä käsitellään perustuen maksukykyyn, eli sen kulutat mistä maksat. Sosiokapitalistisessa järjestelmässä uudet yhteydet pääsevät mukaan ja vanhat yhteydet saatavat kärsiä siitä ( vakio palveluaika ) Puhtaassa kapitalistisessa järjestelmässä olemassa olevien yhteyksien tilaan ei puututa mitenkään 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 24
TCP-ruuhkanhallinta Tehtävä on määrittää kuinka paljon verkossa on kapasiteettia vapaana Toimii itseohjautuvasti Kellotus vastesanomilla (ACK) Kello on kiertoaikaviive (RTT), joka kertoo ajan, joka kuluu paketin lähettämisestä sen vastaanottamiseen. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 25 TCP-ruuhkanhallinta Ruuhkaikkuna vastaa vuonhallinnan ilmoitettuaikkunaa Ikkuna on minimiresurssi rajoitettu Maksimissaan: MaxIkkuna = MIN(RuuhkaIkkuna, IlmoitettuIkkuna) Käytännössä: Ikkuna = MaxIkkuna-(Viim. lähetetty tavu - Viim. hyväksytty tavu) KYSYMYS: Kuinka ruuhkaikkuna tiedetään? Lähde suorittaa itseohjautuvaa verkon tilan seurantaa perustuen vastesanomiin (ACK) ja kadonneisiin paketteihin 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 26
TCP-ruuhkanhallinta Lineaarinen kasvu Jokainen onnistuneesti lähetetty ruuhkaikkunallinen kasvattaa ruuhkaikkunaa yhdellä paketilla: RuuhkaIkkuna = RuuhkaIkkuna + MSS Käytännössä jokainen vastesanoma kasvattaa ikkunaa omalta osaltaan: Eksponentiaalinen peräytyminen Jokainen epäonnistunut lähetys (ajastin laukeaa) aiheuttaa ruuhkaikkunan puoliintumisen: RuuhkaIkkuna = ½ * RuuhkaIkkuna Inc = MSS * (MSS/RuuhkaIkkuna) RuuhkaIkkuna = RuuhkaIkkuna + Inc 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 27 TCP-ruuhkanhallinta Perusversion käyttäytyminen Pitkät hitaat kasvamiset Nopeat pudotukset 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 28
TCP-ruuhkanhallinta Lähteen nopeuden kasvattaminen on alussa liian hidasta Tarvitaan tehokkaampi mekanismi ensi alkuun Ruuhkaikkuna tuplataan jokaisella vastesanomalla SLOW START on mekanismi, jossa Ruuhkaikkunaa kasvatetaan 1:stä paketista tuplaamalla jokaisen paketin kohdalla ikkunan arvo Se estää laitetta lähettämästä täyttä ikkunaa paketteja niissä tapauksissa, joissa se vastaanottaa useita ACK-paketteja 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 29 TCP-ruuhkanhallinta Alussa lähteen ruuhkaikkunan loputon tuplaaminen johtaa pakettien suureen katoamiseen mittaa verkon kapasiteetin tulevan toiminnan varalle Ajastimen laukeamisen jälkeen tuplaamista käytetään ainoastaan siihen asti, että saavutetaan edellinen validi ruuhkaikkunan koko tämän jälkeen jatketaan normaalia toimintaa (lineaarinen kasvu) 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 30
TCP-Ruuhkanhallinta Slow Start käyttäytyminen Nopeat nopeuden kasvattamiset Pitkät kuolleet hetket Lähetettävä data Paketin katoaminen ja siitä johtuva ajastimen laukeaminen Ruuhkaikkuna 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 31 TCP-Ruuhkanhallinta Miten poistaa pitkät hiljaiset hetket yksittäisen paketin kaoamisen jälkeen? Fast Recovery and Fast Retransmit on menetelmä siihen OLETUS: Verkossa katoaa useimmiten vain yksi paketti!!! 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 32
TCP-Ruuhkanhallinta Jokainen yksittäinen kadonnut tai viivästynyt paketti vahvistetaan edellisellä oikealla ACK sanomalla. Paketti 1 Paketti 2 Paketti 3 Paketti 4 ACK 1 ACK 2 Kolme peräkkäistä samaa ACK sanomaa laukaisee uudelleen lähetyksen. Mikäli uudelleen lähetys ei tuo kuittausta jokaiseen pakettiin odotetaan ajastimen laukeamista. Paketti 5 Paketti 6 Paketti 3 ACK 2 ACK 2 ACK 2 ACK 6 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 33 TCP-Ruuhkanhallinta Nopea vaste useimmissa tapauksissa Monen paketin katoaminen ja niistä johtuva ajastimen laukeaminen Yksittäisen paketin katoaminen ja nopea palaaminen Ruuhkaikkuna 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 34
Reitittimet Ruuhkatila reitittimessä syntyy, kun resurssien tarve reitittimessä ylittää tarjolla olevan resurssien määrän. Reititin suojautuu resurssien vajetta vastaan erilaisilla jonotusalgoritmeilla, joilla jaetaan verkon kapasiteettia jaetaan puskurimuistin määrää ruuhkan aikana poistetaan oikeat paketit 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 35 Reitittimet Ruuhkanhallinnan menetelmät voidaan jakaa kahteen luokkaan: ruuhkatilaa ennustaviin ruuhkatilaan reagoiviin 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 36
Reitittimet Ennustavat menetelmät pyrkivät pitämään verkon/reitittimen toimintapisteen resurssiteho maksimissa Reagoivat menetelmät pyrkivät palauttamaan toimintapisteen optimiin, mikäli se sen ylittää. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 37 Reitittimet Toimiakseen menetelmät tarvitsevat erilaisia suoritusarvoja: Jonon keskimääräinen pituus Kiertoaikaviive Mikäli suoritusarvoja mitataan ja ennustetaan perustuen liian tiheään tai harvaan näytteenottoon ilmenee tuloksissa väistämättä virheitä, jotka johtuvat internet-liikenteen dynamiikasta. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 38
Reitittimet Kiertoaikaviive voidaan määrittää jonon regeneroitumisprosessista. Periaate on hyödyntää dominoivan liikenteen dynamiikkaa. Dominoiva kiertoaikaviive voidaan määrittää tarkkailemalla jonon täyttymis- ja tyhjentymisprosessia. Mikäli prosessi on deterministinen, voidaan syklin pituudesta määrittää kiertoaikaviive. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 39 Reitittimet Puskurinhallintaan on erilaisia mekanismeja Tail Drop (häntäkarsinta) Random Drop (Satunnaiskarsinta) Random Early Detection (Ennakoiva satunnaiskarsinta) Weighted Fair Queueing (Reilujonotus) 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 40
Tail Drop Tail Drop eli häntäkarsinta on yksinkertaisin puskurinhallintamekanismi. Siinä rajallinen puskuri, jota palvellaan FIFOperiaatteella, ylivuotaa pitäen siten liikenteen kurissa. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 41 Tail Dropin ongelmia Pienellä puskurilla: TCP:llä hankaluuksia päästä slow-startista Heikko vaste verkon transienteille Suurella puskurilla: Reaaliaikaiselle liikenteelle kohtuuttoman suuri viive Verkossa ei etene hetken päästä ollenkaan liikennettä, mikäli linkin nopeus on pieni. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 42
Tail Dropin ongelmia Globaali synkronisaatio seuraa siitä, että jonon täyttyessä kaikki yhteydet kokevat pakettihukkaa miltei yhtäaikaisesti ja joutuvat siten slow startiin. Selkeä painotus tasaiselle liikenteelle, koska jonon ollessa kasvussa todennäköisyys, että purskeiselle yhteydelle riittää puskurikapasiteettia pienenee. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 43 Random Drop Perustuu olettamukseen, että paketti, joka valitaan satunnaisesti kuuluu lähteelle N todennäköisyydellä, joka on suoraan verrannollinen lähteen keskinopeuteen. Paketti valitaan tällä kertaa koko jonosta tasajakaumaan perustuvulla satunnaisprosessilla. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 44
Random Drop Voidaan käyttää sekä ruuhkaa ennakoivana että ruuhkaan reagoivana menetelmänä. Reagointi perustuu paketin karsintaan jokaisen uuden paketin saapuessa Ennakoinnissa jokainen tuleva paketti aiheuttaa karsintatodennäköisyyden laskemisen ja sen perusteella toimimisen. 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 45 Random Early Detection REDissä hyödynnetään puskurin keskimääräistä tilaa karsinta todennäköisyyden laskemiseen. Keskimääräinen puskurin täyttöaste lasketaan keskiarvo-suodattimella Max Min avg q ( ) avg t t 1 t 1 avg 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 46
REDin edut Ei aiheuta globaalia synkronoitumista Toiminta perustuu eston havainnointiin jo ennen kuin sitä edes esiintyy. Takaa puskuriin kapasiteettia purkeiden varalle Purskeen todennäköisyys tulla karsituksi ei kasva lineaarisesti; sillä purske ei aikaansaa keskiarvon välitöntä nousua (EWMA). 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 47 Fair Queuing Menetelmä, jossa ryhmälle yhteyksiä muodostetaan rinnakkaiset jonot Nämä rinnakkaiset jonot ovat tietyssä mielessä autonomisia, eli niillä ei ole suoraa interaktiota keskenään 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 48
Fair Queuing metodit Palvelua jaetaan kiertävällä periaattella perustuen: Tasapuolisesti» Paketti kerrallaan» Bitti kerrallaan Painotetusti» Paketti kerrallaan» Bitti kerrallaan 13.10.1999 S-38.188 Tietoliikenneverkot / Marko Luoma 49