Kapittel 3 Transport Layer

Presentasjon om: "Kapittel 3 Transport Layer"— Utskrift av presentasjonen:

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

2 Kapittel 3: Transportlaget
Mål: forstå prinsippene bak trangsportlags-tjenester: multipleksing/demulti-pleksing pålitelig dataoverføring flytkontroll metningskontroll lære om transportlags-protokoller i Internett: UDP: forbindelsesløs transport TCP: forbindelsesorientert, pålitelig transport TCP metningskontroll Transportlaget

3 Kapittel 3 – oversikt 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

4 Transporttjenester og protokoller
applikasjon transport nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk logisk ende til ende-transport nettlag linklag fysisk nettlag linklag fysisk applikasjon transport nettlag linklag fysisk Transportlaget

5 Transportlag vs. nettlag
Analogi: 12 barn sender brev til 12 andre barn prosesser = barn app meldinger = brev i konvolutter maskiner = hus transportprotokoll = Anne og Bjørn netlagsprotokoll = postens tjenester nettlag: logisk kommunikasjon mellom maskiner transportlag: logisk kommunikasjon mellom prosesser benytter seg av og bygger videre på nettlagstjenester Transportlaget

6 Internett transportlagsprotokoller
pålitelig, i rekkefølge leveranse (TCP) metningskontroll (congestion control) flytkontroll (flow control) oppsett av forbindelse upålitelig, uordnet leveranse: UDP enkel utvidelse av IP (“best-effort”) tjenester som ikke gis: forsinkelsesgaranti båndbreddegaranti applikasjon transport nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk nettlag linklag fysisk logisk ende til ende transport nettlag linklag fysisk nettlag linklag fysisk appliasjon transport nettlag linklag fysisk Transportlaget

7 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

8 Multipleksing/demultipleksing
Multipleksing hos avsender: Demultipleksing hos mottager: levere mottatte segmenter til korrekt socket samle data fra flere sockets, sette på header som senere brukes for demultipleksing = socket = prosess applikasjon transport nettlag linklag fysisk P1 P2 P3 P4 maskin 1 maskin 2 maskin 3 Transportlaget

9 Hvordan demultipleksing virker
maskin mottar IP-datagrammer hvert datagram har avsenders og mottakers IP-adresse hvert datagram bærer med seg ett transportlags-segment hvert segment har avsenders og mottagers portnummer (“well-known” portnumre for spesifikke applikasjoner) maskin bruker IP-adresser og portnumre for å dirigere hvert segment til riktig socket 32 bits avs. portnr mott. portnr andre header-felter applikasjons- data (melding) TCP/UDP segmentformat Transportlaget

10 Forbindelsesløs demultipleksing
Når maskin mottar UDP-segment: sjekker mottagers portnummer i segmentet sender UDP-segmentet til socket med angjeldende portnummer IP-datagrammer med annen avsender IP-adresse og/eller avsender portnummer sendes til samme socket Etablere sockets med portnumre: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); UDP socket identifiseres ved følgende tallpar: (mott. IP-adresse, mott. portnummer) Transportlaget

11 Forbindelsesløs demultipleksing
DatagramSocket serverSocket = new DatagramSocket(6000); klient IP:B P2 IP: A P1 P3 server IP: C SP: 6000 DP: 9000 SP: 9000 DP: 6000 DP: 5000 SP: 5000 SP angir “returadresse” Transportlaget

12 Forbindelsesorientert demux
TCP-socket identifisert ved 4-tuppel: avsender IP-adresse avsender portnummer mott. IP-adresse mott. portnummer mottager bruker alle fire verdier for å levere segmenter til korrekt socket Server maskin kan støtte mange samtidige TCP-sockets: hver socket identifiseres ved sitt eget “4-tuppel” Webservere har ulike sockets for hver klient som kobler seg til ikke-persistent HTTP vil ha ulike sockets for hver forespørsel Transportlaget

13 Forbindelsorientert demultipleksing
klient- IP: A P4 P5 P6 P2 P1 P3 AP: 5775 MP: 80 A-IP: B M-IP: C AP: 9157 AP: 9157 MP: 80 MP: 80 klient- IP: B server- IP: C A-IP: A A-IP: B M-IP: C M-IP: C Transportlaget

14 Forbindelsesorientert demux: Threaded web server
P1 klient- IP: A P4 P2 P1 P3 AP: 5775 MP: 80 A-IP: B M-IP: C AP: 9157 AP: 9157 MP: 80 MP: 80 klient- IP:B server- IP: C A-IP: A A-IP: B M-IP: C M-IP: C Transportlaget

