Kapitel 3 Transportlaget A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in powerpoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2002 J.F Kurose and K.W. Ross, All Rights Reserved Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. Transportlaget

Kapitel 3: Transportlaget Mål: at forstå principperne bag transportlags-tjenesterne: multiplexing/demultiplexing pålidelig data-overførsel flow control congestion control lære transportlags- protokollerne i Internettet: UDP: forbindelsesløs transport TCP: forbindelses-orienteret transport TCP congestion control Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

Transporttjenester og protokoller skaber logisk kommunikation mellem applikationsprocesser, der kører på forskellige maskiner (hosts) transportprotokoller kører i ende-systemer (kant af net) sendesiden: opdeler applikationsbeskeder i segmenter, som gives videre til netværkslaget modtagesiden: gensamler segmenter til beskeder, som gives videre til appl.-laget. der er mere end én transport- protokol til applikationerne Internet: TCP og UDP application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical Transportlaget

Transportlag kontra netværkslag Dagligdags-analogi: 12 børn sender breve til 12 børn processer = børn applikationsbeskeder = breve i konvolutter hosts = huse transportprotokol = Anne og Birger netværks-lags protokol = postvæsen netværkslag: logisk kommunikation mellem maskiner (hosts) transportlag: logisk kommunikation mellem processer bygger på og forbedrer netværkslagets tjenester Transportlaget

Internet transport-lags protokoller pålidelig aflevering i korrekt orden (TCP) congestion control flow control forbindelsesopsætning upålidelig og ikke-ordnet aflevering: UDP simpel udvidelse af “best-effort” IP dette findes ikke: forsinkelsesgarantier båndbredde-garantier application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multiplexing og demultiplexing 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

Multiplexing/demultiplexing Multiplexing ved afsender-maskine: Demultiplexing ved modtage-maskine: afleverer modtagne segmenter til korrekt socket indsamling af data fra mange sockets og indpakning af data med header (bruges senere til demultiplexing) = socket = proces applik.lag transportlag netværks-lag link-lag fysisk lag P1 P2 P3 P4 maskine 1 maskine 2 maskine 3 Transportlaget

Sådan virker demultiplexing maskinen modtager IP- datagrammer hvert datagram har kilde-IP addresse og en destinations-IP addresse hvert datagram bærer 1 transport-lags segment hvert segment har kilde- og destinations-port nummer (husk: velkendte port-numre til specifikke applikationer) maskinen bruger IP-addresserne og port-numrene til at føre segmenterne til de rigtige sockets 32 bits source port nr dest port nr andre header-felter applikations- data (besked) TCP/UDP segment format Transportlaget

Forbindelsesløs demultiplexing Når maskinen modtager UDP segmentet: checker den destinations- portnummeret i segmentet fører UDP segmentet til den socket, der har det portnummer. IP datagrammer med forskellige kilde IP-addresser og/eller kilde portnumre føres til den samme socket Opret sockets med port- numre: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); En UDP-socket identificeres ved parret: (dest IP adresse, dest port nummer) Transportlaget

Forbindelsesløs demux (forts.) DatagramSocket serverSocket = new DatagramSocket(6428); Klient IP:B P3 klient IP: A P1 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 DP: 5775 SP: 5775 SP giver “retur-adressen” Transportlaget

Forbindelses-orienteret demux En TCP-socket identificeres ved 4 tal: source IP adressen source port nummmeret dest IP adressen dest port nummeret modtagermaskinen bruger alle fire tal til at styre segmentet til den rette socket Servermaskinen kan understøtte mange samtidige TCP sockets: hver socket identificeres med dens egne 4 tal Web-servere har forskellige sockets for hver forbundet klient og ikke-persistente HTTP har forskellige sockets for hver anmodning Transportlaget

Forbindelses-orienteret demux (fortsat) P3 klient IP: A P3 P4 P1 P1 SP: 80 DP: 9157 SP: 80 DP: 5775 SP: 9157 SP: 5775 DP: 80 DP: 80 klient IP:B server IP: C Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

UDP: User Datagram Protocol [RFC 768] “simpel” “bare bones” Internet transport- protokol “best effort” service, UDP segmenter kan: tabes afleveres i forkert rækkefølge til applik. forbindelsesløs: ingen handshaking mellem UDP-afsender og -modtager hvert UDP-segment behandles uafhængigt af de andre Hvorfor er der en UDP ? ingen etablering af forbindelse (som kan give ekstra forsinkelse) simpel: ingen forbindelsestilstand hos afsender og modtager lille segment-header ingen congestion control: UDP kan køre så hurtigt som muligt Transportlaget

