Computer Networks 2

Computer Networks 2 The Internet Transport Protocol Veton Këpuska

The Internet Transport Protocols • Internet has two main protocols in transport layer: • Connectionless Protocol (UDP), and • Connection-oriented Protocol (TCP). • UPD (User Datagram Protocol) • UDP is IP with just a short header added. • UDP provides a way for applications to send encapsulated UP datagrams and send them without having to establish a connection. Veton Këpuska

UPD (User Datagram Protocol) • UDP transmits segments consisting of 8-byte header followed by the payload: • Source and Destination Ports: • Two ports are used to identify the end points within the source and destination machines. • The main advantage of the UDP over just using raw IP is the addition of the source and destination ports. Without the port fields, the transport layer would not know what to do with the packet. • Source Port are primarily needed when a reply must be send back to the source. (Source port field is copied from the incoming segment into the destination port field of the outgoing segment). • UDP packets are handed to the process attached to the destination process. • This attachment occurs when a BIND (or a similar) primitive is used. Veton Këpuska

UPD (User Datagram Protocol) • UDP length field: • Includes 80-byte header and payload data. • UDP Checksum: • Optional field. • What UDP does not do: • Flow Control • Error Control • Retransmission upon receipted of a bad segment. • User application responsible for control over the packet flow, error control and timing. Veton Këpuska

UPD (User Datagram Protocol) • UDP useful in client-server situations: • Client sends a short request to the server and expects a short reply back. If either the request or reply is lost, the client can just time out and try again. • Simple code • Fewer messages are required compared to protocols that require initial setup. • Typical application using UDP is DNS (the Domain Name System). • An application that needs to look up the IP address of some host name (e.g., www.cs.berkeley.edu) can send a UDP packet containing the host name to a DSN server. • Server replies with a UDP packet containing the host’s IP address. • No setup is needed in advance and no release is needed afterward. Just two messages go over the network. Veton Këpuska

Remote Procedure Call • Sending a message to a remote host and getting a reply back, in a certain sense is a lot like making a function call in a programming language: • Request/Reply interactions on network are cast in the form of procedure calls. • Example: procedureget_IP_address(host_name);that works by sending a UDP packet to a DNS server and waiting for the reply, timing out and trying again if one is not forthcoming quickly enough. • Remote Procedure Call – RPC technique that allows: • A process on machine 1 to call 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 in the procedure result. No message passing is visible to the programmer. Veton Këpuska

