Presentation on theme: "TANENBAUMComputer Networks II1 Chapter 6-2 The Transport Layer TCP, UDP and Performance Issues."— Presentation transcript:
TANENBAUMComputer Networks II1 Chapter 6-2 The Transport Layer TCP, UDP and Performance Issues
TANENBAUMComputer Networks II2 The Internet Transport Protocols: UDP Introduction to UDP Remote Procedure Call The Real-Time Transport Protocol
TANENBAUMComputer Networks II3 UDP (User Data Protocol) Provides a way to send IP datagrams without establishing a connection A UDP segment has 8-byte header followed by data UDP length includes header and data UDP checksum includes the same format pseudoheader as in TCP
TANENBAUMComputer Networks II4 Remote Procedure Call Allows programs to call procedures located on remote hosts Looks as much possible as local call Two library procedures called client stub and server stub hide the fact that call is remote –The client program makes a local call to client stub to handle the RPC Information is transported in parameters –For this purpose, client stub packs parameters into a message (parameter marshalling)
TANENBAUMComputer Networks II5 Remote Procedure Call Steps in making a remote procedure call. The stubs are shaded.
TANENBAUMComputer Networks II6 Problems with RPC Passing pointers is impossible Array size must be specified and fixed It may not be possible to deduce the types of the parameters Global variables can not be used RPC commonly uses UDP
TANENBAUMComputer Networks II7 Real Time Transport Protocol (RTP) Used to transport multimedia streams Can multiplex different streams such as the audio and video into a single UDP socket Each packet is given a unique increasing number No flow control, no error control, no acks,no retransmission mechanism Contains a payload type field to specify encoding that allows changing quality of the multimedia data when available bandwidth drops Contains timestamps that are used to synchronize streams. However, these timestamps are used to compute the relative time from the start rather than absolute time Has a sister protocol, Real Time Control Protocol (RTCP) that carries delay, jitter, bandwidth and congestion information for feedback purposes
TANENBAUMComputer Networks II8 The Real-Time Transport Protocol (a) The position of RTP in the protocol stack. (b) Packet nesting.
TANENBAUMComputer Networks II9 The Real-Time Transport Protocol (2) The RTP header.
TANENBAUMComputer Networks II10 The Internet Transport Protocols: TCP Introduction to TCP The TCP Service Model The TCP Protocol The TCP Segment Header TCP Connection Establishment TCP Connection Release TCP Connection Management Modeling TCP Transmission Policy TCP Congestion Control TCP Timer Management Wireless TCP and UDP Transactional TCP
TANENBAUMComputer Networks II11 TCP Basic Functionality Provides reliable end-to-end byte stream over an unreliable internetwork Transport entity –A piece of software that is either A user process or Part of kernel –Accepts user data streams from local processes –Breaks them into pieces not exceeding 64K bytes –Send each piece as an IP datagram –At the receiver, it reconstructs original byte streams
TANENBAUMComputer Networks II12 The TCP Service Model The sender and receiver create end points called sockets Each socket has –IP address –Port number (16 bit and local) A socket may be used for multiple connections at the same time Some port numbers are reserved –FTP: 21 –Telnet: 23
TANENBAUMComputer Networks II13 The TCP Service Model Some assigned ports. PortProtocol Use 21 FTP File transfer 23 Telnet Remote login 25 SMTP E-mail 69 TFTP Trivial File Transfer Protocol 79 FingerLookup info about a user 80 HTTP World Wide Web 110 POP-3 Remote e-mail access 119 NNTP USENET news
TANENBAUMComputer Networks II14 The TCP Service Model (2) (a) Four 512-byte segments sent as separate IP datagrams. (b) The 2048 bytes of data delivered to the application in a single READ CALL. A TCP connection is a byte stream, not a message stream Message boundaries are not preserved end to end
TANENBAUMComputer Networks II15 The TCP Service Model (cont’d) When an application passes data to TCP, TCP may send it immediately or buffer it at its discretion To force data out, applications can use PUSH flag, which tells TCP not to delay transmission At the receiver side, the same effect can be obtained by using URGENT flag However, at the receiver side, on the contrary of PUSH flag, URGENT flag causes an interrupt to the application (provides signaling)
TANENBAUMComputer Networks II16 The TCP Protocol Every byte on a TCP connection has its own 32- bit sequence number to be used for acks and sliding window sequencing Window mechanism has its own 32-bit header Data is exchanged in form of segments –A segment consists of a 20-byte header and zero or more bytes –A segment must fit into a IP payload (65635 bytes) or Maximum Transfer Unit, MTU of the underlying network (further segmentation is a major problem) –Sliding window acks next expected sequence number
TANENBAUMComputer Networks II17 The TCP Segment Header TCP Header.
TANENBAUMComputer Networks II18 The TCP Segment Header (2) The pseudoheader included in the TCP checksum.
TANENBAUMComputer Networks II19 The TCP Segment Header (cont’d) Every segment begins with a fixed format 20-byte header Segments without any data are legal –Ack messages or other control messages Ack: Next byte expected Options –Specifies beginning of data Urgent pointer specifies offset of urgent data when URG flag is set ACK bit indicates that the ack field is valid
TANENBAUMComputer Networks II20 The TCP Segment Header (cont’d) PSH flag indicates pushed data RST flag indicates problem with connection SYN flag indicates connection request or connection accepted together with ACK flag FIN flag is used to release a connection Window Size field indicates how many bytes can be accepted starting at the byte acknowledged. Checksum is a control field on header, data and pseudo header that indicates portions of IP header
TANENBAUMComputer Networks II21 The TCP segment Header (cont’d) Options –A host may specify the maximum TCP payload it is willing to accept If not specified, the default is 536 bytes –Window scale option In general 16 bit window size is not sufficient for current systems This option scales up the window size –Selective Reject instead of go back n can be indicated via options field
TANENBAUMComputer Networks II22 TCP Connection Management Server waits for an incoming connection by executing the LISTEN and ACCEPT primitives Client executes CONNECT primitive –IP address, port number and options specified Destination checks to see if a process has done a LISTEN on the indicated port –If not,request is rejected If there is a process which has done a LISTEN, it is asked if it would accept the connection –If process rejects, destination sends a segment with RST set. If process accepts, request is acked
TANENBAUMComputer Networks II23 TCP Connection Establishment (a) TCP connection establishment in the normal case. (b) Call collision. 6-31
TANENBAUMComputer Networks II24 TCP Connection Management (cont’d) If simultaneous connection request happens only one connection is established TCP connections are full duplex However, they are considered as two simplex connections and each of them is released independently To release, a node sends a segment with FIN bit set and the other side acks the release Same procedure is repeated for the other simplex connection.
TANENBAUMComputer Networks II25 TCP Connection Management (cont’d) To avoid two-army problem, timers are used in release process That is, if ack for release does not arrive on time, timer goes off and client releases the connection After release, both sides wait for maximum packet lifetime to erase tables
TANENBAUMComputer Networks II26 TCP Connection Management Modeling The states used in the TCP connection management finite state machine.
TANENBAUMComputer Networks II27 TCP Connection Management Modeling (2) TCP connection management finite state machine. The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled by the event causing it and the action resulting from it, separated by a slash.
TANENBAUMComputer Networks II28 TCP Transmission Policy Window management is not directly tied to acks as in data link protocols Exclusive buffer messages manage the transmission If no buffer at receiver, then no transmission by sender except –Urgent data may be sent –One byte segment can be sent to ask receiver to renounce its buffer status (to prevent deadlock)
TANENBAUMComputer Networks II30 TCP Transmission Policy (cont’d) Sender and receiver are not forced to transmit or receive as soon as they receive data from the application. This improves performance as follows: –If one byte messages are sent (like in TELNET) then use NAGLE’s algorithm Send first byte and keep the rest until ack comes back As ack comes in send the rest and keep the further incoming bytes until ack is received
TANENBAUMComputer Networks II31 TCP Transmission Policy (2) Silly Window Syndrome: Receive bytes one by one and send window messaging accordingly
TANENBAUMComputer Networks II32 TCP Transmission Policy (cont’d) Clark’s Solution to Silly Window Syndrome –Prevent receiver from sending one byte updates and make it wait until decent amount of space available before it sends buffer messages –Sender may also pospone sending messages Nagle’s Algorithm and Clark’s solution are complementary and they can be used at the same time
TANENBAUMComputer Networks II33 TCP Congestion Control When congestion occurs, IP has limited effect on managing congestion Most of the congestion control is done by TCP by cutting down the data rate Indication of congestion –Timeouts –Packet discards –In fiber optic cable transmission errors are minimized so timeouts mainly due to congestion
TANENBAUMComputer Networks II34 Congestion Window In addition to receiver’s buffer information, the sender also maintains a congestion window. This is mainly due to the fact that even if receiver may have space for fast data transfer, network may not carry it due to congestion. The number of bytes to be sent is the minimum of the two windows
TANENBAUMComputer Networks II35 TCP Congestion Control (a) A fast network feeding a low capacity receiver. (b) A slow network feeding a high-capacity receiver.
TANENBAUMComputer Networks II36 Slow Start Algorithm Initialize the size of the congestion window to the maximum segment size If no timeout occurs increase the size of the window by one segment and send again. Repeat above n times. If no timeout, then increase the window by n segments. Internet uses threshold in addition to the above algorithm
TANENBAUMComputer Networks II37 TCP Congestion Control (2) An example of the Internet congestion algorithm.
TANENBAUMComputer Networks II38 TCP Timer Management: Retransmission Timer When goes off, segment is retransmitted Setting the timer value is much more difficult than that of data-link layer, beacuse the delay is not easily predictable TCP uses a dynamic algorithm to solve this problem For each connection, TCP maintains a variable called RTT (round trip time)
TANENBAUMComputer Networks II39 TCP Timer Management (a) Probability density of ACK arrival times in the data link layer. (b) Probability density of ACK arrival times for TCP.
TANENBAUMComputer Networks II40 Retransmission Timer (cont’d) M: The time to receive ack :Smoothing factor, usually 7/8 RTT= RTT+(1- )M D= D+(1- )|RTT-M| Timeout=RTT+4D Karn’s Algorithm –Do not update RTT on any segments that have been retransmitted (difficult to figure out for what segment the ack is)
TANENBAUMComputer Networks II41 TCP Timers (cont’d) Persistence Timer –Used to prevent deadlock when buffer management messages are lost Keepalive Timer –Check the other side if the line is idle for a long time Timed Wait –Used to close the connection
TANENBAUMComputer Networks II42 Wireless TCP and UDP In theory, transport protocol should be independent of the technology of the underlying network layer However, if the transmission is wireless, performance of TCP degrades drastically –Wired connections Timeouts are considered to be caused by congestion not by lost packets –Wireless Connections Timeouts are primarily due to lost packets
TANENBAUMComputer Networks II43 Wireless TCP and UDP (cont’d) Wired TCP Timeout –Slowdown to alleviate congestion Wireless TCP Timeout –Retransmit as soon as possible Indirect TCP –Split TCP connection into two separate connections Sender-to-base station Base station to mobile host
TANENBAUMComputer Networks II44 Wireless TCP and UDP Splitting a TCP connection into two connections.
TANENBAUMComputer Networks II45 Indirect TCP Snooping Agent –Observes and caches TCP segments going out to the mobile host and acknowledges coming back from it –When an ack for a segment to mobile host is late, it retransmits the segment to mobile host without telling anything to the source –Congestion control algorithm will never start unless there is congestion on the wired part Wireless UDP –Stations should not expect reliability
TANENBAUMComputer Networks II46 Translational TCP If RPC requires long replies, then UDP is not suitable and TCP becomes the choice However, TCP requires nine packets and this not efficient A variant of TCP called T/TCP (Translational TCP) solves this problem –Allows transfer of data during setup
TANENBAUMComputer Networks II47 Transitional TCP (a) RPC using normal TCP. (b) RPC using T/TCP.
TANENBAUMComputer Networks II48 Performance Issues Performance Problems in Computer Networks Network Performance Measurement System Design for Better Performance Fast TPDU Processing Protocols for Gigabit Networks
TANENBAUMComputer Networks II49 PERFORMANCE ISSUES: Performance Problems Fast line-slow CPU Broadcast storm Power failure (RARP density when machines are up) Lack of memory allocation Timeouts set incorrectly Bandwidth-delay product (BDP) –The receiver window should be at least BDP Jitter
TANENBAUMComputer Networks II50 Performance Problems in Computer Networks The state of transmitting one megabit from San Diego to Boston (a) At t = 0, (b) After 500 μsec, (c) After 20 msec, (d) after 40 msec.
TANENBAUMComputer Networks II51 Measuring Network Performance Make sure that the sample size is large enough Make sure that the samples are representative Be careful when using a coarse-grained clock Be sure that nothing unexpected is going on during your tests Caching can wreak havoc with measurements Understand what you are measuring Be careful about extrapolating the results
TANENBAUMComputer Networks II52 Network Performance Measurement The basic loop for improving network performance. Measure relevant network parameters, performance. Try to understand what is going on. Change one parameter.
TANENBAUMComputer Networks II53 System Design for Better Performance Rules: CPU speed is more important than network speed. Reduce packet count to reduce software overhead. Minimize context switches. Minimize copying. You can buy more bandwidth but not lower delay. Avoiding congestion is better than recovering from it. Avoid timeouts.
TANENBAUMComputer Networks II54 System Design for Better Performance (2) Response as a function of load.
TANENBAUMComputer Networks II55 System Design for Better Performance (3) Four context switches to handle one packet with a user-space network manager.
TANENBAUMComputer Networks II56 Fast TPDU Processing Main obstacle is protocol software Processing overhead components –Overhead per TPDU –Overhead per byte Optimization for overhead per TPDU –Minimize tests if in ESTABLISHED state –Headers of consecutive data TPDU’s are almost the same Store a prototype header and overwrite the changing values
TANENBAUMComputer Networks II57 Fast TPDU Processing The fast path from sender to receiver is shown with a heavy line. The processing steps on this path are shaded.
TANENBAUMComputer Networks II58 Fast TPDU Processing (2) (a) TCP header. (b) IP header. In both cases, the shaded fields are taken from the prototype without change.
TANENBAUMComputer Networks II59 Optimizations for high speed networks Buffer management –Avoid unnecessary copying Timer Management –Use linked list of timer events sorted by expiry time At every clock tick, the counter in the head entry is decremented –Timer wheel More efficient if timer interval is known in advance
TANENBAUMComputer Networks II61 Protocols for Gegabit Networks 32 bit sequence number is small Communication speed is much faster than computing speed Go back n is not good when bandwidth- delay product is high Gegabit lines are delay limited rather than bandwidth limited Variance of packet arrival time may be very important
TANENBAUMComputer Networks II62 Protocols for Gigabit Networks Time to transfer and acknowledge a 1-megabit file over a 4000-km line.
TANENBAUMComputer Networks II63 Gegabit (cont’d) Design for speed not for bandwidth optimization Make protocols simple and let the main CPU do the work Reserve necessary sources at the connection set up time rather than implementing e.g. Slow start algorithm Minimize header length and copy time Checksum the header and data separately Concentrate on succesful cases rather than failures