UDP (fortsat): andre UDP-brugere bruges ofte til streaming multimedie-applikationer fejltolerante hastighedsfølsomme andre UDP-brugere DNS SNMP pålidelig overførsel over UDP: tilføj pålideligheden i applikationslaget applikations-specifik fejlretning ! 32 bit source port nr dest port nr Længden af UDP-segmentet i byte incl. header længde checksum Applikations- data (besked) UDP segment-format Transportlaget

UDP checksum Mål: at opdage “fejl” (f.eks. vendte bit) i det transmitterede segment Afsender: behandler segment-indholdet som en sekvens af 16-bit heltal checksum: addition (1- komplementsum) af segmentindholdet afsenderen lægger checksumværdien ind i UDP-checksumfeltet Modtager: beregner checksum af det modtagne segment checker om den beregnede checksum er lig med checksum-feltets værdi: NEJ – der er fundet fejl JA – ingen fejl fundet. Men måske er der alligevel fejl ? Mere senere …. Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

Principper for pålidelig dataoverførsel vigtigt i applikations- transport- og link-lag på top-10 listen af vigtigste netværksemner ! den upålidelige kanals egenskaber bestemmer kompleksiteten af den pålidelige dataoverførsels-protokol (rdt) Transportlaget

pålidelig dataoverførsel: indledning rdt_send(): kaldes ovenfra (f.eks. af applikationen). Data skal afleveres til modtagerens øvre lag deliver_data(): kaldes af rdt for at videregive data sende- siden modtage- siden udt_send(): kaldes af rdt, for at overføre pakker over upålidelig kanal til modtager rdt_rcv(): kaldes når pakken ankommer til modtagesiden af kanalen Transportlaget

pålidelig data-overførsel: start Vi vil: trinvis udvikle sende- og modtage-siderne af en pålidelig data-overførsel protokol (rdt) kun se på énvejs data-overførsel men kontrol-info flyder begge veje ! bruge finite state machines (FSM) til at specificere sender og modtager begivenhed der giver tilstandsovergang aktioner der skal foretages ved tilstandsovergang state 1 tilstand: når vi er i denne “tilstand” bestemmes næste tilstand éntydigt af den næste begivenhed state 2 event actions Transportlaget

Rdt1.0: pålidelig overførsel over en pålidelig kanal underliggende kanal er helt pålidelig ingen bit-fejl intet pakketab separate tilstandsmaskiner for afsender og modtager: afsenderen sender data ind i den underliggende kanal modtageren læser data fra den underliggende kanal Wait for call from above rdt_send(data) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) afsender modtager Transportlaget

Rdt2.0: kanal med bit-fejl den underliggende kanal kan vende bit i pakken husk: UDP-checksum for at opdage bit-fejl spørgsmål: hvordan fjernes fejl: acknowledgements (ACKs)(kvittering): modtageren fortæller afsenderen at den modtagne pakke er OK negative acknowledgements (NAKs)(negative kvitteringer): modtageren fortæller afsenderen at pakken havde fejl afsenderen retransmitterer pakken ved NAK-modtagelse hvordan med personer: bruges ACK’er og NAK’er ? nye mekanismer i rdt2.0 (ud over rdt1.0): fejldetektion modtager-feedback: kontrolbesked (ACK,NAK) fra modtager til afsender Transportlaget

rdt2.0: FSM-specifikation rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) modtager rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for ACK or NAK Wait for call from above udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L afsender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

rdt2.0: operation uden fejl rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for ACK or NAK Wait for call from above udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

rdt2.0: situation med fejl rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for ACK or NAK Wait for call from above udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transportlaget

rdt2.0 har en fatal brist ! Hvad sker hvis ACK/NAK ødelagt ? afsenderen ved ikke hvad der skete ved modtageren! man kan ikke gensende: medfører mulig dublet Hvad skal gøres? afsenderens ACKs/NAKs modtagerens ACK/NAK? Hvad hvis afsender ACK/NAK tabes? gensend, men det kan medføre gensending af korrekt modtaget pakke! Håndtering af dubletter: afsenderen tilføjer sequence number (løbenr.) til hver pakke afsenderen gensender den aktuelle pakke hvis ACK/NAK er forvansket modtageren bortkaster (afleverer ikke opad) duplikat-pakker stop and wait Afsenderen sender en pakke og venter så på modtagerens svar Transportlaget

