Network Fundamentals - Learning Module

Loading content...

0/228

Network Resources

The Resources Networks Provide

Networks are not merely conduits for moving bits—they are shared resource systems providing bandwidth, connectivity, storage, and computational capabilities to many simultaneous users. Understanding network resources—their nature, how they're shared, and how conflicts are resolved—is fundamental to network design, operation, and application development.

When you stream a video while your neighbor downloads files while a business runs video conferences, the same network infrastructure serves all. How does this work? How are resources allocated? What happens when demand exceeds supply?

Learning Objectives

By the end of this page, you will:

• Identify the key resources that networks provide • Understand bandwidth, capacity, and throughput distinctions • Explain resource sharing mechanisms and their trade-offs • Analyze Quality of Service (QoS) concepts and implementations • Apply resource concepts to network capacity planning and troubleshooting

Types of Network Resources

Networks provide and manage several distinct types of resources. Each resource type has unique characteristics, constraints, and management challenges.

Network Resource Types
Resource	Description	Measurement	Scarcity Impact
Bandwidth	Data transmission capacity of links	bps (bits per second)	Congestion, delays, dropped packets
Buffer Memory	Temporary storage in network devices	Bytes, packets	Packet loss when buffers overflow
Processing Power	CPU cycles in devices for packet processing	Packets per second, CPU %	Forwarding delays, device overload
Addresses	IP addresses, port numbers, MAC addresses	Count of available	Address exhaustion (IPv4), NAT required
Connectivity	Physical/logical paths between locations	Paths, uptime	Unreachability if paths fail
Time/Slots	Time-division access in shared media	Microseconds, slots	Collision, access delays (WiFi)

Bandwidth: The Primary Resource

Bandwidth is typically the most visible and constrained network resource. It's important to distinguish related but different concepts:

Bandwidth (Capacity):

Theoretical maximum data rate of a link
Determined by physical medium, encoding, equipment
Example: A Gigabit Ethernet link has 1 Gbps bandwidth

Throughput (Actual):

Real data rate achieved in practice
Always less than bandwidth due to overhead, congestion, errors
Example: A 1 Gbps link might achieve 900 Mbps throughput for TCP

Goodput (Application):

Actual useful data rate at application level
Excludes protocol overhead, retransmissions
Example: 900 Mbps throughput with 10% overhead = 810 Mbps goodput

The distinction matters: A user expects to download at link speed but actually receives goodput—potentially much less than the advertised bandwidth.

Factors Reducing Throughput Below Bandwidth

•Protocol Overhead — Headers consume bandwidth. TCP/IP adds 40+ bytes per packet; for small packets, overhead can be substantial.
•Congestion — Competing traffic reduces available capacity. Shared links rarely provide full bandwidth to one user.
•Latency — TCP throughput is bounded by bandwidth-delay product. High latency limits TCP performance regardless of bandwidth.
•Packet Loss — Lost packets require retransmission, consuming additional bandwidth and reducing effective throughput.
•Flow/Congestion Control — TCP intentionally limits sending rate to prevent overwhelming network.
•Half-Duplex — WiFi can only send OR receive, not both simultaneously, halving effective throughput for bidirectional transfer.

The Bandwidth-Delay Product

The Bandwidth-Delay Product (BDP) is the amount of data 'in flight' on a link:

BDP = Bandwidth × Round-Trip Time

Example: 100 Mbps link with 50ms RTT: BDP = 100 Mbps × 0.050s = 5 Mbits = 625 KB

TCP windows must be at least this large to fully utilize the link. This is why high-bandwidth, high-latency links (transcontinental fiber) require special TCP tuning.

Resource Sharing Mechanisms

Networks are fundamentally shared resources. Unlike dedicated point-to-point connections, modern networks allow many users to share the same infrastructure. This sharing dramatically reduces cost but creates resource allocation challenges.

Circuit Switching

•Dedicated path for each communication
•Reserved resources throughout duration
•Guaranteed capacity once connected
•Inefficient when idle—resources wasted
•Example: Traditional telephone networks
•Analogy: Reserved highway lane

Packet Switching

•Shared paths among all users
•No reservation — on-demand allocation
•Statistical multiplexing improves efficiency
•Variable performance based on load
•Example: The Internet
•Analogy: Shared highway with traffic

Statistical Multiplexing:

Packet switching exploits statistical multiplexing—the observation that not all users need resources simultaneously:

A user browses web pages: Short bursts of traffic, long idle periods
100 users with 10 Mbps peak each might only need 100 Mbps shared (not 1000 Mbps)
As user count grows, statistical averaging improves efficiency

Example Calculation:

Assume each user:

Has 10 Mbps access
Is actively transmitting 10% of the time
Total capacity needed = Number of users × 10 Mbps × 0.1 = 1 Mbps average per user

With 1000 users:

Peak theoretically possible: 10,000 Mbps
Average expected: 1,000 Mbps
With 2,000 Mbps capacity, excellent service is likely

This dramatic efficiency gain makes the shared Internet economically viable. Dedicated 10 Mbps per user would be prohibitively expensive.