15 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

16 UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internett transport-protokoll “best effort” tjeneste, UDP segmenter kan: forsvinne på veien leveres til applikasjonen i feil rekkefølge forbindelsesløs: ingen håndhilsing mellom avsender og mottager hvert UDP-segment håndteres uavhengig av andre Hvorfor finnes UDP? ikke noe oppsett av forbindelse (mindre forsinkelse) enkel: ingen tilstandsinfo å passe på liten segment-header ingen metningskontroll: UDP kan pøse ut pakker så hurtig man ønsker Transportlaget

17 UDP: User Datagram Protocol [RFC 768]
benyttes ofte for streaming, som er tapstolerant følsom for bitrate annen bruk av UDP DNS SNMP pålitelig overføring over UDP: addér pålitelighet på applikasjonslaget applikasjonsspesifikk feilhåndtering! 32 bits senderport # mott.port # Lengde i byte av UDP- segment inklusive header lengde sjekksum Applikasjons- data (melding) Formatet til UDP-segmenter Transportlaget

18 UDP sjekksum Mål: oppdage bitfeil i det overførte segmentet Sender:
håndtere innholdet i segmentet som sekvens av 16-bits heltall sjekksum: eners komplement addisjon av segmentets innhold sender legger sjekksum-verdi inn i sjekksumfeltet i UDP-headeren Mottager: beregner sjekksummen til mottatt segment sammenlign med verdien i sjekksumfeltet: forskjellig  feil detektert like  ingen feil detektert (men segmentet kan allikevel inneholde feil…) Transportlaget

19 Sjekksum-eksempel Merk:
Når vi adderer tall, skal eventuell minne fra MSB adderes til resultatet Eksempel: adder to 16-bits tall Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit MSB minne sum sjekksum Transportlaget

20 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

21 Prinsipper for pålitelig dataoverføring
den upålitelige kanalens karakteristika vil bestemme kompleksiteten til “reliable data transfer” protkoll (rdt) Transportlaget

22 Reliable data transfer
rdt_send(): kalles ovenfra, (f.eks. av app.). Data skal leveres til mottagers applikasjonslag deliver_data(): kalles av rdt for å levere data til laget over sender- side mottager- side udt_send(): kalles av rdt for å sende data over den upålitelige kanalen rdt_rcv(): kalles når pakke ankommer på mottagersiden Transportlaget

23 Tilstandsmaskin tilstand tilstand 1 2
hendelse som medfører tilstandsendring aksjoner på bakgrunn av tilstandsendring tilstand 1 tilstand 2 tilstand: når man er i en tilstand, vil neste tilstand være endtydig bestemt av neste hendelse Transportlaget

24 rdt1.0: pålitelig overføring over en pålitelig kanal
Vent på kall ovenfra rdt_send(data) Vent på kall nedenfra rdt_rcv(packet) packet = make_pkt(data) udt_send(packet) extract (packet,data) deliver_data(data) sender mottager Transportlaget

25 rdt2.0: kanal med mulighet for bitfeil
kanalen kan gi bitfeil i overførte pakker husk: UDP-sjekksum kan oppdage bitfeil spørsmålet: hvordan håndtere bitfeil: acknowledgements (ACK): kvittering. Mottager varsler senderen når pakken er mottatt uten feil negative acknowledgements (NAK): Negativ kvittering. Mottager varsler senderen når pakken hadde bitfeil sender retransmitterer pakken ved mottak av NAK eksempler fra dagliglivet på bruk av ACK og NAK? nye mekanismer i rdt2.0: feildeteksjon feedback fra mottager: kontrollmeldinger (ACK, NAK) fra mottager til avsender Transportlaget

26 rdt2.0: tilstandsmaskin (bitfeil)
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) mottager rdt_rcv(rcvpkt) && isNAK(rcvpkt) vent på ACK eller NAK vent på kall ovenfra udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) vent på kall nedenfra L sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

27 rdt2.0: operasjon uten feil
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) vent på ACK eller NAK vent på kall ovenfra udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) vent på kall nedenfra L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

28 rdt2.0: feilscenario rdt_send(data) snkpkt = make_pkt(data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) vent på ACK eller NAK vent på kall ovenfra udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) vent på kall nedenfra L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

