Slik sikrer du kvaliteten i nettverket

Et tema innen nettverk som blir brennaktuelt med å ta i bruk IP-telefoni, er det som med et fellesnavn kalles tjenestekvalitet – QoS, eller Quality of Service. Det blir ikke enklere når det også er navnet på egne standarder i forskjellige datafamilier – f.eks. er IEEE 802.11e-standarden som definerer QoS i WLAN-standardene 802.11a, .11g og .11n.

Av dette følger også en diskusjon som sier at noe er QoS, annet er det ikke. Problemet er at denne diskusjonen ikke ser ut til å få en konklusjon som kan brukes i praksis – om man inntar en puristisk innstilling, er det selvsagt greit, men markedsførere og teknikere vil likevel suverent kunne definere QoS. I vår sammenheng er vi ikke purister, men oppfordrer heller til en kritisk holdning: Det finnes bra QoS-systemer for datanettverk, og det finnes svake QoS-systemer. Poenget er det er sluttbruken som må avgjøre hvilken QoS som brukes.

Viktig og mindre viktig

Tjenestekvalitet handler i bunn og grunn om prioritering mellom ulike type datainnhold, i forhold til hensyn man vil ta til opphold/treghet i datastrømmen (latency), buffer mot støyforvrenging (jitter buffer), om trafikken er enveis eller toveis (uplink/downlink), båndbredde og sikkerhetskrav. Den enkleste type QoS er i de tilfellene hvor det er mulig å sette opp at visse typer trafikk skal ha forrang foran annen trafikk, som har vært vanlig i f.eks. bredbåndsrutere beregnet for dataspill i årevis. På den andre siden har man løsninger som innebærer store svitsjer hvor trafikk ikke bare kan prioriteres etter type, men også ned til portnivå – at en PC eller et sub-nettverk av klienter skal ha forrang foran andre.

I en nyere bredbåndsruter kan man fint oppleve at man kan innstille QoS på flere steder. Det gjelder f.eks. gjerne valg for å prioritere spill og/eller VoIP foran annen trafikk, eller detaljer rundt forskjellige spill eller forrang for visse applikasjoner. Dette kan også inkludere portbruk, som i denne sammenhengen betegner virtuelle porter i IP-protokollen: F.eks. er port 80 forbeholdt Web-trafikk. Det er også av og til egne avkryssingsbokser for QoS over WLAN-nettverket, som er en fast standard. Det kan også finnes egne QoS-grep for å få datastrømmer til å gli best mulig mellom det indre og eksterne nettverket. Det skal vi se litt nærmere på, etter litt pakketeori.

Pakker, strømmer og flaskehalser

Grunnen til at QoS har allmenn interesse nå, skyldes for en stor grad VoIP og nettverksspill. Opp gjennom Internett sin vekst har vi løst treig datatrafikk med å hive mer båndbredde inn i løsningen. Og dette fungerer så lenge trafikken er den klassiske Web-surfingen, e-post og filoverføring. Imidlertid krever spill at trafikk går lynraskt slik at respons på handling kan overføres – et klart treff på klientsiden må også oppfattes som et treff av nettverksspilltjeneren. Og overføring av lyd, og for den saks skyld video, krever både en jevn strøm av datapakker og minimalt med såkalt pakketap.

For å forsøke å forklare, veldig forenklet: Tenk deg at Internett (eller et vanlig datanettverk) består av en mengde data oppdelt i datapakker som strømmer mellom minst to punkter. Trafikken er todelt, noe går i en strøm hvor det sjekkes at alt går som det skal, og at ingenting faller fra. Faller noen pakker fra, må disse resendes.

Denne strømmen kalles TCP-laget (Transmission Control Protocol). Side- og underordnet dette har vi strømmer som kalles UDP (User Datagram Protocol), som er enklere i den forstand at deres pakker ikke stoppes og kontrolleres, eller resendes hele tiden. Intuitivt ser man at TCP er pålitelig, men går litt i rykk og napp. UDP er jevn og rask, men kan miste pakker.

Veldig forenklet kan vi si at i TCP går alt som kan gå litt tregt, men må være pålitelig: som e-post og filoverføring. I UDP går de dataene som må ga raskt, som tale og bildedata. Går noe galt i nettverket, så mistes pakker. I lyd og taledata blir dette skurr og lyd som forsvinner. I e-post spiller det ingen rolle, fordi pakken som er tapt sendes på nytt. Målet i et nettverk som skal sende lyd- og bildedata av noe kvalitet, er derfor at UDP-strømmen mister minst mulig data, og at den går i en jevn strøm slik at det ikke blir opphold i tale eller lyd – den må prioriteres foran annen trafikk.

