760 likes | 776 Views
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
E N D
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 (5.1, 5.2) Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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! Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
“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] Transport Layer & TCP
often used for streaming multimedia apps loss tolerant rate sensitive other UDP users 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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 • … Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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) Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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) Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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? Transport Layer & TCP
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 Transport Layer & TCP
Detecting Half-Open Connections TCP A TCP B • (CRASH) • CLOSED • SYN-SENT <SEQ=400><CTL=SYN> • (!!) <SEQ=300><ACK=100><CTL=ACK> • SYN-SENT <SEQ=100><CTL=RST> • SYN-SENT • SYN-SENT <SEQ=400><CTL=SYN> • (send 300, receive 100) • ESTABLISHED • (??) • ESTABLISHED (Abort!!) CLOSED Transport Layer & TCP
Client Server TCP State Diagram: Connection Setup CLOSED active OPEN create TCP Snd SYN passive OPEN CLOSE create TCP delete TCP CLOSE LISTEN delete TCP 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 Transport Layer & TCP
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. Transport Layer & TCP
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? Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 TCP Transport Layer & TCP
TCP Connection Management FSM TCP client lifecycle TCP client lifecycle Transport Layer & TCP
TCP Connection Management FSM TCP server lifecycle TCP server lifecycle Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
Problems with Stop and Wait • How to recognize a duplicate • Performance • Can only send one packet per round trip Transport Layer & TCP
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 Transport Layer & TCP
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! Transport Layer & TCP
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! Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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! Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
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 Transport Layer & TCP
Loss Recovery • Go-Back-N recovery • Set timer upon transmission of each packet • Cumulative ACK • Retransmit all unacknowledged packets • No receiver buffering, out-of-order packets are discarded • Selective Repeat • Sender keeps a timer for each packet • Selective ACK • Receiver must buffer all out-of-order packets • When timeout, retransmit only one packet • Performance during loss recovery • No longer have an entire window in transit • Can have much more clever loss recovery Transport Layer & TCP
Go-Back-N in Action Transport Layer & TCP