Chapter3.pdf

Chapter 3 Transport Layer A note on the use of these PowerPoint slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and 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) that you mention their source (after all, we’d like people to use our book!) ▪ If you post any slides 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. For a revision history, see the slide note for this page. Computer Networking: A Thanks and enjoy! JFK/KWR Top-Down Approach All material copyright 1996-2023 8th edition J.F Kurose and K.W. Ross, All Rights Reserved Jim Kurose, Keith Ross Modifed by Dr. Abdulhakim Sabur & Dr. Abdullah Bin Ali, Taibah University, Madinah, Saudi Arabia Pearson, 2020 Transport Layer: 3-1 Transport layer: overview Our goal: ▪ understand principles ▪ learn about Internet transport behind transport layer layer protocols: services: UDP: connectionless transport multiplexing, TCP: connection-oriented reliable demultiplexing transport reliable data transfer TCP congestion control flow control congestion control Transport Layer: 3-2 Transport layer: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-3 Transport Layer services and protocols application transport ▪ Transport Layer provide logical mobile network network data link physical communication between application national or global ISP processes running on different hosts ▪ transport protocols actions in end systems: local or sender: breaks application messages regional ISP into segments, passes to network layer home network content receiver: reassembles segments into provider network datacenter messages, passes to application layer application transport network network ▪ two transport protocols available to data link physical Internet applications enterprise TCP,: Transport Control Protocol network UDP: User Datagram Protocol Transport Layer: 3-4 Transport vs. network layer services and protocols 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 in-house siblings ▪ network-layer protocol = postal service Transport Layer: 3-5 Transport vs. network layer services and protocols household analogy: ▪transport layer: 12 kids in Ann’s house sending communication between letters to 12 kids in Bill’s processes house: relies on, network layer ▪ hosts = houses services ▪ processes = kids ▪ app messages = letters in envelopes ▪network layer: ▪ transport protocol = Ann and Bill communication between who demux to in-house siblings hosts ▪ network-layer protocol = postal service Transport Layer: 3-6 Transport Layer Actions Sender: application ▪ is passed an application- application app. msg layer message transport ▪ determines segment TThhtransport app. msg header fields values network (IP) ▪ creates segment network (IP) link ▪ passes segment to IP link physical physical Transport Layer: 3-7 Transport Layer Actions Receiver: application ▪ receives segment from IP application ▪ checks header values transport app. msg ▪ extracts application-layer transport message network (IP) network (IP) ▪ demultiplexes message up link to application via socket link physical physical Th app. msg Transport Layer: 3-8 Two principal Internet transport protocols application ▪ TCP: Transmission Control Protocol transport network mobile network data link reliable, in-order delivery physical national or global ISP congestion control flow control Connection Oriented: connection setup ▪ UDP: User Datagram Protocol Connectionless oriented (No connection setup) local or regional ISP unreliable, unordered delivery no-frills extension of “best-effort” IP home network content provider No congestion control network datacenter application No flow control transport network network ▪ services not available in TCP nor UDP: data link physical delay guarantees enterprise bandwidth guarantees network Transport Layer: 3-9 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-10 Multiplexing/demultiplexing multiplexing as sender: demultiplexing as receiver: handle data from multiple use header info to deliver sockets, add transport header received segments to correct (later used for demultiplexing) socket application application P1 P2 application socket P3 transport P4 process transport network transport network link network link physical link physical physical Transport Layer: 3-11 HTTP server client application application HTTP msg transport Ht HTTP msg Hnnetwork Ht HTTP msg transport transport Hn Hnetwork t HTTP msg link network link physical link physical physical Hn Ht HTTP msg Transport Layer: 3-12 Q: how did transport layer know to deliver message to Firefox browser process rather then Netflix process or Skype process? client application application HTTP msg HTTP msg transport Ht HTTP msg transport network transport network link network link physical link physical physical Transport Layer: 3-13 ? de-multiplexing application ? transport de-multiplexing Demultiplexing multiplexing application transport multiplexing Multiplexing How demultiplexing works ▪ host receives IP packet 32 bits each packet has source IP source port # dest port # address, destination IP address each packet carries one other header fields transport-layer segment each segment has source, application destination port number data ▪ host uses IP addresses & port (payload) numbers to direct segment to appropriate socket TCP/UDP segment format Transport Layer: 3-21 Connectionless demultiplexing Recall: when receiving host receives ▪ when creating socket, must UDP segment: checks destination port # in specify host-local port #: segment DatagramSocket mySocket1 directs UDP segment to = new DatagramSocket(12534); socket with that port # ▪ when creating datagram to send into UDP socket, must specify IP/UDP datagrams with same dest. port #, but different source IP destination IP address addresses and/or source port destination port # numbers will be directed to same socket at receiving host Transport Layer: 3-22 Connectionless demultiplexing: an example mySocket = socket(AF_INET,SOCK_DGRAM) mySocket.bind(myaddr,6428); mySocket = mySocket = socket(AF_INET,SOCK_STREAM) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr,9157); mySocket.bind(myaddr,5775); application application application P1 P3 P4 transport transport transport network network link network link physical link physical physical B D source port: 6428 source port: ? dest port: 9157 dest port: ? A C source port: 9157 source port: ? dest port: 6428 dest port: ? Connection-oriented demultiplexing ▪ TCP socket identified by ▪ server may support many 4-tuple: simultaneous TCP sockets: source IP address each socket identified by its source port number own 4-tuple dest IP address each socket associated with dest port number a different connecting client ▪ demux: receiver uses all four values (4-tuple) to direct segment to appropriate socket Transport Layer: 3-24 Connection-oriented demultiplexing: example application application P4 P5 P6 application P1 P2 P3 transport transport transport network network link network link physical link physical server: IP physical address B host: IP source IP,port: B,80 host: IP address A dest IP,port: A,9157 source IP,port: C,5775 address C dest IP,port: B,80 source IP,port: A,9157 dest IP, port: B,80 source IP,port: C,9157 dest IP,port: B,80 Three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets Transport Layer: 3-25 Summary ▪ Multiplexing, demultiplexing: based on segment, datagram header field values ▪ UDP: demultiplexing using destination port number (only) ▪ TCP: demultiplexing using 4-tuple: source and destination IP addresses, and port numbers ▪ Multiplexing/demultiplexing happen at all layers Transport Layer: 3-26 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-27 UDP: User Datagram Protocol Why is there a UDP? ▪ “best effort” service, UDP segments may be: ▪ no connection establishment (which can lost add RTT delay) delivered out-of-order to ▪ simple: no connection state app at sender, receiver ▪ small header size ▪ connectionless: ▪ no congestion control no handshaking between UDP ▪ UDP can blast away as fast as desired! sender, receiver ▪ can function in the face of each UDP segment handled congestion independently of others Transport Layer: 3-28 UDP: User Datagram Protocol ▪ UDP use: ▪ streaming multimedia apps (loss tolerant, rate sensitive) ▪ DNS ▪ SNMP ▪ HTTP/3 ▪ if reliable transfer needed over UDP (e.g., HTTP/3): ▪ add needed reliability at application layer ▪ add congestion control at application layer Transport Layer: 3-29 UDP segment header format 32 bits source port # dest port # length checksum application length, in bytes of data UDP segment, (payload) including header data to/from UDP segment format application layer Transport Layer: 3-30 UDP checksum Goal: detect errors (i.e., flipped bits) in transmitted segment 1st number 2nd number sum Transmitted: 5 6 11 Received: 4 6 11 receiver-computed sender-computed checksum = checksum (as received) Transport Layer: 3-31 Internet checksum Goal: detect errors (i.e., flipped bits) in transmitted segment sender: receiver: ▪ treat contents of UDP ▪ compute checksum of received segment (including UDP header segment fields and IP addresses) as sequence of 16-bit integers ▪ check if computed checksum equals ▪ checksum: addition (one’s checksum field value: complement sum) of segment not equal - error detected content equal - no error detected. But maybe ▪ checksum value put into errors nonetheless? More later …. UDP checksum field Transport Layer: 3-32 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-33 Principles of reliable data transfer sending receiving process process application data data transport reliable channel reliable service abstraction Transport Layer: 3-34 Principles of reliable data transfer sending receiving sending receiving process process process process application data data application data data transport transport reliable channel sender-side of receiver-side reliable service abstraction reliable data of reliable data transfer protocol transfer protocol transport network unreliable channel reliable service implementation Transport Layer: 3-35 Principles of reliable data transfer sending receiving process process application data data transport sender-side of receiver-side Complexity of reliable data reliable data transfer protocol of reliable data transfer protocol transfer protocol will depend (strongly) on characteristics of transport network unreliable channel (lose, unreliable channel corrupt, reorder data?) reliable service implementation Transport Layer: 3-36 Principles of reliable data transfer Sender, receiver do not know sending receiving process process the “state” of each other, e.g., application data data was a message received? transport ▪ unless communicated via a sender-side of receiver-side reliable data of reliable data message transfer protocol transfer protocol ▪ e.g.: receiver sends “Acknowledgment (ACK)” transport network message: unreliable channel ▪ Received correctly reliable service implementation ▪ There is error or loss Transport Layer: 3-37 *Data Communication over channels with errors Assumption 1: underlying channel approach: sender sends packet(s) then can have errors in packets (data, waits “reasonable” amount of time ACKs) for Acknowledgment (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 receiver must specify seq # of pkt being ACKed ▪ requires countdown timer Transport Layer 3-38 *Data Communication over channels with Loss Assumption 2: underlying channel approach: sender waits “reasonable” can also lose packets (data, ACKs) 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 receiver must specify seq # of pkt being ACKed ▪ requires countdown timer Transport Layer 3-39 *Examples on How Data Communication Works sender receiver sender receiver send pkt0 pkt0 send pkt0 pkt0 rcv pkt0 rcv pkt0 ack0 send ack0 ack0 send ack0 rcv ack0 rcv ack0 send pkt1 pkt1 send pkt1 pkt1 rcv pkt1 X ack1 send ack1 loss rcv ack1 send pkt0 pkt0 rcv pkt0 timeout ack0 send ack0 resend pkt1 pkt1 rcv pkt1 ?? ack1 send ack1 rcv ack1 send pkt0 pkt0 rcv pkt0 ack0 send ack0 ?? (a) no loss (b) packet loss Transport Layer 3-40 *Examples on How Data Communication Works sender receiver sender receiver send pkt0 pkt0 send pkt0 pkt0 rcv pkt0 send ack0 rcv pkt0 ack0 send ack0 rcv ack0 ack0 send pkt1 pkt1 rcv ack0 rcv pkt1 send pkt1 pkt1 send ack1 rcv pkt1 ack1 ack1 send ack1 X loss timeout resend pkt1 pkt1 rcv pkt1 timeout resend pkt1 pkt1 rcv ack1 (detect duplicate) rcv pkt1 send pkt0 pkt0 send ack1 (detect duplicate) ack1 ack1 send ack1 rcv ack1 rcv pkt0 rcv ack1 send pkt0 ack0 send ack0 send pkt0 pkt0 pkt0 rcv pkt0 rcv pkt0 ack0 (detect duplicate) ack0 send ack0 send ack0 ?? ?? (c) ACK loss (d) premature timeout/ delayed ACK Transport Layer 3-41 stop-and-wait operation* sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives Round Trip Time last packet bit arrives, send ACK (RTT ) ACK arrives, send next packet, t = RTT + L / R Example: Calculate Utilization of sender if: t=.008 ms, RTT= 30 ms. U L/R.008 sender = = = 0.00027 = 27/100,000. (Very bad utilization) RTT + L / R 30.008 Transport Layer 3-42 *Pipelined protocols operation pipelining: sender allows multiple, “in-flight”, yet- to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver ❖two generic forms of pipelined protocols: go-Back-N, selective repeat Transport Layer 3-43 *Pipelined protocols: overview Go-back-N: ▪ sender can have up to N unacked packets in pipeline ▪ receiver only sends a cumulative ack doesn’t ack packet if there’s a gap ▪ sender has timer for oldest unacked packet when timer expires, retransmit all unacked packets Transport Layer 3-44 Go-Back-N: sender ▪ sender: “window” of up to N, consecutive transmitted but unACKed pkts k-bit seq # in pkt header ▪ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n on receiving ACK(n): move window forward to begin at n+1 ▪ timer for oldest in-flight packet ▪ timeout(n): retransmit packet n and all higher seq # packets in window Transport Layer: 3-45 *GBN in action Seq#: 0-8, just an example sender window size (N=4) sender receiver 012345678 send pkt0 012345678 send pkt1 012345678 send pkt2 receive pkt0, send ack0 012345678 send pkt3 Xloss receive pkt1, send ack1 (wait) receive pkt3, discard, 012345678 rcv ack0, send pkt4 (re)send ack1 012345678 rcv ack1, send pkt5 receive pkt4, discard, (re)send ack1 ignore duplicate ACK receive pkt5, discard, (re)send ack1 pkt 2 timeout 012345678 (re)send pkt2 012345678 (re)send pkt3 012345678 (re)send pkt4 rcv pkt2, deliver, send ack2 012345678 (re)send pkt5 rcv pkt3, deliver, send ack3 rcv pkt4, deliver, send ack4 rcv pkt5, deliver, send ack5 Transport Layer 3-46 *Selective repeat ▪sender can have up to N unacked packets in pipeline ▪receiver sends individual ack for all correctly received packets buffers packets, as needed, for eventual in-order delivery to upper layer ▪sender times-out/retransmits individually for unACKed packets sender maintains timer for each unACKed pkt ▪sender window N consecutive seq #s limits seq #s of sent, unACKed packets Transport Layer: 3-47 *Selective repeat: sender, receiver windows Transport Layer: 3-48 Selective repeat: sender and receiver sender receiver data from above: packet n in [rcvbase, rcvbase+N-1] ▪ if next available seq # in ▪ send ACK(n) window, send packet ▪ out-of-order: buffer timeout(n): ▪ in-order: deliver (also deliver buffered, in-order packets), ▪ resend packet n, restart timer advance window to next not-yet- ACK(n) in [sendbase,sendbase+N]: received packet ▪ mark packet n as received packet n in [rcvbase-N,rcvbase-1] ▪ if n smallest unACKed packet, ▪ ACK(n) advance window base to next otherwise: unACKed seq # ▪ ignore Transport Layer: 3-49 Selective Repeat in action sender window (N=4) sender receiver 012345678 send pkt0 012345678 send pkt1 012345678 send pkt2 receive pkt0, send ack0 012345678 send pkt3 Xloss receive pkt1, send ack1 (wait) receive pkt3, buffer, 012345678 rcv ack0, send pkt4 send ack3 012345678 rcv ack1, send pkt5 receive pkt4, buffer, record ack3 arrived send ack4 receive pkt5, buffer, pkt 2 timeout send ack5 012345678 REsend pkt2 012345678 (but not 3,4,5) 012345678 rcv pkt2; deliver pkt2, 012345678 pkt3, pkt4, pkt5; send ack2 Q: what happens when ack2 arrives? Transport Layer: 3-50 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-51 TCP: overview RFCs: 793,1122, 2018, 5681, 7323 ▪ point-to-point: ▪ cumulative ACKs one sender, one receiver ▪ pipelining: ▪ reliable, in-order byte TCP congestion and flow control steam: set window size no “message boundaries" ▪ connection-oriented: ▪ full duplex data: handshaking (exchange of control bi-directional data flow in messages) initializes sender, same connection receiver state before data exchange MSS: maximum segment size ▪ flow controlled: sender will not overwhelm receiver Transport Layer: 3-52 TCP segment structure 32 bits source port # dest port # segment seq #: counting ACK: seq # of next expected sequence number bytes of data into bytestream byte; A bit: this is an ACK (not segments!) acknowledgement number head not length (of TCP header) len used C EUAP R SF receive window flow control: # bytes Internet checksum checksum Urg data pointer receiver willing to accept options (variable length) C, E: congestion notification TCP options application data sent by RST, SYN, FIN: connection data application into management (variable length) TCP socket Transport Layer: 3-53 TCP sequence numbers, ACKs outgoing segment from sender Sequence numbers: source port # dest port # sequence number byte stream “number” of acknowledgement number rwnd first byte in segment’s data checksum urg pointer window size Acknowledgements: N seq # of next byte expected from other side sender sequence number space cumulative ACK sent sent, not- usable not ACKed yet ACKed but not usable (“in-flight”) yet sent Q: how receiver handles out-of- order segments outgoing segment from receiver A: TCP spec doesn’t say, - up source port # dest port # sequence number to implementor acknowledgement number A rwnd checksum urg pointer Transport Layer: 3-54 TCP sequence numbers, ACKs Host A Host B User types‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario Transport Layer: 3-55 TCP round trip time (RTT), timeout Q: how to set TCP timeout Q: how to estimate RTT? value? ▪ SampleRTT:measured time ▪ longer than RTT, but RTT varies! from segment transmission until ACK receipt ▪ too short: premature timeout, ignore retransmissions unnecessary retransmissions ▪ SampleRTT will vary, want ▪ too long: slow reaction to estimated RTT “smoother” segment loss average several recent measurements, not just current SampleRTT Transport Layer: 3-56 TCP Sender (simplified) event: data received from event: timeout application ▪ retransmit segment that caused timeout ▪ create segment with seq # ▪ restart timer ▪ seq # is byte-stream number of first data byte in segment event: ACK received ▪ start timer if not already running ▪ if ACK acknowledges previously unACKed segments think of timer as for oldest unACKed segment update what is known to be ACKed expiration interval: TimeOutInterval start timer if there are still unACKed segments Transport Layer: 3-58 TCP: retransmission scenarios Host A Host B Host A Host B SendBase=92 Seq=92, 8 bytes of data Seq=92, 8 bytes of data Seq=100, 20 bytes of data timeout timeout ACK=100 X ACK=100 ACK=120 Seq=92, 8 bytes of data Seq=92, 8 SendBase=100 bytes of data send cumulative SendBase=120 ACK for 120 ACK=100 ACK=120 SendBase=120 lost ACK scenario premature timeout Transport Layer: 3-59 TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes of data Seq=100, 20 bytes of data ACK=100 X ACK=120 Seq=120, 15 bytes of data cumulative ACK covers for earlier lost ACK Transport Layer: 3-60 TCP fast retransmit Host A Host B TCP fast retransmit if sender receives 3 additional ACKs for same data (“triple duplicate ACKs”), resend unACKed segment with smallest seq # X ▪ likely that unACKed segment lost, so don’t wait for timeout timeout Receipt of three duplicate ACKs indicates 3 segments received Seq=100, 20 bytes of data after a missing segment – lost segment is likely. So retransmit! Transport Layer: 3-61 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-62 **TCP flow control Q: What happens if network layer application delivers data faster than Application removing process application layer removes data data from TCP socket buffers from socket buffers? TCP socket A: TCP socket receiver buffer will receiver buffers be over-loaded (or overflow) TCP code Q: How to solve it? Network layer delivering IP datagram A: Using TCP Flow Control payload into TCP IP Next slide socket buffers code from sender receiver protocol stack Transport Layer: 3-63 TCP flow control application Q: What happens if network Application removing process layer delivers data faster than data from TCP socket buffers application layer removes TCP socket data from socket buffers? receiver buffers TCP code Network layer delivering IP datagram payload into TCP IP socket buffers code from sender receiver protocol stack Transport Layer: 3-64 *TCP flow control flow control application receiver controls sender, so sender Application removing process won’t over-load (overflow) receiver’s data from TCP socket buffer by transmitting too much, too fast buffers TCP socket receiver buffers TCP code receive window flow control: # bytes receiver willing to accept IP code from sender receiver protocol stack Transport Layer: 3-65 TCP connection management before exchanging data, sender/receiver “handshake”: ▪ agree to establish connection (each knowing the other willing to establish connection) ▪ agree on connection parameters (e.g., starting seq #s) application application connection state: ESTAB connection state: ESTAB connection variables: connection Variables: seq # client-to-server seq # client-to-server server-to-client server-to-client rcvBuffer size rcvBuffer size at server,client at server,client network network Socket clientSocket = Socket connectionSocket = newSocket("hostname","port number"); welcomeSocket.accept(); Transport Layer: 3-66 Agreeing to establish a connection 2-way handshake: Q: will 2-way handshake always Let’s talk work in network? ESTAB ESTAB OK ▪ variable delays ▪ retransmitted messages (e.g. req_conn(x)) due to message loss ▪ message reordering choose x req_conn(x) ▪ can’t “see” other side ESTAB acc_conn(x) ESTAB Transport Layer: 3-67 2-way handshake scenarios choose x req_conn(x) ESTAB acc_conn(x) ESTAB data(x+1) accept data(x+1) ACK(x+1) connection x completes No problem! Transport Layer: 3-68 2-way handshake scenarios choose x req_conn(x) ESTAB retransmit acc_conn(x) req_conn(x) ESTAB req_conn(x) connection client x completes server terminates forgets x ESTAB acc_conn(x) Problem: half open connection! (no client) Transport Layer: 3-69 2-way handshake scenarios choose x req_conn(x) ESTAB retransmit acc_conn(x) req_conn(x) ESTAB data(x+1) accept data(x+1) retransmit data(x+1) connection x completes server client terminates forgets x req_conn(x) ESTAB data(x+1) accept data(x+1) Problem: dup data accepted! TCP 3-way handshake Server state serverSocket = socket(AF_INET,SOCK_STREAM) Client state serverSocket.bind((‘’,serverPort)) serverSocket.listen(1) clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept() LISTEN clientSocket.connect((serverName,serverPort)) LISTEN choose init seq num, x send TCP SYN msg SYNSENT SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK msg, acking SYN SYN RCVD SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 received SYNACK(x) ESTAB indicates server is live; send ACK for SYNACK; this segment may contain ACKbit=1, ACKnum=y+1 client-to-server data received ACK(y) indicates client is live ESTAB Transport Layer: 3-71 A human 3-way handshake protocol 1. On belay? 2. Belay on. 3. Climbing. Transport Layer: 3-72 Closing a TCP connection ▪ 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 Transport Layer: 3-73 *TCP: closing a connection client state server state ESTAB ESTAB clientSocket.close() FIN_WAIT_1 can no longer FINbit=1, seq=x send but can receive data CLOSE_WAIT ACKbit=1; ACKnum=x+1 can still FIN_WAIT_2 wait for server send data close LAST_ACK FINbit=1, seq=y TIMED_WAIT can no longer send data ACKbit=1; ACKnum=y+1 timed wait for 2*max CLOSED segment lifetime CLOSED Transport Layer 3-74 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-75 *Principles of congestion control Congestion: ▪ informally: “too many sources sending too much data too fast for network to handle” ▪ different from flow control! ▪ Manifestations (indicators : long delays (queueing in router buffers) packet loss (buffer overflow at routers) ▪ a top-10 problem! congestion control: ▪ Q: How to solve it? too many senders, sending too fast ▪ A: Using TCP Congestion Control ▪ controlling sender, so it won’t over-load the network by transmitting too much, too fast flow control: one sender ▪ Next slide too fast for one receiver Transport Layer: 3-76 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-77 *TCP congestion control: AIMD (Additive Increase Multiplicative Decrease) ▪ approach: senders can increase sending rate until packet loss (congestion) occurs, then decrease sending rate on loss event ▪ How is it implemented? ▪ additive increase: sender increases transmission rate (congestion window size) cwnd by 1 MSS every RTT until loss detected. ▪ MSS: Maximum Segment Size. RTT: Round Trip Time ▪ multiplicative decrease: cut cwnd in half after loss ▪ AIMD Behavior is called SAW Tooth Behavior ▪ ➔ cwnd is dynamic, function of perceived network congestion additively increase window size … congestion window size …. until loss occurs (then cut window in half) cwnd: TCP sender AIMD saw tooth behavior: probing for bandwidth time Transport Layer 3-78 TCP congestion control: AIMD ▪ approach: senders can increase sending rate until packet loss (congestion) occurs, then decrease sending rate on loss event Additive Increase Multiplicative Decrease increase sending rate by 1 cut sending rate in half at maximum segment size every each loss event RTT until loss detected TCP sender Sending rate AIMD sawtooth behavior: probing for bandwidth time Transport Layer: 3-79 TCP congestion control: details sender sequence number space cwnd TCP sending behavior: ▪ roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes last byte available but ~ cwnd ACKed sent, but not- TCP rate ~ bytes/sec yet ACKed not used RTT (“in-flight”) last byte sent ▪ TCP sender limits transmission: LastByteSent- LastByteAcked < cwnd ▪ cwnd is dynamically adjusted in response to observed network congestion (implementing TCP congestion control) Transport Layer: 3-80 TCP slow start Host A Host B ▪ when connection begins, increase rate exponentially until first loss event: RTT initially cwnd = 1 MSS double cwnd every RTT done by incrementing cwnd for every ACK received ▪ summary: initial rate is slow, but ramps up exponentially fast time Transport Layer: 3-81 TCP: from slow start to congestion avoidance Q: when should the exponential increase switch to linear? X A: when cwnd gets to 1/2 of its value before timeout. Implementation: ▪ variable ssthresh ▪ on loss event, ssthresh is set to 1/2 of cwnd just before loss event * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer: 3-82 *TCP congestion control: AIMD (Additive Increase Multiplicative Decrease) ▪ approach: senders can increase sending rate until packet loss (congestion) occurs, then decrease sending rate on loss event ▪ How is it implemented? ▪ additive increase: sender increases transmission rate (congestion window size) cwnd by 1 MSS every RTT until loss detected. ▪ MSS: Maximum Segment Size. RTT: Round Trip Time ▪ multiplicative decrease: cut cwnd in half after loss ▪ AIMD Behavior is called SAW Tooth Behavior ▪ ➔ cwnd is dynamic, function of perceived network congestion additively increase window size … congestion window size …. until loss occurs (then cut window in half) cwnd: TCP sender AIMD saw tooth behavior: probing for bandwidth time Transport Layer 3-83 Chapter 3: summary ▪ principles behind transport Up next: layer services: ▪ leaving the network multiplexing, demultiplexing “edge” (application, reliable data transfer transport layers) flow control ▪ into the network “core” congestion control ▪ two network-layer ▪ instantiation, implementation chapters: in the Internet data plane UDP control plane TCP Transport Layer: 3-85

Document Details

Tags

Related

Full Transcript

Upgrade to continue