Forvaltning av multimedia tjenestekvalitet

Anders Andersen

Høsten 1995

Sammendrag

Denne presentasjonen tar for seg forvaltning av tjenestekvalitet i multimediasystemer, og da spesielt i distribuerte multimediasystemer. Vi vil legge hovedvekten på det arbeidet som er gjort innenfor forhandling av tjenestekvalitet.

Vi vil først komme inn på hva tjenestekvalitet konkret er, og berøre noen av problemstillingene omkring dette. Vi kommer så til å presentere noen konkrete forsøk på å lage systemer med mulighet for å forhandle om tjenestekvalitet. Til slutt vil vi forsøke å diskutere disse løsningene og andre muligheter.

Innhold

Hva er tjenestekvalitet?
Forvaltning av tjenestekvalitet
Kompilserende faktorer
Kategorier av tjenestekvalitetsparametre
Begrensninger

Forhandling av tjenestekvalitet
QoS Broker
Andre

Konklusjon

Referanser

Hva er tjenestekvalitet?

 Før vi kan begynne å ta for oss problemstillinger omkring tjenestekvalitet, så må vi finne en avklaring på hva vi mener med dette begrepet. I "Distributed Multimedia and QOS: A Survey" (Vogel, Kerhervé, von Bochmann og Gecsei) [1] foreslås følgende definisjon:
Tjenestekvalitet representerer det sett av kvantitative og kvalitative karakteristikker til et distribuert multimediasystem som er nødvendig for å oppnå ønsket funksjonalitet til en applikasjon.
Tjenestekvalitetsparametrene skiller seg fra andre parametre ved at de kan forhandles mellom systemkomponentene.

Forvaltning av tjenestekvalitet

 Bruker eller applikasjon stiller krav til tjenestekvalitet. En bruker vil typisk kunne stille krav om kavalitet på bilde (oppløsning, farger), lyd (stereo/mono, telefon-/cd-kvalitet), leppesynkronisering (merkbar forskyving mellom bilde og lyd), responstid og ressursforbruk.

Denne type parametre må mappes til konkrete systemkrav eller tjenestekvalitetsparametre til ulike systemkomponenter på ulike nivå. Krav fra bruker om oppløsning i bilde til en videostrøm vil kreve en gitt båndbredde for overføring av denne.

Ut i fra tjenestekvalitetsparametrene til de ulike systemkomponentene kan det foretas en forhandling om de ressursene som kreves. For å gjennomføre en slik forhandling trenger vi protokoller som de ulike komponentene kan forstå å gi respons på.

Kompilserende faktorer

En del omstendigheter kompliserer modellen som er beskrevet ovenfor. Under forhandling er det viktig å være klar over at de ulike tjenestekvalitestparametrene ikke er uavhengig av hverandre. Ulike krav kan komme i konflikt med hverandre, og dette må det tas hensyn til når disse forvaltes.

En tjenestekvalitetsparameter trenger ikke å være en gitt verdi. Den kan være angitt som et akseptabelt verdiområde eller med en gitt sansynlighet over et tidsrom.

Ulik last og feil i systemet kan påvirke tjenestekvalitetsparametrene. Det er derfor også viktig å kunne monitorere om de ulike tjeneste oppfyller kravene, og eventuelt kunne gjøre noe hvis så ikke er tilfelle.

Etter at vi har fått forhandlet frem tildeling av ressurser slik at gitte tjenestekvalitetskrav i et ende til ende system oppfylles, så kan endringer som ny last eller feiling i systemet føre til at tjenestekvalitetskravene med reforhandles.

Kategorier av tjenestekvalitetsparametre

Vi kan skille mellom 5 kategorier av tjenestekvalitet [1]: Ytelsesparametre vil typisk være parametre som ende til endeforsinkelse og bitrate. Format beskriver ting som video-oppløsning, lagringsformat og komprimeringsskjema. Synkronisering tar for seg `skew' og `jitter'. Kostanad er priser på oppkobling, dataoverføring og prosessering. Brukerparametre beskriver brukers subjektive oppfattelse av kvalitet på for eksempel lyd og bilde.

Begrensninger

 Omgivelsene kan sette begrensninger både på verdier og typer av tjenestekvalitetsparametre som kan settes. Systemkomponenter som operativsystem og kommunikasjonsprotokoll kan mangle muligheter for å gi garantier eller spesifikt tildele ressurser. Et operativsystem som ikke har reelltid skedulering av prosesser kan ikke støtte opp om applikasjoner som har behov for dette. Kommunikasjonsprotokoller som kun tilbyr best mulig kvalitet på overføringen kan ikke gi sikre garantier for overføring av en video- eller lydstrøm.

Også på applikasjonsnivået kan vi ha slike begrensninger. En tjener kan mangle muligheter til å oppfylle sikre garantier, eller muligheten til å kode data på et format som støtter et gitt format. Den databasen som benyttes kan mangle mekanismer for dette.

For å få til et system med muligheter for å garantere tjenestekvalitet, så må den underliggende systemet på en eller annen måte støtte opp under det. Vi må altså har transportprotokoller, prosesskedulering, i/o håndtering og tjenerapplikasjoner som kan håndtere data med tjenestekvalitetskrav.