Remote Procedure Call • The idea behind RPC is to make a remote procedure call look as much as possible like a local one. • This is done using client stub (small library that represents server procedure in the client's address space) and server stub (similarly a small library that represents client procedure in the servers address space). • Actual steps in making an RPC are shown if Fig. 6-24. Veton Këpuska

Remote Procedure Call • Client calling the client stub. This is a local procedure call with the parameters pushed onto the stack in the normal way. • Client stub packing the parameters into a message and making a system call to send the message. • Kernel sends the message from the client machine to the server machine. • Kernel passing the incoming packet to the server stub. • Server stub calling the server procedure with the unpacked parameters. Veton Këpuska

Remote Procedure Call • Client Procedure (written by the user) makes a usual (i.e., local) procedure call to the client stub, which has the same name as the server procedure. • Since the client procedure and client stub are in the same address space, the parameters are passed in the usual way. • Server Procedure in similar function is called by a procedure in its address space with the parameters it expects. To the server procedure nothing is unusual. • In this way instead of I/O being done on sockets, network communication is done by faking a normal procedure call. Veton Këpuska

Remote Procedure Call • Difficulties of RPC model with weakly-typed languages (like C). • Passing pointers (stub must pass the data were the pointer is pointing to and deliver a copy and its pointer to the server). • Arrays that do not have a preset size impossible to handle. • When it is not possible to deduce a type of the parameters (e.g., printf) the RPC is difficult. • Global variables when the called procedure is moved to a remote machine. Veton Këpuska

The Real-Time Transport Protocol • Client-Server RPC is an area in which UDP is widely used. • RPC is also used in Internet for real-time multimedia applications: • Radio, • Telephony, • Music-on-demand, • Videoconferencing, • Vide-on-demand, etc. • Generic Real-time transport protocol evolved for those multiple applications. • RTP is placed over UDP in protocol stack as presented in Fig. 6-25 (a). Packet nesting is presented in figure (b). Veton Këpuska

The Real-Time Transport Protocol • Basic function of RTP is to multiplex several real-time data streams onto a single stream of UDP packets. • The UDP stream can be send to a single destination (unicasting) or to multiple destinations (multicasting). • Because RTP uses normal UDP there are no special guarantees about delivery, jitter, etc. • Each RTP packet send is given a number one higher then its predecessor. This numbering allows the destination to determine if any packets are missing. If a packet is missing, the best action is to approximate the missing value by interpolation. • Since retransmission is not a practical solution (real-time streaming) RTP does not do flow control, error control nor it does acknowledgments and it does not have mechanism to request retransmissions. Veton Këpuska

The Real-Time Transport Protocol • Each RTP payload may contain multiple samples, and they may be coded differently. For this reason RTP defines several profiles (e.g., single audio stream) and for each profile multiple coding formats may be allowed. • Single audio stream may be encoded as 8-bit PCM samples at 8 kHz, delta encoding, predictive encoding, GSM encoding, MP3, and so on. • RTP provides a header field (Payload type) in which the source can specify the encoding but it otherwise is not involved in encoding itself. • RTP header has a timestamp field that is used to reduce jitter at the receiver. It also can be used to synchronize multiple streams (video, audio 1 of original sound, audio 2 of dubbed soundtrack). Veton Këpuska

The Real-Time Transport Protocol • Real time Transport Control Protocol (RTCP) is a associated protocol to RTP that is used to handle feedback, synchronization and the user interfaces but does not transport any data. • It is used to provide feedback on delay, jitter, bandwidth, congestion, and other network properties to the sources. • This information can be used by encoding process to • Increase the data rate (and give better quality) when the network is functioning well, and • Decrease the data rate when there is trouble in the network. • => Best possible quality under given circumstances. Veton Këpuska

The Internet Transport Protocols: TCP • For some niche uses such as client-server interactions and multimedia UDP protocol is well suited. • However, for most Internet applications where reliable, sequenced delivery is needed, UDP is not appropriate tool, so another protocol is needed. • The protocol suitable for reliable delivery application is TCP. • TCP is the main workhorse of the Internet. Veton Këpuska

Introduction to TCP • TCP (Transmission Control Protocol) • Specifically designed to provide reliable end-to-end byte stream over an unreliable inter-network. • An inter-network differs from a single network because different parts may have wildly different: • Topologies, • Bandwidths, • Delays, • Packet Sizes, • Other parameters. • TCP was designed to dynamically adapt to properties of the inter-network and to be robust in the face of many kinds of failures. Veton Këpuska

Introduction to TCP • Each machine supporting TCP has a TCP transport entity • Library procedure, • User process, or • Part of the kernel. Which in either case manages TCP streams and interfaces to the IP layer. • TCP entity accepts user data streams and • 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), • Sends each piece as a separate IP datagram. • When TCP data arrive, they are handled by TCP entity of that destination machine which reconstructs the original byte stream. • Since IP layer gives no guarantee that datagrams will be delivered properly, it is up to TCP to time out and retransmit them as needed. • Datagrams that do arrive may do so at the wrong order; thus it also up to TCP in the destination machine to reassemble them into messages in the proper sequence. Veton Këpuska

The TCP Service Model • TCP service is obtained by sender and receiver creating end points (sockets). • Each Socket has Socket Number (address) consisting of: • IP address of the host and • 16-bit number local to that host called port. (Port is a TCP name for Transport Service Access Point – TSAP). • TCP service is obtained when a connection is explicitly established between a socket on the sending machine and a socket on the receiving machine. Veton Këpuska

The TCP Service Model • A socket may be used for multiple connections at the same time. Connections are identified at both ends as (socket1,socket2). • Port numbers bellow 1024 are called well-known ports and are used for standard services. A few of better know ports are listed in Fig. 6-27. Veton Këpuska

The TCP Service Model • Some Assigned Ports Veton Këpuska

The TCP Service Model • All TCP connections are full duplex and point-to-point. TCP does not support multicasting nor broadcasting. • A TCP connection is a byte stream not a message stream. Message boundaries are not preserved end-to-end. • If the sending process does 4X512-byte writes to a TCP stream, these data may be delivered to the receiving process as 4X512-byte chunks, 2X1024-byte chunks or 1X2048-byte chunk or some other way. (See Fig.6-28). Veton Këpuska

