UDP-Based Network Applications

UDP is a connectionless transport protocol that offers fast but unreliable data transmission.
Unlike TCP, UDP doesn't establish connections, perform handshakes, or guarantee packet
delivery, making it suitable for specific applications where speed is prioritized over reliability.

1. Domain Name System (DNS)

DNS is a hierarchical naming system that translates human-readable domain names (like
www.example.com) into IP addresses (like 192.168.1.1) that computers use to identify each
other on networks.

Why DNS uses UDP:

 Most DNS queries are small and fit within a single UDP datagram
 UDP's lower overhead provides faster response times for name resolution
 DNS queries are typically simple request-response transactions that don't require a
persistent connection
 If a DNS query fails, clients can simply retry the request
 For standard queries, the 512-byte UDP message size limit is usually sufficient
 DNS does support TCP as a fallback for larger responses (like zone transfers) that exceed
UDP size limits

DNS UDP Operation:

 Client sends a name resolution request to DNS server on port 53

 Server responds with the corresponding IP address
 Typically completes in a single round-trip exchange

2. Simple Network Management Protocol (SNMP)

SNMP is a protocol used for collecting information from and configuring network devices like
routers, switches, servers, printers, and other IP-enabled devices.

Why SNMP uses UDP:

 Most SNMP operations are simple status requests that fit in small packets
 Network monitoring requires regular polling of many devices, where UDP's low
overhead is beneficial
 Lost SNMP packets are often not critical since monitoring systems poll devices at regular
intervals
 UDP port 161 is used for sending and receiving requests
 UDP port 162 is used for receiving traps (asynchronous notifications) from managed
devices

SNMP UDP Operation:

  Network Management System (NMS) sends queries to SNMP agents
 Agents respond with device status information
 Devices can send unsolicited trap messages for critical events
 SNMPv3 added security features while still using UDP as the transport protocol

3. Trivial File Transfer Protocol (TFTP)

TFTP is a simple, lightweight file transfer protocol designed for transferring files where memory
usage or program size is a constraint.

Why TFTP uses UDP:

 Simpler implementation than FTP (no authentication, directory navigation, etc.)

 Commonly used for booting diskless workstations, networking equipment, and embedded
devices
 Operates on UDP port 69
 Particularly useful in environments with limited resources (like router firmware updates)

TFTP UDP Operation:

 Built-in reliability mechanisms despite using UDP

 Uses a stop-and-wait protocol where each data packet must be acknowledged
 Files are broken into small blocks (typically 512 bytes)
 Each block must be acknowledged before the next is sent
 Implements timeouts and retransmissions at the application layer

4. Routing Information Protocol (RIP)

RIP is a distance-vector routing protocol used by routers to exchange network topology

information to determine the best path for forwarding packets.

Why RIP uses UDP:

 Regular updates are broadcast/multicast to neighboring routers on UDP port 520

 If an update is missed, the next periodic update will resolve any inconsistencies
 Simple implementation with low processing requirements
 Updates are periodic rather than requiring persistent connections

RIP UDP Operation:

 Routers broadcast their routing tables to directly connected neighbors every 30 seconds
 Uses hop count as its routing metric (limited to 15 hops)
 Implements various timers to handle network changes and prevent routing loops
 RIPv2 added subnet mask information and multicast capabilities

5. Kerberos
Kerberos is a network authentication protocol designed to provide strong authentication for
client/server applications using secret-key cryptography.

Why Kerberos uses UDP:

 Authentication requests are typically small and fit within UDP datagrams
 Speed is important for authentication processes
 Uses UDP port 88 by default
 Can fall back to TCP when necessary for larger exchanges

Kerberos UDP Operation:

 Client sends an authentication request to the Key Distribution Center (KDC)

 KDC responds with a ticket-granting ticket (TGT)
 Client uses TGT to request service tickets for specific services
 Implements its own reliability mechanisms at the application layer
 UDP is used for the initial authentication exchange, while some implementations use
TCP for larger ticket exchanges

All these applications share common characteristics that make UDP suitable: they typically
involve simple request-response interactions, can tolerate occasional packet loss, benefit from
lower overhead, and often implement their own application-layer reliability mechanisms when
needed.
Remote Procedure Call (RPC)
Remote Procedure Call (RPC) is a protocol that allows a program on one computer to execute a
procedure (function) on another computer across a network. It abstracts the complexities of
network communication, making remote function calls appear as if they were local calls.

Core Concepts of RPC

Basic Functionality