29 rdt2.0 har en vesentlig feil!
Hva skjer hvis ACK/NAK får bitfeil? sender kan da ikke vite hva mottager ønsket å gi beskjed om! kan ikke bare sende på nytt (retransmittere): mulighet for duplikater Hva kan gjøres?  sekvensnummer Håndtering av duplikater: sender setter på sekvens- nummer på hver pakke sender retransmitterer pakke ved feil i ACK/NAK mottager kaster eventuelle duplikatpakker “stop and wait” Senderen sender en pakke og stopper så og venter på respons fra mottager Transportlaget

30 rdt2.1: Sender (m/sekvensnummer)
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) vent på ACK eller NAK 0 vent på kall 0 ovenfra udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L vent på ACK eller NAK 1 vent på kall 1 ovenfra rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) Transportlaget

31 rdt2.1: Mottager (m/sekvensnummer)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) vent på 0 neden-fra vent på 1 neden-fra rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Transportlaget

32 rdt2.1: diskusjon Sender: sekvensnummer på pakker
det er nok med to sekvensnumre (0 og 1). Hvorfor? må sjekke om mottatt ACK/NAK har bitfeil dobling av antall tilstander tilstand må “huske” om forrige pakke har sekvensnummer 0 eller 1 Mottager: må sjekke om mottatt pakke er duplikat tilstand indikerer om 0 eller 1 er forventet sekvensnummer merk: mottager kan ikke vite om dens sist sendte ACK/NAK ble korrekt mottatt av sender Transportlaget

33 rdt2.2: en NAK-fri protokoll
samme funksjonalitet som rdt2.1, uten bruk av NAK istedenfor NAK, sender mottager ACK for siste pakke som er mottatt korrekt mottager må inkludere sekvensnummeret til den pakken den ACKer dupliserte ACK til sender har samme betydning som mottak av NAK ville hatt. Resultat: retransmisjon av forrige pakke Transportlaget

34 rdt2.2: deler av senders og mottagers tilstandsmaskiner (ikke NAK)
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) vent på kall 0 ovenfra vent på ACK udt_send(sndpkt) deler av senders tilstandsmaskin rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L vent på 0 ned-enfra deler av mottagers tilstandsmaskin udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) Transportlaget

35 rdt3.0: kanal med bitfeil og pakketap
Ny antagelse: på underliggende kanal kan også ha pakketap (både data og ACK) sjekksum, sekvensnr, ACK, retransmisjoner vil vært til help, men ikke tilstrekkelig Mulig løsning: sender venter en “rimelig” tid på ACK retransmitterer dersom det ikke har kommet ACK i løpet av denne tiden hvis pakke eller ACK bare er forsinket (ikke tapt): retransmittert pakke vil være duplikat, men bruk av sekvensnummer håndterer dette mottager må angi sekvens-nummeret til pakken den ACKer krever bruk av timer (nedtellingsklokke) Transportlaget

36 rdt3.0 sender (pakketap) L L L L rdt_send(data) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L L vent på kall 0 ovenfra vent på ACK0 timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer vent på ACK1 vent på kall 1 ovenfra timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L Transportlaget

37 rdt3.0 i aksjon Transportlaget

38 rdt3.0 i aksjon Transportlaget

39 Ytelsen til rdt3.0 rdt3.0 fungerer, men ytelsen er elendig
eksempel: 1 Gb/s link, 15 ms e-e gangtid, 1KB pakke: L (pakkelengde i bit) 8kb T = = = 8 ms transmit R (datarate i b/s) 1 Gb/s Usender: utnyttelse (utilization) – andel av tiden som senderen sender data 1KB pakke hvert 30 ms -> ca 260 kb/s over en 1 Gb/s link!  protokollen begrenser utnyttelsen av de fysiske ressursene Transportlaget

40 rdt3.0: “stop-and-wait”-operasjon
sender mottager første bit sendt ved tiden, t = 0 siste bit i pakken sendt t = L / R første bit ankommer RTT siste bit ankommer, sender så ACK ACK ankommer, send neste pakke, t = RTT + L / R Transportlaget

41 “Pipelined protocols”
Pipelining: sender sende flere pakker etterhverandre før den må stoppe og vente på kvittering antall sekvensnumre må økes pakker må kunne bufres hos sender og/eller mottager To generiske former for “pipelined protocols”: ”go-back-N” og “selective repeat” Transportlaget

