Multimedia Networking

Lyd og video som bits

Før vi kan sende multimedia over et nettverk, må vi forstå hvordan analoge signaler blir til en strøm av bits.

Lyd er trykkbølger i luften. Video er en sekvens av bilder som vises raskt nok til at øyet oppfatter bevegelse. Ingen av delene er naturlig «digitale» — de er kontinuerlige, analoge størrelser. For å sende dem over et pakkenett må vi først gjøre dem om til en strøm av bits, og det er der sampling og kvantisering kommer inn.

Audio: sampling og kvantisering

Et analogt lydsignal samples ved en fast rate — verdien av signalet måles med jevne mellomrom. Hver måling kvantiseres, altså rundes av til nærmeste tillatte verdi. Hvis vi bruker 8 bits per sample, har vi 2⁸ = 256 mulige verdier. Resultatet er en strøm av tall som representerer lyden.

Legg merke til forskjellen: en CD bruker 1,4 Mbps for å representere musikk. MP3 komprimerer den ned til under 160 kbps ved å fjerne lyddetaljer som de fleste ikke hører. Internett-telefoni trenger bare 5–64 kbps fordi menneskelig tale er mye enklere enn musikk.

Video: romlig og temporal koding

En video er en sekvens av bilder (typisk 24–30 bilder per sekund), der hvert bilde er et rutenett av piksler. Rå video krever enorm båndbredde, men det finnes to typer redundans vi kan utnytte for å komprimere:

CBR vs. VBR

Når vi koder video, kan vi velge mellom to strategier:

• CBR (Constant Bit Rate): Videoen kodes med en fast bitrate hele veien. Enkelt for nettverket å planlegge for, men kan gi unødvendig lav kvalitet i stille scener eller for dårlig kvalitet i komplekse scener.
• VBR (Variable Bit Rate): Bitraten varierer etter hvor komplekst innholdet er. En enkel scene med lite bevegelse bruker få bits, mens en actionscene bruker mange. Bedre kvalitet, men vanskeligere for nettverket å håndtere.

Tre typer multimedia-applikasjoner

Ikke all multimedia har de samme kravene til nettverket.

Multimedia over nettverk kan deles inn i tre kategorier med vidt forskjellige nettverkskrav. Det er viktig å skille dem, fordi løsningene vi trenger er forskjellige for hver.

Den røde tråden er at alle tre typene har til felles at de er tidssensitive — bits som kommer for sent er verdiløse. En e-post som bruker 2 sekunder ekstra spiller ingen rolle, men 2 sekunder ekstra forsinkelse i en telefonsamtale gjør den ubrukelig. Hele resten av dette kapittelet handler om å takle denne tidsfølsomheten over et nettverk som bare lover «best effort».

Streaming av lagret video

Klienten spiller av den ene enden mens serveren fremdeles sender den andre — og bufferen i midten gjør det hele mulig.

Hovedutfordringen med streaming er enkel å forklare: videoen ble spilt inn med en fast rate (f.eks. 30 bilder per sekund), og den må spilles av med nøyaktig samme rate for at den skal se riktig ut. Men nettverket leverer pakker med variabel forsinkelse — noen ganger litt fortere, noen ganger litt tregere. Denne variabiliteten kalles jitter, og det er den klienten må kompensere for.

Continuous playout constraint

Når avspillingen først har begynt, må den fortsette med jevn rate. Hvis pakker som trengs for neste bilde ikke har kommet frem ennå, fryser videoen — den klassiske «buffering»-animasjonen vi alle hater. Vi kan ikke sende pakkene tilbake i tid, så den eneste strategien er å vente litt med å starte avspillingen, slik at vi bygger opp en buffer først.

Klient-side buffering

Idéen er elegant: klienten har en buffer med plass til en viss mengde video. Serveren fyller bufferen med variabel rate x(t) (påvirket av nettverksforhold), mens klienten tømmer bufferen med konstant avspillingsrate r.

