ilab Lab 4 TCP/UDP Purpose of the Transport Layer Provides an end - PowerPoint PPT Presentation

Lehrstuhl für Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München ilab Lab 4 TCP/UDP

Purpose of the Transport Layer  Provides an end to end connectivity to applications application application 4 TCP TCP 3 IP IP IP IP 1 / 2 Network 1 Network 1Network 2 Network 2Network 3 Network 3  Tasks  Addressing of applications on end hosts  Reliable data transfer  Packets might • get lost on their way • arrive out of order • contain errors  Protection of the receiver and the network ilab: TCP/UDP 2

Addressing of application Client Server Webserver Mailserver Browser Port 80 Port 25  The internet model uses port numbers to address services  „Well-known“ Ports:  e.g. a webserver is usually reachable at port 80  Sometimes port numbers are dynamically exchanged on connection establishment (e.g. Voice over IP)  Otherwise the user needs to specify the port in order to communicate with a service ilab: TCP/UDP 3

Addressing of applications II Client Client Server Webserver Browser Browser Browser Browser Port 80  Port numbers are NOT globally unique  Several clients can connect to the same server using the same port  Thus, more information is needed in order to uniquely identify a connection  IP 5 tuple:  Source port, source IP address, destination port, dest. IP address, layer 4 protocoll (tcp or udp)  The endpoints of such a connection are called sockets ilab: TCP/UDP 4

The transport layer in the internet  Mainly two protocols of the transport layer are used in the internet:  TCP (Transmission Control Protocol): reliable, connection oriented transport protocol on top of the unreliable IP  UDP (User Datagram Protocol): unreliable, connectionless transport protocol. Provides an application interface for IP Application Application protocol protocol TCP UDP TCP UDP Internet IP IP Layer 2 Layer 2 protocol protocol host A host B ilab: TCP/UDP 5

UDP (User Datagram Protocol)  unreliable, connectionless, simpler and faster than TCP  Demultiplexing based on port numbers  Optional checksum (mandatory for UDP over IPv6) 0 16 31 Source Port Destination Port Packet- header Message Length Checksum Data ...  some „well-known“ ports:  13: daytime  53: domain name server  123: network time protocol  Many multimedia applications use UDP instead of TCP ilab: TCP/UDP 6

TCP: properties and services  TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer.  TCP adapts dynamically to the environment (e.g. network topology, changing bandwidth)  Data transfer:  Connection oriented  Full duplex  Error correction through sequence numbers, checksum, acknowledgements and retransmissions  Flow control and congestion control (-> adaption to network load, stability of the network and fairness)  Multiplexing based on port numbers ilab: TCP/UDP 7

TCP: well-known ports  Many applications are based on TCP and need to choose a port number  Well known ports reserved for the most important services  13: time > telnet walapai 13 Trying 129.13.3.121...  20: FTP data Connected to leonis. Escape character is '^]'. Mon Aug 4 16:57:19 2002  25: SMTP Connection closed by foreign host (Simple Mail Transfer Protocol) > telnet mailhost 25  53: DNS Trying 129.13.3.161... Connected to mailhost . (Domain Name Server) Escape character is '^]'. 220 mailhost ESMTP Sendmail 8.8.5/8.8.5; Mon, 4 Aug 2002 17:02:51 +0200  80: HTTP HELP 214-This is Sendmail version 8.8.5 (Hyper Text Transfer Protocol) 214-Topics: 214- HELO EHLO MAIL RCPT DATA  119: NNTP 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN (Network News Transfer Protocol) 214-For more info use "HELP <topic>". ... 214 End of HELP info ilab: TCP/UDP 8

TCP Header 31 0 16 Source Port Destination Port Sequence Number Piggyback Acknowledgement Packet 4 bit TCP U A E R S F Header 6 bit Window R C O S Y I header unused G K M T N N length Checksum Urgent Pointer Options (0 oder mehr 32-bit-Worte) Daten ... alternatively: PSH (Push-Bit) ilab: TCP/UDP 9

Lifetime of a TCP connection Client Server  connection establishment [SYN, seq=17]  3 way handshake  Negotiation of window size and [SYN, seq=39, ACK=18] Connection sequence numbers establishment [seq=18, ACK=40]  data transfer  [seq=53, ACK=78, data=‚hi‘] Piggyback confirmation Data [seq=78, ACK=55, data=‚ho‘] transfer  connection termination  confirmed [FIN]  Ressources on client are deallocated after the time-wait [ACK] period (e.g. after 30s or 1min) Connection [FIN] termination [ACK] Time wait ilab: TCP/UDP 10