rdt2.1: afsenderen behandler ødelagte ACK/NAK rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) Wait for ACK or NAK 0 Wait for call 0 from above udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L Wait for ACK or NAK 1 Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) Transportlaget

rdt2.1: modtageren behandler ødelagte ACK/NAK 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) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(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

rdt2.1: diskussion Afsender: sekvensnummer tilføjes til pakken to sekvensnumre (0,1) er nok. Hvorfor ? skal checke om modtagne ACK/NAK’er er ødelagte dobbelt så mange tilstande tilstande skal “huske” om “aktuelle” pakke har 0 eller 1 som løbenummer Modtager: skal checke om modtagne pakke er en dublet tilstanden angiver om 0 eller 1 det forventede løbenummer bemærk: modtageren kan ikke vide om dens sidste ACK/NAK blev modtaget OK af afsenderen. Transportlaget

rdt2.2: en NAK-løs protokol samme funktionalitet som rdt2.1 men kun med ACK i stedet for NAK sender modtageren ACK for den sidste pakke, der er modtaget OK modtageren skal eksplicit angive løbenumrene for ACKede pakker dobbelte ACK ved afsenderen resulterer i samme aktion som NAK: gensend den aktuelle pakke Transportlaget

rdt2.2: afsender- og modtager-fragmenter rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 0 from above Wait for ACK udt_send(sndpkt) sender FSM fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L Wait for 0 from below receiver FSM fragment 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

rdt3.0: kanaler med fejl og tab Ny antagelse: den underliggende kanal kan også tabe pakker (data eller ACK’er) checksum, løbenr, ACK’er, gensending hjælper, men er ikke nok Spm: hvordan klares tab ? afsenderen venter indtil visse data eller ACK tabes og retransmitterer så men: ulemper ? Tilgang: afsenderen venter “et rimeligt” tidsinterval på ACK retransmitterer, hvis ingen ACK modtages i dette tidsinterval hvis pakken (eller ACK) bare er forsinket (ikke tabt): så er retransmissionen en dublet, men brug af løbenumre klarer allerede dette. modtageren skal give løbenr. på pakker, der ACK’es kræver en timer Transportlaget

rdt3.0 afsender 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 Wait for call 0from above Wait for 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 Wait for ACK1 Wait for call 1 from above 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

rdt3.0 i aktion Transportlaget

rdt3.0 i aktion Transportlaget

R (transmissionshast. i b/s) Ydelse af rdt3.0 rdt3.0 virker, men er ineffektiv eksempel: 1 Gb/s link og 15 ms e-e forsinkelse og en 1KB pakke: L (pakkelængde i bit) 8kb/pakke T = = = 8 mikrosek transmit R (transmissionshast. i b/s) 10**9 b/sek U sender: utilization (udnyttelse) – brøkdel af tiden afsenderen sender 1KB pakke hver 30 msek -> 33kB/sek thruput over 1 Gb/s link netværksprotokollen begrænser brugen af de fysiske resourcer ! Transportlaget

rdt3.0: stop-og-vent operation afsender modtager første pakkebit sendes, t = 0 sidste pakkebit sendes, t = L / R første pakkebit ankommer RTT sidste pakkebit ankommer, der sendes ACK ACK ankommer, send næste pakke, t = RTT + L / R Transportlaget

Pipelinede protokoller Pipelining: afsenderen tillader mange, “in-flight”, endnu ikke kvitterede pakker antallet af løbenumre skal forøges bufring ved afsender og/eller modtager To generelle typer pipelinede protokoller: go-Back-N, selective repeat Transportlaget

Pipelining: forøget udnyttelse afsender modtager første pakkebit sendes, t = 0 sidste bit sendes, t = L / R første pakkebit ankommer RTT sidste pakkebit ankommer, send ACK sidste bit af 2nd pakke, send ACK sidste bit af 3rd pakke ankommer, send ACK ACK ankommer, send næste pakke, t = RTT + L / R Udnyttelsen forøges med en faktor 3! Transportlaget

Go-Back-N Afsender: k-bit løbenummer i pakke-headeren et “vindue” på op til N konsekutive ikke kvitterede pakker tillades ACK(n): ACK’er alle pakker til og med løbenr. n - “kumulativ ACK” kan narre dobbelte ACK’er (se modtager) timer for hver pakke, der er undervejs timeout(n): retransmittér pakke n og alle pakker med højere løbenumre i vinduet Transportlaget

GBN: afsender-udvidet FSM 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 Wait 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

GBN: modtager-udvidet FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ kun ACK: send altid ACK for korrekt modtagne pakker med høeste løbenummer i den korrekte rækkefølge kan give dobbelte ACK’er man behøver kun at huske expectedseqnum pakker i gal rækkefølge: smides væk (buffring) -> ingen bufring i modtageren! Gen-kvittér pakker med højest løbenr. i den korrekte rækkefølge Transportlaget

GBN i aktion Transportlaget

Selective Repeat modtageren kvitterer individuelt for hver korrekt modtagne pakke og bufrer pakkerne efter behov til senere “in-order” aflevering til øverste lag afsenderen gensender kun pakker for hvilke ACK ikke er modtaget afsender-timer for hver ikke-ACK’ede pakke afsender-vindue N fortløbende løbenumre der er igen en grænse på antallet af afsendte, men ukvitterede pakker Transportlaget

Selective repeat: afsender- og modtager-vinduer Transportlaget

Selective repeat modtager afsender data ovenfra : hvis det næste disponible løbenr. er i vnduet, så send pakken timeout(n): gensend pakke n, genstart timeren ACK(n) i [sendbase,sendbase+N]: markér pakke n som modtaget hvis n er mindste ikke-ACKede pakke, så ryk vinduesbasis frem til næste ikke-ACKed løbenr. pakke n i [rcvbase, rcvbase+N-1] send ACK(n) out-of-order: buffer in-order: aflevér (med samt bufrede in-order pakker), ryk vinduet frem til næste endnu ikke modtagne pakke pkt n i [rcvbase-N,rcvbase-1] ACK(n) ellers: ignorér den Transportlaget

Selective repeat i aktion Transportlaget

Selective repeat: dilemma Eksempel: løbenumre: 0, 1, 2, 3 vinduesstørrelse=3 modtageren kan ikke kende forskel på de to situationer ! og vil fejlagtigt videregive dublet-data som nye i (a) Spm: hvad er sammenhængen mellem antallet af løbenr. og vinduesstørrelsen? Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

TCP: Oversigt RFCs: 793, 1122, 1323, 2018, 2581 punkt-til-punkt: en afsender og en modtager pålidelig “in-order” byte- strøm: ingen “besked-grænser” pipelinet: TCP congestion og flow control bestemmer vinduesstørrelsen sende- & modtage-buffere fuld duplex data: bi-direktionel datastrøm i samme forbindelse MSS: maximum segment size forbindelses-orienteret: handshaking (udveksling af kontrolbeskeder) initialiserer afsender- og modtager-tilstanden før data udveksles flow-kontrolleret: afsender oversvømmer ikke modtageren Transportlaget

TCP segment-struktur source port nr dest port nr applikations- data 32 bits applikations- data (variabel længde) sequence number acknowledgement number Modtage-vindue Urg data pnter checksum F S R P A U head len not used Options (variabel længde) URG: vigtige data (bruges ikke normalt) tælles som antal byte data (ikke segmenter!) ACK: ACK-r gyldigt PSH: push data nu (bruges ikke normalt) antal bytes modtageren er villig til at acceptere RST, SYN, FIN: etablér forbindelse (setup, teardown kommandoer) Internet checksum (som i UDP) Transportlaget

TCP løbenumre og ACK’er byte stream “nummer” på første byte i segmentets data ACK’er: løbenummeret på den næste byte, der forventes fra den anden side kumulativ ACK Spm: hvordan behandler modtageren “out-of-order” segmenter Svar: det står ikke i TCP-specifikationen, det er op til implementatoren Maskine A Maskine B Bruger trykker ‘C’ Seq=42, ACK=79, data = ‘C’ B ACK’er modtaget ‘C’ og ekkoer ‘C’ tilbage Seq=79, ACK=43, data = ‘C’ A ACK’er modtagelse af ekkoet ‘C’ Seq=43, ACK=80 tid simpel telnet situation Transportlaget

TCP Round Trip Time og Timeout Spm: hvordan skal TCP timeout værdien sættes ? længere end RTT men RTT varierer for kort: præmature (for tidlig) timeout unødvendige retransmissioner for lang: sløv reaktion på segment-tab Spm: hvordan estimeres RTT? SampleRTT: tiden målt fra segment-transmission indtil ACK modtagelse se bort fra retransmissioner SampleRTT vil variere, men vi ønsker en “udglattet” RTT tag middelværdi af flere nye målinger, ikke bare den sidste SampleRTT Transportlaget

TCP Round Trip Time og Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Eksponentielt vægtet glidendende gennemsnit indflydelsen af gamle værdier aftager eksponentielt typisk værdi:  = 0.125 Transportlaget

Eksempel på RTT estimation: Transportlaget

TCP Round Trip Time og Timeout Fastsættelse af timeout EstimatedRTT plus “sikkerhedsmargin” stor variation i EstimatedRTT -> større sikkerhedsmargin første estimat af, hvor meget SampleRTT afviger fra EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typisk er  = 0.25) Så sæt timeout-intervallet: TimeoutInterval = EstimatedRTT + 4*DevRTT Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

