Prediksjon 3 — «Wildcard-pensum»

Riktig svar: B

Pure ALOHA: 1/(2e) ≈ 18 %. Slotted ALOHA: 1/e ≈ 37 %. Synkronisering halverer kollisjons­vinduet — to pakker kolliderer kun hvis de starter i samme slot, ikke hvis én starter mens en annen sender.

Trade-off: slotted krever globalt klokke-synk; pure trenger ikke det.

Pensum: Kap. 6.3 — ALOHA

Riktig svar: C

NAT-ruteren erstatter både kilde-IP og kilde-port. Den private IP-en er ikke synlig utenfor. Den oversatte porten lagres i en NAT-tabell sammen med (privat IP, privat port, dest IP, dest port), slik at svar-pakker kan rutes tilbake til riktig intern host.

Felle: B antar at kilde-port forblir uendret. Det er bare unntaksvis — hvis flere interne klienter tilfeldigvis bruker samme kilde-port, må NAT mappe om for å unngå kollisjon.

Pensum: Kap. 4.3 — NAT

Riktig svar: C — Port 3

Adressen matcher tre prefikser: /8, /16 og /24. Lengste prefiks-match velger /24, dvs. port 3.

Default-ruten (/0) brukes bare hvis ingen andre prefikser matcher.

Pensum: Kap. 4.3 — Longest prefix match

Riktig svar: B

Pakker ankommer med varierende forsinkelse (jitter). Ved å samle opp et par sekunder med video først, kan klienten spille av jevnt — selv om enkelte pakker er litt sen­ankomne. Dette er forutsetningen for at HTTP- og DASH-streaming kan levere god kvalitet uten direkte sanntids­garantier fra nettverket.

Kostnaden er økt initial avspillings­forsinkelse: typisk 2–10 s buffring før første frame vises.

Pensum: Kap. 9.2 — Streaming og playout-buffer

Riktig svar: B

To hovedgrunner: (1) Mange brannmurer er konfigurert til å blokkere UDP men tillate HTTP/HTTPS over port 80/443. (2) Med HTTP får streaming-applikasjoner pålitelig levering «gratis» — kombinert med playout-buffer er det god nok kvalitet for de fleste video­typer.

UDP brukes fortsatt der lav forsinkelse er kritisk (live-stream, VoIP, spill).

Pensum: Kap. 9 — Streaming

Riktig svar: C

Lavere SNR (mer støy relativt til signal) → flere feiltolkede bits → høyere BER. For en gitt SNR pakker høyere-rate modulasjoner inn flere bit per symbol; konstellasjons­punktene blir tettere; støy får lettere kastet et symbol til feil punkt → høyere BER.

Praktisk konsekvens: WiFi/4G/5G velger lavere modulasjon når SNR faller, for å holde BER lav.

Pensum: Kap. 7.1 — Trådløse karakteristikker

Riktig svar: B

5G er designet for høyere peak-bitrate, lavere latens og MIMO-kapasitet. mmWave-bånd (24+ GHz) gir høy båndbredde men kort rekkevidde og dårlig vegg­penetrering — derfor brukes også sub-6 GHz-bånd. Kontroll/data-plan-separasjon er en annen viktig 5G-egenskap.

Pensum: Kap. 7.4 — Mobilnett

Riktig svar: A — KHOS

(x + 3) mod 26: H(7)→K(10), E(4)→H(7), L(11)→O(14), P(15)→S(18). Resultat: KHOS.

Cæsar er svak: bare 25 mulige nøkler — brute force på sekunder. Bevarer dessuten bokstavfrekvensene.

Pensum: Kap. 8.2 — Substitusjon

Riktig svar: B

De to ordene er hverandres ones' complement (bit for bit invers). Summen blir alltid 1111 1111 1111 1111. Checksum = ones' complement av summen = 0000 0000 0000 0000.

Mottaker summerer alle ordene inkludert checksummen og forventer å få 1111 1111 1111 1111 (alle 1-er). Hvis så, ingen oppdaget feil.

Pensum: Kap. 3.3 — UDP-sjekksum

Riktig svar: C — CSMA/CD

Tre kategorier:

• Kanalpartisjonering: TDM, FDM, CDMA (CDMA er ikke pensum, men kan komme som distraktor).
• Tilfeldig tilgang: Pure ALOHA, Slotted ALOHA, CSMA/CD, CSMA/CA.
• Taking turns: Token Ring, polling-baserte protokoller (Bluetooth — ikke pensum).

Pensum: Kap. 6.3 — Multiple access

Riktig svar: B

Ved enkeltbit-feil vil nøyaktig én rad og én kolonne vise feil paritet — krysningen identifiserer den feile bit-en, som så kan flippes. 2D-paritet kan oppdage de fleste 2-bits-feil men kan ikke alltid korrigere dem entydig (4 bit på et rektangel kan være «usynlige»). CRC er mye sterkere.

Pensum: Kap. 6.2.2 — 2D-paritet

Riktig svar: B — ρ = 0,8

ρ = L·a/R = 10 000·800 / 10⁷ = 8·10⁶/10⁷ = 0,8.

For ρ < 1 er køen i prinsippet stabil; men gjennomsnittlig køforsinkelse går mot uendelig når ρ → 1. Ved ρ ≥ 1 vokser køen ubegrenset (eller pakker dropes når bufferen fylles).

Pensum: Kap. 1.4 — Trafikkintensitet

Riktig svar: C

Brannmurer beskytter mot uautorisert tilgang ved å filtrere trafikk basert på adresser, porter, flagg, forbindelsestilstand eller applikasjonsdata. De erstatter ikke kryptering eller autentisering — de er ett lag i et lagdelt forsvar.

Pensum: Kap. 8.9 — Brannmurer

Riktig svar: C

Cache reduserer latens og båndbredde-behov for objekter som er populære innad i institusjonen, og avlaster opphavs­serveren. Den har ingenting med kryptering å gjøre — og har faktisk ofte problemer med kryptert HTTPS-trafikk fordi cachen ikke kan se innholdet uten å bryte tilliten.

Pensum: Kap. 2.2 — HTTP og web-caching

a) Hvorfor vente?

Pakker over Internett ankommer med varierende forsinkelse (jitter). Hvis avspilling startet umiddelbart, ville senere pakker som er forsinket bli «for sene» og resultere i hakking. En innledende ventetid lar klienten bygge opp en buffer av flere fremtidige blokker, slik at avspilling skjer jevnt selv ved variasjon.

Større initial buffer ⇒ flere blokker rekker frem i tide, men også høyere innledende forsinkelse for brukeren.

b) Avspilling fra t₁ + Δ:

Blokk i skal spilles av ved tid t1 + (i)·Δ (fra og med i=1: t₁+Δ for blokk 1, t₁+2Δ for blokk 2, ...).

Blokk	Avspillings-tid	Ankomst-tid	I tide?
1	t1+Δ	t1	Ja
2	t1+2Δ	t1+0,5Δ	Ja
3	t1+3Δ	t1+2,5Δ	Ja
4	t1+4Δ	t1+2Δ	Ja
5	t1+5Δ	t1+3,5Δ	Ja
6	t1+6Δ	t1+5Δ	Ja
7	t1+7Δ	t1+5,5Δ	Ja

Alle blokkene rekker frem i tide.

(Merk: dette eksemplet er konstruert slik at jitter er liten relativt til ventetid Δ. Med en mer aggressiv jitter ville noen blokker bli forsinket.)

c) Avspilling fra t₁ + 2Δ:

Avspillings-tidene skifter med Δ ekstra: blokk i spilles ved t1 + (i+1)·Δ. Alle blokker har nå Δ ekstra slack — alle rekker fortsatt fram, og marginen er større.

Trade-off: Større playout-forsinkelse ⇒ mer robust mot jitter (færre eller ingen «tapte» blokker), men brukeren venter lenger på første frame. Dette er kjernen i playout-buffer-design — typisk sekunder ved live-streaming, lenger ved on-demand video.

Pensum: Kap. 9.2 — Streaming og playout-buffer

a) Forwarding:

Adresse	Match-prefiks	Utport
192.168.64.10	/16, /18, /20 — lengste = /20	3
192.168.96.50	/16, /18, /22 (96 er innenfor /18 64.0; sjekk /22 96.0 — match) — lengste = /22	4
192.168.200.5	/16 (200 er ikke innenfor 64.0/18 → 64–127, eller 96.0/22) — kun /16	1
10.0.0.1	Ingen prefiks unntatt default (/0)	5

Detaljert utregning for 192.168.64.10:

• /16: 192.168.0.0: andre oktett 168 = 168 ✓
• /18: 192.168.64.0: tredje oktett /18 betyr de to øverste bit i tredje oktett må matche 64 (binær 01...). 64 binært er 0100 0000, så øverste 2 bit = 01. 64 også 01 — ✓
• /20: 192.168.64.0: tredje oktett 4 øverste bit = 0100. 64 også 0100 — ✓
• /22: 192.168.96.0: tredje oktett 6 øverste bit må = 96 (binær 011000) = 0110 00. 64 = 0100 00 — ulik 0110 00 — ✗

Lengste match: /20 → port 3.

b) Hvorfor lengste prefiks-match?

Lengste prefiks-match gir mest spesifikk rute først. Eksempel: en /22-rute mot en mindre kunde inne i en /16-blokk. Hadde ruteren brukt første-match, ville rekkefølgen i tabellen avgjøre — og da ville en mer generell /16 før den spesifikke /22 sende trafikk feil sted. Lengste prefiks-match unngår denne sortering-avhengigheten og gjør forwarding-tabellen rekkefølge-uavhengig.

Det er også grunnlaget for hvordan Internett støtter «hierarkisk» tildeling av adresser: ISP får /16, kunden får /22 inne i den, og forwarding finner alltid mest spesifikk vei.

Pensum: Kap. 4.3 — IP-forwarding

a) NAT-tabell:

WAN-side (utside)	LAN-side (innside)	Dest (server)
200.10.20.30 : 41000	192.168.1.5 : 5000	198.51.100.7 : 80
200.10.20.30 : 41001	192.168.1.6 : 5000	198.51.100.7 : 80

NAT må endre kilde-port (41000, 41001) for å skille de to forbindelsene utad. WAN-siden viser hva ekstern verden ser; LAN-siden viser den faktiske private IP/port; dest holder destinasjonen for å kunne matche svar.

b) Svar fra serveren:

• (i) På vei mot NAT: kilde = 198.51.100.7:80, dest = 200.10.20.30:41001 (eller 41000).
• (ii) Etter NAT (på LAN-side): kilde uendret = 198.51.100.7:80, dest = 192.168.1.6:5000 (eller 192.168.1.5:5000).

NAT slår opp i tabellen ved å matche dest-IP+port på WAN-siden — finner unik LAN-side-oppføring og oversetter dest tilsvarende.

c) Problemer med embedded IP/port:

Protokoller som SIP, FTP (passiv mode), H.323 og noen P2P-protokoller legger IP-adresser eller port-numre inne i applikasjons­dataen — for at den andre siden skal kunne kontakte tilbake. Når NAT bare endrer headeren, blir den interne IP-en i payloaden ugyldig utenfor.

Løsninger:

• Application-layer gateways (ALG): NAT-en parser kjente protokoller og endrer også payload.
• STUN / TURN / ICE: applikasjonen oppdager sin offentlige IP og bruker den i payload.
• UPnP IGD eller manuelle port-forwarding: klient kan be om en stabil mapping.

NAT er en viktig grunn til at IPv6 er ønsket — alle endenoder kan da ha global rutbar adresse uten oversettelse.

Pensum: Kap. 4.3.4 — NAT

a) Ren CSMA:

Ved t=0 begynner A å sende. B sjekker kanalen ved t=0,1 — A's signal har ikke nådd B ennå (forplantning 0,2). B oppfatter kanalen som ledig og begynner også å sende. Kollisjon mellom A og B. I ren CSMA fortsetter begge å sende hele pakken sin (1 tidsenhet) selv om dataene er ødelagt. Begge er ferdig ved ca. t=1.

Ved t=1,2 er kanalen ledig — C sjekker, ser ledig, sender. D klar ved t=1,5 sjekker — har C's signal nådd D? Avhengig av geografi og 0,2 forplantning. Anta D er nær C: ja, kanal er opptatt → D venter. C lykkes, ferdig ved t=2,2.