Avveiningen: playout-forsinkelse

Jo lengre vi venter med å starte avspillingen, jo mer buffer bygger vi opp — og jo tryggere er vi mot korte perioder der nettverket er tregt. Men brukeren vil ikke vente. Denne avveiningen er fundamental:

Dra slideren for å se hvordan initial playout-forsinkelse påvirker bufferrobusthet og brukeropplevelse. Modellen er forenklet, men illustrerer kjernen av trade-off-en.

UDP vs. HTTP-streaming

To helt forskjellige strategier for å få videobits fra server til klient.

Historisk har det vært to hovedtilnærminger for å strømme video. I de tidlige dagene brukte man oftest UDP; i dag har HTTP/TCP vunnet nesten fullstendig. Det er verdt å forstå begge og hvorfor pendelen svingte.

Grunnen til at HTTP/TCP vant er pragmatisk: det passerer brannmurer, det krever ingen spesiell serverinfrastruktur (vanlig webserver holder), og TCP gir pålitelig levering slik at man slipper å håndtere tap selv. Avveiningen er høyere playout-forsinkelse, men for streaming av lagret video er det akseptabelt.

Voice-over-IP: samtale over pakkenett

Kravene til interaktiv tale er fundamentalt annerledes enn for lagret video — forsinkelse er fienden.

Når to mennesker snakker sammen, forventer de et svar innen brøkdelen av et sekund. Hjernen vår er utrolig sensitiv for forsinkelser i samtaler — allerede ved 150 millisekunder merker vi at noe er «rart», og ved 400 ms bryter samtalen sammen i en pinlig dans av «snakket du? nei, du først». Denne forsinkelsessensitiviteten gjør VoIP til et mye vanskeligere problem enn streaming av video.

VoIP-karakteristikker

En typisk VoIP-strøm ser slik ut:

• Taleren veksler mellom snakkefaser og stillhet (talk spurts vs. silence). Pakker genereres bare under snakkefaser.
• Under snakking: 64 kbps (= 8 Kbytes/s) med PCM-koding.
• Lyden deles opp i 20 ms biter — hver bit er 160 bytes med lyddata.
• Til hver bit legges en applikasjonsheader, og resultatet pakkes i et UDP- eller TCP-segment.
• Applikasjonen sender én pakke hvert 20. millisekund under en snakkefase.

Krav til forsinkelse

Pakketap og forsinkelsestap

VoIP må takle to typer tap:

Et viktig poeng: VoIP tåler noe tap. Avhengig av lydkoding og teknikker for å skjule tap (loss concealment), kan man tolerere 1–20% pakketap uten at samtalen blir uforståelig. Det er en dramatisk forskjell fra f.eks. filoverføring, der ethvert tapt byte er katastrofalt.

Jitter og playout-forsinkelse

Konstant sende-rate inn i nettet, variabel forsinkelse gjennom det — og en buffer som retter opp igjen.

VoIP-senderen sender pakker med jevne mellomrom (hver 20. ms under en snakkefase). Men nettverket leverer dem med variabel forsinkelse — akkurat som med video-streaming. Denne variasjonen i forsinkelse er jitter, og den må kompenseres av mottakeren. Løsningen er, igjen, en buffer — men nå handler avveiningen om millisekunder, ikke sekunder.

Fast playout-forsinkelse

Den enkleste strategien: mottakeren bestemmer seg for en fast forsinkelse q, og spiller av hver lydbit nøyaktig q millisekunder etter at den ble generert av senderen.

• Hvis en lydbit har tidsstempel t, spilles den av ved tid t + q.
• Hvis biten ankommer etter t + q → den er tapt (for sen).
• Stor q: færre pakker «for sene» → lavere tap, men lengre forsinkelse i samtalen.
• Liten q: bedre interaktivitet, men flere pakker rekker ikke frem i tide.

Adaptiv playout-forsinkelse