TCP pålidelig dataoverførsel TCP bygger rdt service (pålidelig dataoverførsel) oven på IP’s upålidelige service Pipelinede segmenter Kumulative ACK’er TCP bruger en enkelt retransmissions-timer Retransmissioner udløses af: timeout-begivenhed dubletter af ACK’er I starten ser vi på en forenklet TCP-afsender: se bort fra dublet ACK’er se bort fra flow control og congestion control Transportlaget

TCP afsender-begivenheder: data fra applikationen: Opbyg segment med løbenummer løbenummeret er byte-stream-nummeret på den første data-byte i segmentet start timeren, hvis den ikke allerede kører (er timer for ældste u-ack’ede segment) udløbsinterval: TimeOutInterval timeout: retransmittér segmentet, som gav timeout genstart timer Kvittering (ACK) modtaget: Hvis den kvitterer for gamle u-ack’ede segmenter: opdatér hvad man ved der skal kvitteres for start timeren, hvis der er udestående segmenter Transportlaget

TCP afsender (forenklet) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) } } /* end of loop forever */ TCP afsender (forenklet) Kommentar: SendBase-1: sidste kumulativt ack’ed byte Eksempel: SendBase-1 = 71; y= 73, så modtager vil have 73+ ; y > SendBase, så der kvitteres for disse nye data Transportlaget