D venter til kanal blir ledig ved t=2,2 (+ propagering). D sender deretter, ferdig ca. t=3,4.

A klar igjen ved t=3,0; sjekker kanalen — D's signal har nådd A: D opptar. A venter til D er ferdig (~t=3,4 + 0,2 propagering = 3,6). A sender, ferdig ca. t=4,6.

C klar igjen ved t=4,1; sjekker kanalen — A's sending opptar. C venter. A ferdig 4,6 + 0,2 propagering = 4,8. C starter, ferdig 5,8 — etter t=5.

Lykkede sendinger før t=5: C (første), D, A (andre). A og B kolliderte. C (andre) blir ferdig akkurat etter t=5.

(Studenten får poeng for å vise riktig metode og resonere med propageringsforsinkelse.)

b) CSMA/CD:

Ved kollisjon mellom A og B ved t≈0,1 detekterer begge kollisjonen raskt (innen 0,2 tidsenheter), avbryter sendingen umiddelbart, og venter en random backoff. La oss si A backoff = 0,3, B backoff = 0,5.

Kanalen er ledig igjen tidlig — la oss si t≈0,3. A starter på nytt ved t=0,3+0,3 = 0,6. Lykkes, ferdig t=1,6.

B er klar etter sin backoff ved 0,3+0,5 = 0,8 — ser kanal opptatt (A sender), venter. Etter A ferdig (t=1,6), kanal blir ledig — men nå starter også C (klar t=1,2, har ventet) og D (klar t=1,5). Avhengig av detaljer kolliderer de igjen og må backoff på nytt.

Forskjellen: ved kollisjon i CSMA/CD avbrytes sendingen umiddelbart i stedet for at hele pakken «sløses» bort. Ved kollisjon på t≈0,1 mellom A og B er kanalen ledig igjen ved t≈0,3 i stedet for t=1. Det betyr mer tid til vellykkede sendinger — høyere effektivitet, særlig under høy belastning.

(Eksakte tider avhenger av antatt backoff. Studenten skal vise resonnementet og demonstrere at CD reduserer kollisjons­kostnaden.)

Pensum: Kap. 6.3 — CSMA/CD

a) TLS-tjenester:

1. Konfidensialitet: data krypteres med en symmetrisk sesjonsnøkkel.
2. Integritet: hver melding inkluderer en MAC (Message Authentication Code) som mottaker verifiserer.
3. Autentisering: server (og evt. klient) autentiseres via X.509-sertifikater fra en betrodd CA.

Hvorfor over TCP: TLS bygger på pålitelig, in-order levering — ellers ville krypterte/MAC-validerte meldinger måtte håndtere reordering og tap selv. UDP-varianten av TLS kalles DTLS og kompenserer for dette med ekstra mekanismer; den brukes blant annet i WebRTC og VPN-er.

b) RTP-headerens to nøkkelfelt:

• Sekvensnummer: RTP teller pakker, slik at mottaker kan oppdage tap og rekke­følge­problemer (UDP gir ikke dette).
• Tidsstempel (timestamp): indikerer når mediaprøven ble laget hos avsender. Mottaker bruker dette til å spille av media på riktig tidspunkt — kritisk for både playout-buffer og synkronisering av flere strømmer (audio + video).

Uten disse to feltene måtte applikasjonen selv legge til lignende informasjon i payload — RTP standardiserer det.

c) CDN-fordeler:

1. Lavere ende-til-ende-forsinkelse for klienten — klienten betjenes fra en kopi nær geografisk, ikke fra én sentral server tvers over jorda.
2. Avlasting av opphavs­serveren og høyere total kapasitet — populært innhold (videoer, oppdateringer) serveres parallelt fra mange CDN-noder. Mindre risiko for overbelastning ved trafikktopper, og mindre båndbredde ut av opphavs­datasenter.

(Andre gyldige svar: bedre robusthet ved nodefeil, lavere transit-kostnader for ISP-er, bedre kvalitet for video-streaming pga lavere RTT og mindre jitter.)

Pensum: Kap. 8.6 — TLS · Kap. 9.3 — RTP · Kap. 2 — CDN