1. Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Part 3: TCP

2. Transport Layer3-2 Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable data transfer m flow control m congestion control r learn about transport layer protocols in the Internet: m UDP: connectionless transport m TCP: connection-oriented transport m TCP congestion control

3. Transport Layer3-3 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m TCP connection m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

4. Transport Layer3-4 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers r point-to-point: m one sender, one receiver m No multi-cast (at this layer) m Intermediate nodes (routers, etc.) do not know anything about the protocol

5. Transport Layer3-5 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size

6. TCP connection r TCP in client connects to TCP in server via 3- way handshake m Client TCP sends a special TCP segment m Server responds with a second special TCP segment m Client responds with third special TCP segment m First two have no payload (i.e., application data) m Third may have payload Transport Layer3-6

7. Transport Layer 3-7 Connection Management before exchanging data, sender/receiver “handshake”: r agree to establish connection (each knowing the other willing to establish connection) r agree on connection parameters connection state: ESTAB connection variables: seq # client-to-server server-to-client rcvBuffer size at server,client application network connection state: ESTAB connection Variables: seq # client-to-server server-to-client rcvBuffer size at server,client application network Socket clientSocket = newSocket("hostname","port number"); Socket connectionSocket = welcomeSocket.accept();

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

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

10. Opening a connection r One side (client) does an active open to the other (server) side Socket connectToServer = new Socket(“computer1.ithaca.edu”, 8000); r Server must have previously done a passive open. ServerSocket myServer = new ServerSocket(port); Socket clientConnection = myServer.accept(); r Then begin the 3-way handshake Transport Layer3-10 Active open Passive open

11. 3-way handshake r Goal: agree on a set of parameters: m Starting sequence numbers m MSS m Etc. r Client sends a segment to server with initial seg no. (Flags=SYN, SequenceNum=x) Transport Layer3-11

12. 3-way handshake r Server responds with a single segment that both acknowledges the client’s sequence no. (Flags=ACK, Ack = x + 1) r And states its own beginning sequence no. (Flags=SYN, SequenceNum=y) r i.e., both SYN and ACK bits are Set in the Flags field Transport Layer3-12

13. 3-way handshake r Client then sends third segment to acknowledge the server’s sequence no. (Flags=ACK, Ack = y + 1) r Reason for ACK’ing the Seq no: the ACK’ed no. + 1 is the next seq no. expected. Thus it implicitly ack’s all earlier seq no. r Note that a timer is set for the ACK messages. Transport Layer3-13

14. 3-way handshake r Why are seq no. exchanged? m Protects against two incarnations of the same connection reusing the same seq no. too soon m TCP requires that each side select an initial starting seq no. at random. Transport Layer3-14

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

16. Transport Layer 3-16 TCP 3-way handshake: FSM closed  listen SYN rcvd SYN sent ESTAB Socket clientSocket = newSocket("hostname","port number"); SYN(seq=x) Socket connectionSocket = welcomeSocket.accept(); SYN(x) SYNACK(seq=y,ACKnum=x+1) create new socket for communication back to client SYNACK(seq=y,ACKnum=x+1) ACK(ACKnum=y+1) 

17. FSM for opening/closing conn Transport Layer3-17 Client

18. FSM for opening/closing conn Transport Layer3-18 Server

19. 3-way handshake r If client’s ACK to server is lost (3 rd leg), then the connection still functions correctly m Client is already in ESTABLISHED state m Application can send data m Each segment sent will have ACK flag set and the correct value in the Acknowledgement field m Server will move to ESTABLISHED state when receives first segment. Transport Layer3-19

20. 3-way handshake r The server can send a SYN to a client m i.e., the server can actively make a connection! m No application process actually uses this r The time-out arcs are not shown in the diagram m If the expected response does not arrive resend m After several tries, give up and return to CLOSED state. Transport Layer3-20

21. Closing a connection r Both sides must independently close its half of the connection r If only one side closes, it cannot send but can still receive. r So there are three possible combinations: m This side closes first m The other side closes first m Both sides close at the same time. Transport Layer3-21

22. Actual FSM Transport Layer3-22

