Transport Layer Protocols: TCP and UDP

Transport Layer Overview

• The goal of the transport layer is to understand the principles behind transport layer services like multiplexing, demultiplexing, reliable data transfer, flow control, and congestion control
• Focus on learning about Internet transport layer protocols like UDP (connectionless) and TCP (connection-oriented reliable transport), including TCP congestion control.
• Transport-layer services provide logical communication between application processes running on different hosts.
• Transport protocols' actions in end systems involve the sender breaking application messages into segments for the network layer, and the receiver reassembling segments into messages for the application layer.
• Two transport protocols available to Internet applications are TCP and UDP

Transport vs. Network Layer Services

• The transport layer focuses on communication between processes, relying on and enhancing network layer services.
• Network layer focuses on communication between hosts
• Sender actions involve receiving an application-layer message, determining segment header field values, creating segment, and passing it to the IP.
• Receiver actions involve receiving segment from IP, checking header values, extracting application-layer message and demultiplexing message up to application via socket.

Internet Transport Protocols

• TCP (Transmission Control Protocol) offers reliable, in-order delivery with congestion control, flow control, and connection setup.
• UDP (User Datagram Protocol) provides unreliable, unordered delivery as a no-frills extension of best-effort IP, without delay or bandwidth guarantees

Multiplexing/Demultiplexing

• Multiplexing involves handling data from multiple sockets and adding a transport header, used later for demultiplexing.
• Demultiplexing uses header information to deliver received segments to the correct socket.
• The host uses IP addresses and port numbers to direct a segment to the appropriate socket by checking the source and destination port numbers.

Connectionless Demultiplexing

• When creating a socket, a host-local port number must be specified.
• When a receiving host receives a UDP segment, it checks the destination port number, and directs the UDP segment to the socket with that port number.
• IP/UDP datagrams with the same destination port number, but different source IP addresses and/or source port numbers direct to the same socket at the receiving host.

Connection-oriented Demultiplexing

• TCP socket is identified by a 4-tuple: source IP address, source port number, destination IP address, destination port number.
• A server supports simultaneous TCP sockets, each identified by its own 4-tuple and associated with a different connecting client.
• Demultiplexing uses all four values (4-tuple) to direct a segment to the appropriate socket.

Multiplexing/Demultiplexing Summary

• Multiplexing/demultiplexing is based on segment/datagram header field values.
• UDP uses the destination port number only for demultiplexing.
• TCP uses a 4-tuple: source and destination IP addresses, and port numbers for demultiplexing
• Multiplexing/demultiplexing happen at all layers.

UDP: User Datagram Protocol

• UDP is a no-frills Internet transport protocol, offering best-effort service where segments may be lost or delivered out-of-order.
• There is no connection establishment which reduces delay, and the header size is small
• UDP does not have congestion control, allowing it to transmit as fast as desired.

Why Use UDP?

• UDP is connectionless, and each segment is handled independently
• It is used for streaming multimedia apps (loss tolerant, rate sensitive), DNS, SNMP and HTTP/3
• Reliable transfer can be added to UDP connections at the application layer with congestion control

UDP Transport Layer Actions

• Sender actions involve receiving an application-layer message, determining UDP segment header fields values, creating UDP segment, and passing segment to IP.
• Receiver actions involve receiving segment from IP, checking UDP checksum header value, extracting application-layer message and demultiplexing message up to application via socket

UDP Segment Header

• Contains source port #, dest port #, length, and checksum
• Length is in bytes of UDP segment, including header

UDP Checksum

• The goal is to detect errors (i.e., flipped bits) in a transmitted segment
• Sender treats contents of UDP segment (including UDP header fields and IP addresses) as sequence of 16-bit integers
• Checksum: addition (one’s complement sum) of segment content and the checksum value put into UDP checksum field

Steps For Receiver

• Compute checksum of received segment
• Check if the computed checksum equals checksum field value, if not equal an error is detected
• If equal no error is detected

UDP Summary

• Segments may be lost, delivered out of order
• A best effort service, to "send and hope for the best."
• There is no setup/handshaking needed and it helps with reliability (checksum).
• Additional functionality can be built on top of UDP in application layer (e.g., HTTP/3).

Principles of Reliable Data Transfer

• Reliable data transfer provides a reliable service abstraction to the application layer.
• The complexity of the reliable data transfer protocol depends strongly on the characteristics of the unreliable channel and whether it loses, corrupts, or reorders data.
• Sender and receiver do not automatically know the "state" of each other, for example, whether a message was received.

