Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Versjon 2.0 / 01.11.03 Multimedia7-1 Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim.

Liknende presentasjoner


Presentasjon om: "Versjon 2.0 / 01.11.03 Multimedia7-1 Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim."— Utskrift av presentasjonen:

1 Versjon 2.0 / Multimedia7-1 Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, Slides adapted from the slides accompanying the book of Kurose & Ross. © J.F Kurose and K.W. Ross, All Rights Reserved Norsk versjon: © Christian F Heide, 2004.

2 Versjon 2.0 / Multimedia7-2 Multimedia og tjenestekvalitet: hva er det? Multimediaapplikasjoner: nettverks audio og video (“kontinuerlige medier”) nettet tilbyr applikasjonen en ytelse som er nødvendig for at applikasjonen kan fungere QoS

3 Versjon 2.0 / Multimedia7-3 Kapittel 7: Mål Prinsipper r Klassifisere multimediaapplikasjoner r Identifisere nettverkstjenestene applikasjonen trenger r Få mest mulig ut av “best-effort” tjenesten r Mekanismer for å tilby tjenestekvalitet (QoS) Protokoller og arkitekturer r Spesifikke protokoller for “best-effort” r Arkitekturer for tjenstekvalitet

4 Versjon 2.0 / Multimedia7-4 Kapittel 7 - oversikt r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

5 Versjon 2.0 / Multimedia7-5 MM nettverksapplikasjoner Grunnleggende karakteristika: r Typisk følsom for forsinkelser m ende-til-ende forsinkelse m jitter r Tapstolerant: ikke altfor hyppige tap gir liten innvirkning på opplevd kvalitet r komplementært av f eks filoverføring som tåler forsinkelse og jitter, men ikke tap Klasser av MM applikasjoner: 1) Streaming av lagret audio og video 2) Streaming av live audio og video 3) Sanntids interaktiv audio og video Jitter er variasjonen i pakkeforsinkelse i samme pakkestrøm

6 Versjon 2.0 / Multimedia7-6 Streaming av lagret multimedia Streaming: r media lagres hos sender r sendes til klient r streaming: klient starter avspillingen før alle data har ankommet r tidsbegrensning for data som skal sendes: må ankomme mottager i tide til å bli avspilt til riktig tid

7 Versjon 2.0 / Multimedia7-7 Streaming av lagret multimedia: hva er det? 1. video innspilt 2. video sendt 3. video mottatt, avspilt hos klient Kumulative data streaming: på dette tidspunkt vil klienten spille av begynnelsen av videoen mens server fortsatt sender de siste deler av videoen nettverks- forsinkelse tid

8 Versjon 2.0 / Multimedia7-8 Streaming av lagret multimedia: interaktivitet r videomaskin-lignende funksjonalitet: klient kan pause og spole m 10 s initiell forsinkelse OK m 1-2 s inntil kommando har effekt er OK m RTSP benyttes ofte r tidsbegrensning for data som skal sendes: må ankomme mottager i tide til å bli avspilt til riktig tid

9 Versjon 2.0 / Multimedia7-9 Streaming av live multimedia Eksempler: r Direktesendt radioprogram r Sportsarrangement Streaming r avspillingsbuffer r avspilling kan ligge titalls sekunder etter sendingen (“lag”) r fortsatt gjelder tidsbegrensingen Interaktivitet r FF (spoling framover) umulig r spoling bakover og pause er mulig

10 Versjon 2.0 / Multimedia7-10 Interaktiv sanntidsmultimedia r ende-til-ende forsinkelseskrav: m audio: < 150 ms: god, < 400 ms: OK •inkluderer applikasjonsnivå (pakketisering og nettverks- forsinkelser) •forsinkelser over 150 ms merkbart, dårligere interaktivitet r sesjonsinitialisering m hvordan kan den oppringte angi sin IP-adresse, portnummer og kodingsalgoritme? r applikasjoner: IP-telefoni, videokonferanser, distribuerte interaktive verdener

11 Versjon 2.0 / Multimedia7-11 Multimedia over dagens Internett TCP/UDP/IP: “best-effort” tjeneste r ingen garantier om forsinkelser eller tap Dagens multimediaapplikasjoner på Internett benytter teknikker på applikasjonsnivå for å lindre effektene av forsinkelse og tap Men trenger ikke multimedia appl en viss tjenestekvalitet for å fungere ? ? ?? ? ? ? ? ? ? ?

12 Versjon 2.0 / Multimedia7-12 Hvordan burde Internett utvikle seg for bedre å kunne støtte multimedia? “Integrated services” filosofi: r Fundamentale endringer av Internett slik at applikasjoner kan reservere båndbredde ende-til-ende r Krever ny, kompleks programvare i maskiner og rutere Laissez-faire r ingen vesentlige endringer r mer båndbredde ved behov r innholdsdistribusjon, applikasjonslags multicast m applikasjonslaget “Differentiated services” filosofi: r Færre endringer av Internetts infrastruktur, allikevel kunne gi ulik tjenestekvalitet.

