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.

Hvor båndbredde-tung er video, egentlig?

For å sette tallene i kontekst, sammenlign tre brukere som er aktive i 67 minutter:

Video bruker altså en hel størrelsesorden mer båndbredde enn musikk eller bildetunge nettsteder. Cisco anslo at video ville utgjøre rundt 80 % av all forbruker-Internett-trafikk i 2019 — og det er denne dominansen som gjør designvalg for video-streaming så viktige for hele Internett-økosystemet.

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.

Matematisk analyse av buffring

La oss formalisere intuisjonen. La B være bufferstørrelsen (i bits), Q antall bits som må bufres før avspilling starter (Q < B), r avspillingsraten (bits/s) og x fyllraten fra serveren (bits/s). Initial playout-forsinkelse t_p er da tiden det tar å bygge opp Q bits:

Hva som skjer etter t_p avhenger av forholdet mellom x og r:

Hovedinnsikten: kontinuerlig avspilling krever bare at gjennomsnittlig x(t) holder seg over r. Korte perioder der x < r tåles fint, så lenge bufferen ikke tømmes helt. Wang et al. (2008) viste at hvis gjennomsnittlig TCP-throughput er rundt det dobbelte av mediabitraten, gir HTTP-streaming minimal frysing og lav playout-forsinkelse — det er denne tommelfingerregelen mange streamingtjenester planlegger etter.

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.

Prefetching: laste ned raskere enn man spiller av

Når video strømmes over HTTP/TCP, prøver klienten å laste ned raskere enn forbruksraten r. Hvis nettverket leverer 1,5 Mbps og videoen krever 1 Mbps, går overskuddet på 500 kbps til å bygge opp en reserve i applikasjonsbufferen. Denne prefetching-en skjer naturlig — ikke fordi applikasjonen ber om det, men fordi TCPs metningskontroll prøver å bruke all tilgjengelig båndbredde. Reserven gjør at hvis nettverket senere droppes til under r i en kort periode, kan klienten fortsatt spille av kontinuerlig fra det som er bufret.

Et fullt applikasjonsbuffer setter også en indirekte øvre grense på sende-raten: når klientbufferen er full, slutter den å lese fra TCP-mottakerbufferen, som blir full, som «back-pressurer» tilbake til serveren via TCPs flytkontroll. Slik unngår man at en uendelig hurtig server fyller klientens minne unødig.

HTTP byte-range header: seek og repositionering

Når brukeren spoler i videoen (klikker et nytt punkt på tidslinjen), sender klienten en ny HTTP GET-forespørsel med en byte-range header som spesifiserer fra hvilken byte i filen serveren skal sende. Serveren glemmer da forrige forespørsel og starter på nytt fra det angitte punktet. Det er den samme mekanismen som lar HTTP fungere som streaming i utgangspunktet — klienten «late-binder» til filen i stedet for å laste ned alt i én blokk.

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.

Hva ende-til-ende-forsinkelse består av

Før vi snakker om hvor mye forsinkelse VoIP tåler, er det nyttig å bryte ned hva ende-til-ende-forsinkelsen faktisk består av. En VoIP-pakkes reise fra mikrofon til høyttaler er en sum av flere komponenter:

• Pakketiseringsforsinkelse: tiden senderen bruker på å samle nok lyddata til en pakke (typisk 20 ms i VoIP — det er en hard nedre grense satt av kodingen).
• Transmisjonsforsinkelse: tiden å klokke pakken ut på senderens link (pakke-størrelse / link-rate).
• Propageringsforsinkelse: tiden signalet bruker over fysiske medier — dominert av geografisk avstand. Norge til USA er ~70 ms én vei i lyset alene; lengre om det går via undersjøkabler.
• Køforsinkelse i rutere: hovedkilden til jitter. Varierer per pakke avhengig av trafikken på hvert hopp.
• Prosesseringsforsinkelse: tid brukt på pakkebehandling i rutere og endenoder (typisk lite, men ikke null).
• Playout-forsinkelse hos mottaker: tiden mottakeren venter med å spille av pakken — typisk 50–200 ms for å absorbere jitter.