The TCP Service Model • TCP may buffer the data before sending it. If application requires that the data be send immediately it can use the PUSH flag which indicates to TCP not to delay the transmission. • One additional feature of TCP service worth mentioning is urgent data. • If sending application puts some control information in the data stream and gives it to TCP along with the URGENT flag it causes TCP to stop accumulating data and transmit everything it has for that connection immediately. (CTRL-C or DEL) • At the receiving end when this packet arrives the application in the destination is interrupted so it can stop whatever it was doing and read the data stream to find the urgent data. The end of the urgent data is marked so the application knows when it is over. Veton Këpuska

The TCP Protocol • A key feature which dominates the protocol design is that every byte on a TCP connection has its own 32-bit sequence number. • In the early days of Internet when lines between routers were mostly 56-kbps the TCP host working at its full speed took over 1 week to cycle through the sequence numbers. • At modern network speeds, the sequence numbers can be consumed at an alarming rate. • Separate sequence numbers are used for: • Acknowledgments and • Window mechanism As explained next. Veton Këpuska

The TCP Protocol • TCP entities exchange data in the form of segments. • A TCP segment consists of a fixed 20-byte header (plus optional part) followed by zero or more data bytes. • TCP software decides how big segments should be. • It can accumulate data from several writes, or • It can split data from one write over multiple segments. Veton Këpuska

The TCP Protocol • TCP Segment. Two limits restrict segment size: • Each segment 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) and thus defines the upper bound on segment size. Veton Këpuska

The TCP Protocol • Sliding Window Protocol: • The basic protocol used by TCP entities. • When a sender transmits a segment, it also starts a timer. • Destination sends back a segment (upon receiving the senders segment) containing acknowledgment number equal to the next sequence number it expects to receive. • If sender’s timer goes off before the acknowledgment is received, the sender transmits the segment again. Veton Këpuska

The TCP Segment Header • Figure 6-29 depicts layout of TCP segment including its header. • Every segment begins with a fixed-format 20-byte header. Fixed-header may be followed by header options. • After options, if any, up to 65,535-20-20 data bytes may follow (20 for TCP header and 20 for IP header). • Segments without data are legal and are used for acknowledgments and control messages. Veton Këpuska

The TCP Segment Header • Source and Destination Port fields. • Identify local end points of the connection. • Well-known ports are defined at www.iana.org • Port + host’s IP address forms a 48-bit unique end-point. The source and destination end-points together identify the connection. • Sequence Number and Acknowledgment Number fields. • Sequence number identifies the byte number of a sequence of a transmission. • Acknowledgment Number specifies the next byte expected (NOT the last byte correctly received). • Both are 32 bits long because every byte of data is numbered in TCP stream. Veton Këpuska

The TCP Segment Header • TCP header length. • It specifies how many 32-bit words are contained in the TCP header. • This information is needed because of the Options field which makes overall header of variable length. • 6-bit Unused field. • The fact that this field has survived intact for over a quarter of century is testimony to how well thought out TCP is. Veton Këpuska

The TCP Segment Header • Six 1-bit flags: • URG is set to 1 if Urgent Pointer is in use. Urgent Pointer itself is used to indicate a byte offset from the current sequence number at which urgent data are to be found. • This facility is used in lieu of interrupt messages. It allows sender to signal the receiver without getting TCP itself involved in the reason for the interrupt. • ACK bit is set to 1 to indicate that the Acknowledgment number is valid. If ACK is 0, the segment does not contain an acknowledgment so the Acknowledgment number field is ignored. Veton Këpuska

The TCP Segment Header • Six 1-bit flags (cont): • PSH bit indicates PUSHed data. The receiver is kindly requested to deliver the data to the application upon arrival and not to be buffered and delivered when buffer is full. • RST bit is used to reset a connection that has become confused due to a host crash or some other reason. It is also used to reject an invalid segment or refuse an attempt to open a connection. In general, if segment has RST bit on, it indicates that there is a problem of a sort that needs special handling. Veton Këpuska

The TCP Segment Header • SYN bit is used to establish connections. If SYN=1 and ACK=0 indicates that the piggyback acknowledgment field is not in use. If connection reply does bear an acknowledgment then this is indicated by SYN=1 and ACK=1. • In essence SYN bit is used to denote CONNECTION REQUEST and CONNECTION ACCEPTED. • The ACK-bit is used to distinguish between those two possibilities. • FIN bit is used to release connection. It indicates that the sender has no more data to transmit. • After closing a connection the closing process may continue indefinitely to receive data. This is because TCP is full-duplex connection. • Both SYN and FIN segments have sequence numbers and are thus guaranteed to be processed in the correct order. Veton Këpuska

The TCP Segment Header • Flow Control: • TCP does Flow Control by using a variable-sized sliding window. • Window Size field specifies how many bytes may be sent starting at the byte acknowledged. • A window size of 0 indicates that the bytes up to and including Acknowledgment number-1 have been received but the receiver can not accept more data at a moment. • The receiver can later grant permission to send by transmitting a segment with the same Acknowledgment number and a nonzero Window size field. Veton Këpuska

The TCP Segment Header • Checksum is provided for extra reliability. It checksums the header, the data, and conceptual pseudo header shown in Fig. 6-30. When performing this operation: • TCP Checksum field is set to zero. • Data field is padded out with additional zero byte if its length is an odd number • All of the 16-bit words in 1’s complement are added up and the sum is then 1’s complemented. Consequently when receiver performs the calculation on the entire segment, including the Checksum field the results should be zero. Veton Këpuska

The TCP Segment Header • The pseudo-header contains • The 32-bit IP addresses of the source and destination machines, • Protocol number for TCP (6), and • Byte count for the TCP segment (including header) • Including pseudo-header in the TCP checksum computation helps detect miss-delivered packets. However including it violates the protocol hierarchy since the IP addresses in it belong to IP layer - not to the TCP layer. Veton Këpuska

The TCP Segment Header • The Options field provides a way to add extra facilities not covered by the regular header. • The most important option is the one that allows each host to specify the maximum TCP payload it is willing to accept. • Using large segment it is more efficient than using small ones. However, small hosts may not be able to handle big segments. • During connection setup, each side can announce its maximum. If a host does not use this option it defaults to a 536-byte payload. • All internet hosts are required to accept TCP segments of 536+20=556 bytes. Veton Këpuska

The TCP Segment Header • For lines with: • High bandwidth, or • High delay, or both the 64KB window is often a problem. • Example: T3 line (44.736 Mbts) it takes only 12 msec to output a full 64-KB window. If round trip delay is 50 msec (typical for transcontinental fiber) the sender will be idle ¾ of the time waiting for acknowledgements. On a satellite connection the situation is even worse. • With 16-bit window size field there is no way to express larger window size. • Window scale option was proposed allowing the sender and receiver to negotiate a window scale factor. This number allows both sides to shift the Window size field up to 14 bits to the left, thus allowing windows of up to 230 bytes. Veton Këpuska

The TCP Segment Header • Selective Repeat instead of go-back-n protocol. • If the receiver gets one bad segment and then a large number of good ones the normal TCP protocol will eventually time out and retransmit all the unacknowledged segments, including all those that were received correctly (i.e., go-back-n protocol). • Newly introduced protocol allow NAKs to ask for a specific segment (or segments) upon reception of which it can acknowledge all the buffered data thus reducing amount of data transmitted. Veton Këpuska

TCP Connection Establishment • Connections in TCP are established by means of three-way handshake (introduced earlier). • To establish a connection one side (i.e., server), passively waits for an incoming connection by executing the LISTEN and ACCEPT primitives. • The other side (i.e., client) executes CONNECT primitive specifying: • IP address and port to which it wants to connect too. • Maximum TCP segment it is willing to accept, and • Optionally some user specific information (e.g., password). • CONNECT primitive sends a TCP segment with SYN=1 and ACK=0 and waits for response. Veton Këpuska

When this TCP segment arrives at the destination, 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 (RST=1) to reject the connection. • If some process is listening to the port that process is given that TCP segment. This process then can accept or reject the connection. If it is accepted the normal case is shown if Fig. 6-31(a). (SYN segment consumes byte of sequence space so that it can be acknowledged unambigously). • The case of two hosts simultaneously attempting to establish a connection between the same two sockets is presented in Fig. 6-31(b). The result of these events is that just one connection is established. Veton Këpuska

TCP Connection Establishment • TCP Connection Establishment • normal case. • call collision Veton Këpuska

TCP Connection Establishment • In the event that two hosts simultaneously attempt to establish a connection between the same two sockets only one connection is established as exemplified in the figure (b). • One connection is established because connections are identified by their end-points (one connection per pair of end-points). • If the first setup results in a connection identified by (x,y) and the second one does too, only one table entry is made for the entry (x,y) Veton Këpuska