The Trade-Off: Statistical multiplexing provides efficiency but not guarantees. When many users are simultaneously active, congestion occurs. This is the fundamental nature of shared networks.

Oversubscription

Network providers oversubscribe—they sell more capacity than they physically have, betting on statistical multiplexing. An ISP selling '100 Mbps' to 1000 customers doesn't have 100 Gbps of upstream capacity—they might have 10 Gbps, assuming most users are idle most of the time.

This usually works. But during peak hours or unusual events (everyone working from home during a pandemic), oversubscription leads to congestion. Understanding this explains why 'my Internet is slow in the evening.'

Congestion: When Demand Exceeds Supply

Congestion occurs when network demand exceeds available capacity. It's the inevitable consequence of shared resources and is one of the most significant challenges in network design and operation.

Symptoms of Congestion

•Increased Latency — Packets wait in queues, adding delay. A 5ms link becomes 500ms at congestion.
•Packet Loss — When buffers overflow, incoming packets are dropped. TCP retransmits, UDP loses data.
•Reduced Throughput — Even though link is 'full,' actual goodput drops due to retransmissions and overhead.
•Jitter — Variable delays cause inconsistent packet arrival. Disruptive for real-time applications.
•Timeout Failures — Applications expecting quick responses may fail entirely.
•Congestion Collapse — In extreme cases, throughput approaches zero as the network spends all capacity on failed transmissions.

Congestion Control Mechanisms:

TCP Congestion Control: TCP actively adjusts sending rate to avoid congestion:

Slow Start — Begin slowly, double window each RTT until loss
Congestion Avoidance — After reaching threshold, increase linearly
Congestion Detection — Packet loss or increased RTT signals congestion
Rate Reduction — Halve window on congestion, restart growth

Algorithms:

TCP Reno — Classic, widely deployed, conservative
TCP Cubic — Default on Linux, better for high-BDP networks
TCP BBR — Google's algorithm, estimates bandwidth/RTT, more aggressive

Network-Based Control:

Random Early Detection (RED) — Routers proactively drop packets before buffers fill, signaling senders to slow
Explicit Congestion Notification (ECN) — Routers mark packets to signal congestion without dropping
Traffic Shaping — Devices enforce rate limits, smoothing bursts

congestion-visualization
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
"""
Simplified TCP Congestion Control Simulation
Demonstrates slow start and congestion avoidance
"""
 
class SimpleTCPCongestionControl:
    def __init__(self):
        self.cwnd = 1  # Congestion window (MSS units)
        self.ssthresh = 64  # Slow start threshold
        self.phase = "slow_start"
        self.history = []
    
    def on_ack_received(self):
        """Called when ACK is received (successful transmission)"""
        if self.phase == "slow_start":
            # Exponential growth: double window
            self.cwnd += 1  # For each ACK, increase by 1 MSS
            if self.cwnd >= self.ssthresh:
                self.phase = "congestion_avoidance"
        else:
            # Linear growth: increase by 1/cwnd per ACK
            # Net effect: +1 MSS per RTT
            self.cwnd += 1 / self.cwnd
        
        self.history.append(('ack', self.cwnd, self.phase))
    
    def on_packet_loss(self):
        """Called when packet loss is detected"""
        # Multiplicative decrease
        self.ssthresh = max(self.cwnd / 2, 2)
        self.cwnd = 1  # Restart slow start (TCP Tahoe style)
        self.phase = "slow_start"
        self.history.append(('loss', self.cwnd, self.phase))
 
# Simulate 20 successful transmissions, then a loss
cc = SimpleTCPCongestionControl()
 
print("Simulation: 20 ACKs, then loss, then 10 more ACKs")
print("-" * 50)
 
for i in range(20):
    cc.on_ack_received()
    print(f"ACK {i+1}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")
 
print("\n*** PACKET LOSS DETECTED ***\n")
cc.on_packet_loss()
print(f"After loss: cwnd = {cc.cwnd:.2f}, ssthresh = {cc.ssthresh:.2f}")
print()
 
for i in range(10):
    cc.on_ack_received()
    print(f"ACK {i+21}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")

Fairness in Congestion Control

TCP congestion control is designed to be fair—multiple flows sharing a bottleneck should each get approximately equal share. However, 'fair' is nuanced:

• UDP doesn't respond to congestion—it can starve TCP flows • Some TCP variants are more aggressive than others • Short flows never exit slow start, getting less than long flows • Flows with different RTTs get different shares (RTT-unfairness)

Despite imperfections, TCP's congestion control has kept the Internet stable for decades.

Quality of Service (QoS)

Quality of Service (QoS) refers to mechanisms that provide differentiated treatment to different types of traffic. Instead of treating all packets equally (best-effort), QoS enables prioritization based on application needs.

QoS Parameters

•Bandwidth — Guaranteed or maximum data rate for a traffic class
•Latency — Maximum acceptable delay from source to destination
•Jitter — Maximum variation in latency between packets
•Packet Loss — Maximum acceptable percentage of dropped packets
•Availability — Percentage of time service is operational

