1 15. Transport Protocols

Prof. Sang-Jo Yoo 2 Contents  Transport protocol  Transport Service  Protocol for reliable network service  Protocol for unreliable network service  TCP  UDP

Prof. Sang-Jo Yoo 3 Transport protocol  Basic end-to-end service of transferring data between users  Shields the TS user from the details of the underlying communication system  Reliable delivery  Nearly error-free service  Assured delivery  In-sequence delivery  No duplication

Prof. Sang-Jo Yoo 4 Connection Oriented Transport Protocol Mechanisms  Logical connection  Establishment  Maintenance & termination  Reliable  e.g. TCP

Prof. Sang-Jo Yoo 5 Reliable Sequencing Network Service  Assume arbitrary length message  Assume virtually 100% reliable delivery by network service  e.g. reliable packet switched network using X.25  e.g. frame relay using LAPF control protocol  e.g. IEEE using connection oriented LLC service  Transport service is end to end protocol between two systems on same network

Prof. Sang-Jo Yoo 6 Issues in a Simple Transprot Protocol  Addressing  Multiplexing  Flow Control  Connection establishment and termination

Prof. Sang-Jo Yoo 7 Addressing  Target user(application) specified by:  User identification  Usually host, port Called a socket in TCP  Port represents a particular transport service (TS) user  Transport entity identification  Generally only one per host  If more than one, then usually one of each type Specify transport protocol (TCP, UDP)  Host address  An attached network device  In an internet, a global internet address

Prof. Sang-Jo Yoo 8 Finding Addresses  Four methods  Know address ahead of time  e.g. collection of network device stats  Well known addresses  Name server  Sending process request to well known address  The target user is to be a process that is spawned at request time

Prof. Sang-Jo Yoo 9 Multiplexing  Multiple users employ same transport protocol  User identified by port number or service access point (SAP) multiplexing

Prof. Sang-Jo Yoo 10 Multiplexing (Port)  Many applications that use TCP depend on well-known ports. Well-known ports are predefined port values that, by prior agreement, belong to particular application protocols.

Prof. Sang-Jo Yoo 11 Multiplexing (Port)  Servers typically just listen for connections. When they do, they listen only for connections to their well-known ports (or predefined ports).  A client contacting a server initiates a connection to that port. Since the client takes the initiative, it must know both the IP address and the port for that server.  The server, on the other hand, does not need to know the identity of the client in advance. The server simply waits for any client to initiate the connection, and it responds to whichever IP address and port value that the client has chosen for itself.

Prof. Sang-Jo Yoo 12 Flow Control  More complex mechanism than at the Link layer because  Longer transmission delay between transport entities compared with actual transmission time  Delay in communication of flow control info  Variable transmission delay  Difficult to use timeouts  Flow may be controlled because:  The receiving user can not keep up  The receiving transport entity can not keep up  Results in buffer filling up

Prof. Sang-Jo Yoo 13 Coping with Flow Control Requirements (1)  Do nothing  Segments (TCP packets are called segment) that overflow are discarded  Sending transport entity will fail to get ACK and will retransmit  Thus further adding to incoming data  Refuse further segments

Prof. Sang-Jo Yoo 14 Coping with Flow Control Requirements (2)  Use fixed sliding window protocol  The use of sequence numbers on data units  The use of window of fixed size  The use of acknowledgments to advance the window  Not work well in an unreliable network  No ACK: flow control or lost of segment?  Use credit scheme

Prof. Sang-Jo Yoo 15 Credit Scheme  Greater control on reliable network  More effective on unreliable network  Decouples flow control from ACK  May ACK without granting credit and vice versa  Each octet has sequence number  Each transport segment has seq number, ack number and window size in header

Prof. Sang-Jo Yoo 16 Use of Header Fields  When sending, seq number is that of first octet in segment  ACK includes AN=i, W=j  All octets through SN=i-1 acknowledged  Next expected octet is i  Permission to send additional window of W=j octets  i.e. octets through i+j-1

Prof. Sang-Jo Yoo 17 Credit Allocation

Prof. Sang-Jo Yoo 18 Sending and Receiving Perspectives

Prof. Sang-Jo Yoo 19 Establishment and Termination  Need to support connection-oriented service.  Allow each end to assure that the other exists  Negotiation of optional parameters  Maximum segment size, maximum window size  Quality of service  Triggers allocation of transport entity resources  By mutual agreement

Prof. Sang-Jo Yoo 20 Connection State Diagram

Prof. Sang-Jo Yoo 21 Connection Establishment

Prof. Sang-Jo Yoo 22 Not Listening  Reject with RST (Reset)  Queue request until matching open issued  Signal TS user to notify of pending request  May replace passive open with accept

Prof. Sang-Jo Yoo 23 Termination  Connection termination  The side that initiates the termination  In response to a TS user’s Close primitive, a FIN segment is sent  Transport entity places the connection in the FIN WAIT state, must continue to accept data  When a FIN is received in response, the transport entity informs its user and closes the connection  The other side  When a FIN segment is received, the transport entity informs its user, and places the connection in CLOSE WAIT state.  Continue to transmit data segments  When the user issues a Close primitive, the transport entity sends a responding FIN segment to the other side and closes the connection

Prof. Sang-Jo Yoo 24 Unreliable Network Service  E.g.  internet using IP,  frame relay using LAPF  IEEE using unacknowledged connectionless LLC  Segments may get lost  Segments may arrive out of order

