Transport Layer Reliability and Protocol Principles

Transport Layer: Principles and Reliability Overview

• The primary goals of the transport layer involve understanding the principles behind various services:   - Multiplexing and Demultiplexing   - Reliable Data Transfer   - Flow Control   - Congestion Control

• Major Internet transport layer protocols studied include:   - UDP: Connectionless transport.   - TCP: Connection-oriented reliable transport, including TCP congestion control.

Transport Services and Protocols

• Definition: Transport protocols provide logical communication between application processes running on different hosts.

• Network Context: This occurs over various infrastructures such as mobile networks, home networks, enterprise networks, national/global ISPs, regional ISPs, data centers, and content provider networks.

• End System Actions:   - Sender: Breaks application messages into segments and passes them to the network layer.   - Receiver: Reassembles segments into messages and passes them to the application layer.

• Internet Availability: Two primary protocols are TCP and UDP.

Transport Layer Actions: Sender and Receiver

• Sender-Side Actions:   - Receives an application-layer message.   - Determines segment header field values.   - Creates the segment.   - Passes the segment to the Internet Protocol (IP) at the network layer.

• Receiver-Side Actions:   - Receives the segment from the IP layer.   - Checks header values.   - Extracts the application-layer message.   - Demultiplexes the message up to the application via a socket.

Principal Internet Transport Protocols

• Transmission Control Protocol (TCP):   - Features: Reliable, in-order delivery; congestion control; flow control; connection setup.

• User Datagram Protocol (UDP):   - Features: Unreliable, unordered delivery; no-frills extension of "best-effort" IP.

• Missing Services: Neither protocol provides delay guarantees or bandwidth guarantees.

Multiplexing and Demultiplexing

• Demultiplexing (at Receiver): The process of using header information to deliver received segments to the correct socket.

• Multiplexing (at Sender): The process of handling data from multiple sockets, adding transport headers (used later for demultiplexing).

• Mechanism:   - Each host receives IP datagrams.   - Each datagram contains a source IP address and a destination IP address.   - Each datagram carries one transport-layer segment.   - Each segment contains a source port number and a destination port number.   - The segment format includes 32 bits for the source and destination port numbers, plus application data (payload) and other header fields.

Connectionless Demultiplexing (UDP)

• Socket Creation: When creating a socket, a host-local port number must be specified.   - Example: $DatagramSocket mySocket1 = new DatagramSocket(12534);$

• Receiving Host Actions:   - Checks the destination port number in the segment.   - Directs the UDP segment to the socket associated with that specific port.

• Sending Actions: When creating a datagram, one must specify the destination IP address and destination port number.

• Outcome: IP/UDP datagrams with the same destination port number but different source IP addresses and/or source port numbers will be directed to the same socket at the receiving host.

Connection-Oriented Demultiplexing (TCP)

• TCP Socket Identification: Identified by a 4-tuple comprising:   1. Source IP address   2. Source port number   3. Destination IP address   4. Destination port number

• Server Support: A server may support many simultaneous TCP sockets, each identified by its own 4-tuple and associated with a different connecting client.

• Demux Process: The receiver uses all four values in the 4-tuple to direct the segment to the appropriate socket.

User Datagram Protocol (UDP) - RFC 768

• Nature: "No frills," "bare bones," "best effort" service.

• Characteristics:   - Segments may be lost or delivered out-of-order.   - Connectionless: No handshaking between sender and receiver; each segment handled independently.   - Advantages: No connection establishment (removes RTT delay); simple (no state at sender/receiver); small header size; no congestion control (can send as fast as desired and function during congestion).

• Applications:   - Streaming multimedia (loss tolerant, rate sensitive).   - Domain Name System (DNS).   - Simple Network Management Protocol (SNMP).   - HTTP/3.

• Reliability in UDP: If reliability or congestion control is needed (as in HTTP/3), it must be added at the application layer.

• UDP Segment Header:   - 32 bits wide.   - Fields: Source port #, Dest port #, Length (including header and data in bytes), and Checksum.

Internet Checksum

• Goal: Detect errors (flipped bits) in the transmitted segment.

• Sender Actions:   - Treats segment contents (including header and IP addresses) as a sequence of 16-bit integers.   - Computes the checksum using one's complement sum of the segment content.   - Places the resulting value in the UDP checksum field.