13 Versjon 2.0 / Multimedia7-13 Audiokomprimering r Analogt signal punktprøves (samples) ved konstant rate m telefon: punktprøver/s m CD musikk: punktprøver/s r Hver punktprøve kvantiseres (avrundes til nærmeste mulige verdi) m f eks 8 bit: 2 8 =256 mulige kvantiseringsnivåer r Hver punktprøve representeres ved et binært tall m 8 bit for 256 verdier r Eksempel: 8000 punktprøver/s, hver på 8 bit (256 mulige verdier)  b/s r Mottager konverterer tilbake til analogt signal: m en viss kvalitetsreduksjon pga kvantiseringen Eksempler på rater r CD: 1411 kb/s r MP3: 96, 128, 160 kb/s r Internettelefoni: kb/s

14 Versjon 2.0 / Multimedia7-14 Videokomprimering r Video er sekvens av bilder som vises ved konstant rate m f eks 24 bilder/s r Digitale bilder er array av piksler (luminans og farge) r Hvert piksel representeres av bit r Redundans m romlig (internt i et bilde) m tidsredundans (fra et bilde til det neste) Eksempler: r MPEG 1 (CD-ROM) 1.5 Mb/s r MPEG 2 (DVD) 3-6 Mb/s r MPEG 4 (ofte benyttet på Internett; < 1 Mb/s)

15 Versjon 2.0 / Multimedia7-15 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications è 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

16 Versjon 2.0 / Multimedia7-16 Streaming av lagret multimedia Applikasjonnivå streaming teknikker for å få mest mulig ut av “best-effort” tjenesten: m buffring hos klienten m bruk av UDP vs. TCP m multiple kodinger av multimedia r fjerning av jitter r dekomprimering r skjuling av feil r grafisk brukergrensesnitt m/ kontroll for interaktivitet Mediespiller

17 Versjon 2.0 / Multimedia7-17 Internett multimedia: enkleste mulighet ikke streaming: r ingen “pipelining”, stor forsinkelse før avspilling r audio eller video lagret på fil r filer overført som HTTP-objekter m mottas i sin helhet og leveres deretter til avspilling

18 Versjon 2.0 / Multimedia7-18 Internet multimedia: streaming r nettleser henter en metafil r nettleser starter spiller og leverer metafilen til den r spiller kontakter server r server streamer audio/video til spiller

19 Versjon 2.0 / Multimedia7-19 Streaming fra en streaming-server r Denne arkitekturen gjør det mulig å bruke andre protokoller enn HTTP mellom server og mediespiller r Kan da benytte UDP istedenfor TCP

20 Versjon 2.0 / Multimedia7-20 konstant bit- rate video- overføring Kumulative data tid variabel nettverks- forsinkelse klient video- mottak konstant bit- rate video- avspilling hos klient klientens avspillings- forsinkelse buffret video Streaming multimedia: klient-buffring r Klient-buffring – avspillingsforsinkelse for å kompensere for nettverksforsinkelse og jitter

21 Versjon 2.0 / Multimedia7-21 Streaming multimedia: klient-buffring buffret video variabel fyll- rate, x(t) konstant drenerings- rate, d fra nettet til dekomprimering og avspilling klient- buffer r Klient-buffring – avspillingsforsinkelse for å kompensere for nettverksforsinkelse og jitter

22 Versjon 2.0 / Multimedia7-22 Streaming multimedia: UDP eller TCP? UDP r server sender på rate passende for klienten (uten å bry seg om evt. metning i nettet) m ofte: senderate = kodingsrate = k onstant rate m da vil fyllrate = konstant rate - pakketap r kort avspillingsforsinkelse (2-5 s) for å kompensere for nettets forsinkelse og jitter TCP r sender på maksimal rate som er mulig med TCP r fyllrate fluktuerer pga TCP metningskontroll r må ha større avspillingsforsinkelse for å glatte ut variasjonene som TCP gir

23 Versjon 2.0 / Multimedia7-23 Streaming multimedia: klientrate Hvordan håndtere ulike mottaksrater hos klientene? m 28.8 kb/s modem m 100 Mb/s Ethernet  Server lagrer og sender flere kopier av video kodet på ulike rater 1.5 Mb/s koding 28.8 kb/s encoding

24 Versjon 2.0 / Multimedia7-24 Brukerkontroll av streaming media: RTSP HTTP r Ikke beregnet for multimediainnhold r Ingen kommandoer for spoling osv. RTSP: RFC 2326 r Klient-tjener applikasjons- lagsprotokoll r For at bruker skal kunne kontrollere visningen: spoling, pause, reposisjonering osv Hva den ikke gjør: r definerer ikke hvordan audio/video innkapsles for streaming over nettet r begrenser ikke hvordan streamet media skal overføres – tillater både UDP og TCP r spesifiserer ikke hvordan mediespilleren buffrer audio og video

25 Versjon 2.0 / Multimedia7-25 RTSP: “out-of-band” kontroll FTP benytter en “out-of- band” kontrollkanal: r En fil overføres over en TCP-forbindelse r Kontrollinformasjon (katalogendringer, filslettinger osv) sendes over en egen TCP- forbindelse r De to kanalene (forbindelsene) bruker ulike portnumre RTSP meldinger sendes også i en “out-of-band” kanal: r RTSP kontrolmeldinger benytter andre portnumre enn mediestrømmen m Port 554 r Mediestrømmen anses å være “in-band”