QoS Requirements by Application Type
Application	Bandwidth	Latency	Jitter	Loss Tolerance
VoIP	Low (100 Kbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Conference	Medium (2-10 Mbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Streaming	High (5-25 Mbps)	Moderate (buffering)	Moderate	Very Low
Online Gaming	Low-Medium	Critical (<50ms)	Critical	Medium
Web Browsing	Variable	Noticeable (but tolerate)	Not critical	Must retry
File Transfer	As available	Not critical	Not critical	Zero (TCP ensures)
Email	Low	Minutes acceptable	Not applicable	Zero (TCP)

QoS Mechanisms:

Traffic Classification:

Identify traffic type by port, protocol, source, deep packet inspection
Mark packets with priority (DSCP field in IP header, 802.1p in Ethernet)
Classes: EF (Expedited Forwarding), AF (Assured Forwarding), BE (Best Effort)

Traffic Shaping:

Enforce rate limits per class
Smooth bursts to prevent congestion
Token bucket: Allow bursts up to bucket size, then rate-limit

Queuing Disciplines:

FIFO — First-in-first-out, no differentiation
Priority Queuing — High-priority always before low (starvation risk)
Weighted Fair Queuing (WFQ) — Proportional bandwidth allocation
Class-Based WFQ — WFQ with defined classes and weights

Admission Control:

Reject new flows if accepting would degrade existing service quality
Common in VoIP systems: limit concurrent calls based on bandwidth

QoS End-to-End Challenge

QoS only works when enforced everywhere along the path. Your enterprise can prioritize VoIP, but once traffic leaves your network to the ISP, those markings may be ignored or re-marked. The public Internet is largely best-effort—which is why real-time applications use adaptive techniques (buffering, quality switching) rather than relying on QoS guarantees.

Address Space as a Resource

IP addresses are a finite resource—perhaps the most constrained in modern networking. The IPv4 address space exhaustion and the transition to IPv6 represent one of the largest infrastructure changes in Internet history.

IPv4 vs IPv6 Address Space
Characteristic	IPv4	IPv6
Address Size	32 bits	128 bits
Total Addresses	~4.3 billion	~340 undecillion (3.4×10³⁸)
Format	Dotted decimal (192.168.1.1)	Hexadecimal (2001:db8::1)
Status	Exhausted globally	Vast availability
Private Addresses	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	fc00::/7 (ULA)
Broadcast	Supported	Replaced by multicast

The IPv4 Exhaustion Crisis:

The Internet's architects in the 1970s allocated 32-bit addresses, believing 4.3 billion addresses would be plenty. They were wrong:

Timeline:

1981: IPv4 formalized
1990s: Rapid Internet growth consumes addresses
2011: IANA exhausts its pool
2015-2019: Regional registries exhaust pools
Today: IPv4 addresses are traded; some worth $50+ each

Mitigation Strategies:

Network Address Translation (NAT):

Multiple devices share one public IP
Private-to-public address mapping
Extends IPv4 lifetime significantly
Drawbacks: Breaks end-to-end principle, complicates protocols

Classless Inter-Domain Routing (CIDR):

Variable-length subnet masks
More efficient address allocation
Replaced wasteful classful addressing

IPv6 Deployment:

Long-term solution
Adoption growing but slow (>40% of Google traffic now IPv6)
Dual-stack deployment common during transition

Why IPv6 Adoption is Slow

Despite being standardized in 1998, IPv6 adoption took decades because:

• IPv6 is not backward compatible—requires parallel infrastructure • NAT 'solved' the immediate problem, reducing urgency • Costs of dual-stack outweigh benefits for many organizations • No compelling features for users—speed/security arguments weak

Adoption accelerated when mobile operators (needing massive address space) and large content providers (Google, Facebook) deployed IPv6, creating critical mass.

Network Services as Resources

Beyond raw connectivity, networks provide services that are themselves shared resources. These services have capacity limits and require management.

Network Services as Resources

•DNS Resolution Capacity — DNS servers have query limits. Under DDoS attack, DNS can become the bottleneck preventing all name resolution.
•DHCP Address Pools — Limited pool of dynamic addresses. Exhausted pools prevent new device connections.
•NAT Translation Tables — Each NAT device has finite memory for translation entries. High connection counts can exhaust tables.
•Firewall State Tables — Stateful firewalls track connections. Connection flooding attacks exhaust state, blocking legitimate traffic.
•VPN Tunnel Capacity — VPN concentrators have concurrent tunnel limits. Exceeded during mass remote-work events.
•Load Balancer Capacity — Connection handling, SSL termination have limits. Over-capacity means failed requests.

Service Resource Planning:

Network service capacity planning requires understanding:

Baseline Load:

What's normal traffic? Peak times?
How many concurrent users/connections?

Growth Projections:

How is usage increasing?
Planned new applications?

Headroom:

How much spare capacity for unexpected spikes?
Typical target: 70% utilization at peak

Failure Modes:

What happens when capacity is exceeded?
Graceful degradation vs. total failure?

Scaling Strategy:

Vertical (bigger device) vs. horizontal (more devices)
Lead time for procurement/deployment

The Cloud Scaling Illusion

Cloud services create an illusion of infinite resources—'just spin up more instances.' In reality:

• Cloud regions have physical capacity limits • Quotas limit individual account usage • Scaling takes time (seconds to minutes) • Costs grow with usage (potentially dramatically)

Even in the cloud, capacity planning remains essential. The model changes from 'buy equipment' to 'manage costs and quotas.'

Monitoring and Managing Resources

Effective resource management requires visibility. Network monitoring provides data for capacity planning, troubleshooting, and optimization.

Network Monitoring Approaches
Method	What It Measures	Tools	Use Case
SNMP Polling	Device counters (bytes, errors, CPU)	Cacti, Nagios, PRTG	Capacity trends, health dashboards
Flow Analysis	Traffic patterns (source, dest, protocol)	NetFlow, sFlow, ntopng	Who's using bandwidth? What protocols?
Packet Capture	Full packet contents	Wireshark, tcpdump	Deep troubleshooting, forensics
Synthetic Probing	Simulated transactions	Smokeping, ThousandEyes	Application experience, SLA verification
Log Analysis	Event records from devices	ELK stack, Splunk	Security, troubleshooting, audit
APM	Application-level metrics	New Relic, Datadog, Dynatrace	End-user experience, service dependencies

Key Metrics to Monitor:

Bandwidth/Utilization:

Interface traffic in/out (bps)
Utilization percentage
Trend over time

Latency:

Round-trip time to key destinations
Jitter (latency variation)
Path latency decomposition

Errors:

Interface errors (CRC, collisions, drops)
Protocol errors (TCP retransmissions)
Device errors (CPU overload, memory usage)

Availability:

Service uptime percentage
Mean time between failures (MTBF)
Mean time to recovery (MTTR)

Session Counts:

Active connections
Connection rate (new connections/second)
NAT table utilization

bandwidth-monitor
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
"""
Simple bandwidth utilization calculation from SNMP counters
Demonstrates fundamental network monitoring concepts
"""
 
from datetime import datetime
from dataclasses import dataclass
 
@dataclass
class InterfaceCounters:
    """SNMP counter values at a point in time"""
    timestamp: datetime
    if_in_octets: int  # Bytes received
    if_out_octets: int  # Bytes transmitted
    interface_speed: int  # Interface speed in bps
 
def calculate_utilization(prev: InterfaceCounters, 
                          curr: InterfaceCounters) -> dict:
    """
    Calculate bandwidth utilization between two measurement points
    """
    time_delta = (curr.timestamp - prev.timestamp).total_seconds()
    
    if time_delta <= 0:
        raise ValueError("Time delta must be positive")
    
    # Calculate bits transferred (counter difference × 8)
    in_bits = (curr.if_in_octets - prev.if_in_octets) * 8
    out_bits = (curr.if_out_octets - prev.if_out_octets) * 8
    
    # Calculate rates (bits per second)
    in_bps = in_bits / time_delta
    out_bps = out_bits / time_delta
    
    # Calculate utilization percentage
    in_util = (in_bps / curr.interface_speed) * 100
    out_util = (out_bps / curr.interface_speed) * 100
    
    return {
        'interval_seconds': time_delta,
        'in_bps': in_bps,
        'out_bps': out_bps,
        'in_mbps': in_bps / 1_000_000,
        'out_mbps': out_bps / 1_000_000,
        'in_utilization_pct': in_util,
        'out_utilization_pct': out_util
    }
 
# Example: 1 Gbps interface, 5-minute polling interval
interface_speed = 1_000_000_000  # 1 Gbps
 
sample_1 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 0, 0),
    if_in_octets=1_000_000_000,
    if_out_octets=500_000_000,
    interface_speed=interface_speed
)
 