• Receiver Actions:   - Computes the checksum of the received segment.   - Checks if the computed sum equals the checksum field value.   - If NOT equal: Error detected.   - If equal: No error detected (though it is possible for errors to exist that the checksum doesn't catch).

• Addition Rule: When adding numbers, any carryout from the most significant bit must be added to the result (wraparound).   - Example:     - Add two 16-bit integers.     - If sum results in a carry, it is wrapped around.     - Checksum is the 1's complement of the sum.

Principles of Reliable Data Transfer (rdt)

• Overview: The complexity of an rdt protocol depends on the characteristics of the unreliable channel (whether it loses, corrupts, or reorders data).

• Interfaces:   - $rdt\_send()$: Called from above (application) to pass data to the transport layer.   - $udt\_send()$: Called by rdt to transfer packets over the unreliable channel.   - $rdt\_rcv()$: Called when a packet arrives at the receiver side.   - $deliver\_data()$: Called by rdt to deliver data to the upper layer.

• Methodology: Use Finite State Machines (FSM) to specify sender and receiver logic.

Evolution of Reliability Protocols

rdt 1.0: Reliable Transfer over a Reliable Channel

• Assumptions: Underlying channel is perfectly reliable (no bit errors, no loss).

• FSM:   - Sender: Waits for call from above; $make\_pkt(data)$ and $udt\_send(packet)$.   - Receiver: Waits for call from below; $extract(packet, data)$ and $deliver\_data(data)$.

rdt 2.0: Channel with Bit Errors

• Assumptions: Channel may flip bits; uses checksum for detection.

• Recovery Mechanism: Stop-and-Wait Protocol.   - Acknowledgements (ACKs): Receiver tells sender the packet was received OK.   - Negative Acknowledgements (NAKs): Receiver tells sender the packet had errors.   - Action: Sender retransmits packet upon receipt of NAK.

• Flaw: If the ACK or NAK itself is corrupted, the sender doesn't know the state of the receiver.

rdt 2.1: Handling Corrupted ACKs/NAKs

• Solution: Sender adds a sequence number to each packet.

• Sequence Numbers: For Stop-and-Wait, sequence numbers $0$ and $1$ suffice.

• Logic:   - If ACK/NAK is garbled, sender retransmits the current packet.   - Receiver checks sequence numbers to detect and discard duplicate packets.   - Receiver must be in a state to "remember" whether it expects sequence $0$ or $1$.

rdt 2.2: A NAK-free Protocol

• Mechanism: Instead of NAKs, the receiver sends an ACK for the last correctly received packet.

• Logic: A duplicate ACK (e.g., receiving ACK 0 when expecting ACK 1) acts as a NAK, triggering the sender to retransmit the current packet.

rdt 3.0: Channels with Errors and Loss

• Assumption: Channel can lose packets (data or ACKs).

• Solution: Sender waits a "reasonable" amount of time for an ACK.

• Countdown Timer: Sender starts a timer when sending; if no ACK is received before timeout, the packet is retransmitted.

• Duplicate Handling: Retransmissions caused by delays rather than loss are handled by sequence numbers.

Performance of rdt 3.0 (Stop-and-Wait)

• Utilization Analysis Example:   - Link Speed ($R$): $1\,Gbps = 10^9\,bits/sec$   - Propagation Delay ($d_{prop}$): $15\,ms$   - Packet Size ($L$): $8000\,bits$   - Transmission Delay ($D_{trans}$):     - $D_{trans} = \frac{L}{R} = \frac{8000}{10^9} = 8\,μs$

• Round Trip Time (RTT): $15\,ms \times 2 = 30\,ms$

• Sender Utilization ($U_{sender}$):   - $U_{sender} = \frac{L/R}{RTT + L/R}$   - $U_{sender} = \frac{.008}{30.008} = 0.00027$

• Conclusion: The performance of rdt 3.0 (stop-and-wait) is extremely poor because the protocol limits the performance of the underlying infrastructure.

Questions & Discussion

• Q: How did the transport layer know to deliver a message to the Firefox browser process rather than Netflix or Skype?   - A: Through the process of demultiplexing using port numbers and IP addresses.

• Q: How do humans recover from "errors" during conversation?   - A: They use feedback like "What?" (Negative Acknowledgement) or acknowledging understanding (Positive Acknowledgement).

• Q: How do humans handle lost sender-to-receiver words in conversation?   - A: By waiting for a response and, if none comes, repeating the statement (similar to a timeout and retransmission).