TCP Connection Release • TCP connections are full duplex. • Connection Release is best understood if full duplex connection is viewed as a pair of simplex connections. • Each simplex connection is released independently. • To release a connection: • Either party can send a TCP segment with the FIN bit set (no more data to send). • When FIN is acknowledged that direction is shut down for new data. • Data may continue to flow indefinitely in the other direction. • When both connections are terminated the connection is released. • Normally 4 segments are needed for release of a connection: • 1 FIN and 1 ACK for each direction. • Two avoid the “two-army” problem, timers are used: • If a response to a FIN is not forthcoming within two maximum packet lifetimes, the sender of the FIN releases the connection. • The other side will eventually notice that nobody seems to be listening to it any more and will time out as well. Veton Këpuska

TCP Connection Management Modeling • The steps required to establish and release connections can be represented in a finite state machine with the 11 states listed in Fig.6-32. • In each state only certain events are legal. • When legal event happens some action may be taken. • Otherwise an error is reported. • Each connection starts in CLOSED state. It leaves CLOSED state when: • Passive open (LISTEN) or • Active open (CONNECT). • Connection is established if the other side does the opposite. Veton Këpuska

TCP Connection Management Modeling • The common case of client actively connecting to a passive server is with heavy lines: • Solid for client • Dotted for server. • Each line is marked as event/action pair. • Event can be: • User initiated call (CONNECT, LISTEN, SEND, or CLOSE) • Segment arrival (SYN, FIN, ACK, or RST), or • Timeout of twice the maximum packet lifetime. • Action can be: • Sending of a control segment (SYN,FIN, or RST), or • Nothing (indicated by ___). Veton Këpuska

TCP Connection Management Modeling • Starting from the application program on the client machine issuing a CONNECT request: • TCP entity creates a connection record: • Marks it as SYN SENT state • Sends SYN segment Veton Këpuska

TCP Transmission Policy • Window management in TCP is not directly tied to acknowledgments (as in most data link protocols). Example: • Sender transmits 2048-byte segment. • Receiver that has 4096-byte buffer acknowledges the segment. However, since now it has only 2048 bytes of buffer space it will set advertise a window of 2048 starting at the next byte expected. • Sender then transmits another 2048 bytes. • This second segment is acknowledged with window size of 0. • The sender must stop until the application process on the receiving host has removed some data from the buffer, at which time TCP can advertise a larger window. • The sender normally may not send segments with two exceptions: • Urgent data may be sent • 1-byte segment may be sent to make the receiver re-announce the next byte expected and window size. The TCP standard explicitly provides this option to prevent deadlock if a window announcement ever gets lost. Veton Këpuska

TCP Transmission Policy • Senders are not required to transmit data as soon as they are available from the application. • TCP (in previous example) knowing that 4KB of window data is available could have waited after getting first 2KB of data until its buffer is filled up to 4KB. In that case it would transmit a segment with a 4KB payload. Those strategies can be applied to improve performance. • Receivers are not required to send acknowledgements as soon as possible. Veton Këpuska

TCP Transmission Policy • Consider a telnet connection to an interactive editor that reacts on every key-stroke. • When a character arrives at the sending TCP entity, TCP creates a 21 byte TCP segment. This segment is sent as a 41 byte IP datagram. • At the receiving side sends 40 bytes as ACK segment. • When application (editor) has read the byte, TCP sends a window update, moving the window 1 byte to the right. (This packet is also 40 bytes.) • Finally, when the editor has processed the character, it echoes the character as a 41 byte packet. • 162 bytes of are transmitted and four segments are sent for each character typed: Inefficient and wasteful. Veton Këpuska

TCP Transmission Policy • One solution: Delay acknowledgments and window updates for 500 msec in order to piggyback on top of the data that needs to be send. If the application (editor) echoes within 500 msec, only one 41 byte packet need be sent back to the remote user. • This rule reduces the load placed on the network by the receiver. The sender is still operating inefficiently. • Nagle’s algorithm. • When data come into the sender one byte at a time, just send the first byte and buffer all the rest until the outstanding byte is acknowledged. • When outstanding byte is acknowledged send all the buffered characters in one TCP segment. Veton Këpuska

Computer Networks 2