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

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 Multimedia

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

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

MM nettverksapplikasjoner Grunnleggende karakteristika: Typisk følsom for forsinkelser ende-til-ende forsinkelse jitter Tapstolerant: ikke altfor hyppige tap gir liten innvirkning på opplevd kvalitet 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 Multimedia

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

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

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

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

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

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

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

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

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

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

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

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

Internet multimedia: streaming nettleser henter en metafil nettleser starter spiller og leverer metafilen til den spiller kontakter server server streamer audio/video til spiller Multimedia

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

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

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

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

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

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

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

RTSP eksempel Scenario: metafil oversendt til nettleser nettleser starter mediespiller mediespiller setter opp en RTSP kontrollforbindelse og dataforbindelse til streaming server Multimedia

Metafil eksempel <title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> Multimedia

RTSP operasjon Multimedia

RTSP meldingsutveksling C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 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 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 S: 200 3 OK Multimedia

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

Sanntids interaktive applikasjoner Bruker PC-2-PC Internett telefon som eksempel PC-2-PC telefon instant messaging tjenester muliggjør dette nummertaster Net2phone videoconferanse med Webkameraer Multimedia

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

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

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

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

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’ Multimedia

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

Adaptiv avspillingsforsinkelse (2) Det er også nyttig å estimere gjennomsnittlig avvik på forsinkelsen, vi : Estimatene di og vi 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 Multimedia

Adaptiv avspillingsforsinkelse (3) Hvordan kan mottager vite om en pakke er den første i en talkspurt? Hvis tap ikke forekommer kan mottager se på tidsstemplene dersom differansen mellom påfølgende tidsstempler er større enn 20 ms vet den at det er en ny talkspurt Dersom tap forekommer må mottager se både på tidsstempel og sekvensnummer 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 Multimedia

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

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 Multimedia

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

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

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

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

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 Multimedia

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

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

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 Multimedia

RTP-header (2) Timestamp (32 bit). Angir tidspunktet første punktprøve i pakken ble tatt For audio vil tidsstemplingsklokka normalt inkrementeres med en for hver punktprøveperiode (f. eks. hvert 125 μs for en samplingsrate på 8 kHz 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 SSRC (32 bit). Identifiserer kilden til RTP-strømmen. Hver strøm i en RTP-sesjon skal ha sin egen SSRC. (SSRC = synchronization source) Multimedia

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

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 Multimedia

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

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

RTCP båndbreddeskalering RTCP forsøker å begrense sin trafikk til 5% av sesjonens båndbredde Eksempel 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 RTCP gir 75% av denne raten til mottagerne; 25% igjen til senderen De 75 kb/s deles likt mellom mottagerne: Med R mottagere kan hver mottager sende RTCP-trafikk på 75/R kb/s Sender kan sende RTCP-trafikk på 25 kb/s Deltager finner pakke-sendingsperioden ved å beregne gjennomsnittlig RTCP-pakke-størrelse i hele sesjonen og dividere med tildelt rate Multimedia

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

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

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 Multimedia

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

Eksempel på SIP-melding INVITE sip:bjorn@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:anne@hereway.com To: sip:bjorn@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Merk: HTTP-lignende meldingssyntaks sdp = session description protocol 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 5060. Anne spesifiserer i “Via:”-headeren at SIP- klienten sender og mottar SIP-meldinger over UDP Multimedia

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

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

SIP proxy Anne sender en “INVITE”-melding til sin proxy-server inneholder adressen “sip:bjorn@domain.com” Proxy ansvarlig for å rute SIP-meldingen til respondent muligens via flere proxier Respondent sender svar via samme kjede av proxier Proxy returnerer SIP responsmeldingen til Anne inneholder Bjørns IP-adresse Merk: SIP-proxy ligner på en lokal DNS-server Multimedia

Eksempel Initiator jim@umass.edu som ringer keith@upenn.edu (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 keith@eurecom.fr (4) UMass proxy sender INVITE til eurecom registrar. (5) eurecom registrar videresender INVITE til 197.87.54.21, 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 Multimedia

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

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

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

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

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

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

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

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

Oppsummering av QoS prinsipper Tjenestekvalitet for nettverksapplikasjoner: Pakkeklassifisering Isolering: sendeplan og trafikkforming Høy ressursutnyttelse Anropstilgang Skal nå se på mekanismer for å oppnå dette Multimedia

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

Sendeplan og trafikkforming sendeplan (scheduling): velg hvilken pakke man skal velge som neste for sending FIFO (first in first out) sendeplan: send ut i samme rekkefølge som de kom inn på køen eksempler? 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 FIFO: kø sender Multimedia

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

Sendeplaner (forts) round robin sendeplan: flere klasser syklisk skanning av klassekøer, betjener en fra hver klasse eksempler? Multimedia

Sendeplaner (forts) Weighted Fair Queuing (WFQ): generalisert round robin hver klasse får sin vektede del av tjenesten i hver runde eksempel? Multimedia

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

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

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

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

IETF Integrated Services arkitektur for å kunne gi QoS garantier i IP-nett for individuelle applikasjonssesjoner ressursreservering: rutere har tilstandsinformasjon (lignende VC) om allokerte ressurser og QoS-krav 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? Multimedia

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

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

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

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

. Diffserv arkitektur Kantruter: merking r sendeplan b Kjerneruter: - per-flow trafikkhåndtering - merker pakker som innenfor-profil og utenom-profile r b merking sendeplan . 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) Multimedia

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

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

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

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

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

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

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