TCP: retransmissions-situationer Host A Seq=92, 8 bytes data ACK=100 mistes timeout situation med mistet ACK Host B X tid Host A Host B Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Sendbase = 100 Seq=92, 8 bytes data SendBase = 120 Seq=92 timeout ACK=120 SendBase = 100 SendBase = 120 for tidlig timeout tid Transportlaget

TCP retransmissions-situationer (mere) Host A Seq=92, 8 bytes data ACK=100 mistet timeout Kumulativt ACK situation Host B X Seq=100, 20 bytes data ACK=120 tid SendBase = 120 Transportlaget

TCP ACK-genererering [RFC 1122, RFC 2581] Begivenhed ved modtager Ankomst af “in-order” segment med forventet løbenr. Alle data op til forventet løbenummer er ACK’et Ankomst af "in-order" segment med forventet løbenummer. Et andet segment mangler ACK. Ankomst af “out-of-order” segment med løbenr. højere end forventet. Et hul er opdaget. Ankomst af segment, som helt eller delvis udfylder hullet. TCP modtager-aktion Forsinket ACK. Vent op til 500ms på næste segment. Hvis intet næste segment, send ACK Send straks en enkelt kumulativ ACK. Kvittér for begge "in-order" segmenter Send straks en dobbelt ACK, med løbenummeret på den næste forventede byte Send straks ACK, forudsat at segmentet starter ved hullets nedre ende Transportlaget

Hurtig retransmission Time-out perioden er ofte relativt lang: lang forsinkelse før gensending af tabt pakke Opdag tabte segmenter via dobbelte ACK’er. Afsenderen sender ofte mange segmenter “back-to-back” Hvis segmenter tabes, vil der sikkert komme mange dobbelte ACK’er. Hvis afsenderen modtager 3 ACK’er for de samme data, antager den at segmentet efter de ACK’ede data gik tabt: fast retransmit: gensend segmentet før timeren løber ud Transportlaget

Fast retransmit algoritme: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y en dobbelt ACK for et allerede ACK’et segment fast retransmit Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

TCP Flow Control flow control afsenderen vil ikke oversvømme modtage-rens buffer ved at sende for hurtigt flow control modtager-siden af TCP- forbindelsen har en modtager-buffer: speed-matching service: afpas sende-hastigheden til den modtagende applikations optage- hastighed applikationsprocessen kan være langsom til at læse fra bufferen Transportlaget

TCP Flow control: hvordan den virker Modtageren annoncerer sin frie plads ved at indlægge værdien af RcvWindow i segmenter Afsenderen begrænser ukvitterede data til RcvWindow dette garanterer at modtager-bufferen ikke løber over (Antag at TCP-modtageren forkaster “out-of-order” segmenter) ledig plads i buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

