Tjenestekvalitet

Innen telekommunikasjonsnettverk brukes begrepet servicekvalitet eller mer enkelt QoS (fra engelsk Quality of Service ) for å indikere parameterne som brukes for å karakterisere kvaliteten på tjenesten som tilbys av nettverket (for eksempel pakketap , forsinkelse ) , eller verktøyene eller teknikkene for å oppnå ønsket kvalitet på tjenesten.

Kvaliteten på tjenesten er normalt negativt korrelert med trafikken som tilbys til nettverket, og positivt med ressursene som brukes til å bygge og administrere nettverket.

Trafikken som tilbys til nettverket og intervensjon av funksjonsfeil er vanligvis modellert som stokastiske prosesser : Følgelig er parametrene som brukes for å karakterisere kvaliteten på tjenesten vanligvis tilfeldige variabler .

Når en tjenestekontrakt gir parametre for tjenestekvalitet, med tilhørende straffer hvis disse parametrene ikke respekteres, snakker vi om SLA eller Service Level Agreement .

Beskrivelse

Telefoni

Innen telefoni og generelt kretssvitsjing inkluderer tjenestekvaliteten parametere som:

Pakkenettverk

I et pakkenettverk kan en pakke mottatt av en svitsj finne porten som den skal overføres på av en annen pakke i overføring. I dette tilfellet blir den lagret i en bufferkø , og blir derfor utsatt for en køforsinkelse. Hvis køen er full, blir pakken kastet eller tapt.

Parametrene som vanligvis vurderes for et pakkenettverk er:

For ikke-sanntidsapplikasjoner eller tjenester som filoverføring eller videodeling tilfredsstilles noen av disse parameterne (med unntak av forsinkelse og gjennomstrømning) av TCP -nettverksprotokollen som tar seg av ombestillingsforespørselen og feilgjenoppretting på mottatte pakker og videresending av tapte pakker eller pakker som ikke er mottatt på bekostning av en viss behandlingstid. Forsinkelsen og dens variasjon for slike applikasjoner anses ikke som en kritisk parameter, da den tolereres av brukeren som den tiden som er nødvendig for å tilfredsstille hans forespørsel om datainnsamling. Hvis overføringstiden er for lang, har brukeren vanligvis en tendens til å be om en høyere gjennomstrømning som imidlertid bare kan tilfredsstilles av leverandøren gjennom en høyere båndbredde .

På den annen side, for sanntidsapplikasjoner , som voice over IP ( VOIP ) og live audio-video- streaming , blir forsinkelsesparametrene, forsinkelsesvariabiliteten og pakketapet følsomme, noe som henholdsvis innebærer for høye latenstider , jitter som gir opphav til levering utenfor rekkefølge og påfølgende behov for ombestilling med ytterligere behandlingsforsinkelse, og til slutt retransmisjonsforespørsler fra TCP med ytterligere ytterligere forsinkelse. I slike applikasjoner er det derfor å foretrekke å unngå bruken av TCP-protokollen til fordel for den andre UDP -transportprotokollen som ikke kontrollerer overføring eller ikke utfører de ovennevnte funksjonene, på bekostning av noe datatap.

I tillegg til dette kreves det ofte en større garanti på de såkalte tjenestekvalitetsparametrene (QoS) i tilfelle sanntidskommunikasjon som tale og spredning av multimedialyd - video sanntidsinnhold i situasjoner med overbelastning på interne . byttenoder

Applikasjoner som krever QoS

Den originale QoS-modellen av Internett, som ikke er QoS, er egnet for fleksible applikasjoner , som kan fungere selv på nettverk med svært dårlig ytelse, og omvendt bruke all tilgjengelig båndbredde hvis dette er rikelig.

Andre typer tjenester kalles uelastiske , noe som betyr at de krever et visst nivå av båndbredde for å fungere - hvis de får mer, bruker de det ikke, og hvis de får mindre, fungerer de ikke i det hele tatt. Det er disse applikasjonene som gjør det nødvendig å ta skritt for å sikre en viss QoS.

Applikasjoner som krever QoS er for eksempel følgende:

I arbeidssammenheng kan det forekomme at QoS-krav er definert selv for applikasjoner som ikke er iboende elastiske, for å sikre tilstrekkelige produktivitetsnivåer. For eksempel "reisebyråterminalen skal kunne gjennomføre transaksjonen innen 10 s i 98 % av tilfellene". Ofte krever imidlertid et krav av denne typen at man griper inn både på nettverket og på informasjonssystemet som leverer tjenesten (for eksempel å sette opp et tilstrekkelig antall servere).

QoS-mekanismer på Internett

Da Internett ble opprettet , var det ikke noe behov for QoS for applikasjoner. Faktisk følger hele Internett den beste innsatsfilosofien , det vil si at systemet garanterer å gjøre alt for å fullføre en operasjon, men garanterer ikke i det hele tatt at operasjonen vil bli utført, eller på hvilken måte. Selv om IP-protokollen gir 4 bits for typen tjeneste og 3 for forrangen til hver pakke, er disse bitene stort sett ubrukte. Med økningen i antall og typer tjenester og trafikken som tilbys sammenlignet med kapasiteten i nettet, har problemet med tjenestekvalitet begynt å bli viktig og stadig mer vurdert.