42 Pipelining: øket utnyttelse av kapasiteten
sender mottager første bit sendt, t = 0 siste bit i pakken sendt, t = L / R første bit ankommer RTT siste bit ankommer, send ACK siste bit i pakke 2 ankommer, send ACK siste bit i pakke 3 ankommer, send ACK ACK ankommer, send neste pakke, t = RTT + L / R Linjeutnyttelsen øker med en faktor 3! Transportlaget

43 Sliding window Eksempel med tre bits sekvensnummer Pakker
Pakker som er sendt Pakker som kan sendes (vindu) 5 6 7 1 2 3 4 Sending av pakker krymper vinduet fra venstre Mottak av ACK gjør at høyre kant flyttes mot høyre Transportlaget

44 Sliding window - senderside
Eksempel med tre bits sekvensnummer 5 6 7 1 2 3 4 P7, P0, P1 5 6 7 1 2 3 4 ACK1 5 6 7 1 2 3 4 Transportlaget

45 Go-Back-N (GBN) Sender:
k-bit sekvensnummer i pakkehode (vindusstørrelse: N=2k pakker) et “vindu” på opp til N = 2k påfølgende, ukvitterte pakker tillatt ACK(n): Kvittering for alle pakker t.o.m. sekvensnummer n  kumulativ ACK timer for hver pakke som er underveis (sendt men ikke kvittert) timeout(n): retransmittér pakke n og alle etterfølgende Transportlaget

46 GBN: tilstandsmaskin for sender
rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) L base=1 nextseqnum=1 timeout vent start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transportlaget

47 GBN: tilstandsmaskin for mottager
default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L vent expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ ACK-only: send alltid ACK for korrekt mottatt pakke med høyeste sekvensnummer som er i rekkefølge kan generere duplikatkvitteringer (ACK) trenger bare å huske expectedseqnum pakke som kommer utenom tur: kast -> ingen bufring hos mottager! Send ny ACK med sekvensnummer til siste pakke i riktig rekkefølge Transportlaget

48 GBN i aksjon Transportlaget

49 Selective repeat (selective reject)
mottager kvitterer individuelt for korrekt mottatte pakker bufrer pakker for leveranse i rett rekkefølge til laget over sender retransmitterer bare pakker den ikke har fått kvittering for sender må ha timer for hver ukvittert pakke sendervindu N konsekutive sekvensnumre vinduet begrenser sekvensnumre til sendte men ukvitterte pakker Transportlaget

50 Selective repeat: sender- og mottagervinduer
Transportlaget

51 Selective repeat mottager sender data ovenfra:
hvis neste tilgjengelige sekvensnummer er i vinduet, send pakken timeout(n): send pakke n på nytt, restart timer ACK(n) i [sendbase, sendbase+N]: merk pakke n som mottatt dersom n er minste ukvitterte pakke, flytt venstre kant av vinduet til neste ukvitterte sekvensnummer pakke n i [rcvbase, rcvbase+N-1] send ACK(n) utenom tur: legg pakke i buffer i tur: lever til laget over, (også bufrede pakker i tur), flytt vindu til neste sekvensnummer som ikke er mottatt pakke n i [rcvbase-N, rcvbase-1] ellers: ignorér Transportlaget

52 Selective repeat i aksjon
Transportlaget

53 Selective repeat: dilemma
Eksempel: sekvensnumre: 0, 1, 2, 3 vindusstørrelse: 3 mottager ser ingen forskjell på de to scenariene videresender dupliserte data i (a)  relasjon mellom antall sekvensnummer og vindusstørrelse? Transportlaget

54 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

55 TCP: Oversikt RFC: 793, 1122, 1323, 2018, 2581 punkt-til-punkt:
en sender, en mottager pålitelig, leverer strøm: ingen meldingsgrenser sett fra applikasjonen “pipelined”: TCP metnings- og flyt-kontroll setter vindus-størrelsen sender og mottagerbuffer full dupleks: toveis datastrøm i samme forbindelse MSS: maximum segment size forbindelsesorientert: håndhilsing (utveksling av kontrollmld) før data sendes flytkontroll: sender ovsersvømmer ikke mottager med data Transportlaget

56 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

57 Opsjoner (variabel lengde)
TCP segmentstruktur senderport # mott.port # 32 bit applikasjons- data (variabel lengde) sekvensnummer kvitteringsnummer Mottagervindu Urg data pnter sjekksum F S R P A U head len not used Opsjoner (variabel lengde) URG: urgent data (normalt ikke brukt) angir byte (oktetter), ikke segmenter ACK: ACK # gyldig PSH: send data nå (normalt ikke brukt) antall byte mottager kan motta (“vindu”) RST, SYN, FIN: etablering av og nedkobling av forbindelse Sjekksum (som i UDP) Transportlaget

