Chapter 3 Transport Layer Computer Networking A Top

Chapter 3 Transport Layer Computer Networking: A Top Down Approach All People Seem To Need Data Processing 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 All material copyright 1996 -2012 J. F Kurose and K. W. Ross, All Rights Reserved Transport Layer 3 -1

Chapter 3: Transport Layer Lecture Goals: v understand principles behind transport layer services: § Reliable data transfer § Flow control § Congestion control v learn about Internet transport layer protocols: § UDP: connectionless transport § TCP: connection-oriented reliable transport Transport Layer 3 -2

Chapter 3 outline 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 Transport Layer 3 -3

Transport services and protocols v le ca gi nd -e nd ns tra t r po v lo v provide logical communication between app processes running on different hosts transport protocols run in end systems § send side: breaks app messages into segments, passes to network layer § rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps application transport network data link physical Transport Layer 3 -4

Transport vs. network layer: logical communication between hosts v transport layer: logical communication between processes v § relies on, enhances, network layer services household analogy: 12 kids in Ann’s house sending letters to 12 kids in Bill’s house: v hosts = houses v processes = kids v app messages = letters in envelopes v transport protocol = Ann and Bill who demux to inhouse siblings v network-layer protocol = postal service Transport Layer 3 -5

Internet transport-layer protocols v reliable, in-order delivery (TCP) ns tra network data link physical d n -e network data link physical t r po services not available: nd v network data link physical le § no-frills extension of “best-effort” IP network data link physical ca unreliable, unordered delivery: UDP gi v network data link physical lo § congestion control § flow control § connection setup application transport network data link physical § delay guarantees § bandwidth guarantees Transport Layer 3 -6

UDP: User Datagram Protocol [RFC 768] v v v “no frills, ” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: § lost § delivered out-of-order to app connectionless: § no handshaking between UDP sender, receiver § each UDP segment handled independently of others v UDP use: § streaming multimedia apps (loss tolerant, rate sensitive) § DNS § SNMP v reliable transfer over UDP: § add reliability at application layer § application-specific error recovery! Transport Layer 3 -7

UDP: segment header 32 bits source port # dest port # length checksum application data (payload) length, in bytes of UDP segment, including header why is there a UDP? v v v UDP segment format v no connection establishment (which can add delay) simple: no connection state at sender, receiver small header size no congestion control: UDP can blast away as fast as desired Transport Layer 3 -8

Principles of reliable data transfer v important in application, transport, link layers § top-10 list of important networking topics! v characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3 -9

Principles of reliable data transfer v important in application, transport, link layers § top-10 list of important networking topics! v characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3 -10

Principles of reliable data transfer v important in application, transport, link layers § top-10 list of important networking topics! v characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3 -11

Pipelined protocols pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts § range of sequence numbers must be increased § buffering at sender and/or receiver v two generic forms of pipelined protocols: go-Back -N, selective repeat Transport Layer 3 -12

Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK arrives, send next packet, t = RTT + L / R 3 -packet pipelining increases utilization by a factor of 3! Transport Layer 3 -13

Pipelined protocols: overview Go-back-N: Selective Repeat: v sender can have up to to N unacked packets N unack’ed packets in in pipeline v receiver only sends v rcvr sends individual cumulative ack for each packet § doesn’t ack packet if there’s a gap v sender has timer for oldest unacked packet § when timer expires, retransmit all unacked packets v sender maintains timer for each unacked packet § when timer expires, retransmit only that unacked packet Transport Layer 3 -14

Go-Back-N: sender v v v k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” § may receive duplicate ACKs (see receiver) timer for oldest in-flight pkt timeout(n): retransmit packet n and all higher seq # pkts in window Transport Layer 3 -15

GBN: sender extended FSM rdt_send(data) L base=1 nextseqnum=1 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) Wait rdt_rcv(rcvpkt) && corrupt(rcvpkt) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transport Layer 3 -16

GBN: receiver extended FSM default udt_send(sndpkt) L Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum, ACK, chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt, expectedseqnum) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(expectedseqnum, ACK, chksum) udt_send(sndpkt) expectedseqnum++ ACK-only: always send ACK for correctly-received pkt with highest in-order seq # § may generate duplicate ACKs § need only remember expectedseqnum v out-of-order pkt: § discard (don’t buffer): no receiver buffering! § re-ACK pkt with highest in-order seq # Transport Layer 3 -17

GBN in action sender window (N=4) 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 sender send pkt 0 send pkt 1 send pkt 2 send pkt 3 (wait) rcv ack 0, send pkt 4 rcv ack 1, send pkt 5 ignore duplicate ACK pkt 2 timeout 0 1 2 3 4 5 6 7 8 send pkt 2 pkt 3 pkt 4 pkt 5 receiver Xloss receive pkt 0, send ack 0 receive pkt 1, send ack 1 receive pkt 3, discard, (re)send ack 1 receive pkt 4, discard, (re)send ack 1 receive pkt 5, discard, (re)send ack 1 rcv rcv pkt 2, pkt 3, pkt 4, pkt 5, deliver, send ack 2 ack 3 ack 4 ack 5 Transport Layer 3 -18

Selective repeat v receiver individually acknowledges all correctly received pkts § buffers pkts, as needed, for eventual in-order delivery to upper layer v sender only resends pkts for which ACK not received § sender timer for each un. ACKed pkt v sender window § N consecutive seq #’s § limits seq #s of sent, un. ACKed pkts Transport Layer 3 -19

Selective repeat: sender, receiver windows Transport Layer 3 -20

Selective repeat sender data from above: v if next available seq # in window, send pkt timeout(n): receiver pkt n in [rcvbase, rcvbase+N-1] v v v resend pkt n, restart timer ACK(n) in v [sendbase, sendbase+N]: v v mark pkt n as received if n smallest un. ACKed pkt, advance window base to next un. ACKed seq # send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, inorder pkts), advance window to next not-yetreceived pkt n in [rcvbase-N, rcvbase-1] v ACK(n) otherwise: v ignore Transport Layer 3 -21

Selective repeat in action sender window (N=4) 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 sender send pkt 0 send pkt 1 send pkt 2 send pkt 3 (wait) receiver Xloss rcv ack 0, send pkt 4 rcv ack 1, send pkt 5 record ack 3 arrived pkt 2 timeout 0 1 2 3 4 5 6 7 8 receive pkt 0, send ack 0 receive pkt 1, send ack 1 receive pkt 3, buffer, send ack 3 receive pkt 4, buffer, send ack 4 receive pkt 5, buffer, send ack 5 send pkt 2 record ack 4 arrived rcv pkt 2; deliver pkt 2, pkt 3, pkt 4, pkt 5; send ack 2 Q: what happens when ack 2 arrives? Transport Layer 3 -22

Selective repeat: dilemma example: v v seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! duplicate data accepted as new in (b) Q: what relationship between seq # size and window size to avoid problem in (b)? receiver window (after receipt) sender window (after receipt) 0 1 2 3 0 1 2 pkt 0 0 1 2 3 0 1 2 pkt 1 0 1 2 3 0 1 2 pkt 2 0 1 2 3 0 1 2 pkt 0 (a) no problem 0 1 2 3 0 1 2 X will accept packet with seq number 0 receiver can’t see sender side. receiver behavior identical in both cases! something’s (very) wrong! 0 1 2 3 0 1 2 pkt 0 0 1 2 3 0 1 2 pkt 1 0 1 2 3 0 1 2 pkt 2 0 1 2 3 0 1 2 X X timeout retransmit pkt 0 X 0 1 2 3 0 1 2 (b) oops! pkt 0 will accept packet with seq number 0 Transport Layer 3 -23

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 v point-to-point: v § one sender, one receiver v v § bi-directional data flow in same connection § MSS: maximum segment size reliable, in-order byte steam: § no “message boundaries” v connection-oriented: § handshaking (exchange of control msgs) inits sender, receiver state before data exchange pipelined: § TCP congestion and flow control set window size full duplex data: v flow controlled: § sender will not overwhelm receiver 3 -24 Transport Layer

TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UAP R S F len used checksum receive window Urg data pointer options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) Transport Layer 3 -25

TCP seq. numbers, ACKs outgoing segment from sender sequence numbers: § byte stream “number” of first byte in segment’s data acknowledgements: § seq # of next byte expected from other side § cumulative ACK Q: how receiver handles out-of-order segments § A: TCP spec doesn’t say, - up to implementor source port # dest port # sequence number acknowledgement number rwnd checksum urg pointer window size N sender sequence number space sent ACKed sent, not- usable not yet ACKed but not usable (“in-flight”) yet sent incoming segment to sender source port # dest port # sequence number acknowledgement number rwnd A checksum urg pointer Transport Layer 3 -26

TCP seq. numbers, ACKs Host B Host A User types ‘C’ host ACKs receipt of echoed ‘C’ Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=43, ACK=80 simple telnet scenario Transport Layer 3 -27

TCP round trip time, timeout v timeout interval: Estimated. RTT plus “safety margin” § large variation in Estimated. RTT -> larger safety margin v estimate Sample. RTT deviation from Estimated. RTT: Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (typically, = 0. 25) Timeout. Interval = Estimated. RTT + 4*Dev. RTT estimated RTT “safety margin” Transport Layer 3 -28

TCP reliable data transfer v TCP creates rdt service on top of IP’s unreliable service § pipelined segments § cumulative acks § single retransmission timer v retransmissions triggered by: § timeout events § duplicate acks let’s initially consider simplified TCP sender: § ignore duplicate acks § ignore flow control, congestion control Transport Layer 3 -29

TCP sender events: data rcvd from app: timeout: v create segment with v retransmit segment seq # that caused timeout v seq # is byte-stream v restart timer number of first data ack rcvd: byte in segment v if acknowledges v start timer if not previously unacked already running segments § think of timer as for oldest unacked segment § expiration interval: Time. Out. Interval § update what is known to be ACKed § start timer if there are still unacked segments Transport Layer 3 -30

TCP: retransmission scenarios Host B Host A Send. Base=92 X ACK=100 Seq=92, 8 bytes of data timeout Seq=92, 8 bytes of data Seq=100, 20 bytes of data ACK=100 ACK=120 Seq=92, 8 bytes of data Send. Base=100 ACK=100 Seq=92, 8 bytes of data Send. Base=120 ACK=120 Send. Base=120 lost ACK scenario premature timeout Transport Layer 3 -31

TCP: retransmission scenarios Host B Host A Seq=92, 8 bytes of data timeout Seq=100, 20 bytes of data X ACK=100 ACK=120 Seq=120, 15 bytes of data cumulative ACK Transport Layer 3 -32

TCP ACK generation [RFC 1122, RFC 2581] event at receiver TCP receiver action arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK arrival of in-order segment with expected seq #. One other segment has ACK pending immediately send single cumulative ACK, ACKing both in-order segments arrival of out-of-order segment higher-than-expect seq. #. Gap detected immediately send duplicate ACK, indicating seq. # of next expected byte arrival of segment that partially or completely fills gap immediate send ACK, provided that segment starts at lower end of gap Transport Layer 3 -33

TCP fast retransmit v time-out period often relatively long: § long delay before resending lost packet v detect lost segments via duplicate ACKs. § sender often sends many segments back -to-back § if segment is lost, there will likely be many duplicate ACKs. TCP fast retransmit if sender receives 3 ACKs for same data (“triple duplicate ACKs”), resend unacked segment with smallest seq # § likely that unacked segment lost, so don’t wait for timeout Transport Layer 3 -34