RPC enables a client program to request a service from a server program on a remote machine
without having to understand the network details. The client makes what looks like a local
procedure call, while the RPC system handles:

1. Parameter marshalling - Converting function parameters into a standard format for

transmission
2. Network communication - Sending the request to the remote server
3. Parameter unmarshalling - Converting received data back into the format expected by
the receiving program
4. Execution and response - Running the procedure on the server and returning results to
the client

RPC Architecture Components

1. Client: The application that initiates a request for service

2. Client Stub: Client-side code that appears as a normal procedure but packages
parameters for transmission
3. RPC Runtime: Manages the network communication between client and server
4. Server Stub: Unpacks the marshalled parameters and calls the actual procedure
5. Server: Executes the requested procedure and returns results

RPC Operation Flow

1. The client application calls a local procedure (the client stub)
2. The client stub marshals the parameters into a message
3. The client's RPC runtime sends the message to the server
4. The server's RPC runtime receives the message and passes it to the server stub
5. The server stub unmarshals the parameters and calls the actual procedure
6. The server procedure executes and returns results to the server stub
7. The server stub marshals the results and sends them back through the RPC runtime
8. The client's RPC runtime receives the results and passes them to the client stub
9. The client stub unmarshals the results and returns them to the client application

Key RPC Characteristics

Binding Mechanisms

 Static Binding: The client knows the server's address at compile time
 Dynamic Binding: The client discovers the server's address at runtime through a name
service or directory service

Parameter Passing

 Call by Value: Parameters are copied and sent to the remote procedure
 Call by Reference: More complex as network addresses don't share memory space;
requires special handling

Synchronization Models

 Synchronous (Blocking): Client waits for the server to complete the procedure
 Asynchronous (Non-blocking): Client continues execution without waiting for server
response
 Deferred Synchronous: Client waits explicitly for results at a later point

RPC Transport Options

RPC can use various transport protocols:

 TCP: For reliable, connection-oriented communication

 UDP: For faster, connectionless communication (requires additional reliability
mechanisms)

Major RPC Implementations

1. Sun RPC (ONC RPC)

 Developed by Sun Microsystems

 Forms the basis for Network File System (NFS)
 Uses External Data Representation (XDR) for data encoding
 Interface definitions stored in .x files processed by the RPCGEN tool

2. DCE RPC

 Developed by the Open Software Foundation

 Part of the Distributed Computing Environment
 Uses Interface Definition Language (IDL) to specify interfaces
 More sophisticated security features than Sun RPC

3. Microsoft RPC (MSRPC)

  Based on DCE RPC
 Foundation for COM/DCOM technologies
 Extended to support object-oriented programming models
 Used extensively in Windows operating systems

4. gRPC

 Modern open-source RPC framework developed by Google

 Uses Protocol Buffers for interface definition and data serialization
 Supports bidirectional streaming and multiple programming languages
 Built on HTTP/2 for improved performance and features

RPC Challenges and Solutions

1. Failure Handling

RPC systems must handle various failure scenarios:

 Server crashes: Client may receive no response

 Lost requests/responses: Needs timeouts and retransmission strategies
 Duplicate requests: Requires idempotent operations or tracking

Solutions include:

 At-least-once semantics: Retry until success, may lead to duplicates

 At-most-once semantics: Never execute more than once, may not execute at all
 Exactly-once semantics: Most desirable but hardest to implement

2. Performance Considerations

RPC involves inherent performance overhead:

 Network latency
 Parameter marshalling/unmarshalling
 Protocol processing

Optimization approaches include:

 Batching multiple calls

 Asynchronous calls
 Caching results
 Using lightweight serialization formats

3. Security Aspects
RPC systems must address:

 Authentication of clients and servers

 Authorization of procedure calls
 Data privacy through encryption
 Protection against replay attacks

RPC vs. REST and Other Alternatives

RPC vs. REST

 RPC: Focuses on actions/operations, procedure-oriented

 REST: Focuses on resources, data-oriented
 RPC typically uses POST methods, while REST uses appropriate HTTP methods (GET,
POST, PUT, DELETE)
 RPC often more efficient for complex operations that don't map well to CRUD operations

RPC vs. Message Queuing

 RPC: Typically synchronous, tightly coupled

 Message Queuing: Asynchronous, loosely coupled
 RPC focuses on procedure calls, while message queuing focuses on message exchange
 Message queuing better for disconnected operations

Modern RPC in Distributed Systems

