Luku 10 TCP/IP Performance over Asymmetric Networks
Langattomien verkkojen suorituskyky-seminaari
Pertti Salo 2008Asymmetrinen tekniikkaTekniikka on asymmetrinen, kun tietovirta keskuksesta tilaajalle päin on suurempi kuin päinvastoin
Verkon ominaisuudet yhteen suuntaan ovat erilaiset kuin toiseen suuntaan
Upstream kaistanleveys on usein rajoitettu asiakkaan suunnasta, verrattuna downstream kaistanleveyteen asiakkaan suuntaan
Verkko asymmetria voi vaikuttaa TCP:n suorituskykyyn, vaikka verkkolähde datavirran suunnassa on ilman ruuhkaa, ruuhka toiseen suuntaan voi häiritä feedback virtaa.
Uplink ja Downlink
Kaistanleveys asymmetria
Kahden tyyppisiä tilanteita syntyy yksisuuntaisessa liikenteessä verkoissa: kun vastakkaisessa pullonkaula linkissä on riittävästi jonotusta estämään paketti(ACK) hävikit, tai kun vastakkaisessa pullonkaula linkissä on pieni puskuri.
Jos vastaanotin tunnistaa säännöllisesti enemmän kuin yhden ACK:n jokaista k = 8 data pakettia kohden, vastakkainen pullonkaulalinkki täyttyy ennen kuin asiakkaan suuntainen pullonkaula- linkki, rajoittaen throughputtia asiakkaan suuntaan.
Rajoitettu vastakkainen kaistanleveys ja jonotus vastakkaisessa pullonkaula reitittimessä muuttaa ACK:ien väliä jonka havaitsee lähettäjä. Kun ACK:it saapuvat pullonkaulalinkkiin vastakkaiseen suuntaan nopeammin kuin linkki voi tukea, ne jonoutuvat toistensa taakse.
Erilainen tilanne syntyy kun vastakkaisessa pullonkaulalinkissä on suhteellisen pieni puskuritila ACK:ja varten. Kun siirtoikkuna kasvaa jono täyttyy ja ACK:t putoavat liikenteestä.
Heikentyneelle suorituskyvylle on kolme syytä tässä tapauksessa koska ACK:t ovat epäsäännöllisiä.
1. Ensinnäkin, lähettäjä lähettää dataa suurina purskeina. Jos lähettäjä vastaanottaa vain yhden ACK:n k pakettia kohti, se lähettää dataa k:n suuruisina purskeina (tai enemmän) segmenteissä, koska jokainen ACK siirtää sliding windowta vähintään k (tunnistettua) segmentin verran. Tämä lisää datahävikin todennäköisyyttä, koska reitittimet eivät käsittele suuria pakettipurskeita kovin hyvin.
2. Toiseksi TCP lähetinsovellukset lisäävät niiden ruuhkautumisikkunaa laskemalla ACK:iden lukumäärän, jonka ne vastaanottavat mutta eivät sitä kuinka paljon dataa tunnistetaan ACK:ta kohti. Koska pienepi ACK:iden määrä aiheuttaa hitaamman kasvun ruuhkaikkunassa ja se heikentää suorituskykyä pitkien viiveiden yhteyksissä.
3. Kolmanneksi lähettäjän uudelleenlähetys ja elpymisalgoritmit ovat vähemmän tehokkaita kun ACK:t ovat hävinneet.
10.2 Asymmetrian vaikutus TCP:n suorituskykyyn
Yksisuuntainen datasiirtoTavallinen esimerkki on käyttäjä, joka lataa dataa palvelimelta. Rajoitetaan tapaus yksinkertaiseen TCP yhteyteen downstream suuntaan.
Jos vastaanotin lähettää enemmän kuin yhden ACK:n jokaista k datapakettia kohden niin upstream pullonkaulalinkki täyttyy ennen kuin downstream. Tämä pakottaa lähettäjän syöttämään dataa hitaammin kuin optimaalia, joka vähentäen troughputtia.
jos upstream pullonkaula jää ruuhkaiseksi pitkäksi aikaa, vastaava puskuri täyttyy, aiheuttaen ACK:ien putoamisen.
keskimäärin vain yksi ACK pääsee läpi jokaista K datapakettia kohti, jotka lähettäjä lähettää, joka voi heikentää suorituskykyä monin tavoin.
Kaistanleveys asymmetrian vaikutus
Ensinnäkin, lähettäjä voi lähettää k määrän paketteja tiettynä aikana, joka lisää datapaketin häviämis-mahdollisuutta, erityisesti kun k on suurempi.
Toiseksi, perinteinen TCP lähettäjän perusruuhkaikkunan kasvu epäsäännöllisessä ACK lähetyksessä johtaa hitaampaan ruuhkaikkunan kasvuun.
lopuksi (the now infrequent) ACKien hävikki muualla verkossa voi aiheuttaa pitkän odotus jakson kun lähettäjä odottaa seuraavan ACK:in saapumista.
Kaksisuuntainen datasiirto
Kirjassa käsitellään tapausta jossa sekä downstream että upstream TCP lähetykset tapahtuvat samanaikaisesti.
Esimerkki tästä on käyttäjä joka lähettää dataa esim sähköposti, kun samalla vastaanottaa toista dataa, esim websivu.
kaksisuuntainen liikenne tehokkaasti lisää kaistanleveys asymmetriaa downstream lähetyksessä.
On myös muita vaikutuksia jotka syntyvät interaktiosta upstream datapakettien ja downstreamin ACK:iden välillä
Erityisesti, edellinen voi nopeasti täyttää upstream puskurin aiheuttaen laajan viiveen ja jälkimmäisen korkean hävikkimäärän
esimerkiksi yksittäinen 1-KB datapaketti upstream siirrossa voi lisätä merkittävän1 sekunnin jonotusviiveen ACK:eille downstream siirrossa
Yhteenvetoyhteenvetona, kaksisuuntainen liikenne pahentaa ongelmia kaistanleveys-symmetrian takia ja vastakkainen vuorovaikutus upstreamliikenteen data- pakettien ja downstream yhteyden ACK:ien välillä.
Media-Access asymmetriaMedia-access asymmetria ilmenee monin tavoin: perussyy on kuitenkin sama – epätasainen pääsy jaettuun mediaan, joka muodostuu hajautetuista päätelaitteista.
Hub-and-spokes mallissa, tukiasemalla on täydellinen tieto ja kontrolli downstream liikenteestä; siksi se kärsii alemmasta MAC overheadista kuin hajautetut päätelaiteet jotka ohjaavat uplinkkiä.
toisaalta 3 G verkossa, päätelaitteet ovat samanarvoisia.
turn-around -viiveen aiheuttama MAC overhead tekee työlääksi siirtää paketteja yhteen suuntaan, kun vastakkaiseen suuntaan on käynnissä oleva datasiirto.
Half-Duplex RadiosKoska siirtovoima alentaa tulevaa vastaanottoa samassa taajuuskaistassa, päätelaitteet verkossa ovat half-duplex, Tämä tarkoittaa, etteivät ne voi samanaikaan lähettää ja vastaanottaa dataa.
H-FDD (Hybrid / Halfduplex FDD) –moodissa uplink ja downlink osat eri taajuuksilla siten, ettei päätelaitteelle allokoida sekä lähetys- että vastaanottovuoroa samanaikaisesti.
Media-Access protokollapäätelaitteet verkossa suorittavat taajuushyppelyä, laajassa spektrissä.
Taajuushyppelyprotokollan ominaisuudet eivät ole relevantteja siirron suorituskykyyn, koska pääasiallinen syy huonoon suorituskykyyn on vuorovaikutus media-access(MAC) protokollan ja TCP:n välillä
Luotettava link-layer protokolla jota käytetään verkossa virhekontrollia varten on yksinkertainen frame-by-frame protokolla,jossa ikkunakoko on1.
kun kehys on vastaanotettu, vastaanotin lähettää link-level ACK:in lähettäjälle.
jos kehys ei ole vastaanotettu onnistuneesti, lähetin lähettää sen timeout jakson jälkeen.
tarve merkittävään turnaround aikaan päätelaitteissa johtaa high-packet overheadiin.
RTS/CTS protokollan vaihtaminen tarvitsee varmistusta kun kohteena oleva päätelaite on muuten kiireinen.
Tämä johtaa laajoihin ja muuttuviin kommunikaatio viiveisiin verkoissa. Lisäksi asymmetriseen työkuormaan useimpien datavirtojen kanssa yhteensuuntaan asiakkaille.
ACK:lla on taipumus ruuhkautua tietyissä laitteissa, kuten asiakkaiden modeemeissa.
Nämä vaihtelevat viiveet ja ACK jonot vaikuttavat pehmeään datavirtaan.
Erityisesti ,TCP ACK liikenne häiritsee datavirtaa ja lisää liikennekuormaa järjestelmässä.
Yleensä,oikea tapa uudelleenlähetysajastimelle on laukaista uudelleenlähetys segmentti tietyn ajan jälkeen joka riippuu sekä round-trip ajasta ja lineaarisesta poikkeamasta.
Linkkikerroksen optimointi, virhekontrolli protokolla joka toimii linkkikerroksen ACK:t datakehyksillä vähentää TCP round-trip vaihtelua jossain määrin.
Liikenne molempiin suuntiin, jopa TCP ACK:ien aiheuttamina, aiheuttaa turnaroundeja. Niinpä jos linkkikerroksen ACK:t toimivat datakehyksillä, muutamia ylimääräisiä päätelaitteiden turnaroundeja voidaan poistaa.
Huolimatta optimoinnista, perusongelma lisäliikenteessä ja taustalla olevissa protokollissa, jotka vaikuttavat round-trip aika arvioihin ja aiheuttavat muuttujia suorituskyvyssä on yhä olemassa.
poikittaiset multiple hops yhteydet langattomissa verkoissa ovat haavoittuvampia tälle vaikutukselle, koska on todennäköisempää että päätelaitteet voivat jo olla sitoutuneina keskusteluun muiden päätelaitteiden kanssa.
10.3 TCP suorituskyvyn parantaminen asymmetrisissä verkoissa
10.3.1 Uplink Bandwidth Management
10.3.2 Handling InfrequentACKs Uplink kaistanleveyden hallinta voidaan suorittaa valvomalla pakkauksen tasoa, taajuutta ja upstream ACK:iden aikataulutusta.
TCP otsikon pakkausTCP otsikkopakkaus kuvaa TCP otsikon pakkausta käytettäessä low-bandwidth linkkejä, jotka käyttävät SLIP tai PPP protokollaa.
Koska se huomattavasti vähentää ACK:iden kokoa uplinkissä kun hävikit ovat epäsäännöllisiä, sen käyttö on suositeltavaa low-bandwidth uplinkeissä jos mahdollista.
TCP otsikkopakkaus ei yksin kata kaikkia ongelmia:
• tietyissä verkoissa on merkittävä per-packet MAC overhead joka on riippumaton paketin koosta.
• ACK:iden koon vähennys ei estä vastakkaista vuorovaikutusta suurien upstream datapakettien kanssa kaksisuuntaisen liikenteen yhteydessä.
• jos halutaan tehokkaasti vaikuttaa suorituskykyongelmiin, joita aiheuttaa asymmetria tarvitaan tekniikkaa over and beyond TCP otsikko pakkauksen.
ACK Filtering(AF)ACK suodatus(AF) on TCP linkkikerros tekniikka joka vähentää TCP ACK:iden lukumäärää joita lähetetään upstream kanavalla.
Haasteena on varmistaa että lähettäjä ei jää odottamaan ACK:eja, joka voi tapahtua jos ACK:ta poistetaan upstream lähteestä. AF poistaa vain tietyt ACK:t näännyttämättä lähettäjää hyödyntämällä siitä tosiasia että TCP ACK:t ovat kumulatiivisia.
Mitä tulee lähettäjän virhekontrolli mekanismiin se informaatio mikä on ACK:ssa with later sequence number subsumes the tiedon joka on sisältynyt aikaisempiin ACK;hin.
Kun ACK vastaanottimesta on menossa jonoon upstream pullonkaula reitittimessä, reititin or the end-host linkki kerroksessa tarkistaa jononsa vanhat ACK:it jotka kuuluvat samaan yhteyteen. Jos niitä löytyy, se poistaa ne jonosta niin vähentäen ACK:iden määrää jotka menevät takaisin lähettäjälle.
Näiden ACK:iden poistaminen vapauttaa puskuritilaa muulle datalle ja ACK paketeille.
AF ei poista duplikaatti tai selective ACK:ia jonosta että vältetään ongelmat TCP:n hävikistä elpymismekanismissa.
ACK congestion control(ACC)ACK ruuhkan hallinta on vaihtoehto ACK suodatukselle joka toimii päästä päähän mielummin kuin upstream pullonkaula reitittimessä.
Avainidea ACC:ssa on laajentaa ruuhkan hallintaa TCP ACK:hin, koska ne muodostavat merkittäviä vaatimuksia resursseihin upstream linkkiin.
ACK:it muodostavat osioita upstream kanavapuskuriin, joiden kapasiteetti on usein rajoitettu tiettyyn lukumäärään paketteja.
ACK:s First Schedulingkaksisuuntaisessa siirrossa data ja ACK paketit kilpailevat resursseista upstream suuntaan.
Tässä tapauksessa yksittäinen FIFO jono sekä datapaketeissa että ACK:issa voi aiheuttaa ongelmia.
esimerkiksi jos upstream kanava on 28.8 Kbps dialup linjalla, 1 –KB-kokoisen paketin siirto voi kestää 280 ms.
Näin ollen jos vain kaksi sellaista datapakettia menevät jonoon ACKien edelle ne sulkevat ACK pois puolen sekunnin ajaksi.
ACK reconstructionACK reconstruction(AR) on tekniikka jolla rekonstruoidaan ACK virtaa joka on kulkenut upstream suuntaan pullonkaulalinkissä.
AR on paikallinen tekniikka joka on suunniteltu estämään vähentynyt ACK:iden määrä joka haitallisesti vaikuttaa TCP lähettäjän sovellusten suorituskykyyn.
Tämä mahdollistaa aikataulujen käytön kuten ACK suodatus tai ACK ruuhkan hallinta vaatimatta, että TCP lähettäjät modifoidaan suorittamaan lähettäjän sovitusta.
Tämän ratkaisun voi Internet Service Provider(ISP) helposti ottaa käyttöön saavuttaakseen hyvän suorituskyvyn.
10.4 Suorituskyvyn parantamis- tekniikoiden kokeellinen arviointi
10.4.1 Experiments with Bandwidth Asymmetry
10.4.2 Experiments with Media-Access Asymmetry
Kaistanleveys asymmetrian kokeetKokeissa käytetään 10-Mbps downlink ja a 28.8 –Kpps uplink with TCP otsikon pakkauksella..
maksimi ikkunakoko on asetettu 120 pakettiin ja jonokoot asetettiin 10 pakettiin.
AF/AR ja AF/SA suoriutuvat parhaiten saavuttaen troughputit 15 – 21 prosenttia paremmin kuin Reno.
ACC/SA suoriutuu 5 prosenttia paremmin kuin Reno.
Tärkeä asia on että purskeisuuden määrä vähenee merkittävästi, koska upstream reititin jono ei ole enää jatkuvasti täynnä AF tai ACC ansiosta.
Taulukko osoittaa, että ACK:iden toistumisen vähentäminen ei ole riittävä ja myös SA ja AR tekniikoiden käyttämistä tarvitaan.
AR johtaa suurempaan round-trip aikaan kuin muut protokollat, mutta tämä johtaa parhaaseen suorituskykyyn näillä parametreillä koska se vähentää hävikkien lukumäärää
yhteenvetona tulokset, osoittavat että SA tai AR ovat tärkeitä selviydyttäessä purskeista jotka on tuloksena hävikkiä tuottavasta ACK virrasta.
ks. dia 32.
Kokeet Media-Access asymmetriallakokeessa käytettiin Ricochet verkon mallia.
työkuorma tässä kokeessa sisältää 100-sekunnin TCP siirron, ilman kilpailevaa liikennettä ja maksimissaan vastaanottimen 32 KB:n ikkunakoolla
ruuhkahävikit ilmenevät tuloksena puskurin ylivuodosta ja johtavat lähettäjän timeoutteihin jos paketteja menetetään siirtoikkunassa.
tutkittuihin protokolliin kuului modifioimaton TCP Reno, Reno with ACC/SA ja Reno with AF/SA
dia 35 osoittaa tulokset kokeesta AF:n ja ACC:n suorituskyky SA:n kanssa on parempi kuin Renon ja AF/SA on parempi kuin ACC/SA
10.6 YhteenvetoVerkkoasymmetria, liittyen kaistanleveyteen, media-accessiin ja loss rateen voi vaikuttaa vakavasti feed-back siirtoprotokollan suorituskykyyn, kuten TCP:hen.
10.9 Case Study: Improving TCP Performance over ADSLVaikka suurin osa WCORP työntekijöistä tekee
töitä toimistossa, jotkut etätyöskentelevät kotonaan yhden
tai kaksi päivää.
Kotona etätyöskentely tarjoaa joustavuutta ja tekee
työnteosta houkuttelevamman.
Aikaisemmin työntekijät käyttivät soittoyhteyttä
Internettiin.
Työntekijät kohtasivat kolme pääasiallista ongelmaa:
pitkät latausajat, epäluotettavat yhteydet,
äänipuhelut eivät toimineet internetyhteydet aikana. Siksi
WCORP siirtyi ADSL:n käyttöön.
WCORP case study
ADSL käytössä todettiin kuitenkin, että sen nopeus oli alhaisempi kuin
ajateltiin ja ruuhkat dataliikenteessä aiheuttivat latausongelmia.
Matalatasoinen throughput johtui ACK ruuhkasta uplinkissä(kotoa
Internettiin) Uplink kapasiteetti todettiin 150 kertaa hitaammaksi kuin
downlink.
TCP lähettäjä ei voinut palvelinpuolella pumpata dataa nopeammin
koska ACK paketit saapuivat hitaasti asiakkaan puolelta.
Ratkaistakseen TCP ongelmat kotikäyttäjillä, WCORP mietti kolmea
tekniikkaa:
TCP otsikko pakkausta, ACK suodatusta ja ACK ruuhkanhallintaa.
TCP otsikkopakkaus valittiin lopulta tekniikaksi.
Kaikki koti TCP/IP.t päivitettiin TCP otsikko pakkauksella, jonka avulla
saatiin merkittävästi vähennettyä ACK pakettien kokoa.
Mittaus osoitti selvää parannusta latausaikoihin.
Latauskapasiteetista voitiin hyödyntää 95 %
Lähteet
Mahbub Hassan, RaJ Jain. High Performance TCP/IP Networking.
www.mit.jyu.fi/arjuvi/opetus/ties422/wimax.ppt 9.5.2008