Untitled Quiz

Chapter 3: Transport Layer

• PowerPoint slides are freely available for faculty, students, and readers
• Slides can be adapted for use in classes or on websites
• When using the slides, mention the source (the book)
• If posting slides online, indicate that they are adapted from the book's slides and note the copyright
• Revision history is available in slide notes

Transport Layer: Overview

• Goal: understand transport layer principles, services, multiplexing, demultiplexing, reliable data transfer, flow control, congestion control
• Protocols: UDP (connectionless transport), TCP (connection-oriented reliable transport), TCP congestion control

Transport Layer: Roadmap

• Transport-layer services (multiplexing and demultiplexing)
• Connectionless transport (UDP)
• Principles of reliable data transfer
• Connection-oriented transport (TCP)
• Principles of congestion control
• TCP congestion control
• Evolution of transport-layer functionality

Transport Services and Protocols

• Transport layer provides logical communication between processes running on different hosts
• Transport protocols act at end systems
• 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
• Two transport protocols available for internet applications: TCP and UDP

Transport vs. Network Layer Services and Protocols

• Network Layer: logical communication between hosts
• Transport Layer: logical communication between processes
• Transport Layer relies on and enhances Network Layer services

Transport Layer Actions: Sender

• Application layer passes a message to the transport layer
• Transport layer determines segment information
• Transport layer creates a segment
• Transport layer passes the segment to the network layer

Transport Layer Actions: Receiver

• Receiver receives a segment from the network layer
• Receiver checks header values
• Receiver extracts application-layer message
• Receiver demultiplexes the message to the appropriate application via a socket

Two Principal Internet Transport Protocols: TCP

• Reliable, in-order delivery
• Congestion control
• Flow control
• Connection setup

Two Principal Internet Transport Protocols: UDP

• Unreliable, unordered delivery
• No-frills extension of "best-effort" IP
• No delay guarantees
• No bandwidth guarantees

Chapter 3: Roadmap (repeated for clarity)

• Transport-layer services (multiplexing and demultiplexing)
• Connectionless Transport: UDP
• Principles of reliable data transfer
• Connection-oriented transport: TCP
• Principles of congestion control
• TCP congestion control
• Evolution of transport-layer functionality

Multiplexing/Demultiplexing

• Multiplexing (sender): Handles data from multiple sockets, adding transport header information
• Demultiplexing (receiver): Uses header information to deliver received segments to the correct socket

How Demultiplexing Works

• Host receives IP datagrams
• Each datagram has source and destination IP addresses
• Each datagram carries one transport-layer segment
• Each segment has source and destination port numbers
• Host uses IP addresses and port numbers to direct the segment to the appropriate socket

Connectionless Demultiplexing

• When receiving, the host checks the destination port number in the UDP segment
• Directs the UDP segment to the socket with that port number
• IP/UDP datagrams with the same destination port but different source IP addresses and/or source port numbers are directed to the same socket at the receiving host

Connectionless Demultiplexing: Example

• Example diagram showing DatagramSockets for different applications/processes

Connection-Oriented Demultiplexing

• TCP socket identified by a 4-tuple: source IP address, source port number, destination IP address, destination port number
• Receiver uses all four values to direct the segment to the appropriate socket
• Servers can support multiple simultaneous TCP sockets, each with its own 4-tuple

Connection-Oriented Demultiplexing: Example

• Diagram showing how three segments destined to the same IP address and port are demultiplexed

UDP: User Datagram Protocol

• "Bare bones" internet transport protocol
• No frills, simple, delivers messages without guarantees
• Fast and efficient
• No connection setup, minimal overhead
• Useful for streaming/loss-tolerant apps like multimedia
• Used also for DNS, SNMP (Simple Network Management Protocol)

UDP Use

• Streaming multimedia applications (e.g. loss-tolerant, rate-sensitive applications)
• DNS
• SNMP
• HTTP/3 (If reliability or congestion control is needed, these are handled at the application layer)

UDP: User Datagram Protocol (RFC 768)

• Formal specification of UDP
• Describes how UDP datagrams are structured
• States that applications using UDP are responsible for error handling and reliability.

UDP: Transport Layer Actions (sender)

• Transports application-layer message
• Determines UDP segment
• Defines header values
• Creates UDP Segment
• Passes UDP segment to IP layer

UDP: Transport Layer Actions (receiver)

• Receives a segment from the IP layer
• Receives UDP header
• Extracts application-layer message
• Demultiplexes message to correct application socket
• Verifies checksum validity

UDP Segment Header

• Components: source port, destination port, length, checksum, application data
• Length field indicates size in bytes, including header
• Checksum field used for error detection.

UDP Checksum