23. Closing a connection r A connection in the TIME_WAIT state cannot move to the CLOSED state until m It has waited for two times the maimum amount of time an IP datagram might live in the Internet (i.e., 120 seconds) m Reason: the local side may have sent an ACK in response to the other side’s FIN, but does not know if it was received m The other side might thus retrans it’s FIN segment m If we closed too soon, some other process might open the same connection then receive the FIN segment! Transport Layer3-23

24. TCP connection r Data processing m Client sends stream of data through socket to TCP m TCP puts data into a send buffer m From time-to-time TCP grabs some data from buffer and passes it to network layer m Network layer encloses in an IP datagram, then sends over network m Network layer at server extracts the TCP segment from the IP datagram and passes the segment to server TCP layer m TCP layer extracts the data and places in a receive buffer m Server process reads data from the receive buffer Transport Layer3-24

25. TCP connection r Data processing m Max data that can be grabbed by TCP is limited by the maximum segment size (MSS) MSS set by first determining the length of the largest link-layer frame (the maximum transmission unit) Then set MSS to ensure that a TCP segment, when encapsulated in an IP datagram plus TCP/IP header length (40 bytes) will fit into the MTU Transport Layer3-25 Ehternet and PPP link layer protocols both have MSS of 1,500 bytes

26. TCP data processing r TCP is byte-oriented m The sender writes bytes into a TCP connection m The receiver reads bytes out of a TCP conn r TCP does not transmit individual bytes over the internet m Source host buffers enough bytes to fill a reasonably sized packet m Destination TCP empties the content into a buffer; application reads from buffer at its leisure. Transport Layer3-26

27. TCP data processing Transport Layer3-27 This diagram only shows one direction; in reality connections are bi-directional Called “segments” because they contain a segment of the byte stream

28. Transport Layer3-28 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pointer checksum F SR PAU head len not used Options (variable length) Based on what we’ve seen so far, what do each of these fields do?

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

30. Transport Layer3-30 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pointer checksum F SR PAU head len not used Options (variable length) 4 tuple: Can be closed and later reopened (called incarnations) 4 tuple: Can be closed and later reopened (called incarnations)

31. Transport Layer3-31 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pointer checksum F SR PAU head len not used Options (variable length) Used in sliding window algorithm Seq no. are for first byte of data in segment ACK is no. of next byte expected Seq no. are for first byte of data in segment ACK is no. of next byte expected Flag bits: SYN, FIN, RESET, PUSH, URG, and ACK Flag bits: SYN, FIN, RESET, PUSH, URG, and ACK Checksum field same as UDP— computed over the TCP header, the TCP data, and the pseudoheader (source address, destination address, and length fields from the IP header) Checksum field same as UDP— computed over the TCP header, the TCP data, and the pseudoheader (source address, destination address, and length fields from the IP header)

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

33. Transport Layer3-33 TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK* Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementer Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario *Receipt of ACK with seq no n is cummulative, i.e., all packets up to and including n are ACK’d More on this later!

34. timeouts r TCP uses a timeout/retransmit mechanism r How long should this be? m Larger than RTT (round trip time) m How much larger? m How do we estimate this in the first place? m Do we associate a timer with each segment? Transport Layer3-34

35. Transport Layer3-35 TCP seq. #’s and ACKs r TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT m but RTT varies r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

36. Transport Layer3-36 TCP seq. #’s and ACKs Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions  SampleRTT will vary, want estimated RTT “smoother”  average several recent measurements, not just current SampleRTT Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

37. Estimating round-trip time r Definition: SampleRTT for a segment is the amount of time between when the segment is “sent” (passed to IP) and when an acknowledgement for the segment is received. Transport Layer3-37

38. Estimating round-trip time r Approach m TCP take one SampleRTT measurement at a time, not one for each segment sent. m i.e., SampleRTT is being estimated for only one of the transmitted but currently unack’d segments. m TCP never calculates SampleRTT for a retransmitted segment. Transport Layer3-38