Det er i hovedsak to måter å gi kvalitetsgarantier på.

Overprovisioning

Den første metoden, kalt overprovisioning , består i å tilby nettverksressurser (overføring, lagring og prosessering) i overflod, nok til å tilfredsstille den forventede toppetterspørselen , med en betydelig sikkerhetsmargin. En enkel løsning, men noen mener at det i praksis er for dyrt og ikke er aktuelt dersom toppetterspørselen vokser raskere enn forutsatt: det tar alltid tid å ha nye ressurser.

Prioritet

Alternativet er å administrere tilgjengelig båndbredde, og sørge for at pakker som kommer til en nettverksnode ( ruter ) gjennomgår en differensiert behandling eller de som en viss QoS må garanteres får spesialbehandling. For å oppnå dette må to problemer løses:

Klassifisering

De strukturerte metodene for å identifisere trafikken som skal privilegeres er:

Spesielt i små nettverk kan det brukes enklere metoder, som innebærer å manuelt identifisere trafikken som skal prioriteres på ruterne, typisk ved bruk av tilgangskontrolllister (ACL).

Haledipliner

På en ruter som ikke håndhever QoS-policyer, blir pakker overført til utgående porter i den rekkefølgen de ankom. En kødisiplin, eller pakkeplanlegging , består i hovedsak av å administrere for hver port flere utgående køer, der pakker er klassifisert. Kødisiplinen bestemmer i hvilken rekkefølge pakker skal hentes fra de ulike køene.

Eksempler på haledisiplin:

Andre verktøy som brukes til å administrere tilgjengelig båndbredde:

Diskusjon

Markedet har ennå ikke favorisert fremveksten av ende-til-ende QoS-tjenester, det vil si som er i stand til å garantere begrensninger på QoS for en flyt av data som utveksles mellom eksterne brukere. Noen mener at et dumt nettverk som er overdimensjonert, det vil si som tilbyr nok båndbredde for de fleste applikasjoner og det meste av tiden, allerede er den best mulige løsningen økonomisk, og viser liten interesse for å støtte ikke-standardiserte applikasjoner som er i stand til QoS.

Internett har allerede komplekse avtaler mellom tilbydere, og det ser ut til å være liten entusiasme i å støtte QoS gjennom tilkoblinger som involverer nettverk som tilhører forskjellige leverandører, eller om avtaler om policyer som bør støttes for å støtte dem.

QoS-skeptikere indikerer at hvis du slipper for mange pakker på en elastisk tilkobling med lav QoS, er du allerede farlig nær punktet for overbelastning for uelastiske høy-QoS-applikasjoner, siden det ikke lenger er en måte å forkaste ytterligere pakker uten å bryte kontrakter på QoS.-trafikken.

Det er også viktig å understreke at styring av QoS i LTE og WiMAX trådløse aksessnettverk er et tema av primær betydning for spredningen av disse teknologiene. Faktisk har organene som er ansvarlige for å utstede LTE- og WiMAX-spesifikasjonene allerede innlemmet standardmekanismene som er nødvendige for å administrere QoS som tilbys til terminalene.

Generelt sett, som Kotler påpeker, ettersom selskaper finner det vanskeligere å differensiere sine fysiske produkter, tyr de til tjenestedifferensiering, enten det betyr levering til rett tid, bedre og raskere svar på henvendelser eller raskere løsning av klager. De beste tjenesteleverandørene kjenner disse fordelene godt og vet også hvordan de kan skape minneverdige kundeopplevelser. [1]

QoS-problemer med noen teknologier

Følgende egenskaper kan bare brukes på endelige porter , men ikke på servere , ryggrader eller andre porter, som formidler mange samtidige flyter.

IEEE 802.3x flytkontroll er ikke en ekte flytkontroll, men snarere en køkontroll. Et eksempel på IEEE 802.3x-problemer er head of line- blokker . Mange av dagens svitsjer bruker IEEE 802.3x som standard – selv på uplink/backbone-porten.

Sitat fra: Network World, 09/13/99, 'Flow control feedback' : "... Hewlett-Packard påpeker at tjenestekvalitet er en bedre måte å håndtere potensiell overbelastning på, og Cabletron og Nortel bemerker at QoS-funksjoner kan " t fungere ordentlig hvis en bryter sender [IEEE 802.3x] pauserammer ...."

Dette sitatet antyder at QoS og IEEE 802.3x er inkompatible med hverandre.

Merknader

  1. ^ Philip Kotler og Kevin Lane Keller (2016). Marketing Management, 15. utgave, Pearson Education, Harlow.

Bibliografi

Relaterte elementer

Andre prosjekter

Eksterne lenker