• Goal: detect errors in data
• Calculate checksum at sender before sending
• Receiver calculates checksum independently and checks the result against the sender's value to determine if errors exist

UDP Checksum: Example

• Example of calculating a checksum over two 16-bit integers using the one's complement method

Internet Checksum: An Example

• Example illustrating how 16 bit integers are added and then reversed to create checksum (one’s complement sum).

Internet Checksum: Weak protection

• Errors in individual bits won't necessarily affect the checksum if the bits causing the error are in the correct locations

UDP Summary

• No frills protocol,
• Segments may be lost/out-of-order
• Best-effort service, “send and hope”
• No connection setup/handshaking
• Can function even with compromised network services
• Application layer can add reliability or congestion control mechanisms (e.g., HTTP/3)

Chapter 3: Roadmap (repeated)

Principles of Reliable Data Transfer

• Data transfer from sender to receiver in a reliable manner
• Reliable service abstraction for applications to send/receive data
• Implementation details dependent on unreliable channel characteristics, potentially including packet loss, corruption or reordering

Principles of Reliable Data Transfer

• Sender and receiver don't share any state information about the other
• Sender and receiver need to coordinate their behavior when transmitting and receiving unreliable data.
• The sender and receiver both need some method of knowing that the other has reliably received data. This is the job of the reliable data transfer protocol.

Reliable Data Transfer Protocol (RDT): Interfaces

• RDT_send() function is called to transmit data from higher-level to the RDT protocol
• deliver_data() is called by RDT to transmit data from the lower level to higher levels.
• Communication takes place across an unreliable channel

Reliable Data Transfer: Getting Started

• Sender and receiver implementation development proceeds incrementally
• Only unidirectional data transfer is considered initially before extending to bidirectional data
• Finite state machines are used for specification of sender and receiver operations.
• Actions based on events determine state transitions.

RDT 1.0: Reliable Transfer Over Reliable Channel

• Underlying channel is perfectly reliable (no bit errors, no packet losses).
• Separate finite state machines for sender and receiver
• Sender sends data into the channel
• Receiver receives data from the channel
• Simple and easy to implement.

RDT 2.0: Channel with Bit Errors

• Underlying channel may flip bits in packets.
• Checksums are used to detect bit errors.
• Implementations using 'Stop-and-wait' protocol to retransmit lost or corrupted data packets

RDT 2.0: FSM Specification

• Sender and Receiver finite state machine (FSM) specifications for transmission of data across unreliable channel using ACKs and NAKs
• State-transition diagrams illustrating the functioning of the RDT 2.0 protocol

RDT 2.0: Operation with No Errors

• Illustrative example diagram of how the FSMs in an error-free environment

RDT 2.0: Corrupted Packet Scenario

• Illustrative example diagram of how the FSMs in an environment where a data packet might be corrupted

RDT 2.0 Has a Fatal Flaw

• Handling duplicates is not addressed in RDT 2.0, which creates the need for sequential number for each data packet

RDT 2.1: Sender, Handling Garbled ACK/NAKs

• Sender handles cases where ACKs/NACKs might be corrupted.
• Sender sequences data packets and waits for acknowledgements

RDT 2.1: Receiver, Handling Garbled ACK/NAKs

• Receiver receives packets, including duplicate packets, and determines the next sequence number and sends the appropriate acknowledgment or negative acknowledgement

RDT 2.2 : A NAK free protocol

• Receiver sends only ACKs
• Receiver provides seq number of the packet acknowledged..
• Sender retransmits packets and handles duplicate ACK situations.
• Simpler implementation compared to the RDT 2.1.

RDT 2.2: Sender, Receiver Fragments

• Sender and Receiver FSM specifications for transmission where acknowledgement and negative acknowledgements may be lost, with emphasis on fragmenting operation

RDT 3.0: Channels with Errors and Loss

• Underlying channel can now lose packets, increasing complexity compared to previous versions
• Using timers to handle lost packets.

RDT 3.0: Sender

• Timeout mechanism if no ACK is received.
• Retransmission when a timeout occurs
• Handling duplicate packets using sequence numbers

RDT 3.0 in action

• Demonstrates how the sender and receiver interact in various scenarios, including data and ACK packets arriving in order, timeouts causing retransmission and ACK losses

RDT 3.0: Pipelined Protocols Operation

• Pipelining allows multiple packets to be simultaneously in transit but not yet acknowledged.
• Increased efficiency because of multiple packets being in transit at once. This requires increasing the range of sequence numbers used to track the buffered packets.

Go-Back-N: Sender

• Sender window which is a range of sequence numbers
• Sender maintains a window to control the outstanding data packets that might experience loss
• CWND: congestion window is used to dynamically adjust rate.

Go-Back-N: Receiver