RPC remains relevant in modern distributed systems:

 Microservices architectures often use RPC for inter-service communication

 Cloud computing platforms provide RPC mechanisms for service integration
 Mobile applications use RPC to communicate with backend services
 IoT devices use lightweight RPC variants for efficient communication

Advantages and Disadvantages

Advantages

 Familiar programming model (similar to local procedure calls)

 Hides network communication complexity
 Can be highly efficient with proper implementation
 Supports strong typing and interface definitions

Disadvantages
  Can create tight coupling between systems
 May create brittle distributed systems if not carefully designed
 Network effects (latency, failures) can't be completely hidden
 Version compatibility challenges as systems evolve

RPC continues to evolve with new implementations addressing historical limitations, making it a
fundamental technology in distributed computing.
Remote Procedure Call Concepts in Detail
11.7.1 Network File Sharing
Network File Sharing is an important application of RPC technologies that allows computers to
access files over a network as if they were stored locally.

Key Network File Sharing Systems:

1. Network File System (NFS)

o Developed by Sun Microsystems
o Uses RPC as its underlying mechanism
o Allows transparent access to remote files
o Client mounts remote directories to their file system
o Operations like read, write, create are translated into RPC calls
o Stateless protocol in early versions (NFSv2, NFSv3)
o Added stateful operations in NFSv4
2. Server Message Block (SMB)/Common Internet File System (CIFS)
o Used primarily in Windows environments
o Microsoft's implementation of network file sharing
o Provides file sharing, printer sharing, and authentication
o More feature-rich than NFS (file locking, opportunistic locks)
o Uses RPCs for many operations
3. Andrew File System (AFS)
o Developed at Carnegie Mellon University
o Designed for large-scale distributed computing
o Uses client-side caching extensively
o Better scaling properties than early NFS

Network File Sharing RPC Mechanisms:

 File Operations: Open, close, read, write, etc. are translated to RPCs
 Authentication: User identity verification across the network
 Caching: Local caching of remote files to improve performance
 Consistency: Maintaining file consistency when multiple clients access the same files
 Locking: Coordinating access to prevent conflicts

11.7.2 Sun RPC

Sun RPC (also known as ONC RPC - Open Network Computing Remote Procedure Call) is one
of the most influential RPC implementations, particularly known for its use in NFS.

Sun RPC Architecture:

 1. Interface Definition:
o Uses .x files written in XDR (External Data Representation) language
o RPCGEN compiler generates stub code from these definitions
2. Program, Version, and Procedure Numbers:
o Each RPC service identified by a unique triplet:
 Program number (identifies the service)
 Version number (allows multiple versions of the same service)
 Procedure number (identifies specific procedure within the service)
3. Portmapper/RPCBIND Service:
o Central registry that maps RPC services to port numbers
o Clients query portmapper to find the port for a service
4. Authentication Mechanisms:
o NULL (no authentication)
o UNIX (UID/GID based)
o DES (encryption-based)
o Later versions added Kerberos and other methods

Sun RPC Protocol:

1. Call Message Format:

o XID (transaction identifier)
o Message type (call)
o RPC version
o Program number
o Program version
o Procedure number
o Authentication information
o Procedure arguments (in XDR format)
2. Reply Message Format:
o XID (matching the call)
o Message type (reply)
o Reply status (accepted or rejected)
o Authentication verifier
o Procedure results (in XDR format)
3. Error Handling:
o RPC errors (e.g., program unavailable)
o Authentication errors
o Execution errors

11.7.3 Serialization
Serialization is the process of converting complex data structures into a format that can be
transmitted over a network and reconstructed on the receiving end. It's a critical component of
RPC systems.
Serialization in RPC:

1. External Data Representation (XDR):

o Standard format used by Sun RPC
o Provides machine-independent data description and encoding
o Handles data type differences between heterogeneous systems
o Defines representation for integers, floating point, arrays, etc.
o Uses big-endian byte ordering
2. Interface Definition Languages (IDLs):
o Description languages for defining the interfaces between components
o Examples include:
 DCE IDL
 CORBA IDL
 Microsoft IDL (MIDL)
 Protocol Buffers (Google)
 Thrift (Apache/Facebook)
3. Marshalling Process:
o Converting native data types to wire format
o Handling complex structures (pointers, recursive structures)
o Managing byte ordering (endianness)
o Encoding type information when necessary
4. Unmarshalling Process:
o Reconstructing data structures from wire format
o Type checking
o Memory allocation for reconstructed data
o Converting between different representations