Reliable Data Transfer Protocol Interfaces

• rdt_send(): Called from above (e.g., by app.) and passed data to deliver to receiver upper layer.
• udt_send(): Called by rdt to transfer packet over unreliable channel to receiver.
• rdt_rcv(): Called when packet arrives on receiver side of channel.
• deliver_data(): Called by rdt to deliver data to upper layer.

Reliable Data Transfer: Getting Started

• Sender and receiver sides of reliable data transfer protocol (rdt) are developed incrementally.
• Finite state machines (FSM) are used to specify sender and receiver.

rdt1.0: Reliable Transfer Over a Reliable Channel

• The underlying channel is perfectly reliable, with no bit errors and no loss of packets
• With separate FSMs for sender and receiver, the sender sends data into underlying channel and receiver reads data from underlying channel.

rdt2.0: Channel With Bit Errors

• The underlying channel may flip bits in packet
• Checksum to detect bit errors is used for error recovery
• Acknowledgements (ACKs) are when the receiver explicitly tells sender that pkt received OK
• Negative acknowledgements (NAKs) are when receiver explicitly tells sender that pkt had errors
• The sender retransmits pkt on receipt of NAK in a stop and wait manner (sends one packet, then waits for receiver response)

rdt2.0 Fatal Flaw

• If ACK/NAK is corrupted, the sender doesn’t know what happened at receiver and cannot retransmit, leading to possible duplicates.
• Sender retransmits current pkt if ACK/NAK corrupted, and adds sequence number to each pkt to handle duplicates.
• Receiver discards (doesn’t deliver up) duplicate pkt using stop and wait.

rdt2.1: Sender, Handling Garbled ACK/NAKs

• Sender adds seq # to pkt, with two seq. #s (0,1).
• Must check if received ACK/NAK corrupted, and has twice as many states.
• Receiver must check if received packet is duplicate, and state indicates whether 0 or 1 is expected pkt seq #.
• Receiver can not know if its last ACK/NAK received OK at sender.

rdt2.2: A NAK-Free Protocol

• Same functionality as rdt2.1, using ACKs only
• Instead of NAK, receiver sends ACK for last pkt received OK
• Receiver must explicitly include seq # of pkt being ACKed
• Duplicate ACK at sender results in same action as NAK: retransmit current pkt
• TCP uses this approach to be NAK-free

rdt3.0: Channels With Errors and Loss

• Assumes the underlying channel can lose packets (data, ACKs).
• Checksum, sequence #s, ACKs, retransmissions are used
• Sender waits “reasonable” time for ACK, retransmits if no ACK received in this time.
• Retransmission will be duplicate if pkt (or ACK) just delayed (not lost), but seq #s already handles this, while receiver must specify seq # of packet being ACKed

Timeout

• Use of countdown timer to interrupt after “reasonable” amount of time

rdt3.0 Performance

• 1 Gbps link, 15 ms prop. delay, 8000 bit packet

Sender Utilization

• Protocol limits performance of underlying infrastructure (channel)

rdt3.0: Pipelined Protocols Operation

• Pipelining allows the sender multiple, “in-flight”, yet-to-be-acknowledged packets.
• Range of sequence numbers must be increased.
• Buffering occurs at sender and/or receiver.

Pipelining

• Sender allows multiple in-flight, yet-to-be-acknowledged packets
• Range of sequence numbers must be increased
• Buffering at sender and/or receiver

Go-Back-N Sender

• Sender uses "window" of up to N, consecutive transmitted but unACKed pkts, k-bit seq # in pkt header.
• Cumulative ACK: ACK(n) ACKs all packets up to, including seq # n.
• Receiving ACK(n), the window moves forward to begin at n+1.
• Timeout: retransmit packet n and all higher seq # packets in window

Go-Back-N Receiver

• ACK-only: always send ACK for correctly-received packet so far, with highest in-order seq #.
• May generate duplicate ACKs and needs only to remember rcv_base.
• If out-of-order packet is received either discard or buffer it, and re-ACK pkt with highest in-order seq #.

Selective Repeat

• Multiple packets can be in flight
• The receiver individually ACKs all correctly received packets and buffers packets as needed, for in-order delivery to upper layer.

Sender

• Maintains a timer for each unACKed pkt and retransmits the single unACKed packet associated with timeout
• Maintains a "window" over N consecutive seq #s, and limits pipelined, “in flight” packets to be within this window