39. Estimating round-trip time r Approach m SampleRTT varies (depends on router congestion, load on end systems, etc.) m Need some sort of average: EstimatedRTT m When TCP gets a new SampleRTT, it calculates EstimatedRTT: m EstimatedRTT is a combination of past estimates and newest time. Transport Layer3-39 Past valuesMost recent value EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT

40. Estimating round-trip time r Approach m EstimatedRTT: m EstimatedRTT is a combination of past estimates and newest time. m Recommended value of α is α = 0.125, so formula becomes: Transport Layer3-40 EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT EstimatedRTT = 0.875*EstimatedRTT + 0.125*SampleRTT

41. Estimating round-trip time r Approach m Recommended value of α is α = 0.125, so formula becomes: m Places more weight on recent samples than old samples. How? Expand this a few terms. m Done because recent samples reflect current network congestion. m Called an Exponential weighted moving average the weight of a given SampleRTT decays exponentially fast. influence of past sample decreases exponentially fast m See next slide: variations in SampleRTT are smoothed out. Transport Layer3-41 EstimatedRTT = 0.875*EstimatedRTT + 0.125*SampleRTT

42. Transport Layer3-42 Example RTT estimation:

43. Variability of RTT r RFC 6298 defined DevRTT m An estimate of how much SampleRTT typically deviates from EstimatedRTT: r If DevRTT is small, there there is little fluctuation in SampleRTT Transport Layer3-43 DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.25)

44. TCP Round Trip Time and Timeout r Setting the timeout value for TCP r EstimtedRTT plus “safety margin” m Interval must be ≥ EstimatedRTT ow unnecessary retransmissions m Interval must not be too large ow get unnecessary retransmission delays when packets are lost m large variation in EstimatedRTT -> need larger safety margin Transport Layer3-44 TimeoutInterval = EstimatedRTT + 4*DevRTT

45. TCP Round Trip Time and Timeout r Setting the timeout value for TCP r first estimate of how much SampleRTT deviates from EstimatedRTT: r Initial TimeoutInterval value of 1 second is recommended [RFC 6298] r When timeout occurs, double value of TimeoutInterval (avoid premature timeout of subsequent segment) r But when the next segment is received, go back to formula Transport Layer3-45 TimeoutInterval = EstimatedRTT + 4*DevRTT

46. Transport Layer3-46 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

47. Transport Layer3-47 TCP reliable data transfer r TCP creates rdt service on top of IP’s unreliable service m pipelined segments m cumulative ACKs m TCP uses single retransmission timer Reduces overhead r retransmissions are triggered by: m timeout events m duplicate ACKs r initially consider simplified TCP sender: m ignore duplicate ACKs m ignore flow control, congestion control

48. Transport Layer3-48 TCP sender (simplified) 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 start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ Comment: SendBase-1: last cumulatively ACKed byte Example: SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so segments 71, 72 are considered Acked

49. TCP sender events (3 events): 1. data rcvd from app: m create segment with seq # m 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 –Use EstimatedRTT and DevRTT to determine 2. timeout: m retransmit segment that caused timeout m restart timer 3. ACK rcvd: m if acknowledges previously unACKed segments update what is known to be ACKed start timer if there are outstanding segments Transport Layer3-49

50. Transport Layer 3-50 TCP sender (simplified) wait for event NextSeqNum = InitialSeqNum SendBase = InitialSeqNum  create segment, seq. #: NextSeqNum pass segment to IP (i.e., “send”) NextSeqNum = NextSeqNum + length(data) if (timer currently not running) start timer data received from application above retransmit not-yet-acked segment with smallest seq. # start timer timeout if (y > SendBase) { SendBase = y /* SendBase–1: last cumulatively ACKed byte */ if (there are currently not-yet-acked segments) start timer else stop timer } ACK received, with ACK field value y

51. Transport Layer3-51 TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time SendBase = 100 Discards packet that it already received.

52. Transport Layer3-52 TCP: retransmission scenarios Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Seq=92 timeout SendBase = 120 SendBase = 120 Sendbase = 100 Resends first packet and resets timer. Does not resend second packet unless timeout again

53. Transport Layer3-53 TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120 Receives Ack to second packet. Cummulative Ack, so sender knows that 1 st packet also arrived.