Modern Serialization Formats:

1. Protocol Buffers (Protobuf):

o Developed by Google
o Compact binary format with schema definition
o Cross-language support
o Used in gRPC
2. JSON/XML:
o Text-based formats
o Human-readable
o Wide support across platforms
o Used in many web service RPCs
3. Apache Avro:
o Rich data structures
o Compact binary format
o Schema-based
4. MessagePack:
o Binary format designed for efficiency
 o Smaller than JSON
o Fast serialization/deserialization

11.7.4 Refinements
RPC systems have evolved with various refinements to address limitations and enhance
capabilities.

Semantic Refinements:

1. Parameter Passing Models:

o Pass by Value: Simple data copying
o Pass by Reference: Challenges in distributed systems
o Distributed Shared Memory: Creating illusion of shared memory
2. Failure Semantics:
o Exactly-Once: Guarantees procedure executes exactly once (ideal but difficult)
o At-Least-Once: May execute multiple times (requires idempotent operations)
o At-Most-Once: May not execute (safer for non-idempotent operations)
o Maybe: No guarantees (simplest implementation)
3. Timeout and Retry Mechanisms:
o Adaptive timeout calculations
o Exponential backoff for retries
o Duplicate request detection

Performance Refinements:

1. Asynchronous RPC:
o Non-blocking calls
o Callback mechanisms
o Promise/Future patterns
2. Batching and Pipelining:
o Combining multiple requests
o Sending new requests before receiving responses
o Amortizing network overhead
3. Caching:
o Result caching
o Idempotent operation optimization
o Lease-based cache consistency

Security Refinements:

1. Secure RPC:
o Strong authentication
o Encryption of RPC traffic
o Defense against replay attacks
 o Access control integration
2. Delegation:
o Allowing servers to make calls on behalf of clients
o Credential passing and impersonation
o Kerberos ticket delegation

Scalability Refinements:

1. Load Balancing:
o Multiple server instances
o Client-side or server-side distribution
o Consistent hashing for request routing
2. Service Discovery:
o Dynamic server location
o Health checking
o Automatic failover
3. Versioning:
o Interface evolution
o Backward compatibility
o Graceful degradation

Modern RPC Refinements:

1. Bidirectional Streaming:
o Server streaming to client
o Client streaming to server
o Bidirectional streaming
o Popular in gRPC
2. Circuit Breakers:
o Fail fast during remote system failures
o Prevent cascading failures
o Automatic recovery
3. Observability:
o Detailed tracing across service calls
o Performance metrics
o Logging integration

These refinements have transformed RPC from a simple procedure call mechanism into
sophisticated frameworks that power modern distributed systems, microservices, and cloud
computing platforms.
Principles of Reliable Data Transfer (RDT) in
Transport Layer
Building a Reliable Data Transfer Protocol
Reliable Data Transfer (RDT) protocols ensure that data is delivered from sender to receiver
correctly and in order, despite potential errors in underlying network layers. The development of
RDT protocols typically follows an incremental approach:

Part (a): Provided Service - The Abstraction

The left side shows what RDT protocols provide to the application layer:

 Reliable Channel: The application layer sees a perfect, reliable communication channel
between the sending and receiving processes
 Simple Interface: Applications just call functions like send(data) and receive(data)
without worrying about underlying network problems
 Transparency: All the complexity of ensuring reliability is hidden from the application
layer
 Guaranteed Delivery: Data sent by the sending process is guaranteed to be delivered
correctly to the receiving process

Part (b): Service Implementation - The Reality

The right side shows how this reliability is actually implemented at the transport layer:

Key Components:

1. RDT Protocols on Both Sides:

o Sending Side: rdt_send() function handles outgoing data
o Receiving Side: rdt_rcv() function handles incoming packets
o Delivery: deliver_data() function passes clean data to application
2. Unreliable Channel: The actual network connection between sender and receiver is
unreliable and can:
o Lose packets
o Corrupt data
o Deliver packets out of order
o Introduce delays
3. Protocol Functions:
o udt_send(): "Unreliable data transfer send" - sends packets over the unreliable
channel
o The RDT protocols add mechanisms like sequence numbers, acknowledgments,
timeouts, and retransmissions

The Key Insight

This diagram demonstrates the layered approach of networking:

 Application Layer Perspective: Sees a reliable, perfect channel

 Transport Layer Reality: Must deal with an unreliable network and implement
mechanisms to provide reliability