TCP fast retransmit Host B Host A Seq=92, 8 bytes of data Seq=100, 20 bytes of data X timeout ACK=100 Seq=100, 20 bytes of data fast retransmit after sender receipt of triple duplicate ACK Transport Layer 3 -35

TCP flow control The TCP provides a flow control service to its application to eliminate the possibility of the sender overflowing the receiver. v Flow control is a speed matching service. v TCP provides flow control by having the sender maintains a variable called the receive window(rwnd). v Receiver window is used to give the sender an idea of how much free buffer space is available at the window side. v Transport Layer 3 -36

TCP flow control application may remove data from TCP socket buffers …. … slower than TCP receiver is delivering (sender is sending) application process application TCP code IP code flow control receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast OS TCP socket receiver buffers from sender receiver protocol stack Transport Layer 3 -37

TCP flow control v receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-tosender segments § Rcv. Buffer size set via socket options (typical default is 4096 bytes) § many operating systems autoadjust Rcv. Buffer v v sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value guarantees receive buffer will not overflow to application process Rcv. Buffer rwnd buffered data free buffer space TCP segment payloads receiver-side buffering Transport Layer 3 -38

Connection Management before exchanging data, sender/receiver “handshake”: v v agree to establish connection (each knowing the other willing to establish connection) agree on connection parameters application connection state: ESTAB connection variables: seq # client-to-server-to-client rcv. Buffer size at server, client network Socket client. Socket = new. Socket("hostname", "port number"); application connection state: ESTAB connection Variables: seq # client-to-server-to-client rcv. Buffer size at server, client network Socket connection. Socket = welcome. Socket. accept(); Transport Layer 3 -39

Agreeing to establish a connection 2 -way handshake: Q: will 2 -way handshake always work in network? Let’s talk ESTAB OK ESTAB v v v choose x ESTAB v req_conn(x) acc_conn(x) variable delays retransmitted messages (e. g. req_conn(x)) due to message loss message reordering can’t “see” other side ESTAB Transport Layer 3 -40

Agreeing to establish a connection 2 -way handshake failure scenarios: choose x req_conn(x) ESTAB retransmit req_conn(x) acc_conn(x) ESTAB req_conn(x) client terminates connection x completes acc_conn(x) data(x+1) retransmit data(x+1) server forgets x ESTAB half open connection! (no client!) client terminates connection x completes req_conn(x) data(x+1) accept data(x+1) server forgets x ESTAB accept data(x+1) Transport Layer 3 -41

TCP 3 -way handshake client state server state LISTEN choose init seq num, x send TCP SYN msg SYNSENT received SYNACK(x) indicates server is live; ESTAB send ACK for SYNACK; this segment may contain client-to-server data SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK SYN RCVD msg, acking SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 ACKbit=1, ACKnum=y+1 received ACK(y) indicates client is live ESTAB Transport Layer 3 -42

TCP 3 -way handshake v v The client application process first informs the client TCP that it wants to establish a connection to a process in the server. The TCP in the client then proceeds to establish a TCP connection with the TCP in the server in the following manner: The client-side TCP first sends a special TCP segment to the server-side TCP Transport Layer 3 -43

v v v Host A sends a TCP SYNchronize packet to Host B receives A's SYN Host B sends a SYNchronize-ACKnowledgement Host A receives B's SYN-ACK Host A sends ACKnowledge Host B receives ACK. TCP socket connection s ESTABLISHED. Transport Layer 3 -44

Host B Host A Tcp-SYN SYN-ACK Transport Layer 3 -45

Principles of congestion control congestion: v v informally: “too many sources sending too much data too fast for network to handle” In the case of § lost packets (buffer overflow at routers) § long delays (queueing in router buffers) Transport Layer 3 -46

Chapter 3: summary v v principles behind transport layer services: § multiplexing, demultiplexing § reliable data transfer § flow control § congestion control instantiation, implementation in the Internet next: v leaving the network “edge” (application, transport layers) v into the network “core” § UDP § TCP Transport Layer 3 -47