54. Timeout interval revisited r Modifications (not all TCP implementations) m Timesout: retransmit packet with smallest unAck’d seq no. Double time interval if timeout occurs again will again double interval. Etc. If Ack is received, go back to formula for EstimatedRTT and DevRTT m Why? Limited form of congestion control Timeout probably due to congestion TCP acts politely; sends less packets Transport Layer3-54

55. Transport Layer3-55 TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver 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 Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap TCP Receiver action 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 Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

56. Transport Layer3-56 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate ACKs. m sender often sends many segments back-to-back m if segment is lost, there will likely be many duplicate ACKs for that segment (see previous slide) 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 (“triple duplicate ACKs”), TCP fast retransmit

57. Transport Layer3-57 Host A timeout Host B time X resend seq X2 seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 ACK x1 triple duplicate ACKs

58. Transport Layer3-58 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 } Fast retransmit algorithm: a duplicate ACK for already ACKed segment fast retransmit Replaces the “ACK” event in previous code

59. Go-Back-N or Selective Repeat? r TCP acknowledgements are accumulative r Correctly received but out- of-order segments are not individually ACKd r TCP sender only need maintain the sequence no. of the smallest unACKd byte and the seq. no. of the next byte to send. r Many TCP implementations buffer correctly received but out-of-order segments r If sender sends N segments and all are ACKd, but one ACK (n < N) gets lost. r GBN would retransmit all segments > n r TCP only retransmits the lost segment and would not retransmit this if ACK for segment n+1 arrived! Transport Layer3-59 Looks like GBN Looks like SR

60. Go-Back-N or Selective Repeat? r A proposed modification to TCP called selective acknowledgement [RFC 2018] would allow a TCP receiver to ACK out-of-order segments rather than cumulative ACKs Transport Layer3-60 So, TCP is a hybrid between GBN and SR

61. Transport Layer3-61 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

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

63. Transport Layer 3-63 TCP flow control buffered data free buffer space rwnd RcvBuffer TCP segment payloads to application process  receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments  RcvBuffer size set via socket options (typical default is 4096 bytes)  many operating systems autoadjust RcvBuffer  sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value r guarantees receive buffer will not overflow receiver-side buffering rwnd = receive window receive side of TCP connection has a receive buffer:

64. TCP Flow control: how it works Transport Layer3-64 IP datagrams TCP data (in buffer) (currently) unused buffer space application process rwnd RcvBuffer Sender maintains a variable called the receive window Used to give the sender an idea of how much free buffer space is available at receiver Each side of a connection can send, so both sides maintain a receive window. Assume that the TCP receiver discards out-of-order packets Protocol. Assume Host A is sending large file to Host B Host B allocates a receive buffer of size RcvBuffer. Periodically Application reads from B’s buffer. Host B keeps two variables: LastByteRead: the number of the last byte in the data stream read from buffer by application LastByteRcvd: the number of the last byte in the data stream that has arrived from the network and placed in the buffer

65. TCP Flow control: how it works r (suppose TCP receiver discards out-of-order segments) r unused buffer space: = rwnd = RcvBuffer – (LastByteRcvd – LastByteRead) Transport Layer3-65 rwnd = receive window

66. Transport Layer3-66 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

67. TCP Connection Management r Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e.g. RcvWindow) r client: connection initiator r Socket clientSocket = new Socket("hostname","port number"); r server: contacted by client r Socket connectionSocket = welcomeSocket.accept(); r Three way handshake: r Step 1: client host sends TCP SYN segment to server m specifies initial seq # m no data r Step 2: server host receives SYN, replies with SYNACK segment m server allocates buffers m specifies server initial seq. # r Step 3: client receives SYNACK, replies with ACK segment, which may contain data Transport Layer3-67

68. TCP Connection Management (cont.) r Closing a connection: r client closes socket: clientSocket.close(); r Step 1: client end system sends TCP FIN control segment to server r Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. Transport Layer3-68 client FIN server ACK FIN close closed timed wait

69. Transport Layer3-69 TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. m Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. client FIN server ACK FIN closing closed timed wait closed

70. Transport Layer3-70 TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle