1 Transport Layer - UDP & TCP Protocols "I cannot teach anybody anything, I can only make them think.” - Socrates

2 Transport Layer - UDP & TCP Protocols  Connectionless & connection-oriented protocols  User Datagram Protocol (UDP)  UDP Datagram Format  Transmission Control Protocol (TCP)  TCP Features and Segment Format  Flow Control Mechanism and Congestion Control  Sections 11.6, 12.5, 12.9, 12.10, will not be discussed

3 Transport Protocols Internet protocol architecture Application Services (FTP, Telnet, SMTP, …) Transport Services (TCP, UDP, SCTP) Connectionless Packet Delivery Service (IP) OSI Layers Layer 4 - Transport Layer 3 - Network TCP - Transmission Control Protocol UDP - User Datagram Protocol SCTP - Stream Control Transmission Protocol

4 Encapsulating TCP/UDP in IP Datagrams Layer 2 Data Link HeaderData Link DataFCS IP HeaderIP Data Layer 3 TCP/UDP Header Application Data Layer 4 FCS: Frame Check Sequence (for error checking)

5 Connection-oriented & Connectionless protocols & services Why are they called connection-oriented and connectionless? What are their distinct characteristics? Why these different protocols are needed? Examples of connection-oriented and connectionless transport protocols

6 Connection-oriented protocols Three phases: –Connection setup –Data transfer –Connection release A connection need to be setup between end points prior to the data transfer Data delivery, integrity and sequencing are guaranteed Connection is released after the data transfer Better suited for applications that require guaranteed delivery, but can tolerate some delays E.g. TCP (Transmission Control Protocol)

7 Connectionless protocols No connection setup necessary prior to data transfer Each datagram is routed independently and can take different paths through the network; therefore datagrams could arrive at the destination out of sequence Best-effort delivery (no guaranteed delivery) No connection release phase after data transfer Less overhead and therefore fast (less delay) Better suited for applications needing low delay but can tolerate some data losses (E.g. voice applications) Examples: IP and UDP (User Datagram Protocol)

8 Transport Protocols How can a connection-oriented transport protocol (like TCP) provide guaranteed data delivery, integrity and sequencing when they have to use connectionless IP at the network layer?

9 Transport Protocols The connection-oriented transport protocol (like TCP) has to implement additional procedures at the transport layer for ensuring data delivery, integrity and sequencing This is at the cost of more overhead and processing time (thus slower than connectionless protocols)

10 User Datagram Protocol (UDP) - RFC 768 Provides a minimal, simple, and best-effort transport layer protocol, as some applications do not require the robustness of TCP Provides a connection-less service to applications –Reliable data delivery or delivery of data in the correct sequence are not guaranteed Faster and more efficient than TCP Examples of applications using UDP: –DNS (Domain Name System) –SNMP (Simple Network Management Protocol)

11 UDP Datagram Format Source PortDestination Port Checksum Data Length ………. Bits Source & destination ports: identifies the source and destination processes/applications Length: length of the UDP datagram (including header and data) in bytes Checksum: Covers the UDP header and data; Optional (with value set to 0, if not computed)

12 Port Numbers Defined in three ranges: Well-known ports ( ) Defined in the “Assigned Numbers” RFC Assigned to core services that systems offer E.g. Telnet - Port 23, FTP Control data - Port 21 Registered ports ( ) Assigned to industry applications and processes E.g. Microsoft SQL Server process - Port 1433 Dynamic (or, ephemeral) ports ( ) Can use as temporary ports without being assigned

13 TCP Features Defined in RFC 793 (RFC 1122 contains some corrections) Various enhancements proposed in subsequent RFCs Connection oriented protocol (needs specific connection set up & release) Provides end-to-end (i.e., between hosts) reliable, sequenced delivery of data segments –Checksum covering header & payload –End to end acknowledgements –Retransmissions Flow control using a sliding window mechanism Congestion control (detection & avoidance)

14 Ports, Connections & End points A “port number” identifies an application process An “end point” is identified by IP Address & Port (called a TCP socket) A “connection” is identified by two end points (two sockets) App A TCP IP TCP IP App A App B TCP connection A TCP connection B Ports

15 TCP Segment Format Source PortDestination Port Sequence Number Ack Number Checksum Data Urgent Pointer PaddingOptions (if any) ………. Code bitsHLenResvdWindow Size Bits The basic unit of data transferred by TCP to IP is a “segment”

16 TCP Segment fields... Source & destination ports: identifies the source and destination processes or applications Ack number: indicates the sequence number of the next expected data octet by the receiver. –Acknowledges receipt of all data bytes up to byte sequence number = (Ack number - 1) –TCP Acks are cumulative (i.e., one Ack may acknowledge receipt of data in several consecutive segments)

17 TCP Segment fields... Sequence number: indicates the sequence number of the first byte in the segment HLen (or, Data Offset): Number of 32-bit words in the TCP header. The typical value is 5 (20 bytes of header, if Options are not used) Window: indicates the number of bytes the receiver is prepared to accept from the sender (called rwnd). This reflects free buffer space available at the receiver. Checksum: Covers the TCP header and data; Mandatory in TCP.

18 TCP Segment fields... Urgent Pointer: –Used to deliver urgent data to the application at the receiver, ahead of any other received data that are buffered (jumping the queue) –Indicates the position of the last byte of urgent data –Valid only when URG = 1 in the Code (or, Flags) bits Options: –One of the options is Max. Segment Size (MSS). –If used, MSS is indicated only at the connection set up –If not specifically announced, a default segment size of 536 bytes is assumed

19 TCP Code bits URGACKPSHRSTSYNFIN URGUrgent Pointer field is valid ACKAck field is valid PSHThis segment requests a “Push” RSTReset the connection SYNSynchronize the sequence numbers FINNo more data from sender

20 Connection Establishment 3-way handshake Both sides agree on initial sequence numbers Two data streams (one in each direction) are established Host AHost B Send SYN; Seq = x Receive SYN Send SYN; Seq = y Ack = x+1 Receive SYN + ACK Send Ack = y+1 Receive ACK Time

21 Connection Release Each direction is shut down independently Host AHost B Send FIN; Seq = x Receive FIN Send Ack = x+1 Inform application Receive ACK Send Ack = y+1 Receive ACK Time Application closes connection App closes connection Send FIN; Seq = y; Ack = x+1 Receive FIN + ACK Connection half closed...B can still send data... Connection fully closed...

22

23 Data Transfer In a SYN segment, a host may announce the MSS (max. segment size) it expects to receive (default: 536 bytes) In each TCP header, a host indicates how many “bytes” it is ready to accept - “receiver window advertisement (rwnd)”. Sender divides its byte stream into “segments”. Sequence numbers are assigned to each byte. Each TCP segment header carries the Seq # of the first byte in it. When a segment is sent (not to exceed the MSS or the sender’s window size), a “retransmission timer” is started. If an ACK is not received before the timer expiry, the segment is resent.

24 Flow Control Hosts that send and receive TCP data segments can operate at different data rates because of differences in CPU and network bandwidth. A fast sender can overwhelm a slow receiver! TCP implements flow control based on a sliding window mechanism The sender’s window size = min(rwnd, cwnd) cwnd - Congestion Window value is dependent on the current “congestion control” phase of the sending host. cwnd attempts to consider the network congestion in determining the sender’s window size at any given time.

25 TCP’s Sliding Window example... … … … … Receiver’s advertised window (30 bytes) ASent & acked BSent & not acked CCan be sent now, before receiving an ack DCannot be sent until the window moves (i.e., until an ack is received) ABCD

26 Silly Window Syndrome Sending application creating data slowly or the receiving application consuming received data slowly could result in sending of very few number of data bytes in a segment This decreases the efficiency of TCP operation and is called the “Silly Window Syndrome” Eg: If TCP sends segments with only 1 byte of user data, a 41-byte IP packet (with 20 bytes of TCP header + 20 bytes of IP header) will have only have a data delivery efficiency of: (1/41) x > 2.4% (without even considering data link header + trailer overhead)

27 Syndrome created by Sender Sending application may create data slowly (eg: 1 byte at a time) and sending TCP may create segments containing only a single data byte “Nagle’s Algorithm” provides a solution –Sending TCP sends the 1st segment even if it is only 1 byte –After sending the 1st segment, sending TCP accumulates data and waits until, either: Receives an ACK, or Enough data has accumulated to fill a max-size segment

28 Syndrome created by Receiver Receiving application may consume data slowly (eg: 1 byte at a time) and receiver-side TCP may announce a window size of 1 byte (or, a very small window size), resulting in sender creating very small segments Two solutions: Clark’s Solution & Delayed ACKs Clark’s solution: –Send an ACK as soon as data is received, but announce a window size of 0 until, either: there is enough buffer space to accommodate a segment of max size, or half of the buffer is empty

29 Delayed ACKs When a segment is received, don’t send an ACK immediately Receiver waits until there is sufficient amount of free buffer space before sending an ACK One advantage of Delayed ACKs is reduced traffic (as each segment doesn’t need to be ACKed individually) Disadvantage is, delayed ACKs may force the sender to retransmit unacked segments To minimize retransmissions by sender, receiver should not delay an ACK by more than 500 ms.

30 Selective ACKs ( RFC 2018 ) Allows a receiver to inform the sender a list of duplicate segments and lists of out-of-order segments received in the “Options” field Sender can selectively retransmit only the missing segments During connection setup phase, the two TCP hosts agree whether they support this feature using “SACK- permitted” option SACKs improve TCP performance in congested networks or networks with unreliable links

31 Fast Retransmission (RFC 2581) Originally, TCP was designed to discard out-of-order segments by the receiving host. Most implementations today store out-of-order segments until the missing segment arrives. When an out-of-order segment is received with a seq # higher than the expected seq #, receiver immediately sends an ACK, announcing the seq # of the next expected segment. When the sender receives 4 ACKs with the same value (i.e., 3 duplicate ACKs), it retransmits the segment expected by the receiver without waiting for Retransmission Timer expiry.

32 Figure Fast retransmission

33 TCP Congestion Control Congestion in a network happens when the input traffic rate is greater than the traffic processing rate of network nodes for consistently long periods of time To recover from congestion, traffic input rate needs to be reduced by the sending hosts TCP handles congestion using following mechanisms (RFC 2581): –Slow start –Congestion Avoidance –Congestion detection

34 Slow-Start Phase At the beginning of data transfer phase, sending host probes the status of the network to find out whether the network is already congested or not Sender starts with cwnd = 1 or 2 MSS For each acknowledged segment, cwnd is increased by 1 MSS. cwnd is increased in this manner until a threshold (called “ssthresh - slow start threshold”) is reached In most implementations, “ssthresh” is bytes Increase of cwnd in the slow-start phase is exponential until the ssthresh is reached

35 Figure Slow start, exponential increase

36 Congestion Avoidance Phase Congestion Avoidance Phase: –Starts when cwnd in the slow-start phase reaches ssthresh threshold –To slow down the exponential increase of cwnd, each time the “whole window of segments” is acknowledged, cwnd is increased by 1 MSS. –cwnd is increased additively in this manner until congestion is detected

37 Figure Congestion avoidance, additive increase

38 Congestion Detection Phase When a sender has to retransmit a segment, it is considered as a sign of network congestion In most implementations, if the congestion detection is due to: –“Retransmission Timer expiry”, a new slow-start phase is started –“Receipt of 3 duplicate ACKs”, a new congestion avoidance phase is started

39 Figure Congestion example