De første fem styres av nettverket og er stort sett utenfor applikasjonens kontroll. Den siste — playout-forsinkelsen — er den eneste applikasjonen kan justere. Hele hemmeligheten ved VoIP-design ligger i å sette den så lavt som mulig uten å miste for mange pakker.

Krav til forsinkelse

Pakketap og forsinkelsestap

VoIP må takle to typer tap:

Et viktig poeng: VoIP tåler noe tap. Avhengig av lydkoding og error concealment-teknikker, 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.

Feilretting ved mottaker (error concealment)

Når en pakke er tapt eller ankommer for sent, må mottakeren produsere noe lyd for de 20 ms som mangler. I kapittelutdraget beskrives to mottakerbaserte teknikker:

• Pakkegjentakelse (packet repetition): erstatt tapte pakker med en kopi av pakken som kom rett før tapet. Lav beregningskostnad og fungerer bra ved små tap.
• Interpolering (interpolation): bruk lyden før og etter tapet til å konstruere en erstatningspakke. Bedre kvalitet, men tyngre beregning.

Dette er komplementært til FEC og interleaving (neste seksjon): FEC og interleaving prøver å unngå tap; disse teknikkene tar over når pakken likevel mangler. Sammen med adaptiv playout gjør det at VoIP kan tåle en del pakketap.

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 glidende gjennomsnitt av observerte forsinkelser (utdraget bruker en liten vekt α på nyeste måling), på samme måte som når TCP estimerer rundturtid i kapittel 3:

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). Strukturen ligner på hvordan TCP setter utløpstid ut fra estimert RTT og variasjon i kapittel 3: et glidende gjennomsnitt av forsinkelse pluss et ledd proporsjonalt med avvik. 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. I kapittelutdraget beskrives at mottakeren kan undersøke signalenergien i hver mottatt pakke: lav energi tyder på stillhet, høy energi på tale.

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 super peers, 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 distribuert indeksering.

Arkitekturen

• Skype-klienter: vanlige brukere som kjører Skype-applikasjonen. Under en samtale kobler to klienter seg gjerne direkte til hverandre for selve tale-/videostrømmen.
• Super peers: utvalgte Skype-peers med spesielle funksjoner — de hjelper til med å lokalisere andre brukere og med relay gjennom et overlay-nettverk.
• Overlay-nettverk: super peers danner et overliggende nett seg imellom; en distribuert indeks mapper Skype-brukernavn til gjeldende IP-adresser (og portnumre).

Oppkobling av en samtale

1. Klienten kobler seg til en super peer (forbindelsen er initiert innenfra NAT der det trengs).
2. Klienten søker i den distribuerte indeksen for å finne IP-adressen til den som skal ringes.
3. Vanlig toveis samtale går peer-to-peer; ved NAT-problemer brukes relay via en ikke-NATet super peer, som beskrevet nedenfor.

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 i utdraget: når begge har NAT, velger to super peers en tredje, ikke-NATet relay peer som mellomledd. Alice og Bob initierer hver sin sesjon til relayen (fra innsiden av NAT), og relayen videresender pakker. Tale går da over to hopp via relay — tyngre enn direkte P2P, men det fungerer når direkte forbindelse blokkes.

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.

Hvor passer RTP inn?

I kapittelutdraget 9.4 introduseres RTP (Real-Time Transport Protocol) for sanntidsmediedata, og SIP for samtale-oppsett. Pensum dekker RTP; SIP kan utelates.

RTP brukes i mange kommersielle VoIP- og videosystemer sammen med UDP. Protokollen standardiserer hvordan mediechunks innkapsles slik at ulike applikasjoner kan samhandle.

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.

Det du skal sitte igjen med

Multimedia over pakkenett handler om én fundamental spenning: innholdet krever jevn, tidssensitiv levering, mens Internett bare lover «best effort». Resten av kapittelet er en serie teknikker for å brø seg mellom disse to verdenene — i endepunktene, ikke i nettverket.

De fem nøkkelpunktene fra kapittelet:

Den røde tråden: alle disse teknikkene — buffering, adaptiv playout, FEC, interleaving, error concealment, RTP — er svar på det samme grunnproblemet: et tidssensitivt medium som skal fungere over et nettverk som ikke gir noen tidsgarantier. Løsningen ligger alltid i endepunktene, aldri i nettverket.