The RDT protocols essentially "bridge the gap" between what applications need (reliability) and
what the network provides (unreliability). This is a fundamental principle in computer
networking - higher layers provide abstractions that hide the complexity and limitations of lower
layers.

This abstraction allows application developers to write programs assuming reliable

communication, while the transport layer handles all the complex error detection, retransmission,
and ordering mechanisms needed to achieve that reliability over an inherently unreliable
network.
This diagram shows the service model and interface for reliable data transfer protocols in a
more realistic scenario with an unreliable channel.

Key Components:

1. Upper Layer Interface:

o rdt_send(): Called by application to send data
o deliver_data(): Called by RDT to deliver received data to application
2. Lower Layer Interface:
o udt_send(): RDT calls this to send packets over unreliable channel
o rdt_rcv(): Called when packet arrives from unreliable channel
3. The Challenge: The unreliable channel between sender and receiver can:
o Lose packets
o Corrupt data
o Deliver packets out of order
o Duplicate packets

Protocol Responsibilities:

The reliable data transfer protocol must handle all the complexities of the unreliable channel
while providing a simple, reliable interface to the application layer. This includes:

 Error detection and correction

 Acknowledgments and retransmissions
 Sequence numbering
 Flow control
 Buffering and reordering
RDT 1.0 - Protocol for a Perfectly Reliable Channel

Sending Side (left diagram):

 State: "wait for call from above" - The protocol waits for the application layer to request
data transmission
 Action: When rdt_send(data) is called:
o Creates a packet using make_pkt(packet, data)
o Sends it via udt_send(packet) (unreliable data transfer send)

Receiving Side (right diagram):

 State: "wait for call from below" - Waits for packets to arrive from the network
 Action: When rdt_rcv(packet) is called:
o Extracts data using extract(packet, data)
o Delivers data to upper layer via deliver_data(data)

Since the channel is perfectly reliable, no error checking, acknowledgments, or retransmissions

are needed.

RDT 1.0: Perfect Underlying Channel

 Assumes the underlying channel is completely reliable

 No bit errors or packet loss occur
 Simple implementation: sender sends data, receiver receives data
 No error detection or correction mechanisms needed

RDT 2.0: Channel with Bit Errors

 Introduces error detection using checksums or CRC

 Implements Automatic Repeat reQuest (ARQ) protocols:
o Error detection at receiver
o Receiver feedback (ACK/NAK)
o Retransmission of corrupted packets
  Stop-and-wait approach: sender waits for acknowledgment before sending next packet

RDT 2.1: Handling Corrupted ACK/NAKs

 Adds sequence numbers (typically 0 and 1 alternating)

 Allows sender to identify which packet is being acknowledged
 Sender and receiver maintain state to track sequence numbers

RDT 2.2: NAK-free Protocol

 Eliminates NAKs by using only ACKs with sequence numbers

 Receiver acknowledges correctly received packets
 Duplicate ACKs signal that a packet was corrupted

RDT 3.0: Channels with Errors and Loss

 Adds timeout mechanism at sender to handle packet loss

 If acknowledgment not received within timeout period, packet is retransmitted
 Handles duplicate packets at receiver using sequence numbers

Pipelined Reliable Data Transfer Protocols

Stop-and-wait protocols suffer from performance limitations, especially over high-bandwidth,
high-latency networks. Pipelining improves efficiency by:

 Allowing multiple unacknowledged packets "in flight" simultaneously

 Increasing utilization of available network capacity
 Requiring larger sequence number ranges
 Requiring larger buffers at sender and receiver

Two main approaches to pipelined RDT protocols:

Go-Back-N (GBN) Protocol

Go-Back-N handles errors by "going back" to the last successfully received packet and resending
all subsequent packets.

Key Features:

 Uses a sliding window of size N at the sender

 Sender can have up to N unacknowledged packets in pipeline
 Receiver accepts only in-order packets
 Receiver sends cumulative ACKs for the last in-order packet
 If timeout occurs, sender resends all unacknowledged packets
Sender Behavior:

 Maintains variables:
o base: sequence number of oldest unacknowledged packet
o nextseqnum: sequence number of next packet to send
o Window size: N
 Can send when nextseqnum < base + N
 Single timer for oldest unacknowledged packet
 When timeout occurs, retransmits all packets from base to nextseqnum-1

Receiver Behavior:

 Simple implementation - only accepts in-order packets

 Discards out-of-order packets (no buffering)
 Sends ACK for highest in-order packet received
 Delivers only in-order data to application layer

