Metningskontroll
og evolusjon

Hvorfor metningskontroll?

Flow control beskytter én mottaker. Metningskontroll beskytter det delte nettverket mellom alle sendere.

Tenk deg en motorvei der hver sjåfør bestemmer sin egen fart. Uten noen form for regulering — trafikklys, fartsgrenser, påkjøringsramper — vil veien til slutt gå i lås. Metningskontroll i TCP er trafikklyset: en mekanisme som lar sende ren justere farten sin basert på hvor fullt nettverket virker å være, uten at noen sentral myndighet styrer det.

To vinduer, én begrensning

TCP-senderen styres av to vinduer som begge legger begrensninger:

Regelen er enkel:

TCPs senderrate blir da omtrent:

Bottleneck-lenken

Når TCP øker sendraten, er det til slutt én lenke i stien som blir mettet — bottleneck-lenken. Ruterens utgangskø fyller seg opp, og pakker begynner å gå tapt. Nøkkelinnsikten:

To tilnærminger til metningskontroll

Det finnes to fundamentalt forskjellige måter å angripe metningsproblemet på:

Internettets TCP har tradisjonelt vært rent end-to-end: IP-laget gir ingen hjelp, og senderen er overlatt til seg selv. All informasjon om nettverkets tilstand må utledes indirekte — fra ACK-er som uteblir, fra forsinkelser som øker, eller fra pakker som forsvinner. Det er nettopp dette som gjør TCP-metningskontroll til et så elegant og utfordrende problem.

Eksponentiell opptrapping

Navnet er misvisende — slow start er faktisk den raskeste fasen av TCP. Vinduet dobles hver RTT.

Når en TCP-forbindelse nettopp er opprettet, vet senderen ingenting om nettverkets kapasitet. Å sende for mye umiddelbart kan forårsake metning. Å sende for lite kaster bort tid. Løsningen er å starte forsiktig og doble sendraten for hver RTT til man treffer en grense.

Mekanismen

Eksempel

Med MSS = 1500 bytes og RTT = 200 ms:

Initiell rate: 1500 / 0.2 = 7.5 kB/s. Etter 4 RTT-er: 24 000 / 0.2 = 120 kB/s. Eksponentiell vekst rammer raskt opp til tilgjengelig kapasitet.

Når slutter slow start?

Slow start avsluttes ved ett av tre hendelser:

• Timeout — cwnd settes tilbake til 1 MSS, ssthresh = cwnd/2, og slow start starter på nytt.
• cwnd ≥ ssthresh — overgang til congestion avoidance (lineær vekst).
• 3 dupliserte ACKs — overgang til fast recovery.

Additive increase, multiplicative decrease

Når cwnd har nådd ssthresh, skifter TCP fra eksponentiell til forsiktig lineær vekst — og halverer brutalt ved tap.

AIMD (Additive Increase, Multiplicative Decrease) er kjernen i TCPs metningskontroll. Ideen er vakker i sin asymmetri: voks sakte oppover, kutt raskt nedover. Denne asymmetrien gir stabilitet og rettferdighet — egenskaper som ren eksponentiell vekst aldri kunne gitt.

Additive increase

I congestion avoidance-fasen øker cwnd med 1 MSS per RTT — ikke per ACK som i slow start. Formelen per ACK er:

Multiplicative decrease

Ved pakketap halverer TCP vinduet:

Sagtann-mønsteret

Resultatet er det karakteristiske sagtannmønsteret: cwnd vokser lineært oppover, faller brått ved tap, vokser lineært igjen. TCP «sonderer» stadig etter mer båndbredde.

Regneeksempel: congestion avoidance

Reno vs. Tahoe

Ikke alle pakketap er like alvorlige. Tre dupliserte ACKs betyr at noe fortsatt kommer frem — og TCP kan reagere mildere.