26 Versjon 2.0 / Multimedia7-26 RTSP eksempel Scenario: r metafil oversendt til nettleser r nettleser starter mediespiller r mediespiller setter opp en RTSP kontrollforbindelse og dataforbindelse til streaming server

27 Versjon 2.0 / Multimedia7-27 Metafil eksempel Twister

28 Versjon 2.0 / Multimedia7-28 RTSP operasjon

29 Versjon 2.0 / Multimedia7-29 RTSP meldingsutveksling C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: OK

30 Versjon 2.0 / Multimedia7-30 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video è 7.3 Real-time Multimedia: Internet Phone case study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

31 Versjon 2.0 / Multimedia7-31 Sanntids interaktive applikasjoner r PC-2-PC telefon m instant messaging tjenester muliggjør dette r PC-2-PC telefon m nummertaster m Net2phone r videoconferanse med Webkameraer Bruker PC-2-PC Internett telefon som eksempel

32 Versjon 2.0 / Multimedia7-32 Interaktiv multimedia: Internett-telefon r lyd i høyttaleren: alternerende tale (talk spurts) og stillhet m 64 kb/s for tale r pakker genereres kun når noe sies m 20 ms biter av talen ved 64 kb/s: 160 byte data pr pakke r applikasjonslagsheader legges til hver pakke r pakke+header innkapsles i UDP-segment r applikasjonen sender UDP-segment inn på socketen hvert 20 ms når noe sies

33 Versjon 2.0 / Multimedia7-33 Internett-telefon: pakkettap og forsinkelse r nettverkstap: IP-datagram forsvinner pga metning i nettet (oversvømmelse i et ruterbuffer) r forsinkelsestap: IP-datagram ankommer for sent for avspilling hos mottager m forsinkelser: prosessering, køforsinkelse; forsinkelser i endesystem (sender og mottager) m typisk maksimal tolererbar forsinkelse: 400 ms r tapstoleranse: avhengig av talekodingen (pakketap kan skjules): pakketap mellom 1% og 10% kan tolereres

34 Versjon 2.0 / Multimedia7-34 konstant bit- rate overføring Kumulative data tid variabel nettverks- forsinkelse (jitter) klientens mottak konstant bit- rate avspilling hos klient klientens avspillings- forsinkelse buffrede data Jitter r Se på ende-til-ende forsinkelsen til to etterfølgende pakker: forskjell kan være større eller mindre enn 20 ms

35 Versjon 2.0 / Multimedia7-35 Internett-telefon: fast avspillings- forsinkelse (playout delay) r Mottager forsøker å spille av hver talepakke nøyaktig q ms etter at pakken ble laget m hvis pakken har tidsstempel t, så skal den spilles av ved tidspunktet t + q m pakken ankommer senere enn t + q: data ankommer for sent til å bli spilt av  data “tapt” r Avveining for q: m stor q: mindre pakketap m liten q: bedre interaktivitet

36 Versjon 2.0 / Multimedia7-36 Fast avspillingsforsinkelse - avveining • Sender lager pakker hvert 20 ms under tale (talk spurt) • Første pakke mottas ved tiden r • Liten avsp.forsinkelse: avspilling skal starte ved tiden p • Større avsp.forsinkelse: avspilling skal starte ved tiden p’

37 Versjon 2.0 / Multimedia7-37 Adaptiv avspillingsforsinkelse (1) Mottagerens dynamiske estimat av forsinkelsen: hvor u er en konstant (f eks: u = 0.01) r Mål: minimalisere avspillingsforsinkelse samtidig som forsinkelsestap holdes små r Hvordan?: justerer avspillingsforsinkelse adaptivt: m Estimerer nettverksforsinkelse og justerer avspillingsforsinkelsen ved starten på hver avspilling m stille perioder blir forlenget eller forkortet m talepakker spilles av hvert 20 ms som før

38 Versjon 2.0 / Multimedia7-38 Adaptiv avspillingsforsinkelse (2) Det er også nyttig å estimere gjennomsnittlig avvik på forsinkelsen, v i : Estimatene d i og v i beregnes for hver mottatt pakke, selv om de bare brukes på begynnelsen av en “talkspurt”. For første pakke i talkspurt, settes avspillingstid til: hvor K er en positiv konstant. Resten av pakkene i samme talkspurt spilles av periodisk

39 Versjon 2.0 / Multimedia7-39 Adaptiv avspillingsforsinkelse (3) Hvordan kan mottager vite om en pakke er den første i en talkspurt? r Hvis tap ikke forekommer kan mottager se på tidsstemplene m dersom differansen mellom påfølgende tidsstempler er større enn 20 ms vet den at det er en ny talkspurt r Dersom tap forekommer må mottager se både på tidsstempel og sekvensnummer m dersom differansen mellom påfølgende tidsstempler er større enn 20 ms og sekvensnumrene er uten mellomrom er det begynnelsen på en ny talkspurt