Advantages:

 Simpler receiver implementation

 No need for buffering out-of-order packets at receiver

Disadvantages:

 Inefficient when error rates are high (retransmits many packets)

 Wastes bandwidth by discarding correctly received but out-of-order packets

Selective Repeat (SR) Protocol

Selective Repeat addresses GBN's inefficiency by allowing the receiver to accept and buffer out-
of-order packets and only requesting retransmission of packets that were actually lost.

Key Features:

 Both sender and receiver maintain sliding windows

 Sender retransmits only packets that are suspected to be lost or corrupted
 Receiver individually acknowledges each packet
 Receiver can accept out-of-order packets within its window

Sender Behavior:

 Maintains a sliding window of size N

 Only retransmits individual packets that timeout
 Maintains individual timers for each unacknowledged packet
 Moves window forward when base packet is acknowledged
Receiver Behavior:

 Maintains a sliding window of size N

 Accepts and buffers out-of-order packets within window
 Sends individual ACKs for each correctly received packet
 Delivers in-order packets to application layer

Advantages:

 More efficient use of bandwidth than GBN

 Better performance with high error rates
 Reduces unnecessary retransmissions

Disadvantages:

 More complex receiver implementation

 Requires buffering at receiver
 Requires individual packet timers at sender

Sequence Number Considerations:

 SR requires a sequence number space at least twice the window size to avoid ambiguity
 If window size is N, sequence numbers should be at least 2N

Practical Considerations
Window Size Selection:

 Affects throughput and efficiency

 Should be based on bandwidth-delay product
 Formula: Window Size = Bandwidth × Round-Trip Time

Timeout Value:

 Too short: unnecessary retransmissions

 Too long: slow recovery from packet loss
 Adaptive timeout calculation based on measured RTT

Sequence Number Space:

 Must be large enough to handle maximum window size

 TCP uses 32-bit sequence numbers
 Must handle sequence number wraparound
These principles of reliable data transfer form the foundation of transport layer protocols like
TCP, which implements many of these concepts along with additional mechanisms for flow
control and congestion control.
Transport Layer: Congestion Control -
Teaching Notes
Learning Objectives
By the end of this lesson, students should be able to:

 Understand the concept of network congestion and its causes

 Explain different approaches to congestion control
 Describe congestion control algorithms used in TCP
 Analyze the working of Leaky Bucket and Token Bucket algorithms
 Compare and contrast different traffic shaping mechanisms

4.1 Introduction to Congestion Control

What is Network Congestion?

Network congestion occurs when the demand for network resources exceeds the available
capacity, leading to:

 Increased packet delay

 Packet loss
 Reduced network throughput
 Poor Quality of Service (QoS)

Analogy: Think of network congestion like traffic congestion on highways. When too many cars
try to use the same road at the same time, traffic slows down, delays increase, and efficiency
decreases.

Causes of Congestion

1. Traffic Overload: More data being sent than the network can handle
2. Bottleneck Links: Slower links in the path limiting overall throughput
3. Router Buffer Overflow: Intermediate routers running out of buffer space
4. Inadequate Processing Power: Routers unable to process packets fast enough
5. Network Topology Issues: Poor network design creating choke points

Effects of Congestion

1. Increased Delay: Packets take longer to reach destination

2. Packet Loss: Buffers overflow, causing packets to be dropped
 3. Timeout and Retransmission: Lost packets trigger retransmissions, worsening
congestion
4. Throughput Degradation: Effective data transfer rate decreases
5. Fairness Issues: Some connections may get more resources than others

4.2 Principles of Congestion Control

Key Principles

1. Feedback Mechanism: Network must provide feedback about its current state
2. Additive Increase: Gradually increase sending rate when network is not congested
3. Multiplicative Decrease: Rapidly decrease sending rate when congestion is detected
4. Fairness: All connections should get fair share of available bandwidth
5. Efficiency: Network resources should be utilized optimally

Congestion Control vs Flow Control

Congestion Control Flow Control

Prevents network overload Prevents receiver buffer overflow
Global problem (entire network) Local problem (sender-receiver pair)
Considers network capacity Considers receiver capacity
Involves routers and switches Involves only sender and receiver

4.3 Approaches to Congestion Control

1. Open Loop Control (Preventive)

Approach: Prevent congestion before it occurs by making good decisions at the design and
configuration level.

