William Stallings Data and Computer Communications Chapter 17 Transport Protocols

Transport Protocol - Summary Provides end-to-end data transfer Shields upper layer application protocols from the details of networks TCP: complicated flow and error control since the underlying network service (IP) is unreliable TCP is connection oriented UDP is connectionless

Connection Oriented Transport Protocol Mechanisms Logical connections between end users Establishment Maintenance Termination Reliable service e.g. TCP

Connection Oriented Transport Protocol Mechanisms TCP is complex because of IP, which is unreliable Let’s assume the underlying network service is reliable (for simplicity) frame relay (LAPF control protocol) 802.3 LAN with connection oriented LLC

Flow Control Transport level flow control is more difficult than link-level one transmission delay is variable due to network. That makes difficult to use timeouts Recall from link level flow control Backpressure clumsy and coarse grained Sliding window protocols Works well on reliable network Failure to receive ACK is taken as flow control indication Does not work well on unreliable network Can not distinguish between lost segment and flow control Credit scheme

Credit Scheme Decouples flow control from ACK May ACK without granting credit and vice versa Each octet has a sequence number Each transport segment has a header that contains sequence number ack number window size

Use of Header Fields When sending ACK includes AN=i, W=j seq. number (SN) of first octet in segment is included ACK includes AN=i, W=j All octets through SN=i-1 are acknowledged Next expected octet is i Permission to send additional window of W=j octets i.e. octets through i+j-1

Credit Allocation (Example)

Connection Establishment and Termination Necessary even with a reliable network services Purposes Allow each end to know the other exists Negotiation of optional parameters Triggers allocation of transport entity resources Connection establishment is by mutual agreement control messages are exchanged

Connection State Diagram

Connection Establishment

Not Listening What happens if SYN comes when the receiver is in CLOSED state 3 options Reject with RST (Reset) command Request is queued until matching OPEN is issued Notify upper layer about the pending request

Termination Either side may initiate termination By mutual agreement Graceful termination FIN WAIT state must accept incoming data until FIN received

Side Initiating Termination TS user issues Close request Transport entity sends FIN, requesting termination Connection placed in FIN WAIT state Continue to accept data and deliver data to user Do not send any more data When FIN received, inform user and close connection

Side Not Initiating Termination FIN received Inform TS user and place connection in CLOSE WAIT state Continue to transmit data TS user issues CLOSE primitive Transport entity sends FIN Connection closed This procedure ensures that both sides received all outstanding data both sides agree to terminate

Unreliable Network Service E.g. internet using IP, frame relay using LAPF core protocol IEEE 802.3 using unacknowledged connectionless LLC Segments may get lost Segments may arrive out of order variable transit delays Solutions will create other problems

Problems Ordered Delivery Retransmission strategy Duplication detection Flow control Connection establishment Connection termination

Ordered Delivery Segments may arrive out of order General solution: number data units sequentially TCP numbers each octet sequentially implicit numbering Segments are numbered by the first octet number in the segment

Retransmission Strategy Segment may be damaged while in transit Segment may fail to arrive Positive acknowledgment: receiver must acknowledge successful receipt Cumulative acknowledgment can be used several segments can be acknowledged in one ack message Waiting ACK for a long period of time (timeout period) triggers re-transmission

Timer Value Fixed timer Adaptive scheme: average round-trip delay Based on typical network behavior Can not adapt to changing network conditions “Too small” leads to unnecessary re-transmissions “Too large” causes slow response to lost segments Should be a bit longer than round trip time (but this is not fixed) Adaptive scheme: average round-trip delay May not ACK immediately (cumulative ack) Conditions may change suddenly No complete solution

Duplication Detection If ACK lost, segments are re-transmitted Receiver must recognize duplicates Duplicate may arrive before the original one Duplicate received prior to closing connection Receiver assumes that ACK is lost and send ACK for the duplicate Sender must not get confused with multiple ACKs for the same segment Sequence number space large enough to not cycle within maximum life of segment Duplicate received after closing connection

Incorrect Duplicate Detection Sequence space is 1600 Sliding window with window size of 600

Flow Control Credit allocation scheme is quite robust and flexible it is possible to increase credit without ack after (AN = i, W = j), (AN = i, W = k), k >j it is possible to ack without extra credit after (AN = i, W = j), (AN =i + m, W = j - m), m: acked segment length Lost ACK/CREDIT is generally no problem future acks resynchronize the protocol lost ack causes timeout and retransmission retransmission triggers ack but deadlock is still possible

Flow Control Possible deadlock case receiver temporarily closes window with AN=i, W=0 later reopens with AN=i, W=j, but this is lost Sender thinks window is still closed, receiver thinks it is open SOLUTION: use window timer timer for ACK/CREDIT segments timer expires if no ACK/CREDIT segments are received within the timeout period if timer expires, retransmit the previous ACK/CREDIT segment

Connection Establishment Two way handshake A send SYN, B replies with SYN Lost SYN handled by re-transmission (special timer) Can lead to duplicate SYNs Ignore duplicate SYNs once connected Lost or delayed data segments can cause connection problems Segment from old connections (see next figure)

Two Way Handshake: Obsolete Data Segment

Solution to Obsolete Data Segment Problem First segment number of the new connection must be distant from the last segment number of the previous connection Need to specify the expected sequence numbers of the connections Use SYN i i is the sequence number of the first segment on that connection acknowledged by SYN j New Problem: Obsolete SYN (see next figure)

Two Way Handshake: Obsolete SYN Segment

Solution to Obsolete SYN Problem Acknowledgments should also include the request’s SYN number (AN=i) Three Way Handshake Second ack is actually a data segment

Three Way Handshake: State Diagram

Connection Termination Entity in CLOSE WAIT state sends last data segment, followed by FIN FIN arrives before last data segment Receiver accepts FIN Closes connection Loses last data segment Add sequence number (number just after the last transmitted octet) to FIN Receiver waits for all segments before FIN sequence number

Connection Termination Graceful close Send FIN i and receive AN i Receive FIN j and send AN j Wait twice maximum expected segment lifetime FIN i FIN i AN i AN i, FIN j FIN j AN j AN j

TCP & UDP Transmission Control Protocol User Datagram Protocol (UDP) Connection oriented RFC 793 User Datagram Protocol (UDP) Connectionless RFC 768

TCP Reliable communication between pairs of processes Variety of primitives Passive/Active open Send / Deliver data Close primitives Connections are identified by a pair of sockets a socket is (IP address, port number) ports less than 1024 are fixed e.g. 23 telnet, 80 www others are at operating systems disposal for individual needs

TCP Header

TCP Header Checksum includes IP addresses as well in a pseudo-header check misdelivery spoils protocol hierarchy Question: What about segment length? It is not in the TCP header. How is the receiver TCP user be informed about the payload length?

TCP Mechanisms (1) Connection establishment Three way handshake Between pairs of ports One port can connect to multiple destinations

TCP Mechanisms (2) Data transfer Logical stream of octets Octets numbered modulo 232 Segments contain sequence number of the first octet Flow control by credit allocation of number of octets Data buffered at transmitter and receiver TCP decides when to construct a segment exception is PUSH RST is sent when obsolete and duplicate SYNs are received TCP segment is misdelivered

TCP Mechanisms (3) Connection termination Graceful close TCP users issues CLOSE primitive Transport entity sets FIN flag on last segment sent Abrupt termination by ABORT primitive Entity abandons all attempts to send or receive data RST segment transmitted

Implementation Policy Options Send Deliver Accept Retransmit Acknowledge

Send If no push or close TCP entity transmits at its own convenience Data buffered at transmit buffer May construct segment per data batch May wait for certain amount of data Trade-off infrequent and large segments low processing overhead, slow response frequent and small segments quick response, but high processing overhead

Deliver In absence of push, TCP delivers data at its own convenience May deliver as segments are received May buffer several segments and then deliver Performance trade-off response time versus processing overhead/interrupts

Accept Segments may arrive out of order In order In windows Only accept in-order segments Discard out-of-order segments easy implementation, simple lots of retransmissions In windows Accept all segments within receive window complicated large buffers less retransmissions

Retransmit TCP will retransmit if does not receive ACK in given time First only single timer for all segments waiting ack if expires the oldest segment waiting ack is retransmitted longer delays for the other segments Batch if expires all segments waiting ack are retransmitted smaller delays but unnecessary retransmissions Individual one timer per segment complex implementation

Acknowledgment Immediate Cumulative limits unnecessary retransmissions increase the load by acks Cumulative typical method problem in estimating timer values

Retransmission Timer Management Estimate round trip time (RTT) by observing pattern of delay Set time to value a bit greater than estimate Simple average average the RTTs over a number of segments Exponential average later segments have more weight smaller  means greater weight to the last RTT

Use of Exponential Averaging

How to determine RTO (Retransmission Timeout) Add fixed  to estimated RTT Multiply estimated RTT with a fixed factor Both not good if the observed RTT has variation It is better if the RTO depends on the estimated RTT and standard deviation in RTT Jacobson’s method

Jacobson’s RTO Calculation Exp. Average is not good if variation is too much RTT Variance Estimation (Jacobson’s algorithm) Includes standard deviation in the calculations f: the factor that effects RTO

Exponential RTO Backoff What RTO will be used for a retransmitted segment? Since timeout is probably due to congestion (dropped packet or long round trip), maintaining the same RTO is not good idea RTO increased each time a segment is re-transmitted RTO = 2*RTO Binary exponential backoff

Karn’s Algorithm If a segment is retransmitted, the ACK arriving may be: For the first copy of the segment RTT longer than expected For second copy No way to tell Karn’s rules Do not measure RTT for retransmitted segments Calculate backoff when re-transmission occurs Use backoff RTO until ACK arrives for segment that has not been re-transmitted

Window Management (1) Slow start It is not a good idea to start with a large window since the network situation is not known Start connection with a small window (to fit one segment only) Enlarge window at each ACK, to some max Actually not a slow procedure window growth is exponential

Window Management (2) Dynamic windows sizing on congestion When a timeout occurs Run a slow start until a threshold threshold = half of the current window at which timeout occurred. Increasing window size by 1 segment for every ACK After threshold, increase window by one segment for each RTT linear increase in window size

UDP User datagram protocol RFC 768 Connectionless service for application level procedures Unreliable Delivery and duplication control not guaranteed Reduced overhead

UDP Uses Applications for which the loss of an occasional data does not cause too much problems Inward data collection periodic reports real-time monitoring Outward data dissemination real-time clock Real time application e.g. video

UDP Header