Receiver

• Upon arrival of packet n in [rcvbase, rcvbase+N-1], send ACK(n), and buffer out-of-order packets.
• Deliver in-order packets (also buffered) and advance window to next not-yet-received packet.
• A packet n in [rcvbase-N,rcvbase-1] should be ACK(n); for other packets, ignore

TCP: Overview

• TCP provides cumulative ACKs and pipelining, with congestion and flow control to set window size.
• It is connection-oriented, using handshaking to initialize sender/receiver state before data exchange and enforcing flow control to prevent overwhelming the receiver.
• It is point-to-point with reliable, in-order byte stream (no message boundaries), full duplex data (bidirectional data flow in same connection), and MSS (maximum segment size).

TCP Segment Structure

• Includes Source Port #, Dest Port #, Sequence Number, Acknowledgement Number, Receive Window, Checksum, Urgent Data Pointer and Options
• Receive Window: Flow control is indicated by the # of bytes that the receiver is willing to accept
• Acknowledgement Number: Sequence number of the next expected byte; the A bit indicates this is an ACK
• Includes flags for connection management (RST, SYN, FIN) and congestion notification (C, E).

TCP Sequence Numbers, ACKs

• Sequence numbers represent the byte stream "number" of the first byte in segment’s data.
• Acknowledgements indicate the seq # of next byte expected from other side (cumulative ACK).
• TCP spec doesn’t say how the receiver handles out-of-order segments
• The TCP connection has currently estimated RTT of 30 ms with a deviation of 3 ms, the value of the retransmission timer after the next acknowledgement coming in after 28 ms should be 40.5 ms.

EstimatedRTT = (1- α)EstimatedRTT + αSampleRTT DevRTT = (1-β)DevRTT + β|SampleRTT-EstimatedRTT|

TCP Round Trip Time

• TCP timeout value should be longer than RTT (which varies).
• Too short would causes premature timeout resulting in unnecessary retransmissions and vice versa
• SampleRTT calculation measures time from segment transmission until ACK receipt, ignoring retransmissions where SampleRTT will vary, wanting estimated RTT (smoother)
• To find estimated RTT, average several recent measurements, not just current SampleRTT.

TCP Round Trip Time, Timeout Interval

• TimeoutInterval = EstimatedRTT + 4*DevRTT (estimated RTT + "safety margin")
• DevRTT = (1-β)DevRTT + β|SampleRTT-EstimatedRTT| ("safety margin" is EWMA of SampleRTT deviation from EstimatedRTT)

TCP Sender Simplified

• The sender receives data from application and it creates segment with the sequence number of first data byte in segment and it starts timer if not already running.
• On timeout, retransmit the segment that caused timeout and restart timer.
• If ACK received acknowledges previously unACKed segments, update what is known to be ACKed and start timer if there are still unACKed segments.

TCP Receiver & ACK Generation

TCP Retransmission Scenarios

Receipt of three duplicate ACKs:

• Indicates 3 segments received after a missing segment which means the lost segment is likely
• Resend unACKed segment with smallest seq # for TCP fast retransmit

TCP Flow Control

• Prevents sender from overflowing receiver's buffer by transmitting too much, too fast, where network layer delivers data faster than application removes data from socket buffers.
• TCP receiver "advertises" free buffer space in rwnd field in TCP header, and the sender limits amount of unACKed (“in-flight”) data to received rwnd, guaranteeing receive buffer will not overflow

TCP Connection Management

• Sender/receiver "handshake" before exchanging data to agree to establish connection (each knowing the other willing to establish connection) and agree on connection parameters.
• Connection state: ESTAB; Connection variables: seq # client-to-server, server-to-client, rcvBuffer size,at server,client

Agreeing to Establish a Connection

2-way handshake:

• Causes problem: half open connection and dup data
• Is solved with 3-way handshake

TCP 3-Way Handshake

• SYNbit=1, Seq=x: choose init seq num, x, send TCP SYN msg
• SYNbit=1, Seq=y, ACKbit=1; ACKnum=x+1: choose init seq num, y, send TCP SYNACK msg, acking SYN
• ACKbit=1, ACKnum=y+1: received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data

Closing a TCP Connection

• Client/server each close their side of connection by sending TCP segment with FIN bit = 1 and respond to received FIN with ACK where on receiving FIN, ACK can be combined with own FIN.
• Simultaneous FIN exchanges can be handled.