Methods:

 Traffic Shaping: Regulate the rate at which packets are sent

 Admission Control: Limit the number of connections that can use the network
 Resource Reservation: Reserve bandwidth before sending data
 Load Shedding: Drop packets when congestion is imminent

Advantages:

 Proactive approach
 Prevents congestion rather than reacting to it
  More predictable performance

Disadvantages:

 May be overly conservative

 Difficult to predict actual network conditions
 May underutilize network resources

2. Closed Loop Control (Reactive)

Approach: React to congestion after it has been detected.

Methods:

 Explicit Feedback: Routers explicitly inform senders about congestion

 Implicit Feedback: Senders infer congestion from packet loss or delays
 Rate Adjustment: Modify sending rate based on feedback
 Window Adjustment: Change window size to control data flow

Advantages:

 Adapts to actual network conditions

 Can achieve higher utilization
 Responds to real-time changes

Disadvantages:

 Reactive nature may lead to oscillations

 Time lag between detection and response
 May not prevent congestion bursts

4.4 TCP Congestion Control Algorithms

4.4.1 Slow Start Algorithm

Purpose: Gradually probe the network capacity to find the optimal sending rate.

Working Principle:

1. Start with a small congestion window (cwnd = 1 MSS)

2. For each ACK received, increase cwnd by 1 MSS
3. This results in exponential growth of the sending rate
4. Continue until:
 o Timeout occurs (indicating congestion)
o Slow start threshold (ssthresh) is reached

Example:

Initial: cwnd = 1 MSS

After 1 RTT: cwnd = 2 MSS (received 1 ACK)
After 2 RTT: cwnd = 4 MSS (received 2 ACKs)
After 3 RTT: cwnd = 8 MSS (received 4 ACKs)

Key Points:

 Exponential increase phase

 Quickly finds available bandwidth
 Stops at ssthresh to avoid congestion

4.4.2 Congestion Avoidance Algorithm

Purpose: Once slow start threshold is reached, increase sending rate more conservatively.

Working Principle:

1. When cwnd >= ssthresh, enter congestion avoidance phase

2. For each RTT, increase cwnd by 1 MSS (linear increase)
3. This is achieved by increasing cwnd by 1/cwnd for each ACK
4. Continue until timeout or duplicate ACKs indicate congestion

Example:

If cwnd = 8 MSS and ssthresh = 8:

- For each ACK: cwnd += 1/8 = 0.125 MSS
- After 8 ACKs (1 RTT): cwnd = 9 MSS
- After 16 ACKs (2 RTT): cwnd = 10 MSS

Key Points:

 Linear increase phase (additive increase)

 Conservative approach to avoid congestion
 Provides stability near optimal operating point

4.4.3 Fast Retransmit Algorithm

Purpose: Quickly detect and recover from packet loss without waiting for timeout.

Working Principle:

1. When receiver gets out-of-order packet, send duplicate ACK

 2. Sender receives duplicate ACKs
3. If 3 duplicate ACKs received, assume packet is lost
4. Immediately retransmit the missing packet
5. Don't wait for timeout

Benefits:

 Faster recovery from packet loss

 Avoids timeout delays
 Maintains higher throughput

4.4.4 Fast Recovery Algorithm

Purpose: Avoid slow start after fast retransmit, assuming network is not severely congested.

Working Principle:

1. After fast retransmit, don't enter slow start

2. Set ssthresh = cwnd/2
3. Set cwnd = ssthresh + 3
4. For each additional duplicate ACK, increment cwnd
5. When new ACK arrives, set cwnd = ssthresh

Rationale:

 If only one packet lost, network probably not severely congested

 Duplicate ACKs indicate packets are still flowing
 Avoid dramatic reduction in sending rate

4.5 Traffic Shaping Algorithms

4.5.1 Leaky Bucket Algorithm

Concept: Analogy of a bucket with a small hole at the bottom. Water (data) is poured in at
variable rates but flows out at a constant rate.

Purpose:

 Smooth bursty traffic into constant rate output

 Provide traffic shaping and rate limiting
 Ensure compliance with traffic contracts

Working Principle:
 1. Bucket Capacity: Maximum number of tokens/packets that can be stored
2. Output Rate: Constant rate at which tokens/packets are removed
3. Input: Variable rate at which packets arrive
4. Overflow: Packets are discarded when bucket is full

Algorithm Steps:

Initialize:
- bucket_size = maximum bucket capacity
- current_level = 0
- output_rate = constant output rate

For each arriving packet:

1. If current_level < bucket_size:
- Add packet to bucket
- current_level++
2. Else:
- Discard packet (bucket overflow)

