1 / 81

Transport Layer

Transport Layer . Transport Layer Services connection-oriented vs. connectionless multiplexing and demultplexing UDP: Connectionless Unreliable Service TCP: Connection-Oriented Reliable Service connection management: set-up and tear down reliable data transfer protocols

jeanine
Download Presentation

Transport Layer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Transport Layer • Transport Layer Services • connection-oriented vs. connectionless • multiplexing and demultplexing • UDP: Connectionless Unreliable Service • TCP: Connection-Oriented Reliable Service • connection management: set-up and tear down • reliable data transfer protocols • flow and congestion control Readings: Chapter 5 CSci232: Transport Layer & TCP

  2. Transport Protocols • Lowest level end-to-end protocol. • Header generated by sender is interpreted only by the destination • Routers view transport header as part of the payload 7 7 6 6 5 5 Transport Transport IP IP IP Datalink 2 2 Datalink Physical 1 1 Physical router CSci232: Transport Layer & TCP

  3. 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 Internet: TCP and UDP application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Transport Services and Protocols CSci232: Transport Layer & TCP

  4. Transport Layer Services • Underlying best-effort network • drops messages • re-orders messages • delivers duplicate copies of a given message • delivers messages after an arbitrarily long delay • Common end-to-end services • guarantee message delivery • deliver messages in the same order they are sent • deliver at most one copy of each message • allow the receiver to flow control the sender • support multiple application processes on each host CSci232: Transport Layer & TCP

  5. application layer: application processes and message exchange network layer: logical communication between hosts transport layer: logical communication support for app processes relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service Transport vs. Application and Network Layer CSci232: Transport Layer & TCP

  6. End to End Issues • Transport services built on top of (potentially) unreliable network service • packets can be corrupted or lost • Packets can be delayed or arrive “out of order” • Do we detect and/or recover errors for apps? • Error Control & Reliable Data Transfer • Do we provide “in-order” delivery of packets? • Connection Management & Reliable Data Transfer • Potentially different capacity at destination, and potentially different network capacity • Flow and Congestion Control CSci232: Transport Layer & TCP

  7. TCP service: connection-oriented: setup required between client, server reliable transport between sender and receiver flow control: sender won’t overwhelm receiver congestion control: throttle sender when network overloaded UDP service: unreliable data transfer between sender and receiver does not provide: connection setup, reliability, flow control, congestion control Internet Transport Protocols Both provide logical communication between app processes running on different hosts! CSci232: Transport Layer & TCP

  8. application application application transport transport transport P4 P2 P3 P1 P1 network network network link link link physical physical physical Multiplexing at send host: Demultiplexing at rcv host: host 3 host 2 host 1 Multiplexing/Demultiplexing delivering received segments to correct application process gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) = API (“socket”) = process CSci232: Transport Layer & TCP

  9. host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source, destination port number (recall: well-known port numbers for specific applications) host uses IP addresses & port numbers to direct segment to appropriate app process (identified by “socket’) How Demultiplexing Works 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format CSci232: Transport Layer & TCP

  10. “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 Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired UDP: User Datagram Protocol [RFC 768] CSci232: Transport Layer & TCP

  11. often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! UDP (cont’d) 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format CSci232: Transport Layer & TCP

  12. Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value (1’s complement of 1’s complement sum of 16-bit words) into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later …. UDP Checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment CSci232: Transport Layer & TCP

  13. 0110011001100110 1101010101010101 0000111100001111 arrange data segment in sequences of 16-bit words + sum: 0100101011001011 checksum(1’s complement): 1011010100110100 verify by adding: 1111111111111111 Checksum: Example CSci232: Transport Layer & TCP

  14. Application process Application process W rite Read bytes bytes … … TCP TCP Receive buffer Send buffer … Segment Segment Segment T ransmit segments TCP Overview • Full duplex • Flow control: keep sender from overrunning receiver • Congestion control: keep sender from overrunning network • Connection-oriented • Byte-stream • app writes bytes • TCP sends segments • app reads bytes CSci232: Transport Layer & TCP

  15. Functionality Split • Network provides best-effort delivery • End-systems implement many functions • Reliability • In-order delivery • Demultiplexing • Message boundaries • Connection abstraction • Flow Control • Congestion control • … CSci232: Transport Layer & TCP

  16. High-Level TCP Characteristics • Protocol implemented entirely at the ends • Fate sharing • Protocol has evolved over time and will continue to do so • Nearly impossible to change the header • Use options to add information to the header • Change processing at endpoints • Backward compatibility is what makes it TCP CSci232: Transport Layer & TCP

  17. Evolution of TCP 1984 Nagel’s algorithm to reduce overhead of small packets; predicts congestion collapse 1975 Three-way handshake Raymond Tomlinson In SIGCOMM 75 1987 Karn’s algorithm to better estimate round-trip time 1990 4.3BSD Reno fast retransmit delayed ACK’s 1983 BSD Unix 4.2 supports TCP/IP 1988 Van Jacobson’s algorithms congestion avoidance and congestion control (most implemented in 4.3BSD Tahoe) 1986 Congestion collapse observed 1974 TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1982 TCP & IP RFC 793 & 791 1990 1975 1980 1985 CSci232: Transport Layer & TCP

  18. TCP Through the 1990s 1994 T/TCP (Braden) Transaction TCP 1996 SACK TCP (Floyd et al) Selective Acknowledgement 1996 FACK TCP (Mathis et al) extension to SACK 1996 Hoe Improving TCP startup 1993 TCP Vegas (Brakmo et al) real congestion avoidance 1994 ECN (Floyd) Explicit Congestion Notification 1994 1993 1996 CSci232: Transport Layer & TCP

  19. 32 bits source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent data Options (variable length) application data (variable length) TCP Segment Header Structure counting by bytes of data (not segments!) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) CSci232: Transport Layer & TCP

  20. Data (SequenceNum) Sender Receiver Acknowledgment + AdvertisedWindow TCP Segment Format (cont) • Each connection identified with 4-tuple: • (SrcPort, SrcIPAddr, DstPort, DstIPAddr) • Sliding window + flow control • acknowledgment, SequenceNum, AdvertisedWinow • Flags • SYN, FIN, ACK, RESET, PUSH, URG • Checksum • pseudo header (src & dst IP addresses) + TCP header + data CSci232: Transport Layer & TCP

  21. TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. # buffers, flow control info client: end host that initiates connection server: end host contacted by client Three way handshake: Step 1:client sends TCP SYN control segment to server specifies initial seq # Step 2:server receives SYN, replies with SYN+ACK control segment ACKs received SYN specifies server  receiver initial seq. # Step 3:client receives SYN+ACK, replies with ACK segment (which may contain 1st data segment) TCP Connection Set Up CSci232: Transport Layer & TCP

  22. Question: a. What kind of “state” client and server need to maintain? b. What initial sequence # should client (and server) use? TCP 3-Way Hand-Shake client server initiate connection SYN, seq=x SYN received SYN+ACK, seq=y, ack=x+1 connection established ACK, seq=x+1, ack=y+1 connection established (1st data segment) CSci232: Transport Layer & TCP

  23. TCP Connection Setup Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] 1 13.734375 70.13.155.114 128.101.35.150 TCP 1414 > 22 [SYN] Seq=758244755 Len=0 MSS=1260 2 13.968750 128.101.35.150 70.13.155.114 TCP 22 > 1414 [SYN, ACK] Seq=3778406755Ack=758244756 Win=25200 Len=0 MSS=1460 3 13.968750 70.13.155.114 128.101.35.150 TCP 1414 > 22 [ACK] Seq=758244756 Ack=3778406756 Win=16384 Len=0 CSci232: Transport Layer & TCP

  24. TCP Connection Setup Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] 1 13.6611233 70.13.155.114 128.101.35.204 TCP 1567 > 80 [SYN] Seq=3724852786 Len=0 MSS=1260 2 13.890625 128.101.35.204 70.13.155.114 TCP 80> 1567 [SYN, ACK] Seq=484733971 Ack=3724852787 Win=25200 Len=0 MSS=1460 3 13.890625 70.13.155.114 128.101.35.204 TCP 1567 > 80 [ACK] Seq=3724852787 Ack=484733972 Win=17640 Len=0 4 13.890625 70.13.155.114 128.101.35.204 TCP 1567 > 80 [PSH,ACK] Seq=73724852787 Ack=484733972 Win=17640 Len=564 5 14.630860 128.101.35.204 70.13.155.114 TCP 80> 1567 [ACK] Seq=484733972 Ack=3724853351 Win=25200 Len=0 MSS=1460 CSci232: Transport Layer & TCP

  25. ? ? ? ? ? ? ? ? 3-Way Handshake: Finite State Machine Client FSM? Server FSM? Upper layer: initiate connection sent SYN w/ initial seq =x SYN sent closed SYN+ACK received sent ACK conn estab’ed info (“state”) maintained at client? CSci232: Transport Layer & TCP

  26. Connection Setup Error Scenarios • Lost (control) packets • What happen if SYN lost? client vs. server actions • What happen if SYN+ACK lost? client vs. server actions • What happen if ACK lost? client vs. server actions • Duplicate (control) packets • What does server do if duplicate SYN received? • What does client do if duplicate SYN+ACK received? • What does server do if duplicate ACK received? CSci232: Transport Layer & TCP

  27. Connection Setup Error Scenarios (cont’d) • Importance of (unique) initial seq. no.? • When receiving SYN, how does server know it’s a new connection request? • When receiving SYN+ACK, how does client know it’s a legitimate, i.e., a response to its SYN request? • Dealing with old duplicate packets from old connections (or from malicious users) • If not careful: “TCP Hijacking” • How to choose unique initial seq. no.? • randomly choose a number (and add to last syn# used) • Other security concern: • “SYN Flood” -- denial-of-service attack CSci232: Transport Layer & TCP

  28. Client Server TCP State Diagram: Connection Setup CLOSED active OPEN create TCB Snd SYN passive OPEN CLOSE create TCB delete TCB CLOSE LISTEN delete TCB SEND rcv SYN SYN RCVD SYN SENT snd SYN ACK snd SYN rcv SYN snd ACK Rcv SYN, ACK rcv ACK of SYN Snd ACK CLOSE ESTAB Send FIN CSci232: Transport Layer & TCP

  29. Client wants to close connection: Step 1:client end system sends TCP FIN control segment to server client closing FIN half closed ACK server closing FIN TCP: Closing Connection Remember TCP duplex connection! client server Step 2:server receives FIN, replies with ACK. half closed Step 3:client receives ACK. half closed, wait for server to close half closed Server finishes sending data, also ready to close: Step 4:server sends FIN. CSci232: Transport Layer & TCP

  30. Step 5:client receives FIN, replies with ACK. connection fully closed full closed ACK TCP: Closing Connection (cont’d) client server client closing FIN half closed Step 6:server, receives ACK. connection fully closed ACK half closed server closing FIN Well Done! full closed Problem Solved? CSci232: Transport Layer & TCP

  31. Step 5:client receives FIN, replies with ACK. Enters “timed wait” - will respond with ACK to received FINs client server client closing FIN half closed ACK half closed server closing FIN ACK X FIN timeout timed wait ACK full closed TCP: Closing Connection (revised) Two Army Problem! Step 6:server, receives ACK. connection fully closed Step 7:client, timer expires, connection fully closed full closed CSci232: Transport Layer & TCP

  32. TCP Connection Tear-Down Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] 80 35.156250 70.13.155.114 128.101.35.150 TCP 1414 > 22 [PSH,ACK] Seq=758246388Ack=3778411633 Win=15920 Len=32 81 35.156250 70.13.155.114 128.101.35.150 TCP 1414 > 22 [FIN, ACK] Seq=758246420Ack=3778411633 Win=15920 Len=0 82 35.437500 128.101.35.150 70.13.155.114 TCP 22 > 1414 [ACK] Seq=3778411633Ack=758246420 Win=25200 Len=0 13.968750 83 35.453125 128.101.35.150 70.13.155.114 TCP 22 > 1414 [ACK] Seq=3778411633Ack=758246421 Win=25200 Len=0 13.968750 84 35.453125 128.101.35.150 70.13.155.114 TCP 22 > 1414 [FIN,ACK] Seq=3778411633Ack=758246421 Win=25200 Len=0 13.968750 85 35.453125 70.13.155.114 128.101.35.150 TCP 1414 > 22 [ACK] Seq=758246421Ack=3778411634 Win=15920 Len=0 CSci232: Transport Layer & TCP

  33. Active Close Passive Close State Diagram: Connection Tear-down CLOSE ESTAB send FIN CLOSE rcv FIN send FIN send ACK FIN WAIT-1 CLOSE WAIT rcv FIN CLOSE snd ACK ACK snd FIN rcv FIN+ACK FIN WAIT-2 CLOSING LAST-ACK snd ACK rcv ACK of FIN rcv ACK of FIN TIME WAIT CLOSED rcv FIN Timeout=2min snd ACK delete TCB CSci232: Transport Layer & TCP

  34. TCP Connection Management FSM TCP client lifecycle TCP client lifecycle CSci232: Transport Layer & TCP

  35. TCP Connection Management FSM TCP server lifecycle TCP server lifecycle CSci232: Transport Layer & TCP

  36. Reliability and Error Recovery • ARQ vs. FEC • automatic retransmission request • forward error correction • General ARQ Algorithms • Stop & Wait • Perform issue: low utilization when delay-bw product large • Sliding Window Protocols • Go-Back-N • Selective Repeat • Key design issues: window size vs. size of seq. no. space CSci232: Transport Layer & TCP

  37. Packet ACK Error Recovery: Stop and Wait • ARQ • Receiver sends acknowledgement (ACK) when it receives packet • Sender waits for ACK and timeouts if it does not arrive within some time period • Simplest ARQ protocol • Send a packet, stop and wait until ACK arrives Sender Receiver Timeout Time CSci232: Transport Layer & TCP

  38. Packet Packet Packet Packet Packet ACK ACK ACK ACK ACK Recovering from Error Timeout Timeout Timeout Time Packet Timeout Timeout Timeout Early timeout DUPLICATEPACKETS!!! ACK lost Packet lost CSci232: Transport Layer & TCP

  39. Problems with Stop and Wait • How to recognize a duplicate • Performance • Can only send one packet per round trip CSci232: Transport Layer & TCP

  40. Use sequence numbers both packets and acks Sequence # in packet is finite  How big should it be? For stop and wait? One bit – won’t send seq #1 until received ACK for seq #0 Pkt 0 ACK 0 ACK 0 ACK 1 How to Recognize Resends? Pkt 0 Pkt 1 CSci232: Transport Layer & TCP

  41. Sender Receiver first packet bit transmitted, t = 0 data (L bytes) first packet bit arrives RTT ACK ACK arrives, send next packet, t = RTT + L / R Problem with Stop & Wait Protocol • Can’t keep the pipe full • Utilization is low when bandwidth-delay product (R x RTT)is large! CSci232: Transport Layer & TCP

  42. Example: 1 Gbps connection, 15 ms end-end prop. delay, data segment size: 1 KB = 8Kb Stop & Wait: Performance Analysis • U sender: utilization, i.e., fraction of time sender busy sending • 1KB data segment every 30 msec (round trip time) --> 0.027% x 1 Gbps = 33kB/sec throughput over 1 Gbps link • Moral of story: • network protocol limits use of physical resources! CSci232: Transport Layer & TCP

  43. How to Keep the Pipe Full? • Send multiple packets without waiting for first to be acked • Number of pkts in flight = window • Reliable, unordered delivery • Several parallel stop & waits • Send new packet after each ack • Sender keeps list of unack’ed packets; resends after timeout • Receiver same as stop & wait • How large a window is needed? • Suppose 10Mbps link, 4ms delay, 500byte pkts • 1? 10? 20? • Round trip delay * bandwidth = capacity of pipe CSci232: Transport Layer & TCP

  44. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged data segments range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: Go-Back-N and Selective Repeat Pipelined (Sliding Window) Protocols CSci232: Transport Layer & TCP

  45. Pipelining: Increased Utilization sender receiver first packet bit transmitted, t= 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3! CSci232: Transport Layer & TCP

  46. Sliding Window • Reliable, ordered delivery • Receiver has to hold onto a packet until all prior packets have arrived • Why might this be difficult for just parallel stop & wait? • Sender must prevent buffer overflow at receiver • Circular buffer at sender and receiver • Packets in transit  buffer size • Advance when sender and receiver agree packets at beginning have been received CSci232: Transport Layer & TCP

  47. Sender/Receiver State Sender Receiver Next expected Max acceptable Max ACK received Next seqnum … … … … Sender window Receiver window Sent & Acked Sent Not Acked Received & Acked Acceptable Packet OK to Send Not Usable Not Usable CSci232: Transport Layer & TCP

  48. Window Sliding – Common Case • On reception of new ACK (i.e. ACK for something that was not acked earlier) • Increase sequence of max ACK received • Send next packet • On reception of new in-order data packet (next expected) • Hand packet to application • Send cumulative ACK – acknowledges reception of all packets up to sequence number • Increase sequence of max acceptable packet CSci232: Transport Layer & TCP

  49. Loss Recovery • On reception of out-of-order packet • Send nothing (wait for source to timeout) • Cumulative ACK (helps source identify loss) • Timeout (Go-Back-N recovery) • Set timer upon transmission of packet • Retransmit all unacknowledged packets • Performance during loss recovery • No longer have an entire window in transit • Can have much more clever loss recovery CSci232: Transport Layer & TCP

  50. Go-Back-N in Action CSci232: Transport Layer & TCP

More Related