sample_2 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 5, 0),  # 5 minutes later
    if_in_octets=1_450_000_000,  # 450 MB received
    if_out_octets=650_000_000,   # 150 MB sent
    interface_speed=interface_speed
)
 
result = calculate_utilization(sample_1, sample_2)
 
print("Interface Utilization Report")
print("=" * 40)
print(f"Interval: {result['interval_seconds']:.0f} seconds")
print(f"Inbound:  {result['in_mbps']:.2f} Mbps ({result['in_utilization_pct']:.1f}%)")
print(f"Outbound: {result['out_mbps']:.2f} Mbps ({result['out_utilization_pct']:.1f}%)")

Alerting Strategy

Don't just monitor—alert on actionable conditions:

• Utilization >80% — Warning; may hit capacity • Utilization >90% — Critical; likely causing issues • Sudden drops — Possible failure • Error rates increasing — Hardware or cable issues • Latency increases — Congestion or path changes

Avoid alert fatigue: Too many false positives cause real alerts to be ignored.

Summary: Network Resources

Networks are shared resource systems providing bandwidth, connectivity, addresses, and services to many simultaneous users. Understanding resource characteristics, sharing mechanisms, and management techniques is essential for network design, operation, and troubleshooting.

Key Takeaways

•Resource Types — Networks provide bandwidth, buffer memory, processing power, addresses, connectivity, and time/slots as resources.
•Bandwidth Concepts — Distinguish bandwidth (capacity), throughput (actual), and goodput (application-level). Many factors reduce actual performance below theoretical capacity.
•Resource Sharing — Packet switching enables statistical multiplexing, dramatically improving efficiency over dedicated circuits. Oversubscription is standard but creates congestion risk.
•Congestion — When demand exceeds supply: increased latency, packet loss, reduced throughput. TCP congestion control is the Internet's primary defense.
•Quality of Service — QoS mechanisms prioritize traffic based on requirements. Effective only when applied end-to-end, challenging on the public Internet.
•Address Resources — IP addresses are finite. IPv4 exhaustion led to NAT and drives IPv6 adoption. Address management is operational reality.
•Monitoring — Visibility into resource utilization enables capacity planning, troubleshooting, and optimization. Multiple approaches suit different needs.

Module Complete:

With this page, you've completed Module 1: Network Fundamentals. You now possess a solid foundation in:

What networks are (definition and characteristics)
What they're made of (components)
What they do (applications)
How they work (communication model)
What they provide (resources)

This foundation prepares you for deeper exploration of the Internet, protocols, network models, and the layered architecture that makes modern networking possible.

Module 1 Complete

Congratulations! You've completed the Network Fundamentals module. You now have a comprehensive understanding of what computer networks are, how they're structured, what applications they serve, how communication occurs, and how resources are managed. This foundation will support everything you learn in subsequent modules about protocols, architectures, and implementation.

Network Resources

The Resources Networks Provide

Learning Objectives

By the end of this page, you will:

Types of Network Resources

Networks provide and manage several distinct types of resources. Each resource type has unique characteristics, constraints, and management challenges.

Network Resource Types
Resource	Description	Measurement	Scarcity Impact
Bandwidth	Data transmission capacity of links	bps (bits per second)	Congestion, delays, dropped packets
Buffer Memory	Temporary storage in network devices	Bytes, packets	Packet loss when buffers overflow
Processing Power	CPU cycles in devices for packet processing	Packets per second, CPU %	Forwarding delays, device overload
Addresses	IP addresses, port numbers, MAC addresses	Count of available	Address exhaustion (IPv4), NAT required
Connectivity	Physical/logical paths between locations	Paths, uptime	Unreachability if paths fail
Time/Slots	Time-division access in shared media	Microseconds, slots	Collision, access delays (WiFi)

Bandwidth: The Primary Resource

Bandwidth is typically the most visible and constrained network resource. It's important to distinguish related but different concepts:

Bandwidth (Capacity):

Theoretical maximum data rate of a link
Determined by physical medium, encoding, equipment
Example: A Gigabit Ethernet link has 1 Gbps bandwidth

Throughput (Actual):

Real data rate achieved in practice
Always less than bandwidth due to overhead, congestion, errors
Example: A 1 Gbps link might achieve 900 Mbps throughput for TCP

Goodput (Application):

Actual useful data rate at application level
Excludes protocol overhead, retransmissions
Example: 900 Mbps throughput with 10% overhead = 810 Mbps goodput

The distinction matters: A user expects to download at link speed but actually receives goodput—potentially much less than the advertised bandwidth.

Factors Reducing Throughput Below Bandwidth

•Protocol Overhead — Headers consume bandwidth. TCP/IP adds 40+ bytes per packet; for small packets, overhead can be substantial.
•Congestion — Competing traffic reduces available capacity. Shared links rarely provide full bandwidth to one user.
•Latency — TCP throughput is bounded by bandwidth-delay product. High latency limits TCP performance regardless of bandwidth.
•Packet Loss — Lost packets require retransmission, consuming additional bandwidth and reducing effective throughput.
•Flow/Congestion Control — TCP intentionally limits sending rate to prevent overwhelming network.
•Half-Duplex — WiFi can only send OR receive, not both simultaneously, halving effective throughput for bidirectional transfer.

The Bandwidth-Delay Product

The Bandwidth-Delay Product (BDP) is the amount of data 'in flight' on a link:

BDP = Bandwidth × Round-Trip Time

Example: 100 Mbps link with 50ms RTT: BDP = 100 Mbps × 0.050s = 5 Mbits = 625 KB

TCP windows must be at least this large to fully utilize the link. This is why high-bandwidth, high-latency links (transcontinental fiber) require special TCP tuning.

Resource Sharing Mechanisms

Circuit Switching

•Dedicated path for each communication
•Reserved resources throughout duration
•Guaranteed capacity once connected
•Inefficient when idle—resources wasted
•Example: Traditional telephone networks
•Analogy: Reserved highway lane

Packet Switching

•Shared paths among all users
•No reservation — on-demand allocation
•Statistical multiplexing improves efficiency
•Variable performance based on load
•Example: The Internet
•Analogy: Shared highway with traffic

Statistical Multiplexing:

Packet switching exploits statistical multiplexing—the observation that not all users need resources simultaneously:

A user browses web pages: Short bursts of traffic, long idle periods
100 users with 10 Mbps peak each might only need 100 Mbps shared (not 1000 Mbps)
As user count grows, statistical averaging improves efficiency

Example Calculation:

Assume each user:

Has 10 Mbps access
Is actively transmitting 10% of the time
Total capacity needed = Number of users × 10 Mbps × 0.1 = 1 Mbps average per user

With 1000 users:

Peak theoretically possible: 10,000 Mbps
Average expected: 1,000 Mbps
With 2,000 Mbps capacity, excellent service is likely

This dramatic efficiency gain makes the shared Internet economically viable. Dedicated 10 Mbps per user would be prohibitively expensive.

The Trade-Off: Statistical multiplexing provides efficiency but not guarantees. When many users are simultaneously active, congestion occurs. This is the fundamental nature of shared networks.

Oversubscription

Congestion: When Demand Exceeds Supply

Symptoms of Congestion

•Increased Latency — Packets wait in queues, adding delay. A 5ms link becomes 500ms at congestion.
•Packet Loss — When buffers overflow, incoming packets are dropped. TCP retransmits, UDP loses data.
•Reduced Throughput — Even though link is 'full,' actual goodput drops due to retransmissions and overhead.
•Jitter — Variable delays cause inconsistent packet arrival. Disruptive for real-time applications.
•Timeout Failures — Applications expecting quick responses may fail entirely.
•Congestion Collapse — In extreme cases, throughput approaches zero as the network spends all capacity on failed transmissions.

Congestion Control Mechanisms:

TCP Congestion Control: TCP actively adjusts sending rate to avoid congestion:

Slow Start — Begin slowly, double window each RTT until loss
Congestion Avoidance — After reaching threshold, increase linearly
Congestion Detection — Packet loss or increased RTT signals congestion
Rate Reduction — Halve window on congestion, restart growth

Algorithms:

TCP Reno — Classic, widely deployed, conservative
TCP Cubic — Default on Linux, better for high-BDP networks
TCP BBR — Google's algorithm, estimates bandwidth/RTT, more aggressive

Network-Based Control:

Random Early Detection (RED) — Routers proactively drop packets before buffers fill, signaling senders to slow
Explicit Congestion Notification (ECN) — Routers mark packets to signal congestion without dropping
Traffic Shaping — Devices enforce rate limits, smoothing bursts

congestion-visualization
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
"""
Simplified TCP Congestion Control Simulation
Demonstrates slow start and congestion avoidance
"""
 
class SimpleTCPCongestionControl:
    def __init__(self):
        self.cwnd = 1  # Congestion window (MSS units)
        self.ssthresh = 64  # Slow start threshold
        self.phase = "slow_start"
        self.history = []
    
    def on_ack_received(self):
        """Called when ACK is received (successful transmission)"""
        if self.phase == "slow_start":
            # Exponential growth: double window
            self.cwnd += 1  # For each ACK, increase by 1 MSS
            if self.cwnd >= self.ssthresh:
                self.phase = "congestion_avoidance"
        else:
            # Linear growth: increase by 1/cwnd per ACK
            # Net effect: +1 MSS per RTT
            self.cwnd += 1 / self.cwnd
        
        self.history.append(('ack', self.cwnd, self.phase))
    
    def on_packet_loss(self):
        """Called when packet loss is detected"""
        # Multiplicative decrease
        self.ssthresh = max(self.cwnd / 2, 2)
        self.cwnd = 1  # Restart slow start (TCP Tahoe style)
        self.phase = "slow_start"
        self.history.append(('loss', self.cwnd, self.phase))
 
# Simulate 20 successful transmissions, then a loss
cc = SimpleTCPCongestionControl()
 
print("Simulation: 20 ACKs, then loss, then 10 more ACKs")
print("-" * 50)
 
for i in range(20):
    cc.on_ack_received()
    print(f"ACK {i+1}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")
 
print("\n*** PACKET LOSS DETECTED ***\n")
cc.on_packet_loss()
print(f"After loss: cwnd = {cc.cwnd:.2f}, ssthresh = {cc.ssthresh:.2f}")
print()
 
for i in range(10):
    cc.on_ack_received()
    print(f"ACK {i+21}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")

Fairness in Congestion Control

TCP congestion control is designed to be fair—multiple flows sharing a bottleneck should each get approximately equal share. However, 'fair' is nuanced:

Despite imperfections, TCP's congestion control has kept the Internet stable for decades.

Quality of Service (QoS)

QoS Parameters

•Bandwidth — Guaranteed or maximum data rate for a traffic class
•Latency — Maximum acceptable delay from source to destination
•Jitter — Maximum variation in latency between packets
•Packet Loss — Maximum acceptable percentage of dropped packets
•Availability — Percentage of time service is operational

QoS Requirements by Application Type
Application	Bandwidth	Latency	Jitter	Loss Tolerance
VoIP	Low (100 Kbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Conference	Medium (2-10 Mbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Streaming	High (5-25 Mbps)	Moderate (buffering)	Moderate	Very Low
Online Gaming	Low-Medium	Critical (<50ms)	Critical	Medium
Web Browsing	Variable	Noticeable (but tolerate)	Not critical	Must retry
File Transfer	As available	Not critical	Not critical	Zero (TCP ensures)
Email	Low	Minutes acceptable	Not applicable	Zero (TCP)

QoS Mechanisms:

Traffic Classification:

Identify traffic type by port, protocol, source, deep packet inspection
Mark packets with priority (DSCP field in IP header, 802.1p in Ethernet)
Classes: EF (Expedited Forwarding), AF (Assured Forwarding), BE (Best Effort)

Traffic Shaping:

Enforce rate limits per class
Smooth bursts to prevent congestion
Token bucket: Allow bursts up to bucket size, then rate-limit

Queuing Disciplines:

FIFO — First-in-first-out, no differentiation
Priority Queuing — High-priority always before low (starvation risk)
Weighted Fair Queuing (WFQ) — Proportional bandwidth allocation
Class-Based WFQ — WFQ with defined classes and weights

Admission Control:

Reject new flows if accepting would degrade existing service quality
Common in VoIP systems: limit concurrent calls based on bandwidth

QoS End-to-End Challenge

Address Space as a Resource

IPv4 vs IPv6 Address Space
Characteristic	IPv4	IPv6
Address Size	32 bits	128 bits
Total Addresses	~4.3 billion	~340 undecillion (3.4×10³⁸)
Format	Dotted decimal (192.168.1.1)	Hexadecimal (2001:db8::1)
Status	Exhausted globally	Vast availability
Private Addresses	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	fc00::/7 (ULA)
Broadcast	Supported	Replaced by multicast

The IPv4 Exhaustion Crisis:

The Internet's architects in the 1970s allocated 32-bit addresses, believing 4.3 billion addresses would be plenty. They were wrong:

Timeline:

1981: IPv4 formalized
1990s: Rapid Internet growth consumes addresses
2011: IANA exhausts its pool
2015-2019: Regional registries exhaust pools
Today: IPv4 addresses are traded; some worth $50+ each

Mitigation Strategies:

Network Address Translation (NAT):

Multiple devices share one public IP
Private-to-public address mapping
Extends IPv4 lifetime significantly
Drawbacks: Breaks end-to-end principle, complicates protocols

Classless Inter-Domain Routing (CIDR):

Variable-length subnet masks
More efficient address allocation
Replaced wasteful classful addressing

IPv6 Deployment:

Long-term solution
Adoption growing but slow (>40% of Google traffic now IPv6)
Dual-stack deployment common during transition

Why IPv6 Adoption is Slow

Despite being standardized in 1998, IPv6 adoption took decades because:

Adoption accelerated when mobile operators (needing massive address space) and large content providers (Google, Facebook) deployed IPv6, creating critical mass.

Network Services as Resources

Beyond raw connectivity, networks provide services that are themselves shared resources. These services have capacity limits and require management.

Network Services as Resources

•DNS Resolution Capacity — DNS servers have query limits. Under DDoS attack, DNS can become the bottleneck preventing all name resolution.
•DHCP Address Pools — Limited pool of dynamic addresses. Exhausted pools prevent new device connections.
•NAT Translation Tables — Each NAT device has finite memory for translation entries. High connection counts can exhaust tables.
•Firewall State Tables — Stateful firewalls track connections. Connection flooding attacks exhaust state, blocking legitimate traffic.
•VPN Tunnel Capacity — VPN concentrators have concurrent tunnel limits. Exceeded during mass remote-work events.
•Load Balancer Capacity — Connection handling, SSL termination have limits. Over-capacity means failed requests.

Service Resource Planning:

Network service capacity planning requires understanding:

Baseline Load:

What's normal traffic? Peak times?
How many concurrent users/connections?

Growth Projections:

How is usage increasing?
Planned new applications?

Headroom:

How much spare capacity for unexpected spikes?
Typical target: 70% utilization at peak

Failure Modes:

What happens when capacity is exceeded?
Graceful degradation vs. total failure?

Scaling Strategy:

Vertical (bigger device) vs. horizontal (more devices)
Lead time for procurement/deployment

The Cloud Scaling Illusion

Cloud services create an illusion of infinite resources—'just spin up more instances.' In reality:

• Cloud regions have physical capacity limits • Quotas limit individual account usage • Scaling takes time (seconds to minutes) • Costs grow with usage (potentially dramatically)

Even in the cloud, capacity planning remains essential. The model changes from 'buy equipment' to 'manage costs and quotas.'

Monitoring and Managing Resources

Effective resource management requires visibility. Network monitoring provides data for capacity planning, troubleshooting, and optimization.

Network Monitoring Approaches
Method	What It Measures	Tools	Use Case
SNMP Polling	Device counters (bytes, errors, CPU)	Cacti, Nagios, PRTG	Capacity trends, health dashboards
Flow Analysis	Traffic patterns (source, dest, protocol)	NetFlow, sFlow, ntopng	Who's using bandwidth? What protocols?
Packet Capture	Full packet contents	Wireshark, tcpdump	Deep troubleshooting, forensics
Synthetic Probing	Simulated transactions	Smokeping, ThousandEyes	Application experience, SLA verification
Log Analysis	Event records from devices	ELK stack, Splunk	Security, troubleshooting, audit
APM	Application-level metrics	New Relic, Datadog, Dynatrace	End-user experience, service dependencies

Key Metrics to Monitor:

Bandwidth/Utilization:

Interface traffic in/out (bps)
Utilization percentage
Trend over time

Latency:

Round-trip time to key destinations
Jitter (latency variation)
Path latency decomposition

Errors:

Interface errors (CRC, collisions, drops)
Protocol errors (TCP retransmissions)
Device errors (CPU overload, memory usage)

Availability:

Service uptime percentage
Mean time between failures (MTBF)
Mean time to recovery (MTTR)

Session Counts:

Active connections
Connection rate (new connections/second)
NAT table utilization

bandwidth-monitor
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
"""
Simple bandwidth utilization calculation from SNMP counters
Demonstrates fundamental network monitoring concepts
"""
 
from datetime import datetime
from dataclasses import dataclass
 
@dataclass
class InterfaceCounters:
    """SNMP counter values at a point in time"""
    timestamp: datetime
    if_in_octets: int  # Bytes received
    if_out_octets: int  # Bytes transmitted
    interface_speed: int  # Interface speed in bps
 
def calculate_utilization(prev: InterfaceCounters, 
                          curr: InterfaceCounters) -> dict:
    """
    Calculate bandwidth utilization between two measurement points
    """
    time_delta = (curr.timestamp - prev.timestamp).total_seconds()
    
    if time_delta <= 0:
        raise ValueError("Time delta must be positive")
    
    # Calculate bits transferred (counter difference × 8)
    in_bits = (curr.if_in_octets - prev.if_in_octets) * 8
    out_bits = (curr.if_out_octets - prev.if_out_octets) * 8
    
    # Calculate rates (bits per second)
    in_bps = in_bits / time_delta
    out_bps = out_bits / time_delta
    
    # Calculate utilization percentage
    in_util = (in_bps / curr.interface_speed) * 100
    out_util = (out_bps / curr.interface_speed) * 100
    
    return {
        'interval_seconds': time_delta,
        'in_bps': in_bps,
        'out_bps': out_bps,
        'in_mbps': in_bps / 1_000_000,
        'out_mbps': out_bps / 1_000_000,
        'in_utilization_pct': in_util,
        'out_utilization_pct': out_util
    }
 
# Example: 1 Gbps interface, 5-minute polling interval
interface_speed = 1_000_000_000  # 1 Gbps
 
sample_1 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 0, 0),
    if_in_octets=1_000_000_000,
    if_out_octets=500_000_000,
    interface_speed=interface_speed
)
 