Vrient på internett

I selve internett er det vanskelig å få til QoS helt uten videre, siden det eies og styres av mange og ingen. Men kapasiteten og strukturen er slik at alle datastrømmer skal gå raskest mulig mellom avsender og motakerpunkt. Det eneste som kan kontrolleres, er derfor hva som skjer i dette punktet: Og det er lokalnettverket, det være seg i bedriften – eller hjemme hos deg.

En utfordring man kan se, er at nettverk internt går med 100 000 eller 1 000 000 kbps i hastighet, et tall de fleste er mindre opptatt av enn at bredbåndslenken går med 256, 512 eller 1 024 kbps. Men gitt at din samtale i LANet skal ut gjennom noe som er en brøkdel av den indre kapasiteten, så innebærer det trafikkproblemer som bare en flaskehals kan beskrive.

Norsk kvalitetsteknologi

Et av de viktigste trekkene for å få QoS her, er derfor å redusere effekten av denne flaskehalsen. På den ene siden er det en start å si til bredbåndsruteren at VoIP-trafikk skal ha mest plass, men om det er mye trafikk, er ikke dette nok. Det er her ulik tricks som kalles «StreamEnginge»,«Traffic Shaping» o.l. kommer inn, som av QoS-purister ikke er ekte QoS.

Det «StreamEngine» gjør, er å redusere hastigheten på datastrømmen, repakke og ordne datastrømmen i en jevn fart gjennom bredbåndstilkoplingen. Effekten er at gjennomstrømmingen går raskere, fordi pakketapet og dermed resending i TCP-laget er mindre, og kvaliteten på VoIP blir bedre fordi pakketapet i UDP blir mindre eller forsvinner. Å øke gjennomstrømming ved å redusere hastigheten er et kjent fysisk fenomen, i den fysiske verden brukes dette av og til for å redusere kø-problemer. I Oslo er dette bl.a. prøvd i stor skala på Riksvei 4 på vestsida av Groruddalen til Sinsenkrysset.

Dette er én måte å løse denne type kvalitetsutfordringer. Du vil finne en løsning som bruker dette kvalitetsgrepet levert av norske Owera, som leverer dette som brikker i en mengde forskjellige elektroniske enheter. I vår sammenheng vil de finnes bl.a. hos D-Link og TrendNet. Du kan lese mer om deres løsninger på www.owera.com.

Hva må gjøres?

Kjerneutfordringen er i bunn og grunn at om man vil ha god effekt av IP-telefoni, så må grensesnittet mellom det indre nettverket og Internett på begge kanter av et IP-telefonisamband kunne takle QoS på en akseptabel måte. Hvis ikke er det raskt å bli skuffet av hele løsningen, eller bruke masse unødvendig tid på å få noe som aldri blir helt bra, til å virke. Eller til å skjelle ut en eller annen bruker/kundestøtte som ikke kan gjøre mirakler med datastrømmer. Dersom man i tillegg bruker litt tid på å faktisk prioritere hva som er viktig i det indre nettverket, inkludert å prioritere ned, så får man mer nytte og glede av det indre nettverket.

Så er spørsmålet om dette innebærer at man må kjøpe nytt nettverksutstyr og bredbåndsruter. Det gjør det ikke, fordi det er behovet for sluttbruker som må avgjøre. Og da kan det fint hende at regelsettet for applikasjonsprioritering er tilstrekkelig, eller at en egen tjenerboks med Linux og litt fri programvare kan gjøre jobben. Men om det er en stund siden utstyret ble kjøpt, kan gevinstene i bedre kvalitet for nye tjenester suppleres med at nyere nettverksutstyr gjerne også er forbedret på andre måter også.

Til slutt, for den som har drevet med nettverk en stund, kan vi gjerne legge til at det er lov å tenke «Token Ring». Svært mange av teknikkene og standardene som nå tas i bruk her, fikser på Ethernet-protokollen slik at den likner Token Ring-standarden som signaliseringsstandard for datanettverk. Men den gang i de store datanettverkene sin ungdom var det enkelt og billig som gjaldt, ikke dyrt og sofistikert – og derfor ble Token Ring knust...