40 Versjon 2.0 / Multimedia7-40 Håndtering av pakketap (1) forward error correction (FEC): enkel løsning r for hver gruppe av n pakker, lag en redundant pakke ved en modulo 2 summasjon av de orginale pakkene r send n+1 pakker, noe som vil øke dataraten med 1/n. r kan rekonstruere maks én tapt pakke av de n pakkene r Avspillingsforsinkelsen må være slik at alle n+1 pakkene er mottatt før avspilling r Avveining: m økes n kaster man bort mindre av båndbredden m økes n får man lengre avspillingsforsinkelse m økes n vil man ha større sannsynlighet for at flere enn én pakke forsvinner

41 Versjon 2.0 / Multimedia7-41 Håndtering av pakketap (2) Annen FEC løsning • “piggyback lav- kvalitets-strøm” • send audiostrøm av lavere kvalitet som redundant informasjon • f. eks: nominell strøm er PCM på 64 kb/s og redundant strøm GSM på 13 kb/s. • Så sant man ikke mister to pakker etter hverandre, kan mottageren skjule pakketapet • Liten avspillingsforsinkelse (må kun motta to pakker før avspilling) • Kan også addere både (n-1) og (n-2) lavkvalitetspakke for å håndtere to konsekutive pakketap

42 Versjon 2.0 / Multimedia7-42 Håndtering av pakketap (3) Interleaving (sammenfletting) r talepakker deles opp i mindre enheter r f eks fire enheter à 5 ms pr oversendt pakke r oversendte pakker inneholder biter fra flere talepakker r dersom pakke forsvinner har vi fortsatt mesteparten av hver talepakke r ingen redundans eller overhead r gir ekstra avspillingsforsinkelse

43 Versjon 2.0 / Multimedia7-43 Oppsummering: Internett multimedia: triks man bruker r bruk UDP for å unngå TCP metingskontroll (forsinkelser) for tidskritisk trafikk r klientside bruker adaptiv avspillingsforsinkelse: for å kompensere for variable forsinkelser r serverside tilpasser strømmen til tilgjengelig båndbredde på veien fra klient til server m velger mellom forhåndskodede strøm-rater m dynamisk serverkodingsrater r feilhåndtering (på toppen av UDP) m FEC, interleaving m retransmisjoner hvis tiden tillater det m skjuler feil, f eks ved å avspille forrige pakke om igjen

44 Versjon 2.0 / Multimedia7-44 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study è 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

45 Versjon 2.0 / Multimedia7-45 Real-Time Protocol (RTP) r RTP spesifiserer en pakkestruktur for pakker som frakter audio og video r RFC 3550 r RTP-pakke har m identifikasjon av type nyttelast m sekvensnummerering av pakker m tidsstempling r RTP kjører i endesystemene r RTP-pakker er innkapslet i UDP- segmenter r Interoperabilitet: dersom to Internett- telefoni-applikasjoner kjører RTP, vil de normalt kunne fungere sammen

46 Versjon 2.0 / Multimedia7-46 RTP kjører over UDP RTP-biblioteker gir et transportlagsgrensesnitt som utvider mulighetene man har i UDP: • identifisering av type nyttelast • sekvensnummerering av pakker • tidsstempling transport- lag

47 Versjon 2.0 / Multimedia7-47 RTP eksempel r Sending av 64 kb/s PCM-kodet tale over RTP r Applikasjonen henter kodede data i klumper, f eks hver 20 ms = 160 byte i en klump r Lydklumpen danner sammen med RTP- headeren en RTP- pakke som innkapsles i et UDP-segment r RTP-header indikerer kodingstype i hver pakke m sender kan bytte kodingstype underveis r RTP-header inneholder også sekvensnummer og tidsstempel

48 Versjon 2.0 / Multimedia7-48 RTP og QoS r RTP har ingen mekanisme for garantere at data leveres i tide eller andre garantier for tjeneste- kvaliteten (QoS) r RTP-innkapslingen synes kun i endesystemene, ikke i mellomliggende rutere m Rutere som tilbyr “best-effort”-tjeneste, gir ingen spesialbehandling av RTP-pakker

49 Versjon 2.0 / Multimedia7-49 RTP-header Payload type (7 bit): Indikerer hvilken kodingstype som har vært benyttet. Sender kan endre kodingstype underveis, og informerer da mottager via innholdet i dette feltet •Payload type 0: PCM μ-lov, 64 kb/s •Payload type 3, GSM-koding, 13 kb/s •Payload type 7, LPC, 2.4 kb/s •Payload type 26, “Motion” JPEG •Payload type 31, H.261 •Payload type 33, MPEG2 video Sequence number (16 bit): Øker med en for hver RTP-pakke som sendes, og kan brukes for å oppdage pakketap og gjenopprette korrekt rekkefølge