Prof. Sang-Jo Yoo 25 Problems  Ordered Delivery  Retransmission strategy  Duplication detection  Flow control  Connection establishment  Connection termination  Crash recovery

Prof. Sang-Jo Yoo 26 Ordered Delivery  Segments may arrive out of order  Number segments sequentially  TCP numbers each octet sequentially  Segments are numbered by the first octet number in the segment

Prof. Sang-Jo Yoo 27 Retransmission Strategy  Segment damaged in transit  Segment fails to arrive  Transmitter does not know of failure  Receiver must acknowledge successful receipt  Use cumulative acknowledgement  Time out waiting for ACK triggers re-transmission

Prof. Sang-Jo Yoo 28 Timer Value  Fixed timer  Based on understanding of network behavior  Can not adapt to changing network conditions  Too small leads to unnecessary re-transmissions  Too large and response to lost segments is slow  Should be a bit longer than round trip time  Adaptive scheme  Sets its retransmission timer based on the average of the observed delay : but, problems …  May not ACK immediately  Can not distinguish between ACK of original segment and re- transmitted segment  Conditions may change suddenly

Prof. Sang-Jo Yoo 29 Duplication Detection  If ACK lost, segment is re-transmitted  Receiver must recognize duplicates  Duplicate received prior to closing connection  Receiver assumes ACK lost and ACKs duplicate  Sender must not get confused with multiple ACKs  Sequence number space large enough to not cycle within maximum life of segment  Duplicate received after closing connection

Prof. Sang-Jo Yoo 30 Incorrect Duplicate Detection Sequence number space large enough to not cycle within maximum life of segment ** maximum life of packet?

Prof. Sang-Jo Yoo 31 Flow Control  Credit allocation  Problem if AN=i, W=0 closing window  Send AN=i, W=j to reopen, but this is lost  Sender thinks window is closed, receiver thinks it is open  Deadlock situation  Use window timer  If timer expires, send something  Could be re-transmission of previous segment

Prof. Sang-Jo Yoo 32 Connection Establishment  Two way handshake  A send SYN, B replies with SYN  Lost SYN handled by re-transmission  Can lead to duplicate SYNs  Ignore duplicate SYNs once connected  Lost or delayed data segments can cause connection problems  Segment from old connections  Start segment numbers fare removed from previous connection  Use SYN i  Need ACK to include i  Three Way Handshake

Prof. Sang-Jo Yoo 33 Two Way Handshake: Obsolete Data Segment

Prof. Sang-Jo Yoo 34 Two Way Handshake: Obsolete SYN Segment

Prof. Sang-Jo Yoo 35 Three Way Handshake: Examples

Prof. Sang-Jo Yoo 36 Three Way Handshake: State Diagram

Prof. Sang-Jo Yoo 37 Connection Termination  Entity in CLOSE WAIT state sends last data segment, followed by FIN  FIN arrives before last data segment (problem)  Receiver accepts FIN  Closes connection  Loses last data segment  Associate sequence number with FIN  Next sequence number after the last octet of transmitted data.  Receiver waits for all segments before FIN sequence number

Prof. Sang-Jo Yoo 38 Graceful Close  Send FIN i and receive AN i  Receive FIN j and send AN j  Wait twice maximum expected segment lifetime

Prof. Sang-Jo Yoo 39 TCP & UDP  Transmission Control Protocol  Connection oriented  RFC 793  User Datagram Protocol (UDP)  Connectionless  RFC 768

Prof. Sang-Jo Yoo 40 TCP Services  Reliable communication between pairs of processes  Across variety of reliable and unreliable networks and internets  Two labeling facilities  Data stream push  TCP user can require transmission of all data up to push flag  Receiver will deliver in same manner  Avoids waiting for full buffers  Urgent data signal  Indicates urgent data is upcoming in stream  User decides how to handle it

Prof. Sang-Jo Yoo 41 TCP Header

Prof. Sang-Jo Yoo 42 TCP  TCP header format  Single type of PDU, called a TCP segment  Fields  Source port( 16 bits )  Destination port( 16 bits )  Sequence number( 32 bits ) Number of first data octet If SYN is present, it is the initial sequence number( ISN ), and the first data octet is ISN+1  Acknowledgment number( 32 bits )  Data offset( 4 bits ) Number of 32-bit words in the header

Prof. Sang-Jo Yoo 43 TCP  Flags( 6 bits ) URG : Urgent pointer field significant ACK : Acknowledgment field significant PSH : Push function RST : Reset function SYN : Synchronize the sequence number FIN : No more data from sender  Window( 16 bits ) Flow control credit allocation in octets  Checksum( 16 bits ) One’s complement of the modulo sum of all the 16-bit words in the segment, plus a pseudo-header  Urgent pointer( 16 bits ) Points to the last octet in a sequence of urgent data.  Options( variable ) Specifies maximum segment size that will be accept

Prof. Sang-Jo Yoo 44 UDP  UDP provides a particular type of service to applications called datagram delivery. Datagram delivery is a connectionless service,  each datagram exists entirely independently of all other datagrams, even datagrams between the same sockets  there is no mechanism that allows a receiver to acknowledge reception of a datagram  there is no reference that can establish a relative ordering of different datagrams

Prof. Sang-Jo Yoo 45 UDP header+data UDP Datagram

Prof. Sang-Jo Yoo 46 UDP Checksum With IPv4, however, a sender could effectively omit the checksum by setting its value to zero. Receivers disregarded the checksum. Pseudo header includes some IP level information. Pseudo header