• Receiver only sends ACKs for correctly-received packets.
• Receiver maintains a receiver window and can discard packets that arrive out of order, buffering some.

Go-Back-N in Action

• Example diagram of how sender and receiver interact in scenarios where packets are lost.

Selective Repeat

• Receiver individually acknowledges correctly received packets.
• Buffers packets as needed for in-order delivery.
• Sender times out and retransmits unacknowledged packets individually.
• Sender uses a window to manage outstanding packets.
• Using a sequence number for each packet.

Selective Repeat Sender, Receiver Windows

• Illustrative example depicting the sender and receiver windowing schemes used in selective repeat.

Selective Repeat: Sender and Receiver

• Sender sends data packets and waits for acknowledgements.
• Receiver sends acknowledgements and buffers packets if they arrive out of order.
• Handling of packet loss by retransmission, in a selective fashion to avoid redundant transmissions and congestion.

TCP Overview (RFCs)

• A reliable, connection-oriented byte stream protocol.
• Uses a point-to-point model: one sender, one receiver
• No message boundaries
• Full duplex data flow in the same connection

TCP Segment Structure

• Components of a TCP segment header structure, including acknowledgements, sequence numbers, urgent data pointer, options field, and data payload.

TCP Sequence Numbers, ACKs

• Sequence numbers: byte stream number of first byte in segment’s data
• Acknowledgements: sequence number of next byte expected by receiver from sender

TCP Sequence Numbers, ACKs: Example

• Example of a TCP sequence number exchange in a telnet-like scenario where the sender sends data and receiver acknowledges it correctly.

TCP Sender (simplified)

• TCP sender processes and generates segments for transmission, along with sequence number, segment handling and management
• timeout handling in case data packets and acknowledgements get lost.

TCP Receiver: ACK Generation (RFC 5681)

• Receiver generates Acknowledgements based on whether expected sequence numbers match incoming data
• Duplicate ACKs can be generated by the receiver in certain error conditions

TCP: Retransmission Scenarios

• Scenarios where the sender has to retransmit data after a loss event in the TCP communication channel is evaluated. These include lost ACKs, premature timeouts and cumulative ACKs

TCP Fast Retransmit

• Sender retransmits a packet if it receives three duplicate ACKs
• Avoiding unnecessary retransmissions after packet loss

Chapter 3: Roadmap (repeated)

TCP Flow Control

• Sender won't overwhelm receiver's buffer when network layer delivers data faster than the application layer removes data.
• Receiver controls sender by telling sender how many bytes in a receive window it is willing to accept

TCP Connection Management

• Sender and receiver have to initiate a ‘handshake’ before data exchange to agree on connection parameters
• Connection initialized and closed via a 3-way handshake – SYN, SYN-ACK, ACK

TCP 3-way Handshake

• Process of establishing a TCP connection involves three segments
• Client sends ‘SYN’ – sync (initial) message (also contains an initial sequence number) to Server
• Server sends an acknowledgement (SYN-ACK) in response to client’s SYN, containing an initial sequence number from Server & acknowledgement of the previous sequence number of TCP
• Client receives SYN-ACK, sends ACK back to establish a connection

Closing a TCP Connection

• Client and server each close their connection by sending a FIN (finish) bit.
• Acknowledgment is sent in response to received FIN
• Acknowledgment of closing in order to complete the closing action of the TCP connection

Chapter 3: Roadmap (repeated)

Principles of Congestion Control

• Congestion occurs when too many sources send too much data too fast for the network to handle
• Manifestations include long delays, or packet loss.
• Flow control is distinct from congestion control.

Approaches Towards Congestion Control

• End-to-end congestion control
• Network-assisted congestion control (with routers)

TCP Congestion Control: AIMD (Additive Increase, Multiplicative Decrease)

• Sender increases sending rate until loss is detected
• Then, cuts the sending rate in half to avoid overloading network

TCP AIMD : More Details

• Multiplicative decrease: sending rate cut in half on loss event (e.g., 3 duplicate ACKs – TCP Reno), or timeout (TCP Tahoe).

TCP Slow Start

• Initial increase in the transmission rate until the first loss event detected
• Sender doubles transmission rate every RTT (round-trip time) until sending rate exceeds the threshold (ssthresh).

TCP: From Slow Start to Congestion Avoidance

• Exponential growth in sending rate during slow start changes to linear when reaches a threshold.
• Threshold parameter (ssthresh) is dynamically updated when packet loss event occurs in TCP operations.
• The sender backs off to prevent network overload

Chapter 3: Summary

• Transport layer services
• Multiplexing and demultiplexing
• Reliable data transfer (Connectionless, Connection-oriented)
• Flow control, and congestion control