TCP forbindelses-håndtering Three way handshake: Trin 1: klienten sender et TCP SYN-segment til serveren det angiver det initiale løbenr. ingen data Trin 2: serveren modtager SYN og svarer med SYNACK-segment serveren allokerer buffere angiver serverens initiale lønbenr. Trin 3: klienten modtager SYNACK og svarer med et ACK-segment, som kan indeholde data Husk: TCP-afsender og -modtager etablerer en “forbindelse” før de udveksler data-segmenter initialisér TCP-variabler: løbenumre buffere og flow control info (f.eks. RcvWindow) klient: indleder forbindelsen Socket clientSocket = new Socket("hostname","port number"); server: kontaktes af klienten Socket connectionSocket = welcomeSocket.accept(); Transportlaget

TCP forbindelses-håndtering (fortsat) Nedlukning af en forbindelse: klienten lukker socket: clientSocket.close(); Trin 1: klient-maskinen sender et TCP FIN kontrol-segment til serveren Trin 2: serveren modtager FIN og svarer med ACK. Lukker forbindelsen og sender FIN. client FIN server ACK luk lukket timed wait Transportlaget

TCP forbindelses-håndtering (fortsat) Trin 3: klienten modtager FIN og svarer med ACK. Går i “timed venten” - svarer med ACK på modtagne FIN’er Trin 4: serveren modtager ACK. Forbindelsen lukkes. NB: med små ændringer kan samtidige FIN’er klares. client server lukker FIN ACK lukker FIN ACK timed wait lukket lukket Transportlaget

TCP forbindelses-håndtering (fortsat) TCP-serverens livscyklus TCP-klientens livscyklus Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

Principper for Congestion Control Congestion (overfyldning, trafikprop): uformelt: “for mange kilder sender for meget data hurtigere end nettet kan klare” forskelligt fra flow control ! viser sig ved: tabte pakker (buffer-overflow i routere) lange forsinkelser (kødannelse i router-buffere) et højt prioriteret problem! Transportlaget

Grunde til og omkostninger ved congestion (1) unlimited shared output link buffers Host A lin : original data Host B lout to afsendere og to modtagere en router og uendelig store buffere ingen retransmission store forsinkelser ved congestion maksimalt opnåeligt throughput Transportlaget

Grunde til og omkostninger ved congestion (2) en router og endelige buffere afsender retransmission af tabt pakke Host A lout lin : original data l'in : original data, plus retransmitted data Host B finite shared output link buffers Transportlaget

Grunde til og omkostninger ved congestion (2) out = altid: (goodput) “perfekt” retransmission kun ved tab: retransmission af forsinkede (ikke tabte) pakker gør større (end det perfekte tilfælde) for samme l in out > l in l out “omkostninger” ved congestion: mere arbejde (retransmission) for givet “goodput” unødvendige retransmissioner: links får multiple kopier af pakker Transportlaget

Grunde til og omkostninger ved congestion (3) fire afsendere multihop veje timeout/retransmittering Spm: hvad sker der når og øges ? l in l in Host A lout lin : original data l'in : original data, plus retransmitted data finite shared output link buffers Host B Transportlaget

Grunde til og omkostninger ved congestion (3) Host A lout Host B En anden “omkostning” ved congestion: når en pakke droppes, vil al “upstream” transmissions- kapacitet brugt til den pakke være spildt ! Transportlaget

Metoder til congestion control To generelle metoder til congestion control: End-end congestion control: ingen speciel feedback fra nettet congestion sluttes ud fra observerede tab og forsinkelser i ende-systemer det er TCP’s metode Networks-assisteret congestion control: routerne giver feedback til ende-systemerne en enkelt bit angiver congestion (SNA, DECbit, TCP/IP ECN, ATM) eller den bestemte hastighed afsenderen skal bruge Transportlaget

Case study: ATM ABR congestion control ABR: available bit rate: “elastisk service” hvis afsenderens vej er “underbelastet”: så bør afsenderen bruge den båndbredde, der er til rådighed hvis afsenderens vej er congested: så neddrosles afsenderen til den minimalt garanterede hastighed RM (resource management) celler: sendes af afsenderen og blandes mellem data celler bit i RM-cellen sættes af switche (“netværks-assisteret) NI bit: no increase i hastighed (mild congestion) CI bit: congestion indication RM-cellerne returnes til afsenderen af modtageren med bit intakte Transportlaget

