Verkkoarkkitehtuurien suunnittelu ei ole pelkästään kapasiteetin mitoittamista ja teknologioiden valintaa. Ajoittain on mentävä syvemmälle – kirjaimellisesti muutama jalka pintaa syvemmälle. Tästä ajattelusta myös nimi 5Feet Networks on syntynyt. Tämä syvyys on kriittistä erityisesti kahdessa muutoksen vaiheessa:
a) ennen verkon muutoksia (oikean ongelman tunnistaminen)
b) verkon muutosten jälkeen (vaikutusten varmistaminen ja optimointi).
Ilman tätä näkymää on riski, että ratkaistaan väärä ongelma – tai pahimmillaan investoidaan kapasiteettiin, joka ei paranna käyttäjäkokemusta. Tässä kirjoituksessa tarkastellaan yhtä tyypillistä modernin verkon ilmiötä: TCP-retransmission (uudelleen lähettäminen) ja miksi ne eivät aina tarkoita sitä, mitä usein oletetaan.
Havainto: retransmissio kasvavat, mutta kapasiteetti ei ole ongelma
Analytiikka osoitti merkittävän määrän TCP-retransmission. Tämä tarkoittaa, että lähettävä osapuoli ei saa kuittausta (ACK) vastaanottajalta odotetusti ja lähettää dataa uudelleen. Luonteva ensireaktio on epäillä:
- kapasiteettipulaa
- runkoverkon pullonkauloja tai mtu
- reitittimien tai palomuurien packet droppeja
Syvempi analyysi kuitenkin osoitti:
- ei merkittävää packet lossia infrastruktuuritasolla
- liikennemäärät olivat maltillisia
- ei viitteitä saturaatiosta
On syytä huomioida, että vaikka infrastruktuurin (laitteiden) counterit näyttävät puhtailta, mikrohäviötä voi silti esiintyä, erityisesti langattomassa verkossa tai puskurikäyttäytymisessä, ilman että se näkyy IP-tason droppina laitteissa.
Toisin sanoen: verkko ei ollut täynnä.
TCP:n toimintalogiikka on muuttunut
Keskeinen selitys löytyy protokollatasolta. Perinteisessä TCP:ssä retransmission käynnistyivät pääasiassa:
- timeoutin (RTO) jälkeen
- useiden duplicate ACK -viestien perusteella
Tämä teki TCP:stä varovaisen – uudelleenlähetys tapahtui vasta, kun häviö oli todennäköinen.
Modernit toteutukset (RACK, TLP) sekä QUIC toimivat eri tavalla:
- häviötä päätellään aikaperusteisesti (RTT)
- retransmissiot käynnistyvät ennakoivasti
- reagointi on aggressiivisempaa
Tämän seurauksena retransmissioita voi tapahtua myös ilman todellista paketinhäviötä.
Näitä kutsutaan spurious retransmissioiksi. On kuitenkin tärkeää huomioida, että kaikki retransmissiot eivät ole spurious – erityisesti WLAN-ympäristössä osa uudelleenlähetyksistä on täysin perusteltuja.
Mitä perinteinen TCP olisi tehnyt?
- odottanut pidempään ennen retransmissiota
- sietänyt paremmin pieniä viivevaihteluita
- reagoinut hitaammin
Seurauksena: vähemmän retransmissioita, mutta mahdollisesti merkittävästi korkeampi vasteaika
Modernit protokollat tekevät päinvastoin: ne optimoivat käyttäjäkokemusta, mutta paljastavat verkon laatuongelmat herkemmin
Todellinen juurisyy: kokonaisuuden laatu, ei kapasiteetti
Kun infrastruktuurin packet drop suljettiin pois, huomio siirtyi lähemmäs käyttäjää – päätelaitteisiin ja langattomaan verkkoon.
Analyysi osoitti merkittäviä uudelleenlähetyksiä jo WLAN-tasolla (WiFi retryt), mikä aiheuttaa:
- jitteriä (viivevaihtelua)
- pakettien viivästymistä
- pakettien uudelleenjärjestymistä
Modernit TCP- ja QUIC-algoritmit tulkitsevat nämä tilanteet helposti paketinhäviöksi – ja reagoivat retransmissioilla.
Verkon liikenneprofiili on muuttunut
Kyse ei ole yksittäisestä poikkeamasta, vaan pysyvästä muutoksesta:
- liikenne kohdistuu suurelta osin pilvipalveluihin ja CDN-verkkoihin
- sovellukset käyttävät aggressiivisia kuljetusprotokollia
- päätelaitteiden ja WLANin rooli korostuu
Samalla liikenne on piikikästä (bursty), viiveherkkää ja hajautunutta
Tässä ympäristössä verkon kokonaisuuden laatu on tärkeämpää kuin kapasiteetti. Sama verkko voi toimia täydellisesti lyhyen latenssin yhteyksissä (esim. paikalliseen konesaliin), mutta silti aiheuttaa ongelmia pilviliikenteessä. Lyhyt latenssi peittää ongelmat – pitkä latenssi paljastaa ne.
Miksi kapasiteetin lisääminen ei auta?
Kapasiteetin kasvattaminen auttaa vain, jos ongelma on läpäisykyvyssä.
Tässä tapauksessa ongelma syntyy: ennen runkoverkkoa, radioverkossa sekä viivevaihtelussa
Lisäkaista pahimmillaan peittää oireet, mutta ei:
- poista jitteriä
- vähennä WLAN retryjä (frame uudelleen lähetäminen layer 1 tasolla)
- estä pakettien uudelleenjärjestymistä
Mitä pitäisi tehdä?
Oikea lähestymistapa ei ole yksittäinen tekninen ratkaisu, vaan kokonaisuuden ymmärtäminen.
Ensimmäinen vaihe on tunnistaa, missä kohtaa verkkoa ilmiö syntyy – ei missä se näkyy. Tämä edellyttää näkyvyyttä päätelaitteista sovellustasolle. Toinen vaihe on varmistaa paikallisverkon tasalaatuinen toiminta. Modernissa ympäristössä erityisesti WLANin merkitys korostuu, ja pienetkin häiriöt voivat näkyä suoraan käyttäjäkokemuksessa. Vasta tämän jälkeen voidaan arvioida, tarvitaanko liikenteen hallintaa tai muita optimointikeinoja.
Ilman juurisyyn tunnistamista organisaatio voi:
- tehdä vääriä investointipäätöksiä
- kasvattaa kustannuksia ilman hyötyä
- jättää käyttäjäkokemuksen ongelmat ratkaisematta
Oikein kohdennettu analyysi puolestaan tunnistaa todellisen juurisyyn, ohjaa investoinnit oikein sekä parantaa suoraan loppukäyttäjäkokemusta.
Yhteenveto
TCP-retransmissiot eivät ole ongelma – ne ovat oire.
Tässä tapauksessa ne johtivat pääosin:
- WLAN-verkon airtime kilpailusta
- Optmoimattomien polkujen aiheuttamasta jitteristä
- modernien TCP/QUIC-algoritmien toiminnasta kahden edellisen kanssa
Ja ennen kaikkea: kapasiteetin lisääminen ei ratkaise ongelmaa, jos ongelma on laadussa
Moderni verkko vaatii modernin analyysin. Pintatasolla kaikki voi näyttää hyvältä, Mutta vasta, kun mennään muutama jalka syvemmälle, nähdään mitä oikeasti tapahtuu. Ja vasta silloin voidaan tehdä päätöksiä, jotka oikeasti vaikuttavat.
Entä tilanteet, joissa verkkoa ei voida korjata?
On kuitenkin tärkeää huomioida, että kaikissa ympäristöissä verkon laatua ei voida suoraan parantaa (tai siihen ei ole kontrollia asiakkaalla). Tällaisia tilanteita ovat esimerkiksi satelliittiyhteydet, mobiiliverkot (LTE/5G), korkean latenssin WAN-yhteydet
ympäristöt, joissa käytössä on vain yksi epävakaa linkki jne. Näissä tapauksissa ongelman juurisyy – viive, jitter tai häviö – ei ole organisaation suoraan hallittavissa.
Tällöin vaihtoehtoinen lähestymistapa on optimoida itse kuljetusprotokollan toimintaa. Tämä voidaan toteuttaa esimerkiksi TCP-optimoinnilla tai proxy-ratkaisuilla, joissa yhteys jaetaan osiin (ns. split TCP) ja uudelleenlähetykset sekä kuittaukset käsitellään lähempänä käyttäjää. On kuitenkin keskeistä ymmärtää, että tällaiset ratkaisut eivät poista varsinaista verkon laatuongelmaa, vaan kompensoivat sitä.
Jos verkko näyttää toimivan, mutta käyttäjät kokevat ongelmia – on aika katsoa pintaa syvemmälle.
Hannu Rokka, Senior Network Advisor
5Feet Networks Oy