Det er en vesentlig forskjell mellom en timeout og tre dupliserte ACKs. En timeout betyr: «Jeg har ikke hørt noe som helst på lenge — nettverket er kanskje helt nede.» Tre dupliserte ACKs betyr: «Ett segment gikk tapt, men andre segmenter kommer frem — for mottakeren sender jo ACKs.» TCP Reno utnytter denne forskjellen.

TCP Tahoe (den opprinnelige)

TCP Tahoe (1988) behandler alle tap likt:

TCP Reno (forbedringen)

TCP Reno (1990) differensierer:

Hva skjer i fast recovery?

Under fast recovery øker cwnd med 1 MSS for hver dupliserte ACK som ankommer (disse tyder på at etterfølgende segmenter kommer frem). Når en ny ACK ankommer (som bekrefter det retransmitterte segmentet), avsluttes fast recovery:

Sammenligning

Reno unngår den kostbare turen tilbake til 1 MSS ved dupliserte ACKs — noe som kan spare mange RTT-er med lav gjennomstrømning.

Raskere tilbake med kubisk funksjon

AIMD er rettferdig, men langsom. CUBIC bruker en smartere kurve for å utnytte kapasiteten raskere.

Klassisk TCP bruker AIMD: lineær økning med 1 MSS per RTT. På en lenke med høy kapasitet og lang forsinkelse kan det ta mange RTT-er å fylle lenken etter et tap. CUBIC stiller spørsmålet: kan vi gjøre det bedre?

Innsikten

Kubisk vekst

CUBIC øker cwnd som en funksjon av tiden siden siste tap, ikke av RTT:

• Langt fra W_max — store, raske økninger (kurven er bratt).
• Nær W_max — forsiktige, små økninger (kurven flater ut).
• Forbi W_max — sonderer forsiktig etter ny kapasitet (kurven stiger igjen).

Punktet K er tidspunktet der cwnd ville nå W_max. K er tunbart. Kurven er symmetrisk rundt K — den ligner en kubisk funksjon (derav navnet).

Er TCP fair?

Hvis K TCP-sesjoner deler en flaskehals med kapasitet R, bør hver ideelt sett få R/K.

Rettferdighet er ikke bare et akademisk spørsmål — det handler om internettets grunnleggende funksjon. Hvis én forbindelse kunne ta alt, ville alle andre sulte. AIMD har en elegant egenskap: under idealiserte forhold konvergerer parallelle TCP-forbindelser mot lik fordeling.

AIMD-konvergens

Betrakt to TCP-sesjoner som deler en bottleneck med kapasitet R. Plott gjennomstrømningen til sesjon 1 på x-aksen og sesjon 2 på y-aksen:

A → B: begge sesjoner øker additivt (helning 45°) til de treffer kapasitetsgrensen.
B → C: begge halverer cwnd (trekker mot origo), men dette flytter punktet nærmere den grønne linjen.
Gjenta — punktet konvergerer mot lik fordeling.

Forutsetningene

Rettferdighet og UDP

UDP-applikasjoner (f.eks. videostrømming) deltar ikke i metningskontroll. De kan sende så fort de vil og tar dermed mer enn sin «rettferdige» andel. Det finnes ingen «internettpoliti» som håndhever rettferdighet.

Parallelle TCP-forbindelser

En nettleser som åpner 10 parallelle TCP-forbindelser til en server, får i praksis 10 × sin rettferdige andel sammenlignet med en applikasjon som bruker én forbindelse. Dette er en «lovlig» måte å jukse på — og det er utbredt.

Fra Tahoe til QUIC

TCP har utviklet seg i 40 år. Den nyeste evolusjonen flytter transportfunksjonaliteten opp til applikasjonslaget.

TCP og UDP har vært de to transportprotokollene i over fire tiår. I løpet av den tiden har TCP blitt forbedret gjentatte ganger — fra Tahoe via Reno til CUBIC. Men den mest radikale endringen er en helt ny tilnærming: QUIC, som bygger transportfunksjonalitet oppå UDP.

TCPs utvikling

Forskjellige scenarier, forskjellige utfordringer