Case study: ATM ABR congestion control to-byte ER (explicit rate) felt i RM-cellen congested switch kan sænke ER-værdien i cellen afsenderens sendhast. er minimalt understøttede hast. på vejen. EFCI bit i data-celler: sættes til 1 i congestede switche hvis en data-celle før RM-cellen har EFCI sat, så sætter afsenderen CI-bitten i den returnede RM-celle Transportlaget

Kapitel 3 oversigt 3.1 Transportlags-tjenester 3.2 Multipleksning og demultipleksning 3.3 Forbindelsesløs transport: UDP 3.4 Principper for pålidelig dataoverførsel 3.5 Forbindelses-orienteret transport: TCP segment-struktur pålidelig dataoverførsel flow control forbindelses-håndtering 3.6 Principper for congestion control 3.7 TCP congestion control Transportlaget

TCP Congestion Control end-end control (ingen netværks-assistance) afsenderen begrænser transmissionen: LastByteSent-LastByteAcked  CongWin Omtrent: CongWin er dynamisk; en funktion af den opfattede netværks-congestion Hvordan sporer afsenderen congestion ? tabshændelse = timeout eller 3 dobbelte ack’er TCP afsenderen sænker hastigheden (CongWin) efter en tabshændelse tre mekanismer: AIMD slow start konservative efter tabshændelser hast = CongWin RTT Byte/sek Transportlaget

TCP AIMD multiplicative decrease: cut CongWin halveres efter tabshændelse additive increase: forøg CongWin med 1 MSS hver RTT ved fravær af tabshændelser: probing Længerevarende TCP-forbindelse Transportlaget

TCP Slow Start Når forbindelsen starter, forøg hastigheden eksponentielt hurtigt indtil den første tabshændelse. Når forbindelsen starter er CongWin = 1 MSS (max segm. size) Eksempel: MSS = 500 byte og RTT = 200 msek initial hast = 20 kb/s den til rådighed værende båndbredde kan være >> MSS/RTT det er ønskeligt hurtigt at komme op på en respektabel hastighed Transportlaget

TCP Slow Start (mere) Når forbindelsen starter, forøg hastigheden eksponentielt hurtigt indtil den første tabshændelse: fordobbel CongWin for hver RTT gøres ved at øge CongWin for hver ACK, der modtages Resumé: starthastigheden er langsom, men den kører eksponentielt hurtigt op Host A one segment RTT Host B tid two segments four segments Transportlaget

Forfinelse Efter 3 dobbelte ACK’er: Filosofi: 3 dobbelte ACK’er angiver at netværket er i stand til at aflevere nogle segmenter timeout før 3 dobbelte ACK’er er “mere alarmerende” Efter 3 dobbelte ACK’er: bliver CongWin halveret herefter vokser vinduet lineært Men after en timeout: sættes CongWinto i stedet til 1 MSS; herefter vokser vinduet eksponentielt til en tærskel og vokser så lineært Transportlaget

Forfinelse (mere) Implementation: Spm: Hvornår skal eksponentiel forøgelse skifte til lineær ? Sv: Når CongWin bliver 1/2 af dets værdi før timeout. Implementation: Variabel tærskelværdi Ved tabshændelse sættes tærskelværdien til 1/2 af CongWin lige før tabsbegivenheden Transportlaget

Resumé: TCP Congestion Control Når CongWin er under Threshold og afsender i slow-start fasen, vokser vinduet eksponentielt. Når CongWin er over Threshold og afsender er i congestion-avoidance fasen, vokser vinduet lineært. Når tredobbelt ACK sker, sættes Threshold til CongWin/2 og CongWin sættes til Threshold. Når timeout sker, sættes Threshold til CongWin/2 og CongWin sættes til 1 MSS. Transportlaget

TCP Fairness (retfærdighed) Fairness-mål: Hvis K TCP-sessioner deler samme flaskehals-link med båndbredden R, så skal hver have en gennemsnitlig hastighed på R/K TCP-forbindelse 1 flaskehals- router kapacitet R TCP- forbindelse 2 Transportlaget

Hvorfor er TCP fair? Med to konkurrerende sessioner: Additiv forøgelse giver en hældning på 1 når throughout forøges multiplikativ nedsættelse nedsætter throughput proportionalt R lige andel af båndbredden tab: nedsæt vinduet med en faktor 2 congestion avoidance: additiv forøgelse Forbindelse 2 throughput tab: nedsæt vinduet med en faktor 2 congestion avoidance: forøgelse Forbindelse 1 throughput R Transportlaget