Forhandling av tjenestekvalitet

Forvaltning av tjenestekvalitet er i litteraturen stort sett rettet mot forvaltning av nettressurser. Forvaltning av andre ressurser, som prosessering, lager og i/o er nødvendig i et komplett multimediasystem.

I "The QOS Broker" (Nahrstedt og Smith) [2] presenteres en løsning for forvaltning av ende til ende tjenestekvalitet i et distribuert multimediasystem gjennom forhandling. I "On Distributed Multimedia Presentational Applications: Functional and Computational Architecture and QoS Negoation" (Kerherve, Vogel, von Bochmann, Dssouli, Gecsei og Hafid) [3] presenteres et tjenestekvalitetsgrensesnitt for å håndtere forhandlingen av tjenestekvalitet på en generisk måte. I "A Qualtity of Service Architecture" (Campbell, Coulson, Hutchison) [4] presenteres et rammeverk som støtter opp om forvaltning av tjenestekvalitet i alle nivå i arkitekturen.

Vi kommer her til å konsentrere oss mest om den arbeidet som har kommet lengst med et system for forhandlig av tjenestekvalitet. Her har man valgt å lage en tjenestekvalitetes mekler.

QoS Mekler

Kommunikasjon er kun en av ressursene som en nettapplikasjon trenger. Operativsystemressurser og i/o utstyr må også forvaltes slik at vi kan knytte en gitt kvalitet til disse tjenestene. [2] foreslår en samlet orkestrering av nett-, operativsystem- og i/o-ressurser. Dette gjøres i en QoS mekler (QOS Broker).

QoS meklerens oppgave er å finne en balanse mellom applikasjonens behov og de ulike tjenestene som er tilgjengelig. Det vil si å balansere ressursene i endepunktene (1 og 3) og i nettet (2).

Endepunkt
I hvert endepunkt har vi en QoS mekler. Operativsystemet er delt opp i et system og et bruker område for henholdsvis system- og applikasjonsfunksjoner. En del av mekleren er i system området, og en del er i bruker området.

Applikasjonssubsystemet tar seg av

Transportsubsystemet tar seg av Alle ressursbehov beskrives med tjenestekvalitetsparametre: QoS mekleren er altså en ressursforvalter i endepunktene. For å opprette en ende til ende tjeneste må den lokale QoS mekleren orkestrere nødvendige ressurser i applikasjons- og transportsubsystemet lokalt, og forhandle med nettressursforvalteren og den andre (fjerne) QoS mekleren.
Kjøper og selger
En QoS mekler kan enten være en kjøper eller en selger. En kjøper er et endepunkt som ønsker å reservere ressurser fra andre fjerne endepunkt (maskiner) i det nettbaserte multimediasystemet. En selger er et endepunkt som tilbyr ressurser til salgs. Det er alltid kjøper som tar initsiativet. Kjøper må altså og selger må

Avsender eller mottaker
Vi deler meklerkommuniksjonen i avsender eller mottaker. Avsender er ansvarlig for ressursene ved utgående kall og forbindelser og mottaker er ansvarlig ved inngående kall og forbindelser. Dette gir oss to operasjonsmodi, sender inisiert eller mottaker inisiert mekling.

Ved sender inisiert mekling er kjøper avsenderen som spør etter ressurser fra mottaker som er en selger. Eksempler på dette kan være en forelesning over nettet eller kontroll og styring av et fjerntliggende videokamera.

Ved mottaker inisiert mekling er kjøper en mottaker som spør etter ressurser fra avsender som er en selger. `Video on Demand' er et typisk eksempel på en slik applikasjon.

Avsender forvalter ressurser for utgående forbindelser og input fra kilde, mens mottaker forvalter ressurser for inngående forbindelser og output til rett plass. Både avsender og mottaker har en selger- og kjøperprotokoll som aktiviseres avhengig av hvem som inisierer ressursmeklingen. Applikasjonssubsystemet orkestrerer ressurser i brukerområdet. Transportsubsystemet forvalter ressurser delt av de lavere lagene i protokollstacken.

Konklusjon
QoS mekleren er et godt steg i riktig retning for forhandling av tjenestekvalitet. Mekleren har mekanismer for å forhandle med operativsystem og nettressursforvaltere. Disse mekanismene skal kunne håndtere nyere operativsystem og protokoller med bedre støtte for multimedia. Erfaringer med komplekse applikasjonskrav er mangelfull. Prototypen har vært testet med en telerobotapplikasjon hvor en arm styres, og brukeren får tilbakemelding med motstand/bevegelse, bilde og lyd.

Andre
En RM ODP basert tilnærming
I [3] presenteres en arkitektur innenfor rammeverket til `Reference Model of Open Distributed Processing (RM ODP)' [5].