QUIC: Quick UDP Internet Connections

QUIC er en applikasjonslagsprotokoll bygd over UDP. Den implementerer pålitelighet, metningskontroll, kryptering og multipleksing — alt i brukerrommet, uten å vente på OS-oppdateringer. QUIC er grunnlaget for HTTP/3 og er standardisert i RFC 9000 (2021).

Forbindelsesetablering: 1-RTT og 0-RTT

Med TCP + TLS kreves det minst to serielle håndtrykk: først TCPs tre-veis håndtrykk (1 RTT), deretter TLS-håndtrykket (1 RTT til). Først etter 2 RTT kan applikasjonsdata sendes.

QUIC kombinerer transport- og krypterings-håndtrykket til én enkelt prosess. Klienten sender sin kryptografiske «hello» sammen med forbindelsesparametrene i første pakke, og serveren svarer med sin del — alt i 1 RTT.

Enda bedre: hvis klienten har koblet til serveren tidligere, kan den gjenbruke lagrede kryptografiske nøkler og sende applikasjonsdata allerede i første pakke — såkalt 0-RTT. Serveren kan begynne å behandle forespørselen uten å vente på et komplett håndtrykk.

Strømmer: førsteklasses multipleksing

En sentral innovasjon i QUIC er at strømmer (streams) er et innebygd konsept i selve transportprotokollen. Innenfor én enkelt QUIC-forbindelse kan det opprettes mange parallelle strømmer — uten nye håndtrykk. Hver strøm har:

• Egne sekvensnumre — uavhengig av de andre strømmene
• Egen pålitelig levering — tap og retransmisjon i én strøm påvirker ikke andre
• Egen flytkontroll — både per strøm og per forbindelse

I HTTP/3 tilsvarer hver strøm typisk én HTTP-forespørsel/respons. Nye strømmer kan opprettes med minimal overhead, noe som gjør multipleksing langt mer effektivt enn HTTP/2 over TCP.

QUIC og head-of-line blocking

Med TCP og HTTP/2 deler alle forespørsler én enkelt bytestrøm. Selv om HTTP/2 logisk multiplekser flere forespørsler, er de alle avhengige av TCPs pålitelige, ordnede levering. Hvis et segment tilhørende forespørsel 1 går tapt, må alle tre vente på retransmisjonen — selv om data for forespørsel 2 og 3 allerede er mottatt.

Connection ID og mobilitet

TCP identifiserer en forbindelse med en 4-tuppel: (kilde-IP, kilde-port, dest-IP, dest-port). Hvis en av disse endres — for eksempel når telefonen bytter fra Wi-Fi til mobilnett — må TCP-forbindelsen avsluttes og opprettes på nytt, inkludert nye håndtrykk.

QUIC bruker i stedet en connection ID i pakkene sine. Denne ID-en er uavhengig av de underliggende IP-adressene og portene. Når en klient bytter nettverk, holder connection ID-en forbindelsen i live — klienten fortsetter å sende pakker med samme ID fra sin nye adresse, og serveren gjenkjenner forbindelsen uten re-etablering.

Metningskontroll i QUIC

QUIC implementerer sin egen metningskontroll, separat fra operativsystemets TCP-stabel. Som standard bruker QUIC algoritmer som likner på TCP CUBIC, men siden QUIC kjører i brukerrommet (user space) kan metningskontrollalgoritmen oppdateres uavhengig av OS. Google har for eksempel eksperimentert med og rullet ut BBR (Bottleneck Bandwidth and RTT) i sin QUIC-implementasjon, helt uten å måtte oppdatere operativsystemer.

Oppsummering: QUICs fordeler over TCP

Med dette er hele kapittel 3 dekket: fra transportlagets tjenester og UDP, gjennom TCPs pålitelige dataoverføring, til metningskontroll, CUBIC og QUIC.

cwnd gjennom fasene

Følg utviklingen av congestion window steg for steg — fra slow start, gjennom congestion avoidance, til tap og recovery.