Continuously:
- If current_level > 0:
- Send one packet
- current_level--
- Wait for (1/output_rate) time units

Characteristics:

 Input: Variable (bursty)

 Output: Constant rate
 Buffer: Fixed size bucket
 Overflow Policy: Discard excess packets

Advantages:

 Simple to implement
 Provides guaranteed output rate
 Smooths traffic variations
 Enforces traffic contracts

Disadvantages:

 Discards packets during bursts

 May introduce delay
 Doesn't consider packet priorities
 Fixed output rate regardless of network conditions

Example Scenario:

Bucket Size: 5 packets

Output Rate: 2 packets per second
Time Arrivals Bucket Level Output Discarded
0 3 3 0 0
0.5 2 4 1 1
1.0 1 4 1 0
1.5 0 3 1 0
2.0 4 4 1 3

4.5.2 Token Bucket Algorithm

Concept: A bucket that is filled with tokens at a constant rate. Packets can only be transmitted if
tokens are available.

Purpose:

 Allow controlled bursts while maintaining average rate

 Provide flexible traffic shaping
 Support variable packet sizes

Working Principle:

1. Token Generation: Tokens are added to bucket at constant rate

2. Bucket Capacity: Maximum number of tokens that can be stored
3. Packet Transmission: Each packet requires tokens equal to its size
4. Token Availability: Packets transmitted only if sufficient tokens available

Algorithm Steps:

Initialize:
- bucket_size = maximum token capacity
- current_tokens = bucket_size
- token_rate = rate of token generation
- last_update = current_time

For each packet of size S:

1. Update tokens:
- time_elapsed = current_time - last_update
- tokens_to_add = time_elapsed × token_rate
- current_tokens = min(bucket_size, current_tokens + tokens_to_add)
- last_update = current_time

2. Check token availability:

- If current_tokens >= S:
- Transmit packet
- current_tokens -= S
- Else:
- Either queue packet or discard it

Characteristics:

 Input: Variable (bursty) - but controlled by token availability

  Output: Variable (up to token limit)
 Buffer: Token storage
 Burst Control: Allows bursts up to bucket size

Advantages:

 Allows controlled bursts

 Flexible traffic shaping
 Supports variable packet sizes
 Better utilization of available bandwidth
 Can handle different QoS requirements

Disadvantages:

 More complex than leaky bucket

 May allow temporary congestion
 Requires token management overhead

Example Scenario:

Bucket Size: 10 tokens

Token Rate: 5 tokens per second
Current Tokens: 8

Time Packet Size Tokens Before Action Tokens After

0 3 8 Transmit 5
0.2 6 6 Transmit 0
0.4 4 2 Queue/Discard 2
0.6 2 3 Transmit 1

4.5.3 Comparison: Leaky Bucket vs Token Bucket

Aspect Leaky Bucket Token Bucket

Output Rate Constant Variable (up to limit)
Burst Handling Smooths bursts Allows controlled bursts
Packet Size Typically fixed Variable sizes supported
Buffer Overflow Discards packets Queues packets (if buffer available)
Implementation Simpler More complex
Flexibility Less flexible More flexible
Use Case Constant rate enforcement Bandwidth allocation with burst allowance

4.5.4 Combined Approach: Leaky Bucket + Token Bucket

Some systems use both algorithms in combination:

1. Token Bucket: Controls the input rate and allows bursts

2. Leaky Bucket: Smooths the output from token bucket
Benefits:

 Combines advantages of both approaches

 Allows controlled bursts while ensuring smooth output
 Provides multiple levels of traffic control

4.6 Congestion Detection Methods

1. Implicit Detection

 Packet Loss: Timeout or duplicate ACKs

 Increased Delay: Round-trip time measurements
 Reduced Throughput: Effective data rate monitoring

2. Explicit Detection

 ECN (Explicit Congestion Notification): Routers mark packets

 ICMP Source Quench: Routers send explicit feedback
 ATM Rate-Based Control: Explicit rate information

4.7 Fairness in Congestion Control

Types of Fairness

1. Max-Min Fairness: Maximize minimum allocation

2. Proportional Fairness: Allocate proportional to demands
3. TCP Fairness: Equal sharing among TCP connections

Measuring Fairness

Jain's Fairness Index:

F = (Σxi)² / (n × Σxi²)

Where:

 xi = throughput of connection i
 n = number of connections
 F ranges from 0 to 1 (1 = perfectly fair)