50 Versjon 2.0 / Multimedia7-50 RTP-header (2) r Timestamp (32 bit). Angir tidspunktet første punktprøve i pakken ble tatt m For audio vil tidsstemplingsklokka normalt inkrementeres med en for hver punktprøveperiode (f. eks. hvert 125 μs for en samplingsrate på 8 kHz m dersom applikasjonen genererer klumper på 160 kodede punktprøver vil tidsstempelet øke med 160 for hver RTP- pakke som sendes mens senderen er aktiv. Tidsstemplings- klokka fortsetter å inkrementeres også når senderen er inaktiv r SSRC (32 bit). Identifiserer kilden til RTP-strømmen. Hver strøm i en RTP-sesjon skal ha sin egen SSRC. (SSRC = synchronization source)

51 Versjon 2.0 / Multimedia7-51 Real-Time Control Protocol (RTCP) r Samarbeider med RTP r Hver deltaker i en RTP- sesjon vil periodisk sende RTCP-kontrollpakker til alle andre deltakere r Hver RTCP-pakke inneholder sender- og/eller mottager-rapporter m rapport-statistikk gir nyttig info til applikasjonen r Statistikk omfatter antall pakker sendt, antall pakker tapt, jitter osv r Tilbakemeldinger kan benyttes til å styre ytelsen m Sender kan endre sin sending basert på tilbakemeldinger

52 Versjon 2.0 / Multimedia7-52 RTCP (forts) - For en RTP-sesjon er det normalt en enkelt multicast adresse; alle RTP og RTCP pakker som tilhører samme sesjon benytter multicast adressen - RTP og RTCP pakker skilles fra hverandre ved bruk av ulike portnumre - For å begrense trafikken må hver deltaker redusere sin RTCP-trafikk ettersom antall konferansedeltakere øker

53 Versjon 2.0 / Multimedia7-53 RTCP-pakker Receiver report pakker: r andel pakker som er tapt, siste sekvens- nummer mottatt, gjennomsnittlig jitter Sender report pakker: r RTP-strømmens SSRC, tidspunkt, antall sendte pakker, antall sendte oktetter Source description pakker: r senderens e-post- adresse, senderens navn, SSRC for tilhørende RTP-strøm r knytter SSRC og bruker/maskin-navn

54 Versjon 2.0 / Multimedia7-54 Synkronisering av strømmer r RTCP kan synkronisere ulike media-strømmer i en RTP-sesjon r Eks: videokonferanseappl. hvor sender genererer en RTP-strøm for video og en annen for audio r Tidsstempel i RTP-pakkene er knyttet til video og audio punktprøvingsklokker m ikke knyttet til virkelig tid (wall-clock time) r Hver RTCP sender-rapport pakke inneholder (for den nyest generererte pakke i den tilhørende RTP- strømmen): m tidsstempel for RTP- pakken m virkelig tid (wall-clock time) for når pakken ble laget r Mottakere kan bruke dette til å synkronisere avspillingen av lyd og bilde

55 Versjon 2.0 / Multimedia7-55 RTCP båndbreddeskalering r RTCP forsøker å begrense sin trafikk til 5% av sesjonens båndbredde Eksempel r Anta at vi har en sender som sender video på 2 Mb/s. Da vil RTCP prøve å begrense sin trafikk til 100 kb/s r RTCP gir 75% av denne raten til mottagerne; 25% igjen til senderen r De 75 kb/s deles likt mellom mottagerne: m Med R mottagere kan hver mottager sende RTCP-trafikk på 75/R kb/s r Sender kan sende RTCP- trafikk på 25 kb/s r Deltager finner pakke- sendingsperioden ved å beregne gjennomsnittlig RTCP- pakke-størrelse i hele sesjonen og dividere med tildelt rate

56 Versjon 2.0 / Multimedia7-56 SIP r Session Initiation Protocol r Spesifisert av IETF SIP visjon r Alle telefonsamtaler og videokonferanser foregår over Internett r Mennesker identifiseres ved sitt navn eller sin e- post-adresse, ikke ved sitt telefonnummer r Man kan nå en person uansett hvor han er, og uansett hvilken IP-dings han for øyeblikket bruker

57 Versjon 2.0 / Multimedia7-57 SIP-tjenester r Oppsetting av samtale m Gir mekanismer så initiator (caller) kan la respondent (callee) vite at hun ønsker å etablere en forbindelse/samtale m Gir mekanismer slik at initiator og respondent kan avtale hvilken medietype og koding som skal brukes m Gir mekanismer for å avslutte en samtale r Bestemme nåværende IP-adresse for respondent m Kobler mnemonisk ID til nåværende IP-adresse r Call management m Kan legge til nye mediestrømmer under en samtale m Kan endre kodemetode under en samtale m Invitere andre m Muligheter for “overføring” og “vent” av samtaler

58 Versjon 2.0 / Multimedia7-58 Oppsetting av samtale til kjent IP-adresse • Annes SIP-invitasjons- melding (INVITE) angir hennes portnummer og IP- adresse. Angir også koding som Anne foretrekker å motta (PCM μ-lov) • Bjørns “200 OK”-melding angir hans portnummer, IP-adresse og foretrukne koding (GSM) • SIP-meldinger kan sendes både over TCP og UDP. Her: over RTP/UDP •Default portnummer for SIP, er 5060

59 Versjon 2.0 / Multimedia7-59 Oppsetting av samtale (forts) r Forhandling om kodek: m Anta at Bjørn ikke har PCM μ-lov koder m Bjørn vil da svare med “606 Not Acceptable Reply” og liste de kodere han kan benytte m Alice kan deretter sende en ny INVITE-melding hvor hun har valgt en av de kodere som Bjørn har listet r Avvisning av samtale m Bjørn kan avvise med ulike svar: “busy”, “gone”, “payment required”, “forbidden” r Media kan sendes over RTP eller en annen protokoll

60 Versjon 2.0 / Multimedia7-60 Eksempel på SIP-melding INVITE SIP/2.0 Via: SIP/2.0/UDP From: To: Call-ID: Content-Type: application/sdp Content-Length: 885 c=IN IP m=audio RTP/AVP 0 Merk: r HTTP-lignende meldingssyntaks r sdp = session description protocol r Call-ID er unik for hver samtale • Her kjenner vi ikke Bjørns IP-adresse. Mellomliggende SIP- servere vil være nødvendig • Anne sender og mottar SIP-meldinger på standard SIP- •portnummer • Anne spesifiserer i “Via:”-headeren at SIP- klienten sender og mottar SIP-meldinger over UDP

61 Versjon 2.0 / Multimedia7-61 Oversetting av navn og lokalisering av brukere r Initiator ønsker å kontakte respondent, men har bare hans navn eller e-post- adresse r Må få IP-adressen til respondentens nåværende maskin: m bruker flytter rundt m DHCP-protokoll m bruker har ulike IP- dingser (PC, PDA, osv) r Resultatet kan baseres på: m tid på dagen (arbeid, hjemme) m hvem som ringer (ønsker ikke at sjefen skal ringe deg når du er hjemme) m respondentens status (er respondenten i en samtale sendes anropet til svarer) Tjenester som ytes av SIP-servere: r SIP registrar server r SIP proxy server

62 Versjon 2.0 / Multimedia7-62 SIP registrar REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: To: Expires: 3600 r Når Bjørn starter sin SIP-klient, sender SIP-klienten en “SIP REGISTER”-melding til Bjørns registrar- server Registreringsmelding:

63 Versjon 2.0 / Multimedia7-63 SIP proxy r Anne sender en “INVITE”-melding til sin proxy- server m inneholder adressen r Proxy ansvarlig for å rute SIP-meldingen til respondent m muligens via flere proxier r Respondent sender svar via samme kjede av proxier r Proxy returnerer SIP responsmeldingen til Anne m inneholder Bjørns IP-adresse r Merk: SIP-proxy ligner på en lokal DNS-server

64 Versjon 2.0 / Multimedia7-64 Eksempel Initiator som ringer (1) Jim sender INVITE- melding til SIP-proxy på UMass. (2) Proxy videre- sender forespørsel til UPenn registrar server. (3) UPenn server svarer med en “redirect”- respons som indikerer at den burde forsøke (4) UMass proxy sender INVITE til eurecom registrar. (5) eurecom registrar videresender INVITE til , som kjører Keiths SIP- klient. (6-8) SIP-respons returneres (9) media sendes direkte mellom klientene. Merk: det sendes også SIP ack-meldinger som ikke vises her

65 Versjon 2.0 / Multimedia7-65 Sammenligning med H.323 r H.323 er en signalerings- protokoll for interaktiv sanntidsmedia med funksjonalitet lignende SIP r H.323 er en komplett, vertikalt integrert suite av protokoller for multimedia konferanse: signalering, registrering, tilgangs- kontroll, transport og kodek r SIP er en enkeltkomponent. Fungerer sammen med RTP, men krever den ikke. Kan brukes med andre protokoller og tjenester r H.323 utviklet av ITU (telefoni). r SIP utviklet av IETF: låner mange konsepter fra HTTP. SIP har en “smak” av web, mens H.323 har en “smak” av telefoni r SIP er basert på KISS- prinsippet: “Keep it simple, stupid”

66 Versjon 2.0 / Multimedia7-66 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP è 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

67 Versjon 2.0 / Multimedia7-67 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks è 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

68 Versjon 2.0 / Multimedia7-68 Bedret tjenestekvalitet (QoS) i IP-nett Så langt: få mest mulig ut av “best-effort” tjenesten Framtiden: neste generasjons Internett med tjeneste- kvalitetsgarantier m RSVP: signalering for reservering av ressurser m Differentiated Services: differensierte garantier m Integrated Services: faste garantier r enkel modell for studier av deling og metning: 1.5 Mb/s link R1 utgangskø

69 Versjon 2.0 / Multimedia7-69 Prinsipper for QoS-garantier r Eksempel: 1Mb/s IP-telefon og FTP deler 1.5 Mb/s link m skurer av FTP kan gi metning i ruter og gi tap av lydpakker m ønsker å prioritere lyd framfor FTP merking av pakker nødvendig for at ruter skal kunne skille mellom ulike trafikklasser; og ny ruter policy for å behandle pakker etter merking Prinsipp Mb/s 1 Mb/s

70 Versjon 2.0 / Multimedia7-70 Prinsipper for QoS-garantier (forts) r hva om en applikasjon ikke oppfører seg som den skal (sender med høyere rate enn den har sagt) m trafikkforming (policing): tvinger sender til å holde seg til tildelt båndbredde r merking og trafikkforming på nettets kant: beskytte (isolere) en klasse fra de andre Prinsipp 2 1 Mb/s 1.5 Mb/s merking og trafikkforming

71 Versjon 2.0 / Multimedia7-71 Prinsipper for QoS-garantier (forts) r Tildeling av fast (ikke-delbar) båndbredde til flow: ineffektiv bruk av båndbredde hvis flow ikke bruker sin tildelte andel Selv om man isolerer bør man bruke ressursene så effektivt som mulig Prinsipp 3 merking og trafikkforming 1 Mb/s 1.5 Mb/s 0.5 Mb/s logisk link 1 Mb/s logisk link

72 Versjon 2.0 / Multimedia7-72 Prinsipper for QoS-garantier (forts) r Livets harde realiteter: kan ikke tilfredsstille krav som overgår linkkapasiteten Anropstilgang: flow angir sine behov, nettet kan blokkere samtale (f eks opptattsignal) dersom det ikke kan oppfylle behovene Prinsipp 4 1 Mb/s 1.5 Mb/s 1 Mb/s

73 Versjon 2.0 / Multimedia7-73 Oppsummering av QoS prinsipper Skal nå se på mekanismer for å oppnå dette Tjenestekvalitet for nettverksapplikasjoner: r Pakkeklassifisering r Isolering: sendeplan og trafikkforming r Høy ressursutnyttelse r Anropstilgang

74 Versjon 2.0 / Multimedia7-74 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort è 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

75 Versjon 2.0 / Multimedia7-75 Sendeplan og trafikkforming r sendeplan (scheduling): velg hvilken pakke man skal velge som neste for sending r FIFO (first in first out) sendeplan: send ut i samme rekkefølge som de kom inn på køen m eksempler? m kaste-politikk: dersom pakke ankommer full kø: hvilken pakke skal kastes? •“Tail drop”: kast den sist ankomne •prioritet: kast pakker basert på deres prioritet •tilfeldig: kast tilfeldig ankomst avgang kø FIFO: sender

76 Versjon 2.0 / Multimedia7-76 Sendeplaner (forts) Sendeplan med prioritet (priority scheduling): send først pakke i køen med høyest prioritet r flere klasser med ulike prioriteter m klass kan avhenge av merking eller annen header-info, f. eks. IP-adresser, portnumre osv m eksempler?

77 Versjon 2.0 / Multimedia7-77 Sendeplaner (forts) round robin sendeplan: r flere klasser r syklisk skanning av klassekøer, betjener en fra hver klasse r eksempler?

78 Versjon 2.0 / Multimedia7-78 Sendeplaner (forts) Weighted Fair Queuing (WFQ): r generalisert round robin r hver klasse får sin vektede del av tjenesten i hver runde r eksempel?

79 Versjon 2.0 / Multimedia7-79 Trafikkforming (politifunksjoner, policing) Mål: begrense trafikken så den ikke overskrider grensene som er satt Tre kriterier som ofte benyttes: r (Langtids) Gjennomsnittlig rate: hvor mange pakker kan sendes per tidsenhet, målt over et lengre tidsrom m viktig spørsmål: hva er lengden på tidsintervallet: 100 pakker pr sekund og 6000 pakker pr minutt har sammen gjennomsnitt! r Maks rate: f. eks pakker pr min. i snitt; 1500 pakker pr sekund som maks r (Maks) Skurstørrelse: maks antall pakker sendt etter hverandre uten pause

80 Versjon 2.0 / Multimedia7-80 Trafikkformingsmekanismer Token Bucket: begrenser både skurstørrelse og gjennomsnittlig rate r bøtta kan inneholde b token r token genereres med rate r token/s så sant bøtta ikke er full r over et intervall av lengde t: antall pakker mindre enn eller lik (r · t + b)

81 Versjon 2.0 / Multimedia7-81 Trafikkformingsmekanismer (forts) r token bucket og WFQ kan kombinere for å garantere øvre grense på forsinkelse, dvs QoS garanti WFQ token rate, r bøttestørrelse b pr-flow rate, R D = b/R max ank. trafikk

82 Versjon 2.0 / Multimedia7-82 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms è 7.8 Integrated Services and Differentiated Services r 7.9 RSVP

83 Versjon 2.0 / Multimedia7-83 IETF Integrated Services r arkitektur for å kunne gi QoS garantier i IP-nett for individuelle applikasjonssesjoner r ressursreservering: rutere har tilstandsinformasjon (lignende VC) om allokerte ressurser og QoS-krav r tillater/nekter oppsett av nye forbindelser Spm: kan nye flows gis tilgang med ytelses- garantier uten å ødelegge for de QoS-garantier man alt har gitt til eksisterende flows?

84 Versjon 2.0 / Multimedia7-84 Intserv: QoS-garanti-scenario r Ressursreservering m oppsett av forbindelse, signalering (RSVP) m trafikk, QoS-deklarasjon m tilgangskontroll pr element m QoS-følsom sendeplan (f. eks. WFQ) request/ reply

85 Versjon 2.0 / Multimedia7-85 Anropstilgang Ny sesjon må: r deklarere sine QoS-krav m R-spec: definerer QoS-kravene r karakterisere trafikken den vil sende inn på nettet m T-spec: definerer trafikkarakteristika r signaleringsprotokoll: nødvendig for å overføre R- spec og T-spec til rutere m RSVP

86 Versjon 2.0 / Multimedia7-86 Intserv QoS: Tjenestemodeller [RFC 2211, RFC 2212] Garantert tjenestekvalitet: r verste tilfelle av ankomsttrafikk: token-bucket-formet kilde r enkel (matematisk bevisbar) beskrankning på forsinkelse Tjeneste med styrt last (controlled-load network service): r “en tjenestekvalitet som er tilnærmet den tjenestekvalitet som samme flow ville motta fra et ubelastet nettelement" WFQ token rate, r per-flow rate, R D = b/R max bøttestørrelse, b ank. trafikk

87 Versjon 2.0 / Multimedia7-87 IETF Differentiated Services Problemer med Intserv: r Skalerbarhet: signalering og det å ha en ruter- tilstande pr flow er vanskelig når vi har stort antall flows r Fleksible tjenestemodeller: Intserv har kun to klasser Ønsker også “kvalitative” tjenesteklasser m f eks relative tjenestenivåer: platina, gull, sølv Diffserv-tilnærming: r enkle funksjoner i kjernen, mer komplekse funksjoner i kantrutere eller endesystemer r definerer ikke tjenesteklasser, men gir funksjonelle komponenter for å bygge tjenesteklasser

88 Versjon 2.0 / Multimedia7-88 Diffserv arkitektur Kantruter: - per-flow trafikkhåndtering - merker pakker som innenfor- profil og utenom-profile Kjerneruter: - pr klasse trafikkhåndtering - buffring og sendeplanlegging (scheduling) basert på merking gjort på kanten - fortrinn gis til innenfor-profil pakker - garantert videresending (Assured Forwarding) sendeplan... r b merking

89 Versjon 2.0 / Multimedia7-89 Kantruter – merking av pakker r klasse-basert merking: pakker fra ulike klasser merkes forskjellig r intra-klasse merking: konform del av flow merkes annerledes enn ikke- konform del r profil: forhåndsavtalt rate A og bøttestørrelse B r pakkemerking på kanten baseres på per-flow profil Mulig bruk av merking: Sendte pakker Rate A B

90 Versjon 2.0 / Multimedia7-90 Klassifisering r Pakker merkes i “Type of Service”-feltet (TOS) i IPv4, og i “Traffic Class”-feltet i IPv6 r 6 bit brukes for “Differentiated Service Code Point” (DSCP) og angir den “per-hop-behaviour” (PHB) som pakken vil få r 2 bit er ubenyttet (CU = currently unused)

91 Versjon 2.0 / Multimedia7-91 Klassifisering kan være fordelaktig å begrense injeksjonsraten for noen klasser: r bruker angir trafikkprofil (f eks rate og skurstørrelse) r trafikken måles og formes dersom den ikke følger angitt profil

92 Versjon 2.0 / Multimedia7-92 Videresending (PHB) r PHB resulterer i en observerbar forskjell i videresendingsytelse r PHB spesifiserer ikke hvilke mekanismer som skal benyttes for å sikre nødvendig PHB ytelse r Eksempler: m Klasse A får x% av båndbredden til utgående link i tidsintervaller av spesifisert lengde m Klasse A-pakker har fortrinn framfor klasse B-pakker

93 Versjon 2.0 / Multimedia7-93 Videresending (PHB) PHBer som utvikles: r Expedited Forwarding (kjapp videresending): senderate for pakker tilhørende en klasse er lik eller større enn den spesifiserte raten m logisk link med en garantert minimumsrate r Assured Forwarding (garantert videresending): Fire trafikklasser m hver garanterer minimum båndbredde m hver med tre “drop preference”-kategorier

94 Versjon 2.0 / Multimedia7-94 Kapittel 7 – hvor er vi? r 7.1 Multimedia Networking Applications r 7.2 Streaming stored audio and video r 7.3 Real-time Multimedia: Internet Phone study r 7.4 Protocols for Real- Time Interactive Applications m RTP,RTCP,SIP r 7.5 Distributing Multimedia: content distribution networks r 7.6 Beyond Best Effort r 7.7 Scheduling and Policing Mechanisms r 7.8 Integrated Services and Differentiated Services è 7.9 RSVP

95 Versjon 2.0 / Multimedia7-95 Multimedia Networking: Oppsummering r multimediaapplikasjoner og -krav r få mest mulig ut av dagens “best-effort” tjeneste r sendeplanlegging (scheduling) og trafikkformingsteknikker (policing) r neste generasjons Internett: Intserv, RSVP, Diffserv


Laste ned ppt "Versjon 2.0 / 01.11.03 Multimedia7-1 Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim."

Liknende presentasjoner


Annonser fra Google