Jaringan Komputer Transport Layer The Transport Layer The heart of the whole protocol hierarchy Task: To provide reliable, cost-effective data transport from the source machine to the destination machine, independently of the physical network or networks currently in use The service is provided to its users, normally processes in the application layer Makes use of the services provided by the network layer Without the transport layer, the whole concept of layered protocols would make little sense 2
The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 3 The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 4
Services Similar to Network Layer: Connection Oriented & Connectionless But: Transport code runs entirely on the users' machines, the network layer mostly runs on the routers, which are operated by the carrier (at least for a wide area network) What happens if the network layer offers inadequate service? Suppose that it frequently loses packets? What happens if routers crash from time to time? The existence of the transport layer makes it possible for the transport service to be more reliable than the underlying network service 5 Services Many people have traditionally made a distinction between layers 1 through 4 on the one hand and layer(s) above 4 on the other The bottom four layers can be seen as the transport service provider The upper layer(s) are the transport service user This distinction of provider versus user has a considerable impact on the design of the layers and puts the transport layer in a key position, since it forms the major boundary between the provider and user of the reliable data transmission service 6
Service Primitives 7 TPDU 8
Connection Management A state diagram for a simple connection management scheme Transitions labeled in italics are caused by packet arrivals. The solid lines show the client's state sequence. The dashed lines show the server's state sequence 9 Berkeley Sockets (Internet) Another set of transport primitives, the socket primitives used in Berkeley UNIX for TCP Widely used for Internet programming Offer more features and flexibility 5/2/2006 10
The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 11 Elements of Transport Protocols In some ways, transport protocols resemble the data link protocols Both have to deal with error control, sequencing, and flow control Significant differences due to major dissimilarities between the environments in which the two protocols operate At the data link layer, two routers communicate directly via a physical channel At the transport layer, this physical channel is replaced by the entire subnet 12
Environment (a) Environment of the data link layer (b) Environment of the transport layer. 13 Differences Route: In transport layer, explicit addressing of destinations is required Establishing a connection: Over the wire is simple In transport layer, initial connection establishment is more complicated Potential existence of storage capacity in the subnet Amount rather than of kind Buffering Flow control 14
Addressing TSAP (Transport Service Access Point): to specify which one to connect to 15 Addressing TSAP addresses Stable: every conceivable server listening at a well-known TSAP works for services that never change (e.g. the Web server) Not stable: works for user process that often want to talk to other user processes that only exist for a short time and do not have a TSAP address that is known in advance Schemes: initial connection protocol: each machine wishes to offer services to remote users has a special process server that acts as a proxy name server/directory server: when a new service is created, it must register itself with the name server, giving its service name and its TSAP 16
Connection Establishment Is it as simple as just send a CONNECTION REQUEST TPDU to the destination and wait for a CONNECTION ACCEPTED reply? NO! Problems occur: Packet lost Traffic jam Packet (delayed) duplication Solution (?): Use throw-away transport address (create when needed) Connection identifier Flaw: huge history information & lost if crashed 17 Other Solutions Restrict packet lifetime: Restricted subnet Hop counter Timestamp If machine losing all memory: Clock-based (Tomlinson): equipping each host with a time-of-day clock low-order k bits of the clock are used as the initial sequence number connection must first be established 18
Other Solutions Problem: Incorrect connection establishment three-way handshake (Tomlinson) (a) Normal operation (b) Duplicate CR (c) Duplicate CR and duplicate ACK 19 Connection Release Two styles of terminating a connection: asymmetric release: when one party hangs up, the connection is broken abrupt and may result in data loss symmetric release: treats the connection as two separate unidirectional connections and requires each one to be released separately a host can continue to receive data even after it has sent a DISCONNECT TPDU only if it s obvious to terminate (fixed data and time is known) 20
Connection Release Other situation Protocol that say: I am done. Are you done too? If responds: I am done too. Goodbye, the connection can be safely released. Problem: two-army problem: 2,3,4 (or more) way handshake protocol? substitute ''disconnect'' for ''attack.'' If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen. 21 Protocols for connection release 3 way is adequate Four protocol scenarios for releasing a connection (a) Normal case of three-way handshake (b) Final ACK lost (c) Response lost (d) Response lost and subsequent DRs lost 22
Flow Control and Buffering TL vs. DL: Similarity: in both layers a sliding window or other scheme is needed on each connection to keep a fast transmitter from overrunning a slow receiver Difference: a router usually has relatively few lines, whereas a host may have numerous connections. This difference makes it impractical to implement the data link buffering strategy in the transport layer If the network service is unreliable, the sender must buffer all TPDUs sent, just as in the data link layer 23 Buffer Size (a) Chained fixed-size buffers (b) Chained variable-sized buffers (c) One large circular buffer per connection 24
Multiplexing (a) Upward multiplexing. (b) Downward multiplexing 25 Crash Recovery If hosts and routers are subject to crashes, recovery from these crashes becomes an issue If the transport entity is entirely within the hosts, recovery from network and router crashes is straightforward If the network layer provides datagram service, the transport entities expect lost TPDUs all the time and know how to cope with them If the network layer provides connection-oriented service, then loss of a virtual circuit is handled by establishing a new one and then probing the remote transport entity to ask it which TPDUs it has received and which ones it has not received. The latter ones can be retransmitted 26
Strategy Different combinations of client and server strategy A: ACK, W: write, C: crash 27 The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 28
The Example Service Primitives 5 primitives: CONNECT, LISTEN, DISCONNECT, SEND, and RECEIVE Each primitive corresponds exactly to a library procedure that executes the primitive The parameters for the service primitives and library procedures are as follows: connum = LISTEN(local) connum = CONNECT(local, remote) status = SEND(connum, buffer, bytes) status = RECEIVE(connum, buffer, bytes) status = DISCONNECT(connum) 29 The Example Transport Entity Use connection-oriented, reliable network service Focus on transport issues that do not occur in the lower layers connection establishment connection release credit management Transport entity may be part of the host's operating system, or it may be a package of library routines running within the user's address space Algorithm 30
Graphical Form The example protocol in graphical form. Transitions that leave the connection state unchanged have been omitted for simplicity 31 Packets & States States: IDLE Connection not established yet. WAITING CONNECT has been executed and CALL REQUEST sent. QUEUED A CALL REQUEST has arrived; no LISTEN yet. ESTABLISHED The connection has been established. SENDING The user is waiting for permission to send a packet. RECEIVING A RECEIVE has been done. DISCONNECTING A DISCONNECT has been done locally 32
The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 33 UDP (User Datagram Protocol) Internet connectionless protocol in the transport layer UDP is basically just IP with a short header added UDP provides a way for applications to send encapsulated IP datagrams and send them without having to establish a connection UDP is described in RFC 768 34
UDP Segment & Header UDP transmits segments consisting of an 8-byte header followed by the payload Header: 35 Remote Procedure Call Allowing programs to call procedures located on remote hosts When a process on machine 1 calls a procedure on machine 2, the calling process on 1 is suspended and execution of the called procedure takes place on 2. Information can be transported from the caller to the callee in the parameters and can come back in the procedure result. No message passing is visible to the programmer Idea: to make a remote procedure call look as much as possible like a local one. In the simplest form, to call a remote procedure, the client program must be bound with a small library procedure, called the client stub, that represents the server procedure in the client's address space. Similarly, the server is bound with a procedure called the server stub. These procedures hide the fact that the procedure call from the client to the server is not local 36
Remote Procedure Call Steps in making a remote procedure call. The stubs are shaded 37 Remote Procedure Call Problems: Passing pointers is impossible because the client and server are in different address spaces Unspecified array size (no way of determining how large they are) not always possible to deduce the types of the parameters, not even from a formal specification or the code itself the use of global variables Restrictions are needed 38
Real-Time Transport Protocol Used in real-time multimedia applications Internet radio Internet telephony music-on-demand Videoconferencing video-on-demand Described in RFC 1889 The basic function of RTP is to multiplex several real-time data streams onto a single stream of UDP packets The UDP stream can be sent to a single destination (unicasting) or to multiple destinations (multicasting) 39 Real-Time Transport Protocol (a) The position of RTP in the protocol stack (b) Packet nesting 40
The Transport Layer Services Elements A Simple Transport Protocol Internet Transport Protocol: UDP TCP Performance Issues 41 TCP (Transmission Control Protocol) For most Internet applications, reliable, sequenced delivery is needed TCP Specifically designed to provide a reliable end-to-end byte stream over an unreliable internetwork Designed to dynamically adapt to properties of the internetwork and to be robust in the face of many kinds of failures Formally defined in RFC 793 Clarifications of changes and some bug fixes are detailed in RFC 1122 Extensions are given in RFC 1323 42
TCP Entity Each machine supporting TCP has a TCP transport entity as: library procedure user process part of the kernel It manages TCP streams and interfaces to the IP layer It accepts user data streams from local processes, breaks them up into pieces not exceeding 64 KB (in practice, often 1460 data bytes in order to fit in a single Ethernet frame with the IP and TCP headers), and sends each piece as a separate IP datagram When datagrams containing TCP data arrive at a machine, they are given to the TCP entity, which reconstructs the original byte streams ''TCP'' mean the TCP transport entity (a piece of software) or the TCP protocol (a set of rules) 43 TCP Service Model TCP service is obtained by both the sender and receiver creating end points, called sockets Each socket has a socket number (address) consisting of the IP address of the host and a 16-bit number local to that host, called a port A port is the TCP name for a TSAP For TCP service to be obtained, a connection must be explicitly established between a socket on the sending machine and a socket on the receiving machine A socket may be used for multiple connections at the same time (2 / more connections may terminate at same socket) Connections are identified by the socket identifiers at both ends. No virtual circuit numbers or other identifiers are used. 44
Port Port numbers below 1024 are called well-known ports and are reserved for standard services For example, any process wishing to establish a connection to a host to transfer a file using FTP can connect to the destination host's port 21 to contact its FTP daemon The list of well-known ports is given at www.iana.org. Over 300 have been assigned 45 TCP Service Model All TCP connections are full duplex and point-topoint. TCP does not support multicasting or broadcasting. A TCP connection is a byte stream, not a message stream. Message boundaries are not preserved end to end. For example, if the sending process does four 512-byte writes to a TCP stream, these data may be delivered to the receiving process as four 512-byte chunks, two 1024-byte chunks, one 2048-byte chunk or some other way. There is no way for the receiver to detect the unit(s) in which the data were written. 46
TCP Protocol Every byte on a TCP connection has its own 32-bit sequence number The sending and receiving TCP entities exchange data in the form of segments. A TCP segment consists of a fixed 20-byte header (plus an optional part) followed by zero or more data bytes Two limits restrict the segment size: Each segment, including the TCP header, must fit in the 65,515-byte IP payload Each network has a maximum transfer unit (MTU) and each segment must fit in the MTU. In practice, the MTU is generally 1500 bytes (the Ethernet payload size) 47 TCP Protocol The basic protocol used by TCP entities is the sliding window protocol When a sender transmits a segment, it also starts a timer When the segment arrives at the destination, the receiving TCP entity sends back a segment (with data if any exist, otherwise without data) bearing an acknowledgement number equal to the next sequence number it expects to receive If the sender's timer goes off before the acknowledgement is received, the sender transmits the segment again 48
TCP Segment Header 49 TCP Connection Establishment By means of the three-way handshake To establish a connection, one side passively waits for an incoming connection by executing the LISTEN and ACCEPT primitives, either specifying a specific source or nobody in particular. The other side, say, the client, executes a CONNECT primitive, specifying the IP address and port to which it wants to connect, the maximum TCP segment size it is willing to accept, and optionally some user data (e.g., a password) 50
TCP Connection Establishment The CONNECT primitive sends a TCP segment with the SYN: on and ACK: off and waits for a response When this segment arrives at the destination, the TCP entity there checks to see if there is a process that has done a LISTEN on the port given in the Destination port field. If not, it sends a reply with the RST bit on to reject the connection If some process is listening to the port, that process is given the incoming TCP segment. It can then accept or reject the connection. If it accepts, an acknowledgement segment is sent back 51 TCP Connection Establishment a) TCP connection establishment in the normal case (b) Call collision 52
TCP Connection Release Each simplex connection is released independently of its sibling To release a connection, either party can send a TCP segment with the FIN bit set, which means that it has no more data to transmit When the FIN is acknowledged, that direction is shut down for new data. Data may continue to flow indefinitely in the other direction, however. When both directions have been shut down, the connection is released Normally, four TCP segments are needed to release a connection, one FIN and one ACK for each direction To avoid the two-army problem, timers are used 53 TCP Connection Management 54
TCP Congestion Control Realize that two potential problems exist network capacity receiver capacity Each sender maintains two windows the window the receiver has granted the congestion window Each reflects the number of bytes the sender may transmit. The number of bytes that may be sent is the minimum of the two windows It uses threshold. When a timeout occurs, the threshold is set to half of the current congestion window, and the congestion window is reset to one maximum segment 55 TCP Congestion Control 56
TCP Timer Management TCP uses multiple timers to do its work retransmission timer: wait for ACK persistence timer: prevent deadlock keepalive timer: idle before disconnect 57 Wireless TCP In theory Transport protocols should be independent of the technology of the underlying network layer TCP should not care whether IP is running over fiber or over radio In practice most TCP implementations have been carefully optimized based on assumptions that are true for wired networks but that fail for wireless networks Packet lost is the main cause for timeout 58
Wireless TCP The principal problem is the congestion control algorithm Nearly all TCP implementations nowadays assume that timeouts are caused by congestion, not by lost packets. Consequently, when a timer goes off, TCP slows down and sends less vigorously The idea behind this approach is to reduce the network load and thus alleviate the congestion Wireless transmission links are highly unreliable They lose packets all the time The proper approach to dealing with lost packets is to send them again, and as quickly as possible Slowing down just makes matters worse 59 Transactional TCP A way to combine the efficiency of RPC using UDP (just two messages) with the reliability of TCP An experimental TCP variant which is described in RFCs 1379 and 1644 Idea: modify the standard connection setup sequence slightly to allow the transfer of data during setup Another proposal is SCTP (Stream Control Transmission Protocol) 60
Transactional TCP (a) RPC using normal TCP. (b) RPC using T/TCP 61 Performance Rule #1: CPU Speed Is More Important Than Network Speed Rule #2: Reduce Packet Count to Reduce Software Overhead Rule #3: Minimize Context Switches Rule #4: Minimize Copying Rule #5: You Can Buy More Bandwidth but Not Lower Delay Rule #6: Avoiding Congestion Is Better Than Recovering from It Rule #7: Avoid Timeouts 62