I stedet for å velge en fast q kan vi gjøre den adaptiv: vi estimerer nettverksforsinkelsen fortløpende og justerer playout-forsinkelsen ved starten av hver ny snakkefase. Stille perioder komprimeres eller forlenges litt for å ta igjen endringen — lytteren merker ikke dette.

Estimeringen bruker en EWMA (Exponentially Weighted Moving Average), nøyaktig samme idé som TCP bruker for å estimere RTT:

Her er d_i det estimerte nettverksforsinkelsen etter den i-te pakken, α er en liten konstant (typisk 0,1), r_i er tidspunktet pakken ble mottatt, og t_i er tidsstempelet (når den ble sendt). Uttrykket (r_i − t_i) er den faktisk målte forsinkelsen for pakke i.

Men gjennomsnittlig forsinkelse alene er ikke nok — vi trenger også et mål på variasjonen. Vi estimerer avviket på samme måte:

Playout-tidspunktet for den første pakken j i en ny snakkefase settes da til:

Her er K en konstant (typisk 4). Legg merke til parallellen til TCP: der settes timeout til EstimatedRTT + 4 · DevRTT — nøyaktig samme struktur. Gjennomsnittet fanger opp «normaltilstanden», og K · v legger til en sikkerhetsmargin proporsjonalt med hvor mye forsinkelsen varierer. Alle etterfølgende pakker i samme snakkefase spilles av med faste 20 ms mellomrom fra dette utgangspunktet.

Detektere start av ny snakkefase

Mottakeren må vite når en ny snakkefase starter, for det er da playout-forsinkelsen kan justeres. Uten pakketap er det enkelt: hvis forskjellen mellom to påfølgende tidsstempler er > 20 ms, har det vært en stillhetsperiode. Med mulig pakketap ser mottakeren på både tidsstempler og sekvensnummer — hvis tidsstempelgapet er > 20 ms og det ikke mangler sekvensnummer, er det en ny snakkefase.

FEC og interleaving

Tre teknikker for å gjenopprette tapt lyd uten å vente på retransmisjon.

I VoIP har vi ikke tid til den vanlige TCP-metoden med å be om retransmisjon — en retransmisjon tar minst én RTT, og det kan fort overstige forsinkelsesbudsjettet vårt. Vi trenger teknikker som lar mottakeren gjenopprette tapte pakker uten hjelp fra senderen.

1. Enkel FEC (XOR)

For hver gruppe av n lydbiter lager senderen én ekstra redundant bit ved å XOR-e alle de n originale sammen. Senderen sender altså n+1 pakker i stedet for n, noe som øker båndbredden med en faktor 1/n.

2. Piggyback med lavkvalitetsstrøm

En mer elegant variant: senderen legger ved en lavoppløselig kopi av en tidligere lydbit i hver pakke. For eksempel kan den nominelle strømmen bruke PCM med 64 kbps, mens den redundante strømmen bruker GSM med 13 kbps.

Hvis pakke 3 går tapt, mister vi chunk 3 i full kvalitet, men chunk 2 kan gjenopprettes fra den lave kopien i pakke 4. Resultatet er at bare sammenhengende tap gir hørbare hull. Overhead-en er beskjeden (13 kbps ekstra i dette eksempelet).

3. Interleaving

En tredje teknikk som ikke krever ekstra båndbredde i det hele tatt. Idéen: hver 20 ms lydbit deles opp i fire 5 ms enheter. Enhetene fra forskjellige biter blandes sammen i pakkene. Hvis én pakke går tapt, mister vi bare én liten 5 ms enhet fra fire forskjellige biter — i stedet for en hel sammenhengende 20 ms bit. Hvert hull er så kort at det nesten ikke høres.

Skype: P2P VoIP i praksis

Et tidlig eksempel på storskala VoIP — med supernoder, overlay-nettverk og NAT-traversering.