sample_2 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 5, 0),  # 5 minutes later
    if_in_octets=1_450_000_000,  # 450 MB received
    if_out_octets=650_000_000,   # 150 MB sent
    interface_speed=interface_speed
)
 
result = calculate_utilization(sample_1, sample_2)
 
print("Interface Utilization Report")
print("=" * 40)
print(f"Interval: {result['interval_seconds']:.0f} seconds")
print(f"Inbound:  {result['in_mbps']:.2f} Mbps ({result['in_utilization_pct']:.1f}%)")
print(f"Outbound: {result['out_mbps']:.2f} Mbps ({result['out_utilization_pct']:.1f}%)")

Alerting Strategy

Don't just monitor—alert on actionable conditions:

Avoid alert fatigue: Too many false positives cause real alerts to be ignored.

Summary: Network Resources

Key Takeaways

•Resource Types — Networks provide bandwidth, buffer memory, processing power, addresses, connectivity, and time/slots as resources.
•Bandwidth Concepts — Distinguish bandwidth (capacity), throughput (actual), and goodput (application-level). Many factors reduce actual performance below theoretical capacity.
•Resource Sharing — Packet switching enables statistical multiplexing, dramatically improving efficiency over dedicated circuits. Oversubscription is standard but creates congestion risk.
•Congestion — When demand exceeds supply: increased latency, packet loss, reduced throughput. TCP congestion control is the Internet's primary defense.
•Quality of Service — QoS mechanisms prioritize traffic based on requirements. Effective only when applied end-to-end, challenging on the public Internet.
•Address Resources — IP addresses are finite. IPv4 exhaustion led to NAT and drives IPv6 adoption. Address management is operational reality.
•Monitoring — Visibility into resource utilization enables capacity planning, troubleshooting, and optimization. Multiple approaches suit different needs.

Module Complete:

With this page, you've completed Module 1: Network Fundamentals. You now possess a solid foundation in:

What networks are (definition and characteristics)
What they're made of (components)
What they do (applications)
How they work (communication model)
What they provide (resources)

This foundation prepares you for deeper exploration of the Internet, protocols, network models, and the layered architecture that makes modern networking possible.

Module 1 Complete