TCP: Mechanisms (I)  Unit for the data transfer: Segment (TCP header + payload)  Max. size: 65536 byte (IP payload)  In practice: 1500 byte (ethernet MTU) to avoid IP fragmentation  TCP provides stream of bytes to application, fragmentation and segments are hidden from user  Checksum  Protection of TCP header, payload and some fields of the IP header (mainly source and destination address)  Algorithm used: one‘s complement sum ilab: TCP/UDP 11

TCP: Mechanisms (II)  Detection of missing segments (at sender)  Retransmission timer: a timer is set when sending the segment  If the segment is not acknowledged before the timer has expired the segment is retransmitted  Timer is dynamically adapted to round trip time  Alternative detection of missing segments: Fast Retransmit -> later  Retransmission similar to Go-Back-N  Retransmission begins with the missing packet  Packets that arrive out of order are buffered at the receiver (different than Go-Back-N) ilab: TCP/UDP 12

TCP: Mechanisms (III)  Acknowledgements (ACKs)  ACK number n acknowledges the reception of all bytes until seq. Number n-1 (cumulative acknowledgement)  On gaps (e.g. due to out of order transmission) the receiver always sends an acknowledgement containing the number of the next expected byte which leads to duplicate ACKs (see next slide)  Faulty packets are discarded and not acknowledged  Piggybacking  No separate ACK  ACKs are included in payload ilab: TCP/UDP 13

Cumulative acknowledgements 1. Segment arrives and is acknowledged: 1 send ACK 2. Segment arrived out of order, 1st byte after the first segment is still missing 1 3 send „duplicate“ ACK 3. Segment arrives and fills the gap. Receiver acknowledges 3rd segment 1 2 3 send ACK ilab: TCP/UDP 14

Sliding Window  The receive window specifies the amount of data that the receiver is willing to buffer for the connection  Performance advantage compared to stop and wait Sequence numbers ACK for received packet Px,i is ACK, (i+1) P1,0 0 1 2 3 4 5 … P2,1 Sending window ACK,1 P3,2 ACK,2 0 1 2 3 4 5 … P4,3 ACK,3 0 1 2 3 4 5 … CAREFUL: 0 1 2 3 4 5 … Unit for Sequence- Slide window on received numbers is bytes! acknowledges ilab: TCP/UDP 15

Window size  The sending window is the minimum of  The receiver window for the flow control (protection agains too many packets)  The congestion window (CWND, control the rate of data entering the network)  Flowcontrol in TCP  Credit based  The receiver informs the sender using the „window field“ in the TCP header about the amount of data it is willing to buffer  Scalability of the window field  Default window size is 16 bit (max. 65536 bytes of unacknowledged data)  Not enough for high performance networks (window option with 32bit allows a max. of 4Gb of unack. data) • limit because of 32bit sequence numbers ilab: TCP/UDP 16

Sliding Window / Flow Control Sender Receiver TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteSent NextByteExpected LastByteRcvd Sender Receiver  LastByteAcked < =  LastByteRead < LastByteSent NextByteExpected  LastByteSent < =  NextByteExpected < = LastByteWritten LastByteRcvd +1  Buffers all data  Buffers all data LastByteRead and LastByteAcked and LastByteRcvd LastByteWritten ilab: TCP/UDP 17

Congestion Control  Goals and problems hereby  Reasonable behavior in case of network (over)load  Without controlling the outgoing amount of data, the capacity may drop to zero because of deadlocks  Fair ressource sharing  Criteria: effective, simple, robust, end-host driven max. ideal Flow and congestion control capacity Without control deadlock Load of the system ilab: TCP/UDP 18

Congestion control (Van Jacobson)  Problem: the end host does not know a lot about the network. It only knows if a packet has been delivered successfully or not  Self clocking: for every segment that leaves the network we can send a new one  Assumption: packet loss only because of congestion  Not true for wireless networks Figure: Van Jacobson. Congestion aviodance and control . In ACM SIGCOMM, pages 314 -- 329, August 1988 ilab: TCP/UDP 19