Fairness (mere) Fairness og parallele TCP-forbindelser Fairness og UDP intet hindrer applikationer i at åbne parallele forbindelse mellem 2 maskiner. Web-browsere gør dette Eksempel: et link med rate R understøtter 9 forbindelser; en ny applikation beder om 1 TCP og får R/10 en ny applikation, der beder om 11 TCP’er får R/2 ! Fairness og UDP Multimedie-applikationer bruger som regel ikke TCP ønsker ikke hastigheden nedsat ved congestion control I stedet bruges UDP: udpump audio/video med konstant hastighed og acceptér pakketab Forskningsområde: hvordanTCP-venlig ? Transportlaget

Forsinkelsesmodel Notation og antagelser: Antag et link mellem klient og server med rate R S: MSS (bit) O: objektstørrelse (bit) ingen retransmissioner (intet tab og ingen forvanskninger) Vinduesstørrelse: Antag først: fast congestion-vindue, W segmenter Så et dynamisk vindue, der modellerer slow start Spm: Hvor længe tager det at modtage et objekt fra en Web-server efter afsendelsen af en anmodning ? Hvis der ses bort fra congestion så påvirkes forsinkelsen af: TCP forbindelses-etablering datatransmissionsforsinkelse slow start Transportlaget

Fast congestion-vindue (1) Første tilfælde: WS/R > RTT + S/R: ACK for første segment i vinduet returnerer før vinduets data er sendt forsinkelse = 2RTT + O/R Transportlaget

Fast congestion-vindue (2) Andet tilfælde: WS/R < RTT + S/R: vent på ACK efter afsendelse af vinduets data forsinkelse = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Transportlaget

TCP Forsinkelsesmodellering: Slow Start (1) Antag nu at vinduet vokser som ved slow start Vi vil vise, at forsinkelsen for et objekt er: hvor P er antallet af gange hvor TCP går i tomgang ved serveren: - hvor Q er antallet af gange, hvor serveren går i tomgang, hvis objektet var uendeligt stort. - og K er antallet af vinduer, der dækker dette objekt. Transportlaget

TCP forsinkelsesmodellering: Slow Start (2) Forsinkelseskomponenter: 2 RTT for til etab af forbindelse og anmodning O/R for at sende objektet gange server tomgange p.g.a. slow start Server-tomgange: P = min{K-1,Q} gange Eksempel: O/S = 15 segmenter K = 4 vinduer Q = 2 P = min{K-1,Q} = 2 Servertomgang P=2 gange Transportlaget

TCP forsinkelsesmodellering (3) Transportlaget

TCP forsinkelsesmodellering (4) Husk K = antallet af vinduer, der dækker objektet Hvordan beregner vi K ? Beregning af Q, antallet af tomgange for et objekt, af uendelig størrelse, er analog (se opgave 35). Transportlaget

HTTP modellering Antag en Webside bestående af: 1 basis HTML-side (af størrelsen O bit) M billeder (hver af størrelsen O bit) Ikke-persistent HTTP: M+1 TCP-forbindelser i serie Svartid = (M+1)O/R + (M+1)2RTT + summen af tomgangstider Persistent HTTP: 2 RTT for at bede om og modtage basis HTML-filen 1 RTT for at bede om og modtage M billeder Svartid = (M+1)O/R + 3RTT + summen af tomgangstider Non-persistent HTTP med X parallele forbindelser Antag at M/X er et heltal. 1 TCP forbindelse for basis-filen M/X parallele forbindelser for billeder. Svartid = (M+1)O/R + (M/X + 1)2RTT + summen af tomgangstider Transportlaget

HTTP svartid (i sekunder) RTT = 100 msek, O = 5 Kbyte, M=10 and X=5 Med lav båndbredde er opsætnings-og svartid domineret af transmissionstiden. Persistente forbindelser giver kun mindre forbedringer over parallele forbindelser. Transportlaget

HTTP svartid (i sekunder) RTT =1 sek, O = 5 Kbyte, M=10 and X=5 For større RTT domineres svartiden af TCP-etableringen og slow start forsinkelser. Persistente forbindelser giver nu en vigtig forbedring: især i høje delaybåndbredde netværk. Transportlaget

Kapitel 3: Resumé principperne bag transport-lagstjenesterne: multiplexing, demultiplexing pålidelig dataoverførsel flow control congestion control oprettelse og implementering i Internettet UDP TCP Nu: vi forlader netværks-“kanten” (applikations - og transport-lag) og går ind i netværkets “kerne” Transportlaget