Transport Layer - UDP & TCP Protocols

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, 12.11 will not be discussed

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

4. Encapsulating TCP/UDP in IP Datagrams Layer 4 TCP/UDP Header Application Data Layer 3 IP Header IP Data Layer 2 Data Link Header Data Link Data FCS 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. Bits 0 15 16 31 Source Port Destination Port Length Checksum Data ………. UDP Datagram Format • 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 (0 - 1023) • 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 (1024 - 49151) • Assigned to industry applications and processes • E.g. Microsoft SQL Server process - Port 1433 • Dynamic (or, ephemeral) ports (49152 - 65535) • 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. App A App B App A Ports App B TCP TCP IP IP TCP connection A TCP connection B 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)

15. Bits 0 15 16 31 Source Port Destination Port Sequence Number Ack Number HLen Resvd Code bits Window Size Checksum Urgent Pointer Options (if any) Padding Data ………. TCP Segment Format 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. URG ACK PSH RST SYN FIN TCP Code bits URG Urgent Pointer field is valid ACK Ack field is valid PSH This segment requests a “Push” RST Reset the connection SYN Synchronize the sequence numbers FIN No more data from sender

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

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

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. Receiver’s advertised window (30 bytes) … 17 18 19 20 21 …. 29 30 31 …. 49 50 51 … A B C D A Sent & acked B Sent & not acked C Can be sent now, before receiving an ack D Cannot be sent until the window moves (i.e., until an ack is received) TCP’s Sliding Window example ...

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 100 --> 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 12.27Fast 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-StartPhase • 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 65535 bytes • Increase of cwnd in the slow-start phase is exponential until the ssthresh is reached

35. Figure 12.33Slow start, exponential increase

36. Congestion AvoidancePhase • 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 12.34Congestion avoidance, additive increase

38. Congestion DetectionPhase • 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 12.36Congestion example