Skype var i mange år det dominerende eksempelet på VoIP over Internett. Det brukte en proprietær, kryptert protokoll som ble reverseengineered av forskere. Arkitekturen er interessant fordi den kombinerer P2P-elementer med sentralisert kontroll.

Arkitekturen

• Skype-klienter (SC): vanlige brukere som kjører Skype-applikasjonen. Under en samtale kobler to klienter seg direkte til hverandre for selve VoIP-datastrømmen.
• Supernoder (SN): utvalgte Skype-peers med spesielle funksjoner — de hjelper til med å lokalisere andre brukere og rute trafikk gjennom et overlay-nettverk.
• Overlay-nettverk: supernodene danner et overliggende nettverk seg imellom for å finne brukeres IP-adresser.
• Login-server: en sentralisert server for autentisering (brukernavn/passord).

Oppkobling av en samtale

1. Klienten kobler seg til en supernode (IP-adressen er cachet lokalt) via TCP.
2. Logger inn mot den sentraliserte login-serveren.
3. Får IP-adressen til den man vil ringe fra supernodenes overlay (eller fra kontaktlisten).
4. Initierer samtale direkte til den andre klienten.

NAT-problemet og relay-løsningen

Det interessante problemet oppstår når begge samtalepartene sitter bak NAT. En NAT lar ikke utenforstående initiere en forbindelse inn til en enhet på innsiden — det er jo hele poenget med NAT. Så hvordan kobler to «innelåste» klienter seg til hverandre?

Løsningen: Alice og Bob holder begge en åpen TCP-forbindelse til sin respektive supernode (forbindelsen er initiert innenfra NAT-en, så den er tillatt). Når Alice vil ringe Bob, signalerer hun gjennom sin SN til Bobs SN, som bruker sin åpne forbindelse til Bob. Selve taledataene kan da relays gjennom supernodene. Det er ikke optimalt (dobbelt så mange hopp), men det fungerer selv når begge parter er bak NAT.

RTP — Real-Time Protocol

En tynn protokoll som gir multimedia-pakker det de trenger: type-identifikasjon, sekvensnummer og tidsstempler.

RTP (RFC 3550) er protokollen som gir struktur til multimedia-pakker. Den er ikke en transportprotokoll i tradisjonell forstand — den kjører oppå UDP og gir et sett med felter som applikasjoner trenger for å håndtere sanntidsdata, men som UDP ikke tilbyr: informasjon om hva slags data pakken inneholder, i hvilken rekkefølge den hører hjemme, og nøyaktig når den ble generert.

Hva RTP gir oss

RTP oppå UDP

RTP-biblioteker tilbyr et transportgrensesnitt som utvider UDP med de feltene multimedia trenger. En RTP-pakke består av en RTP-header etterfulgt av lyddata (payload), og hele denne pakken pakkes inn i et UDP-segment. Fra nettverkets synspunkt er det bare en vanlig UDP-pakke — rutere underveis ser aldri RTP-headeren og behandler pakken med vanlig best-effort.

Eksempel: 64 kbps PCM over RTP

En VoIP-applikasjon som sender 64 kbps PCM-kodet tale over RTP gjør følgende:

1. Samler inn 160 bytes lyddata hvert 20. millisekund (= 8000 bytes/s = 64 kbps).
2. Legger til en RTP-header med payload-type, sekvensnummer og tidsstempel.
3. Pakker alt inn i et UDP-segment og sender det.
4. Senderen kan endre kodingstype midt i samtalen — RTP-headeren forteller mottakeren om endringen via payload-type-feltet.

RTP-headeren i detalj

RTP og QoS

Et viktig poeng til slutt: RTP gir ingen QoS-garantier. RTP-pakker er innkapslet i vanlige UDP-segmenter, og rutere i nettet ser bare et IP-datagram med en UDP-header. De gjør ingen spesiell innsats for å levere RTP-pakker raskere eller mer pålitelig enn andre pakker. All smarthet — adaptiv playout, FEC, jitterbuffer — ligger i endepunktene, ikke i nettverket.