Chapter 3: Transport Layer our goals: understand principles behind transport layer : multiplexing, demultiplexing congestion control learn about Internet transport layer protocols: UDP: connectionless transport TCP: connection-oriented reliable transport TCP congestion control Chapter 3 outline 3.1 transport-layer 3.2 principles of reliable data transfer 3.3 connection-oriented transport: TCP segment structure connection management 3.4 principles of congestion control 3.5 TCP congestion control Transport Layer 3-1 Transport Layer 3-2 Transport and protocols Transport vs. layer 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 layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP transport logical end-end transport transport layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, layer household analogy: 12 kids in Ann s house sending letters to 12 kids in Bill s house: hosts = houses processes = kids app messages = letters in envelopes transport protocol = Ann and Bill who demux to inhouse siblings -layer protocol = postal service Transport Layer 3-3 Transport Layer 3-4 Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control connection setup unreliable, unordered delivery: UDP no-frills extension of best-effort IP not available: delay guarantees bandwidth guarantees transport logical end-end transport transport Chapter 3 outline 3.1 transport-layer 3.2 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure connection management 3.6 principles of congestion control 3.7 TCP congestion control Transport Layer 3-5 Transport Layer 3-6 1
Principles of reliable data transfer important in, transport, link layers top-10 list of important ing topics! Principles of reliable data transfer important in, transport, link layers top-10 list of important ing topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-7 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-8 Principles of reliable data transfer important in, transport, link layers top-10 list of important ing topics! Reliable data transfer: getting started rdt_send(): called from, (e.g., by app.). Passed data to deliver to upper layer deliver_data(): called by rdt to deliver data to upper send side receive side characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) udt_send(): called by rdt, to transfer packet over unreliable channel to rdt_rcv(): called when packet arrives on rcv-side of channel Transport Layer 3-9 Transport Layer 3-10 rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for, : sends data into underlying channel reads data from underlying channel call from packet = make_pkt(data) udt_send(packet) call from below rdt_rcv(packet) extract (packet,data) rdt2.0: channel with bit errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): explicitly tells that pkt received OK negative acknowledgements (NAKs): explicitly tells that pkt had errors How retransmits do humans pkt on recover receipt from of NAK errors new mechanisms in rdt2.0 (beyond rdt1.0): during conversation? error detection feedback: control msgs (ACK,NAK) rcvr- > Transport Layer 3-11 Transport Layer 3-12 2
rdt2.0: channel with bit errors rdt2.0: operation with no errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): explicitly tells that pkt received OK negative acknowledgements (NAKs): explicitly tells that pkt had errors retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection feedback: control msgs (ACK,NAK) from to snkpkt = make_pkt(data, checksum) call from ACK or NAK isack(rcvpkt) isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) call from below notcorrupt(rcvpkt) extract(rcvpkt,data) udt_send(ack) Transport Layer 3-13 Transport Layer 3-14 rdt2.0: error scenario snkpkt = make_pkt(data, checksum) call from isack(rcvpkt) ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) call from below notcorrupt(rcvpkt) extract(rcvpkt,data) udt_send(ack) rdt2.0 has a fatal flaw! what happens if ACK/ handling duplicates: NAK corrupted? retransmits current doesn t know pkt if ACK/NAK what happened at corrupted! adds sequence can t just retransmit: number to each pkt possible duplicate discards (doesn t deliver up) duplicate pkt stop and wait sends one packet, then waits for response Transport Layer 3-15 Transport Layer 3-16 rdt2.1:, handles garbled ACK/NAKs && notcorrupt(rcvpkt) && isack(rcvpkt) ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from ACK or NAK 1 ACK or NAK 0 call 1 from ( corrupt(rcvpkt) isnak(rcvpkt) ) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) Transport Layer 3-17 rdt2.1:, handles garbled ACK/NAKs (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack, chksum) 0 from below 1 from below notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack, chksum) (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) Transport Layer 3-18 3
rdt2.1: discussion rdt2.2: a NAK-free protocol : seq # added to pkt two seq. # s (0,1) will suffice. Why? must check if received ACK/NAK corrupted twice as many states state must remember whether expected pkt should have seq # of 0 or 1 : must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # note: can not know if its last ACK/ NAK received OK at same functionality as rdt2.1, using ACKs only instead of NAK, sends ACK for last pkt received OK must explicitly include seq # of pkt being ACKed duplicate ACK at results in same action as NAK: retransmit current pkt Transport Layer 3-19 Transport Layer 3-20 rdt2.2:, fragments rdt3.0: channels with errors and loss (corrupt(rcvpkt) has_seq1(rcvpkt)) sndpkt = make_pkt(0, data, checksum) call 0 from 0 from below ACK 0 FSM fragment FSM fragment notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack1, chksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Transport Layer 3-21 new assumption: underlying channel can also lose packets (data, ACKs) checksum, seq. #, ACKs, retransmissions will be of help but not enough approach: waits reasonable amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but seq. # s already handles this must specify seq # of pkt being ACKed requires countdown timer Transport Layer 3-22 rdt3.0 rdt3.0 in action call 0from && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer ( corrupt(rcvpkt) isack(rcvpkt,0) ) sndpkt = make_pkt(0, data, checksum) Wait for ACK1 Wait for ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer send rcv send rcv ack1 send rcv send rcv ack1 send ack1 rcv send (a) no loss send rcv send resend rcv ack1 send loss ack1 (b) packet loss rcv send rcv send ack1 rcv send Transport Layer 3-23 Transport Layer 3-24 4
rdt3.0 in action send rcv send resend rcv ack1 send ack1 loss ack1 (c) ACK loss rcv send rcv send ack1 rcv (detect duplicate) send ack1 rcv send send rcv send resend rcv ack1 send rcv ack1 send ack1 ack1 rcv send rcv send ack1 rcv (detect duplicate) send ack1 rcv send rcv (detect duplicate) send (d) premature / delayed ACK Performance of rdt3.0 rdt3.0 is correct, but performance stinks e.g.: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: D trans = L R U : utilization fraction of time busy sending U = 8000 bits = 10 9 = 8 microsecs bits/sec L / R RTT + L / R =.008 30.008 = 0.00027 if RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec thruput over 1 Gbps link protocol limits use of resources! Transport Layer 3-25 Transport Layer 3-26 rdt3.0: stop-and-wait operation first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK Pipelined protocols pipelining: allows multiple, in-flight, yetto-be-acknowledged pkts range of sequence numbers must be increased buffering at and/or ACK arrives, send next packet, t = RTT + L / R U = L / R RTT + L / R =.008 30.008 = 0.00027 two generic forms of pipelined protocols: go-back-n, selective repeat Transport Layer 3-27 Transport Layer 3-28 Pipelining: increased utilization Pipelined protocols: overview first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT ACK arrives, send next packet, t = RTT + L / R U = 3L / R RTT + L / R = 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.0024 30.008 3-packet pipelining increases utilization by a factor of 3! = 0.00081 Go-back-N: can have up to N unacked packets in pipeline only sends cumulative ack doesn t ack packet if there s a gap has timer for oldest unacked packet when timer expires, retransmit all unacked packets Selective Repeat: can have up to N unack ed packets in pipeline rcvr sends individual ack for each packet maintains timer for each unacked packet when timer expires, retransmit only that unacked packet Transport Layer 3-29 Transport Layer 3-30 5
Go-Back-N: 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 ) timer for oldest in-flight pkt (n): retransmit packet n and all higher seq # pkts in window Transport Layer 3-31 GBN: extended FSM base=1 nextseqnum=1 && corrupt(rcvpkt) if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) nextseqnum++ } else refuse_data(data) Wait udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt [nextseqnum-1]) notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else Transport Layer 3-32 GBN: extended FSM GBN in action default expectedseqnum=1 sndpkt = make_pkt(0,ack,chksum) Wait && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) sndpkt = make_pkt(expectedseqnum,ack,chksum) expectedseqnum++ ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don t buffer): no buffering! re-ack pkt with highest in-order seq # window (N=4) send send send pkt2 send pkt3 (wait) rcv, send pkt4 rcv ack1, send pkt5 ignore duplicate ACK pkt 2 send pkt2 send pkt3 send pkt4 send pkt5 loss receive, send receive, send ack1 receive pkt3, discard, (re)send ack1 receive pkt4, discard, (re)send ack1 receive pkt5, discard, (re)send ack1 rcv pkt2, deliver, send ack2 rcv pkt3, deliver, send ack3 rcv pkt4, deliver, send ack4 rcv pkt5, deliver, send ack5 Transport Layer 3-33 Transport Layer 3-34 Selective repeat Selective repeat:, windows individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer only resends pkts for which ACK not received timer for each unacked pkt window N consecutive seq # s limits seq #s of sent, unacked pkts Transport Layer 3-35 Transport Layer 3-36 6
Selective repeat Selective repeat in action data from : if next available seq # in window, send pkt (n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq # pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore window (N=4) send send send pkt2 send pkt3 (wait) rcv, send pkt4 rcv ack1, send pkt5 record ack3 arrived pkt 2 send pkt2 record ack4 arrived record ack5 arrived loss receive, send receive, send ack1 receive pkt3, buffer, send ack3 receive pkt4, buffer, send ack4 receive pkt5, buffer, send ack5 rcv pkt2; deliver pkt2, pkt3, pkt4, pkt5; send ack2 Q: what happens when ack2 arrives? Transport Layer 3-37 Transport Layer 3-38 Selective repeat: dilemma example: seq # s: 0, 1, 2, 3 window size=3 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)? window (after receipt) pkt2 retransmit (b) oops! pkt2 pkt3 (a) no problem window (after receipt) will accept packet with seq number 0 can t see side. behavior identical in both cases! something s (very) wrong! will accept packet with seq number 0 Transport Layer 3-39 Chapter 3 outline 3.1 transport-layer 3.2 principles of reliable data transfer 3.3 connection-oriented transport: TCP segment structure connection management 3.4 principles of congestion control 3.5 TCP congestion control Transport Layer 3-40 TCP: Overview RFCs: 793,1122,1323, 2018, 2581 point-to-point: one, one reliable, in-order byte stream: no message boundaries pipelined: TCP congestion and flow control set window size full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) inits, state before data exchange flow controlled: will not overwhelm Transport Layer 3-41 TCP segment structure 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) 32 bits source port # dest port # sequence number acknowledgement number head not len used U A P R S F receive window checksum Urg data pointer options (variable length) data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Transport Layer 3-42 7
TCP seq. numbers, ACKs outgoing segment from source port # dest port # sequence numbers: sequence number byte stream number of acknowledgement number rwnd first byte in segment s checksum urg pointer data window size acknowledgements: N seq # of next byte expected from other side sequence number space cumulative ACK sent sent, notyet ACKed Q: how handles ACKed out-of-order segments ( inflight ) A: TCP spec doesn t say, source port # dest port # - up to implementor incoming segment to sequence number acknowledgement number A rwnd checksum usable not but not usable yet sent urg pointer TCP seq. numbers, ACKs Host A User types C host ACKs receipt of echoed C Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 simple telnet scenario Host B host ACKs receipt of C, echoes back C Transport Layer 3-43 Transport Layer 3-44 TCP round trip time, TCP round trip time, Q: how to set TCP value? longer than RTT but RTT varies too short: premature, unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT smoother average several recent measurements, not just current SampleRTT EstimatedRTT = (1- α)*estimatedrtt + α*samplertt exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) RTT (milliseconds) 350 300 250 200 150 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr samplertt EstimatedRTT Transport Layer 3-45 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) time (seconds) Transport Layer 3-46 SampleRTT Estimated RTT TCP round trip time, Chapter 3 outline interval: EstimatedRTT plus safety margin large variation in EstimatedRTT -> larger safety margin estimate SampleRTT deviation from EstimatedRTT: DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (typically, β = 0.25) TimeoutInterval = EstimatedRTT + 4*DevRTT estimated RTT safety margin 3.1 transport-layer 3.2 principles of reliable data transfer 3.3 connection-oriented transport: TCP segment structure connection management 3.4 principles of congestion control 3.5 TCP congestion control * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer 3-47 Transport Layer 3-48 8
TCP reliable data transfer TCP creates rdt service on top of IP s unreliable service pipelined segments cumulative acks single retransmission timer retransmissions triggered by: events duplicate acks let s initially consider simplified TCP : ignore duplicate acks ignore flow control, congestion control TCP events: data rcvd from app: create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running think of timer as for oldest unacked segment expiration interval: TimeOutInterval : retransmit segment that caused restart timer ack rcvd: if ack acknowledges previously unacked segments update what is known to be ACKed start timer if there are still unacked segments Transport Layer 3-49 Transport Layer 3-50 TCP (simplified) TCP: retransmission scenarios NextSeqNum = InitialSeqNum SendBase = InitialSeqNum wait for event ACK received, with ACK field value y data received from create segment, seq. #: NextSeqNum pass segment to IP (i.e., send ) NextSeqNum = NextSeqNum + length(data) if (timer currently not running) start timer if (y > SendBase) { SendBase = y /* SendBase 1: last cumulatively ACKed byte */ if (there are currently not-yet-acked segments) start timer else stop timer } retransmit not-yet-acked segment with smallest seq. # start timer Transport Layer 3-51 Host A Host B Seq=92, 8 bytes of data Seq=92, 8 bytes of data lost ACK scenario SendBase=92 Host A SendBase=100 SendBase=120 SendBase=120 Seq=92, 8 bytes of data Seq=100, 20 bytes of data ACK=120 Seq=92, 8 bytes of data ACK=120 premature Host B Transport Layer 3-52 TCP: retransmission scenarios TCP ACK generation [RFC 1122, RFC 2581] Host A Host B event at TCP action Seq=92, 8 bytes of data Seq=100, 20 bytes of data ACK=120 arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed arrival of in-order segment with expected seq #. One other segment has ACK pending delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK, ACKing both in-order segments Seq=120, 15 bytes of data arrival of out-of-order segment higher-than-expect seq. #. Gap detected immediately send duplicate ACK, indicating seq. # of next expected byte cumulative ACK arrival of segment that partially or completely fills gap immediate send ACK, provided that segment starts at lower end of gap Transport Layer 3-53 Transport Layer 3-54 9
TCP fast retransmit time-out period often relatively long: long delay before resending lost packet detect lost segments via duplicate ACKs. often sends many segments backto-back if segment is lost, there will likely be many duplicate ACKs. TCP fast retransmit if 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 TCP fast retransmit Host A Host B Seq=92, 8 bytes of data Seq=100, 20 bytes of data Seq=100, 20 bytes of data Transport Layer 3-55 fast retransmit after receipt of triple duplicate ACK Transport Layer 3-56 Chapter 3 outline 3.1 transport-layer 3.2 principles of reliable data transfer 3.3 connection-oriented transport: TCP segment structure connection management 3.4 principles of congestion control 3.5 TCP congestion control TCP flow control flow control controls, so won t overflow s buffer by transmitting too much, too fast may remove data from TCP socket buffers. slower than TCP is delivering ( is sending) process TCP socket buffers from TCP code IP code protocol stack OS Transport Layer 3-57 Transport Layer 3-58 TCP flow control Chapter 3 outline advertises free buffer space by including rwnd value in TCP header of -to- segments RcvBuffer size set via socket options (typical default is 4096 bytes) many operating systems autoadjust RcvBuffer limits amount of unacked ( in-flight ) data to s rwnd value guarantees receive buffer will not overflow to process RcvBuffer buffered data rwnd free buffer space TCP segment payloads -side buffering 3.1 transport-layer 3.2 principles of reliable data transfer 3.3 connection-oriented transport: TCP segment structure connection management 3.4 principles of congestion control 3.5 TCP congestion control Transport Layer 3-59 Transport Layer 3-60 10
Connection Management before exchanging data, / handshake : agree to establish connection (each knowing the other willing to establish connection) agree on connection parameters connection state: connection variables: seq # client-to-server server-to-client rcvbuffer size at server,client connection state: connection Variables: seq # client-to-server server-to-client rcvbuffer size at server,client Agreeing to establish a connection 2-way handshake: choose x Let s talk OK acc_conn(x) Q: will 2-way handshake always work in? variable delays retransmitted messages (e.g. ) due to message loss message reordering can t see other side Socket clientsocket = newsocket("hostname","port number"); Socket connectionsocket = welcomesocket.accept(); Transport Layer 3-61 Transport Layer 3-62 Agreeing to establish a connection 2-way handshake failure scenarios: choose x retransmit client terminates acc_conn(x) connection x completes half open connection! (no client!) server forgets x choose x retransmit retransmit data(x+1) client terminates acc_conn(x) data(x+1) connection x completes data(x+1) accept data(x+1) server forgets x accept data(x+1) Transport Layer 3-63 TCP 3-way handshake client state LISTEN SYNSENT choose init seq num, x send TCP SYN msg received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK msg, acking SYN SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 ACKbit=1, ACKnum=y+1 received ACK(y) indicates client is live server state LISTEN SYN RCVD Transport Layer 3-64 TCP 3-way handshake: FSM TCP: closing a connection Socket connectionsocket = welcomesocket.accept(); SYN(x) SYNACK(seq=y,ACKnum=x+1) create new socket for communication back to client closed listen Socket clientsocket = newsocket("hostname","port number"); SYN(seq=x) client, server each close their side of connection send TCP segment with FIN bit = 1 respond to received FIN with ACK on receiving FIN, ACK can be combined with own FIN simultaneous FIN exchanges can be handled SYN rcvd SYN sent ACK(ACKnum=y+1) SYNACK(seq=y,ACKnum=x+1) ACK(ACKnum=y+1) Transport Layer 3-65 Transport Layer 3-66 11
TCP: closing a connection client state FIN_WAIT_1 FIN_WAIT_2 TIMED_WAIT clientsocket.close() can no longer send but can receive data wait for server close timed wait for 2*max segment lifetime FINbit=1, seq=x ACKbit=1; ACKnum=x+1 FINbit=1, seq=y ACKbit=1; ACKnum=y+1 can still send data can no longer send data server state CLOSE_WAIT LAST_ACK CLOSED CLOSED Transport Layer 3-67 12