58 TCP sekvensnummer og ACK
Sekvensnumre: bytestrøm – nummeret til første byte i segmentets datafelt ACK: sekvensnummer for neste byte som forventes fra den andre siden kumulative ACK Hvordan håndteres segmenter som kommer utenom tur (“out-of-order segments”) A: TCP spes. angir ikke dette  opp til implementering Maskin A Maskin B Bruker taster ‘C’ Seq=42, ACK=79, data = ‘C’ maskin ACKer mottak av ‘C’, returnerer ‘C’ (ekko) Seq=79, ACK=43, data = ‘C’ maskin ACKer mottak av ekko (‘C’) Seq=43, ACK=80 tid enkelt “telnet”-scenario Transportlaget

59 TCP “Round Trip Time” og “Timeout”
Q: hvordan sette TCPs timeout-verdi? lengre enn RTT men RTT varierer for liten: for tidlig timeout unødige omsendinger for lang: sen reaksjon på segmenttap Q: hvordan estimere RTT? SampleRTT: målt tid fra segment er sent til kvittering er mottatt måling ignorerer omsendinger SampleRTT vil variere, ønsker en “glattere” estimert RTT midler over flere målinger istedenfor kun å bruke siste måling (SampleRTT) Transportlaget

60 TCP “Round Trip Time” og “Timeout”
EstimatedRTT = (1-) · EstimatedRTT +  · SampleRTT Ekponentielt vektet gjennomsnitt betydning av forrige sample reduseres eksponentielt hurtig typisk verdi:  = 0.125 Transportlaget

61 Eksempel på RTT-estimering:
Transportlaget

62 TCP “Round Trip Time” og “Timeout”
Setting av “timeout” EstimtedRTT + “sikkerhetsmargin” stor variasjon i EstimatedRTT  større sikkerhetsmargin først estimeres hvor mye SampleRTT avviker fra EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typisk:  = 0.25) Deretter settes “timeout”-tiden: TimeoutInterval = EstimatedRTT + 4*DevRTT Transportlaget

63 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

64 TCP: pålitelig dataoverføring
TCP gir en rdt-tjeneste basert oppå IPs upålitelige tjeneste Pipelining av segmenter Kumulative kvitteringer TCP benytter bare én retransmisjonstimer Retransmisjoner trigges av: timeout dupliserte kvitteringer Ser først på en forenklet TCP-sender: ignorér dupliserte ACK ignorér flytkontroll og metningskontroll Transportlaget

65 TCP-sender hendelser:
data mottatt fra appl: Lag segment med sekvensnummer sekvensnummer er “byte-stream”-nummer til første databyte i segmentet start timer hvis den ikke alt går (timer er for det eldste ukvitterte segmentet timer-tid: TimeOutInterval timeout: retransmitter segmentet som forårsaket timeout restart timer ACK mottatt: Hvis den kvitterer for ukvitterte segmenter: oppdater hva som er kvittert for start timer hvis det finnes utestående segmenter Transportlaget

66 TCP sender (forenklet)
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data mottatt fra applikasjonen lag TCP-segment med sekvensnummer NextSeqNum if (timer ikke går) start timer levér segment til IP NextSeqNum = NextSeqNum + lengde(data) event: timer timeout retransmittér ukvittert segment med minste sekvensnummer event: ACK mottatt, med ACK-verdi y if (y > SendBase) { SendBase = y if (det er flere ukvitterte segmenter) } } /* end of loop forever */ TCP sender (forenklet) Kommentar: SendBase-1: siste kvitterte oktett Eksempel: SendBase-1 = 71; y = 73  mottager forventer da segment med sekvensnummer 73 y > SendBase: denne ACK er en kvittering for data det ikke er kvittert for tidligere Transportlaget

67 TCP: retransmisjon X tap “prematur timeout” tid tid lost ACK scenario
Maskin A Seq=92, 8 byte data ACK=100 tap timeout lost ACK scenario Maskin B X tid Maskin A Maskin B Seq=92 timeout Seq=92, 8 byte data Seq=100, 20 byte data ACK=100 ACK=120 Sendbase = 100 Seq=92, 8 byte data SendBase = 120 Seq=92 timeout ACK=120 SendBase = 100 SendBase = 120 “prematur timeout” tid Transportlaget

68 TCP retransmisjon (forts.)
Maskin A Seq=92, 8 byte data ACK=100 tap timeout Kumulativ ACK scenario Maskin B X Seq=100, 20 byte data ACK=120 tid SendBase = 120 Transportlaget

69 TCP generering av ACK [RFC 1122, RFC 2581]
Hendelse hos mottager Ankomst av segment i rekkefølge med forventet sekvensnr. Alle data opp til forventet sekvensnr allerede ACKet med forventet sekvensnr. Et annet segment har ventende ACK Mottak av segement utenom tur med segmentnr. høyere enn forventet. Gap oppdaget. Ankomst av segment som helt eller delvis fyller et gap TCP mottager aksjon Forsinket ACK. Vent inntil 500ms på neste segment. Hvis intet nytt segment, send ACK Send umiddelbart kumulativt ACK, for å kvittere for begge segmenter Send umiddelbart duplikat ACK som indikerer sekvensnummer til neste forventede oktett Send umiddelbart ACK, forutsatt at segmentet starter i “nedre ende” av gapet Transportlaget

70 Fast retransmit Timeout perioden er ofte relativt lang:
stor forsinkelse før omsending av tapt segment Man kan oppdage tapte segmenter v.hj.a. dupliserte ACK. Sender vil ofte sende flere segmenter rett etter hverandre Hvis segment går tapt, vil sender ofte motta dupliserte kvitteringer Hvis sender mottar 4 kvitteringer for samme data, vil den anta at segmentet etter de kvitterte data er gått tapt: fast retransmit: retransmittér segment umiddelbart uten å vente på timout Transportlaget

71 “Fast retransmit”-algoritme:
event: ACK mottatt, med ACK-felt satt til y if (y > SendBase) { SendBase = y if (det er flere ukvitterte segmenter) start timer } else { inkrementér antall dupliserte ACK mottatt for y if (antall dupliserte ACK mottatt for y = 3) { retransmitter segmentet som har sekvensnummer y en duplisert ACK for allerede kvittert segment fast retransmit Transportlaget

72 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

73 hindrer sender i å oversvømme mottager med data
TCP flytkontroll hindrer sender i å oversvømme mottager med data flytkontroll mottagersiden av TCP-forbindelsen har et mottagerbuffer: hastighetstilpasning: tilpasser senderaten til den mottagende applikasjons “lesehastighet” app prosess kan være sen med å lese fra bufferet Transportlaget

74 TCP flytkontroll: virkemåte
Mottager tilkjennegir ledig plass ved å inkludere verdien RcvWindow i hvert segment Sender begrenser mengden ukvitterte data til verdien RcvWindow garanterer at mottager-buffer ikke blir overfylt ledig plass i buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Transportlaget

75 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

76 TCP: Etablering av forbindelse
Three way handshake: Trinn 1: klient sender TCP SYN- segment til server spesifiserer initielt sekvensnummer ingen data overføres Trinn 2: server mottar SYN, svarer med SYNACK server allokerer buffere spesifiserer servers initielle sekvensnummer Trinn 3: klient mottar SYNACK, svarer med ACK-segment som også kan inneholde data Påminnelse: TCP-sender og – mottager etablerer en slags forbindelse før data utveksles initialiserer TCP-variable: sekvensnumre buffere, flytkontroll-parametre (f.eks. RcvWindow) klient: den som tar initiativet til forbindelsen Socket clientSocket = new Socket("hostname","port number"); server: kontaktes av klient Socket connectionSocket = welcomeSocket.accept(); Transportlaget

77 TCP: Etablering av forbindelse (three-way handshake)
Maskin A Maskin B Initiell kontakt (“active open”) SYN, Seq=1000 Aksepterer og svarer på kontakten (“passive open”) SYN, Seq=89, ACK=1001 kvitterer på aksepten, kan nå sende data Seq=1001, ACK=90, data Transportlaget

78 TCP: Terminering av forbindelse
klient lukker socket: clientSocket.close(); Trinn 1: klienten sender TCP FIN segment til tjener Trinn 2: tjener mottar FIN, svarer ned ACK. Sender sin egen FIN. klient FIN tjener ACK close (active close) (passive close) closed ventetid Transportlaget

79 TCP: Terminering av forbindelse (forts.)
Trinn 3: klient mottar FIN, svarer med ACK. Venter en tid (“timed wait”) - vil svare med ACK på mottatte FIN Trinn 4: tjener mottar ACK på sin FIN. Forbindelsen terminert. klient tjener closing FIN ACK closing FIN ACK ventetid closed closed Transportlaget

80 TCP: etablering og terminering av forbindelser
TCP tjener livssyklus TCP klient livssyklus Transportlaget

81 TCP tilstandsmaskin Transportlaget

82 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

83 Prinsipper for metningskontroll
uformelt: “for mange maskiner sender for mye data for hurtig til at nettet klarer å håndtere det” ikke det samme som flytkontroll! viser seg ved: pakketap (ruteres buffere går fulle og pakke må kastes) store forsinkelser (lange køer i ruteres buffere) et viktig problem Transportlaget

84 Årsaker til og kostnader ved metning: scenario 1
Host A lout to sendere, to mottagere én ruter, uendelig store buffere ingen retransmisjon lin : originale data Host B ubegrenset utgansbuffer store forsinkelser ved metning maksimal oppnåelig gjennomstrømning Transportlaget

85 Årsaker til og kostnader ved metning: scenario 2
en ruter, begrenset bufferstørrelse sender retransmitterer tapte pakker Host A lout lin : originale data l'in : originale data pluss retransmitterte data Host B begrenset utgangsbuffer Transportlaget

86 Årsaker til og kostnader ved metning : scenario 2
out = alltid: (‘goodput’) “perfekt” retransmisjon kun ved tap: retransmisjon av forsinkede (ikke tapte) pakker gjør større (enn i det perfekte tilfellet) for samme l in out > l in l out “kostnader” ved metning: mer arbeid (retransmittering) for gitt “goodput” unødvendige retransmisjoner: link frakter flere kopier av en pakke Transportlaget

87 Årsaker til og kostnader ved metning: scenario 3
Spm: hva skjer når og øker ? l in fire sendere multihopp-stier timeout/retransmisjon l in A lout lin : originale data l'in : originale data pluss retransmitterte data B begrenset utgangsbuffer R1 R4 R2 D C R3 Transportlaget

88 Årsaker til og kostnader ved metning: scenario 3
lout A B Annen kostnad ved metning: når en pakke kastes, vil enhver oppstrøms transmisjonskapasitet som ble brukt for den pakken, være bortkastet Transportlaget

89 Mulige måter å håndtere metning
To tilnærmingsmåter: Ende til ende metningskontroll: ingen eksplisitt tilbakemelding fra nettet kunnskap om metning avledet fra observerte tap og forsinkelser TCP benytter denne tilnærmingen Nettverks-assistert metningskontroll: rutere gir tilbakemelding om metningen i nettet til endesystemene, f.eks. ett-bits indikasjon (SNA, DECbit, TCP/IP ECN, ATM) melding om hvilken bitrate senderen bør bruke Transportlaget

90 Kapittel 3 – hvor er vi? 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transportlaget

91 TCP metningskontroll ende til ende kontroll (ingen nettlags-assistanse) sender begrenser transmisjon: LastByteSent-LastByteAcked  CongWin Omtrentlig: CongWin er en dynamisk funksjon av opplevd metning i nettet Hvordan vurderer senderen om det er metning? segmenttap = timeout eller 3 duplikatkvitteringer TCP-sender reduserer raten (CongWin) etter segmenttap tre mekanismer: AIMD slow start reaksjon på timeout rate = CongWin RTT byte/s Transportlaget

92 TCP AIMD multiplikativ reduksjon (MD): halvér CongWin etter segmenttap (minimum én MSS) additiv økning (AI): CongWin økes med én MSS for hver RTT under fravær av segmenttap (congestion avoidance fase) Langlivet TCP-forbindelse Transportlaget

93 TCP Slow-start Når forbindelsen opprettes, øk raten eksponentielt inntil første segmenttap Når forbindelsen opprettes, CongWin = 1 MSS Eksempel: MSS = 500 oktetter og RTT = 200 ms initiell rate = 20 kb/s tilgjengelig datarate kan være >> MSS/RTT ønskelig å øke rate kjapt opp til en rimelig rate Transportlaget

94 TCP Slow-start Ved starten på forbindelse økes raten eksponetielt inntil man opplever segmenttap: dobler CongWin hver RTT gjøres ved å øke CongWin for hver mottatt ACK Oppsummert: initiell rate er lav, men øker eksponentielt Host A ett segment RTT Host B tid to segmenter fire segmenter Transportlaget

95 Reaksjon på segmenttap
Filosofi: Etter tre dupliserte kvitteringer: CongWin halveres vinduet vokser deretter lineært Men etter en timeout: CongWin settes til én MSS vinduet vokser så eksponentielt opp til halvparten av verdien før timeout, og vokser deretter lineært 3 dupliserte ACK indikerer at nettet kan levere en del segmenter timeout før 3 dupliserte ACK er mer alarmerende Transportlaget

96 Reaksjon på segmenttap (forts)
Q: Når skal eksponentiell økning endres til lineær? A: Når CongWin blir halvparten av dens verdi før timeout. mottak av tre duplikatkvitteringer Implementasjon: Variabel terskel Ved segmenttap settes terskelen til halvparten av det CongWin var før segmenttapet Transportlaget

97 Oppsummering: TCP metningskontroll
Når CongWin er lavere enn Threshold er senderen i slow-start fasen; vindu øker eksponentielt. Når CongWin er større enn Threshold er senderen i congestion-avoidance fasen; vindu øker lineært. Når sender mottar en trippel duplisert ACK, settes Threshold til CongWin/2 og CongWin settes til Threshold. Når sender får timeout, settes Threshold til CongWin/2 og CongWin til én MSS. Transportlaget

98 TCP sender metningskontroll
Hendelse Tilstand TCP-sender aksjon Kommentar ACK mottatt for ukvitterte data Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) bytt tilstand til “Congestion Avoidance” Resulterer i en dobling av CongWin hver RTT Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulterer i en økning av CongWin med 1 MSS hver RTT Tap opp-daget ved mottak av tre dupliserte ACK SS eller CA Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, multiplicative decrease. CongWin vil aldri reduseres til mindre enn 1 MSS Timeout CongWin = 1 MSS, Bytt tilstand til “slow start” Går i slow start Duplisert ACK Øke teller for antall dupliserte ACK Ingen endring i CongWin eller Threshold Transportlaget

99 TCP effektiv bitrate (throughput)
Effektiv bitrate for TCP som funksjon av vindus-størrelse og RTT? Ignorer slow start La W være vindusstørrelsen når segment-tap intreffer Når vinduet er W, vil effektiv bitrate være W/RTT Rett etter segmenttap, vil vinduet være redusert til W/2 og effektiv bitrate til W/2RTT. Gjennomsnittlig effektiv bitrate: 3W/4RTT Transportlaget

100 TCP: framtid Eksempel: 1500 byte segmenter, 100 ms RTT, ønsker 10 Gb/s effektiv bitrate Krever vindusstørrelse på W = in-flight segments Effektiv bitrate kan uttrykkes (L er tapsrate): Ønskes 10 Gb/s, gir dette L = 2· Wow Nye versjoner av TCP trengs for høye hastigheter! Transportlaget

101 TCP rettferdighet (fairness)
Mål: dersom K TCP-sesjoner deler samme flaskehals-link med datarate R, skal hver av dem ha en gjennomsnittlig datarate på R/K TCP forbindelse 1 flaskehals- ruter, kapasitet R TCP forbindelse 2 Transportlaget

102 Hvorfor er TCP rettferdig?
To konkurrerende sesjoner: Additiv økning gir helning på 1, som øker etterhvert multiplikativ reduksjon reduserer gjennomstrømning proporsjonalt R likelig fordelt datarate tap: reduserer vindu med faktor 2 Forbindelse 2 gjennomstrømning congestion avoidance: additiv økning tap: reduserer vindu med faktor 2 congestion avoidance: additiv økning R Forbindelse 1 gjennomstrøming Transportlaget

103 Rettferdighet (forts)
Rettferdighet og parallelle TCP-forbindelser ingenting forhindrer appl å åpne parallelle forbindelser mellom to maskiner. Nettlesere gjør dette Eksempel: link med rate R med 9 forbindelser: ny appl ber om én TCP-forbindelse, får rate R/10 ny appl ber om 11 TCP-forbindelser, får rate R/2 ! Rettferdighet og UDP Multimedia appl benytter sjelden TCP ønsker ikke datarate begrenset pga metningskontroll Benytter isteden UDP: pumper audio/video på konstant rate, tolererer pakketap Forskningsområde: TCP-vennlig oppførsel Transportlaget

104 Kapittel 3: Oppsummering
prinsipper bak transport-lagstjenester: multipleksing, demultipleksing pålitelig dataoverføring flytkontroll metningskontroll implementasjoner i Internett UDP TCP Neste: forlater kanten av nettet (applikasjons- og transportlag) inn i kjernen Transportlaget