I dette prosjektet fokuseres det på distribuerte multimedia presentasjonsapplikasjoner. Med utgangspunkt i QoS mekleren betyr det at kjøper kun er mottaker, og selger kun er avsender. Some en eksempelapplikasjon benyttes en `news-on-demand' tjeneste.

For en distribuert multimedia presentasjonsapplikasjon identifiseres det to hovedobjekter, en tjener som inneholder multimediadokumentene, og en klient som tilbys aksess til tjenerens dokumenter. Disse tilsvarer to endepunkt i QoS mekleren beskrevet ovenfor. Klienten er en kjøper og mottaker, og tjeneren er en selger og avsender.

Tjenestekvalitetsarkitekturen introduserer en klient, en tjener og et transportsystem. Som med QoS mekleren har vi tre deltakere i tjenestekvalitetsforhandligen: hos klienten og tjeneren (endepunktene) har vi lokal tjenestekvalitetsforhandling, og klienten eller tjeneren forhandler med transporttjenesten om tjenestekvalitet for forbindelsen. Denne løsningen er mindre fleksibel på den måten at den kun tilbyr løsninger for distribuerte multimedia presentasjonsapplikasjoner. På brukernivået spesifisers tjenstekvalitetsparametre som verdier som bruker skal kunne kjenne og forstå (for eksempel CD eller telefon lydkvalitet). Disse mappes så til parametre til de ulike tjenestekvalitetsgrensesnittene i arkitekturen. Det ser ut til å være vanskelig å lage algoritmer for mappingen av enkelte av disse parametrene.

QOS-A
QOS-A [4] er en lagdelt arkitektur med tjenester og mekanismer for tjenestekvalitesforvaltning og kontinuerlige media flytkontroll i et multitjenestenett.

En flyt beskriver produksjon, overføring og eventuelt forbruk av en enkelt strøm som en integrert aktivitet styrt av et enkelt tjenestekvalitetsuttrykk. En flyt kan være simplex, unicast eller multicast, og inkluderer både kontinuerlige media og kontroll.

QOS-A består av følgende lag:

Distribuert applikasjonsplatform:
Tjenester for å tilby multimediakommunikasjon og tjenestekvalitetskonfigurering i en objektbasert omgivelse.

Orkestreringslaget:
Tilbyr tjenester for multimediasynkronisering.

Transportlaget:
Tilbyr et sett av ulike tjenestekvalitetskonfigurerbare protokoller.
Disse er igjen delt opp i følgende plan:
Protokollplan:
Består igjen av et brukerplan og et kontrollplan. I brukerplanet har vi simplex flyt med høy gjennomstrømmning. I kontrollplanet er lav forsinkelse viktig. Her er også muligheter for duplex kommunikasjon.

Tjenestekvalitete vedlikeholdplan:
Lagspesifikke tjenestekvalitetsforvaltere som driver med finkornet monitorering og vedlikehold av sine respektive protokollenheter (de ulike lagene).

Flytforvaltningsplan:
Ansvarlig for opprettelse av flyt (tilgjengelighetskontroll, ressursreservering, tjenestekvalitetsbasert ruting), reforhandling av tjenestekvalitet, mapping av tjenestekvalitetsparametre mellom de ulike lagene og godkjenning av tjenestekvalitet (tar opp i seg valgt tjenestekvalitet).
QOS-A arkitekturen tar seg først og fremst av forvaltning av tjenestekvalitet i nettkomponentene. Det ser ut til at det er utviklet en god forståelse av oppgavene til de ulike lag og plan i modellen. Det skal ifølge litteraturen finnes en eksperimentel omgivelse basert på et ATM nett og 486 PC'er med operativsystemet Chorus [6].

Konklusjon

 QoS-A [4] hånterer først og fremst kommunikasjonsdelen av tjenestekvalitetsforvaltningen. En omgivelse for etablering av ende til ende tjenestekvalitet inkluder andre ressurser omfattes ikke av arkitekturen. I [3] tas også denne type ressurser med, men vi ser kun på presentasjonsapplikasjoner. Modellen er spesielt tilpasset dette slik at endepunktene enten er en tjener eller en klient. QoS mekleren [2] har ikke disse begrensningene, men her er noe usikkerhet om hvordan systemet håndterer mer komplekse applikasjonskrav.

Referanser
  1. A. Vogel, B. Kerhervé, G. von Bochmann og J. Gecsei, Distributed Multimedia and QOS: A Survey, IEEE Multimedia, Summer 1995.

  2. K. Nahrstedt og J. M. Smith, The QOS Broker, IEEE Multimedia, Spring 1995.

  3. B. Kerherve, A. Vogel, G. von Bochmann, R. Dssouli, J. Gecsei og A. Hafid, On Distributed Multimedia Presentational Applications: Functional and Computational Architecture and QoS Negoation, Proc. 4th Int. Workshop on Protocols for for Highspeed Networks, London, 1994.

  4. A. Campbell, G. Coulson og D. Hutchison, A Quality of Service Architecture, MPG-94-08, Lancaster University, 1994.

  5. K. raymond, The Reference Model of Open Distributed Processing: A Tutorial, Proc. 1st Int. Conf. on ODP, Berlin, 1993.

  6. G. Coulson, G. S. Blair, P. Robin aog D. Shepherd, Extending the Chorus Micro-Kernel to Support Continuos Media Applications, Proc. 4th Int. Workshop on Network and Operating System Support for Digital Audio and Video, Lancaster, 1993.